Talk:Requests for comment/Login via e-mail address

Previous page history was archived for backup purposes at Talk:Requests for comment/Login via e-mail address/LQT Archive 1 on 2015-06-25.

Hello, We needed this on our wiki so I created a basic extension that implement it: https://www.mediawiki.org/wiki/Extension:EmailLogin (Note that it does not address many of the concerns raised in the RFC.)

This could be interesting... If I know someone else's email address and create an account with that email address as username, and set a random password, would that prevent the user sharing that email address to login via email? because that check would get an invalid password. Well, I guess that's what should be done, but the error message shouldn't be a plain "invalid password", otherwise the user may be confused if the password is actually correct.

I'm afraid not. Because current implementation will only accept emails that already have been authenticated. So although someone have made an account with already-known email address, it will be ignored on authentication process.

I meant that someone could create an account with an email address as username. But well, now I see this shouldn't happen, since @ is not allowed in usernames, althought I'm sure that hasn't been always the case, and someone managed to create accounts like this in wikipedia.

One way to deal with the multiple accounts problem step by step is:

1. make an MVP version which logs you in if the email address matches exactly one account and the password matches that account, and gives the same vague error message in any other case (and always calculates a password hash to thwart timing attacks)
2. add a "primary account for this email address" flag to the user table (or possibly a new table with unique email + primary account - more effort, less race conditions), set it in some sensible way (e.g. max editcount), relax the login conditions for accounts with matching email addresses to "only one account matches or only one matching account has a primary flag"
3. add a "set this account as primary" link in the user preferences; when clicked, it sets the primary flag for that account and clears it for all other accounts with the same email. (Depending on our level of paranoia, this might require verification via email.)

I'm all for this initiative. I do want to point out that we might wish to reach out to developers of authentication-related extensions like Extension:LDAP_Authentication to make sure they're aware of changes in advance. This way they can be part of the conversation. As a 3rd-party wiki admin myself I use extensions (like LDAP Authentication) and an update to MW Core that breaks compatibility with popular extensions would be sad.

Just adding a quick note that the multiple account issue needs to be dealt with cleanly here. Needs further discussion.

May be able to make this a 'pure mediawiki' option though for now.

• We want to avoid timed attacks that can determine whether an e-mail address is in the database.
  • Perhaps only check one account total?
    • This approach avoids needing to insert an intermediate screen for disambiguation.
  • This would mean that for e-mail addresses that correspond to multiple user names, you would need to error and tell the user to maybe try an account name instead? (The error message presumably cannot give away that there were e-mail addresses that matched in the database, unless the password also matches.)

One other way to avoid a timing attack when an email may be associated with multiple accounts would be to pad the time with extra password checks:

1. Pick a cryptographic random number between A and B (this is R).
   • Where A is slightly higher than an estimate of the average number of users associated with an email, B is high enough that there are few emails associated with that number of accounts, and there's a bit of space between these numbers.
   • We may want a (log or exp?) scale that makes this number more likely to be smaller.
2. Subtract the number of users found matching the email address which you need to check the password for from R, but cap it at 0 (this is F).
3. Run a fake password check – by running an actual password verification on some dummy data then discarding the result – repeated F times.
   • If a fake password verification requires the generation of a new disposable password hash, then always generate one, even if there are no fake password verifications to do.
4. Check the password for all users even after we find one that matches.

This way an attacker:

• Cannot guess if you verified passwords on 5 users or verified 5 fake passwords for users that do not exist.
• Without prior knowledge of the value of B. Cannot immediately know that verifying N number of passwords when N > B means that an email has to exist (because normally N is not a constant value across attempts).
  • Note that B can probably be discovered by a determined attacker. By doing timing attacks a large number of times against a single known email and keeping track of the highest N value encountered. Using a random scale that prefers lower numbers will make this harder (because values close to B will be less common) but will only mean this attack on B needs to run longer to work.
  • Alternatively, running the timing attack on an email multiple times to see if N changes would be another method (N will be constant if it is larger than B)