Last modified: 2014-06-17 02:20:04 UTC
Apologies if this is a duplicate. It was suggested to me (and so I am passing it on) that we allow login to the projects with an email address as well as a username. So the field would read Username (or email address): The idea behind this is that for casual editors, remembering one's username is a pain, especially on a big project like Wikimedia where many common usernames may be already taken. The step of trying to recover a lost username and password takes of valuable time and is frustrating and may be a slight barrier to entry for casual editors.
Related to bug 13015.
Yes, this would be nice. I have just spent five minutes trying to find a suitable username on wikipedie and almost given up. Related to bug 21416.
Login using e-mail instead of username sounds like a good idea. Though for account creation we'll still probably need to require a username. There's a reason why we blacklist @ and it's not because the username could be mixed with an e-mail. That said, we could offer username suggestions based on the first portion of the e-mail address.
Nice to see some comments on this. I think requiring a username to register is fine; the trouble is that so many usernames are taken people's "normal" username might not be available, so they register for something else (myname00014, or whatever). If they are an infrequent editor remembering this could be tough, which means they can't even recover their password, which means they could well give up on trying to log in and go away in disgust (which means one more editor lost). Allowing a person to enter their email address instead to log in makes all this slightly easier.
What if there's a username with that email address as name? For example: 1337matthew@gmail.com, 1amjoyturner@hotmail.com And note that those accounts are not necessarily benign (although the need to have them created in the past highly mitiates it). What to do if there are several accounts with that email associated? (eg. the user main account, a bot account and a doppelgänger account)
I find preferable to provide a way to send the usernames on providing a password, which is the fixed bug 13015 (r86482), but needs enabling on WMF sites.
(In reply to comment #5) > What if there's a username with that email address as name? > For example: 1337matthew@gmail.com, 1amjoyturner@hotmail.com > And note that those accounts are not necessarily benign (although the need to > have them created in the past highly mitiates it). > > What to do if there are several accounts with that email associated? > (eg. the user main account, a bot account and a doppelgänger account) Suggestion, not requirement. As in say there's a user creation form with just the e-mail and maybe password (though http://accountchooser.com/ has an interesting idea on that) and after submitting that the user gets a form asking them what username they want. For 1amjoyturner@hotmail.com when User:1amjoyturner is available it might say: Please choose a username: (*) 1amjoyturner ( ) 1amjoyturner-hotmail ( ) ... ( ) ... ( ) Other: [text input] <Continue> While for 1337matthew@gmail.com we may say something like: The username 1337matthew is not available, please choose a username: (*) matthew ( ) 1337matthew-gmail ( ) ... ( ) ... ( ) Other: [text input] <Continue> I would never suggest that given a e-mail we implicitly create a matching username without asking the user if that's even ok. Only make a suggestion on what username may be available. Just take a look at the e-mails I'm using... if MW tried to use the e-mail I use on a wiki I would be User:Wiki practically everywhere it's not already taken.
No. I mean on logging in. The @ blacklisting was not always there, and so there are accounts with email-looking usernames, such as that couple I picked above.
(In reply to comment #8) > No. I mean on logging in. The @ blacklisting was not always there, and so there > are accounts with email-looking usernames, such as that couple I picked above. Search for user_name == userinput. If it matches continue with that. Otherwise if userinput matches an e-mail regexp look for an authenticated user_email that matches userinput. If fount continue with that. ie: Username trumps e-mail if present. So usernames that existed pre @ blacklisting will still work the same way as before. But you can't game the system by trying to swipe people's e-mail since @ is blacklisted in usernames.
now working with https://gerrit.wikimedia.org/r/#/c/42084/
I think this issue may be non-resolvable. There is a problem that has not been addressed so far: MediaWiki allows registering multiple user names with the same e-mail address. When this proposed feature would be active, that should not be possible, and e-mail addresses should be exclusive. Making e-mail addresses exclusive, would also allow one with less good intentions to block registering an account by "someone else", by registering a bogus account with an e-mail address of "someone else", although it would be trivial to reset that, given that it's "someone else"'s e-mail address now, there still may be undesirable account history.
In addition to Siebrand's notes, it's also important to note that in MW e-mails are private information, and unless the process was implemented properly, logging in with e-mails may leak information about what e-mails have accounts on the site already. Also, there are sometimes legitimate reasons for wanting to allow multiple accounts with the same email (alternate accounts, bot accounts, etc.). Unless there's some other reason to keep this open, this should probably be closed with WONTFIX.
What about allowing e-mail login only for those with just one account per e-mail (won't that be like 99% of users?). It seems to me to be pretty standard to allow logging in with an email these days, it would be a shame not to have in on wikipedia.
(In reply to comment #13) > What about allowing e-mail login only for those with just one account per > e-mail (won't that be like 99% of users?). It seems to me to be pretty > standard > to allow logging in with an email these days, it would be a shame not to have > in on wikipedia. I guess that's true. Unfortunately, it'd be difficult to actually implement. The logic would have to be constructed so that the time it takes for a non-existent email to fail logging in would be the same as an existing email with an incorrect password logging in. This would require initializing a fake user when the email doesn't exist, passing it to AuthPlugin and whatnot, and then hashing and comparing a fake password before finally bailing out.
I see, but then is not this what all other websites are doing (if they do it properly)? I can understand you may not have the resources now, but would that necessarily lead to WONTFIX?
No, you're right. It wouldn't lead to a WONTFIX. However, I think a much more beneficial change would be something like enabling OpenID login, so people can login with their Google/Facebook accounts like most other sites allow, but that's an entirely different discussion.
ok. I continue to fix this bug.
(In reply to comment #11) > I think this issue may be non-resolvable. There is a problem that has not > been addressed so far: MediaWiki allows registering multiple user names with > the same e-mail address. I don't think this is unresolvable. Following Daniel's suggestion in comment 9, what we'd do here is always prefer a username over an e-mail address. This would retain existing functionality/behavior. For e-mail addresses that match multiple accounts, the user would be presented with an option post-login to select which of the accounts to log in as. Obviously this would only work with accounts that have an authenticated e-mail address. Such cases are terribly common given "public" accounts, bot accounts, etc. However, given the proposed precedence (preferring username over e-mail address), this change shouldn't really get in anyone's way.
Undoing uncommented change to WONTFIX. The discussion so far doesn't seem to support one person suddenly marking it as WONTIFIX without an associated comment on why.
Just a note: if an email matches many accounts, it may be possible to spare the user from selecting his/her desired account, if the password entered matches only one of the accounts. I mean: if the user enters his/her email and password, and 3 accounts match the email, but only one matches the password, then it's safe to assume that the user wants to log in to that account, not the others. However this may not always work, because many users will also repeat their passwords.
(In reply to comment #20) > Just a note: if an email matches many accounts, it may be possible to spare > the > user from selecting his/her desired account, if the password entered matches > only one of the accounts. I mean: if the user enters his/her email and > password, and 3 accounts match the email, but only one matches the password, > then it's safe to assume that the user wants to log in to that account, not > the > others. However this may not always work, because many users will also repeat > their passwords. That's not a viable solution due to security. The username and password should be a 1-1 association, meaning you *must* have both in order to login. The only time it would be OK to let people log in with email is if only one account has that email.
Regarding Tyler Romeo's concern about email privacy, a solution would be to throw a "Email doesn't exist or incorrect password" error whenever someone tries to login with an email and fails. Doing so wouldn't reveal if there is an account with that email.
Tyler, I know it's not standard practice, but how could it go wrong?
The issue is that you're attempting login to multiple accounts simultaneously. I mean, let's say somebody uses three accounts (main, alternate, and bot) and they use a different password for each. If you know one of the passwords but not the account name, you can then try all at the same time. It could probably be fixed if we increased the login throttle by however many accounts with that email.
Hi, Just became aware of the limitation today that user cannot log in to the system with their email address, I've read over the thread and i have a few things to add. I'd love to see this implemented, however it looks like development on this bug is a little stuck. Proposal: User should be able to log in to the system with either their user name or the email they have associated with their account. Issues: PRIVACY ISSUES WITH SHOWING AN ACCOUNT EXISTS — If a login is attempted with an email address only and no password the login error should be updated as follows CURRENT: "Login error There is no user by the name "jared.zimmerman@wikimedia.org". Check your spelling, or go to Wikipedia's signup page to create a new user account." PROPOSED: "Login error The user account for "jared.zimmerman@wikimedia.org" is not found or your password was entered incorrectly. Check your spelling or password and try again. If you do not have an account you can _create one._" MULTIPLE ACCOUNTS WITH SAME EMAIL — If multiple account exist with the input email address but no password is entered… A. Ideal experience would be that the form cannon be submitted unless login and password fields have valid content, login button would disabled B. If form validation cannon be fixed, the above error should be displayed even if the email address is valid for a user C. If a login (email) and password combination are valid they can only point to 1 account, that account should be logged in to.
(In reply to comment #25) > CURRENT: > "Login error > There is no user by the name "jared.zimmerman@wikimedia.org". Check your > spelling, or go to Wikipedia's signup page to create a new user account." Of course you can not currently log in with an email. If you mean 'there is no user by the name "InvalidUsername"', that's not actually a privacy issue. Anyone can check what usernames exist (https://en.wikipedia.org/w/index.php?title=Special%3AListUsers&username=InvalidUsername&limit=1) Many sites are like MW in allowing you to enumerate the usernames one way or another. However, email should certainly not be enumerable. > PROPOSED: > "Login error > The user account for "jared.zimmerman@wikimedia.org" is not found or your > password was entered incorrectly. Check your spelling or password and try > again. If you do not have an account you can _create one._" I think this is fine. If done correctly (exact same error used for valid email, wrong password) It doesn't leak information about whether the email exists. > MULTIPLE ACCOUNTS WITH SAME EMAIL — > If multiple account exist with the input email address but no password is > entered… I don't understand why "no password" should be a special case. Can we just say "an incorrect password" (the minimum length is currently 1, so any empty/omitted password is incorrect). > A. Ideal experience would be that the form cannon be submitted unless login > and password fields have valid content, login button would disabled By valid content, do you mean the username/password or email/password are correct, or just that the fields are non-empty? We could do username/password check with AJAX authentication, but I'm not sure if that's really that useful. > C. If a login (email) and password combination are valid they can only point > to 1 account, that account should be logged in to. That constraint does not exist yet. Of course, we do not store passwords in plain text (very insecure). So to enforce this constraint, we would have to enforce that (email, hashedPassword) is unique. I'm not sure all the passwords use the same algorithm (legacy reasons). That would also have to be fixed (either all at once, or on login), then enforced going forward. For accounts with an authenticated email, we can email them to request they change their password (to fulfill the unique constraint you mentioned above). However, there's no guarantee they'll actually click the link to do so (and they could have lost their email in the meantime). We have to decide what to do for accounts that continue to have non-unique (email, password). I think it's a bit weird to give them a choice on login, so the simplest solution for this edge case is to simply reject (email, password) for these cases. Until they had unique (email, password), they would have to continue using (username, password).
Here is the only solution I think we should be willing to consider due to our privacy and security constraints: if and only if the given username/email matches a single unique account and the password is correct for that account, the user will be logged in. Otherwise a generic "Username/password combination is wrong" message is displayed. Ideally, I'd much prefer if this was implemented *after* Gerrit change #27022 and Gerrit change #27472 are merged, that way we're not persisting old and shaky architecture. I can probably make a patch on top of Gerrit change #27022 in a few hours if a lot of people want this fixed.
(In reply to comment #27) > Here is the only solution I think we should be willing to consider due to our > privacy and security constraints: if and only if the given username/email > matches a single unique account and the password is correct for that account, > the user will be logged in. Otherwise a generic "Username/password > combination > is wrong" message is displayed. I agree. There are going to be too many issues if we try to guess the right account when multiple accounts have the same email address.
I'm ok with that setup, it supports new users who may have forgotten their user name while basically having no effect on "power users" who run bots all under their same email or malicious users who are running sock puppet accounts. Either way it seems like a win for new, and normal users without affecting other adversely.
(In reply to comment #26) > (In reply to comment #25) > > C. If a login (email) and password combination are valid they can only point > > to 1 account, that account should be logged in to. > > That constraint does not exist yet. Of course, we do not store passwords in > plain text (very insecure). So to enforce this constraint, we would have to > enforce that (email, hashedPassword) is unique. > > I'm not sure all the passwords use the same algorithm (legacy reasons). That > would also have to be fixed (either all at once, or on login), then enforced > going forward. You're basing this all on the assumption that as long as the same password algorithm and same password is used the hashed password will always be the same and can be checked for uniqueness through equality. This is completely false. Unless you set `$wgPasswordSalt = false;` (which is insecure and only exists to support 3rd party systems doing login to MW wikis by directly messing with the database) we salt passwords when we hash them (well they're not really hashes, but that's another topic). This means that if you hash the same password with the same algorithm you're practically guaranteed that the end hash is going to be different each time. This is the very intent of salting passwords for security. It's not going to to away, otherwise we'd be vulnerable to rainbow tables. So checking that passwords are unique just isn't going to happen.
(In reply to comment #30) > So checking that passwords are unique just isn't going to happen. Good point. I wasn't thinking, and I forgot about the per-user salt.
Change 42084 abandoned by Hashar: (bug 28085) Allow login with e-mail address Reason: Lets keep the discussion on bug 28085 which might end up being abandoned. https://gerrit.wikimedia.org/r/42084
Is this being picked up by someone else?
Is this really PATCH_TO_REVIEW or is the status incorrect?
(In reply to Jared Zimmerman (WMF) from comment #34) > Is this really PATCH_TO_REVIEW or is the status incorrect? Status is incorrect.
