If you've ever signed up for one of the most popular password managers or even other services, you've probably noticed one commonality between them. They all ask for your email!
Now, it's standard practice to ask for it, especially for:
- Newsletters
- Recovery options
- Analytics, marketing, and cross-device syncing
But is it really necessary?
The Opaque Identity Alternative
The other design option is to generate an opaque identity for the user, an example would be a randomized string of characters. This choice puts a lot more emphasis on privacy of the user's PII (Personally Identifiable Information) and helps mitigate attacks like credential stuffing based on data leaks from other services.
Blocking Credential Stuffing
Credential stuffing is an attack method where attackers use old database leaks from other sites to try and break into new ones by testing email and password pairs. This is problematic because many people do reuse usernames/emails and passwords across different websites. But since your username is now a random string, a leaked email for that user doesn't meaningfully help an attacker. It breaks the link between your accounts on different websites.
Reducing Target Value
A database without emails is a much less attractive target for hackers. If the provider is breached, the thief doesn't get a valuable list of active emails to spam or sell. This builds more trust in the provider because they are intentionally choosing to hold LESS of your PII.
The Trade-offs
But like every other design, opaque identity comes with downsides too. That's why while increasing privacy and security this choice puts a lot more responsibility on the user to remember their login information.
Recovery options are affected too since you can't just send an email. One option is to generate a recovery key on signup that the user has to store somewhere safe.
Choosing the Right Model
Choosing between the email-based or opaque identity ultimately comes down to how secure your system needs to be. A simple forum account might not benefit much from the randomized username, but a password manager would gain more trust in the provider and would block a whole class of attacks.
In some designs we could go a step further and make the AccountId be the actual GUID of the account from the DB. If this identifier is generated as a sufficiently random value (e.g. a UUIDv4), account enumeration becomes impractical, as guessing valid identifiers is computationally infeasible.
Discussion
I am currently implementing this opaque identity model as part of my bachelor's thesis project. I'm curious to know what other developers think about this approach.
Is the security and privacy gain of an opaque AccountId worth the extra responsibility on the user? Or is the convenience of an email-based login too good to let go of?
Top comments (0)