Anonymous Login

Obviously we support anonymous connection. But that’s not the same as an anonymous login.

By “Anonymous login” we mean being able to login to a 3rd party website without revealing our username.

With Fenrir, that’s pretty simple.

The scenario

Let’s assume we are client@example.com, and we want to connect to a service at example.org

We want to connect to the 3rd party service, where we have an account, but we don’t want them to know that we are famous_guy@example.com, we like privacy and want to be treated like everyone else.

The motivations to avoid revealing your real account might be various. To name a few:

• avoid spam
• avoid account-specific limitations on example.org
• privacy

If the server uses the Fenrir database also for the mailserver, the anonymous account can be tied to a mail that is forwarded to your account. But does not have to.

Also, the mail forwarding can be enabled and then disabled – good luck spammers.

The shared data

Compared to the initial setup, as explained in the Federated Authentication article, the domain will need to store a little bit more data. So for every anonymous login, we now need one more thing: A unique (domain-wide) temporary identification.

If you have read the Federated Authentication, then the workflow should be pretty straightforward:

The workflow

The whole workflow is not that different from before. The only things that changes is that we now need the client to ask a new temporary identification to hide his identity.

The client will login with that identity, and that is all.

The anonymous identifications

Basically, this creates a new (anonymous) identification for every domain, for each client that requests it.

This new identification does not have to be intelligible, so we could reserve names such as: tmp-X2iLfSjtEE6kHDQs@example.com, but that would make it clear that we are using anonymous identifications.

To avoid that, prefixes and any static identification should be avoided, length should be random, only including [a-z] [A-Z] [0-9] and ‘.’ characters.

This could technically generate addresses that could be used by real users, but overlapping the two namespaces is the only solution to avoid easy identification.

Of course, advanced methods such as artificial intelligence training could be used to check whether the username is an anonymous or real one, but that increases the complexity to the point were most won’t even try.

In theory anonymous identifications could be changed, but Fenrir does not have (yet) any synchronization mechanism to report the change to authentication servers in other federations, so for now usernames are static.

Anonymous identifications should stay static to permit the users to limit the login authentications fromi one domain or from a predetermined set of usernames, making it much safer overall.

Dynamic usernames

Things would be much more flexible if we admitted dynamic usernames for the login, but that would open us a bit more to bruteforce attacks.

Worry not, I’ll talk about that in one of the next articles ;)

-Luker