I think the real lesson here is that if emails should remain secret you should not indicate upon signup whether or not a user exists with that email.
Always send an email.
If that user already exists, make sure the email says "We noticed you're trying to sign up again. If you didn't do this, someone else is trying to sign up for you." If that user doesn't exist, send them the typical signup message.
The author has some great security tips in the "what should I do instead" but I don't think the instead portion is accurate. Keep private information private, and make access to public information as easy as it should be.
If emails are public, shoot, use a websocket connection to style the login field in real time and show the user whether or not the email they typed is valid.
Please don't always send an email. A malicious person can now start signing up every day with a bunch of emails resulting in users who do have an account receiving an email from your site daily/hourly saying "we noticed you're trying to sign up again". At which point they become annoyed with your service and either unsubscribe or delete their account.
Hotmail do this everytime someone tries to reset my password which happens almost daily as I have what turns out to be an account name that is in demand and it's really irritating. And there is nothing I can do to stop someone attempting to reset my password - I have 2 factor switched on so they won't be successful.
Of course you can add more logic in to try and be more intelligent about when the emails are sent, but most sites won't get this right when they can't even store passwords correctly.
An attacker could already do this via nearly every service's "forgot my password" functionality, as you noted yourself in the case of hotmail.
As the original author noted, rate limiting is also a fundamental requirement for security. Eventually no more emails are sent because the offending IP addresses are effectively blocked.
Make email notifications an option for users (enabled by default, with an easy link in the email to disable), and you ensure your users that your service is secure, while giving them the ability and easy path to ignore it.
Re your Hotmail problem, personally I would spend 30 seconds configuring sieve to filter those annoying emails into my Trash so I never have to see them again. Problem solved.
Forcing the user to interact with an email client during the signup process before they've confirmed the availability of a username might be good for security, but it's a horrible way to gain users. That's a very high friction process.
I generally agree with this comment, however.
Hmm, I do see your point, though I'd propose that usernames are more often than not public information. That's been my experience at least.
The difference for usernames is that they may or may not be shared across services. They're a bit more transient to the average user than an email is, though only a bit.
That said, it depends more on your use case than anything else. If any information is private information, it should remain private. Otherwise, I say make it easier to access that information, and be consistent.
To be fair to those implementing the example login systems as well, not all malicious attackers are hackers. It could be an angry ex who wouldn't necessarily think to try creating a new user before proceeding with their password-mashing attempts.
"Bad login combination" and variants do avoid information leakage. It's just not consistently enforced across all surface area. As another example, I believe Amazon public wishlists are searchable by email. That alone can net you an easy list of logins to brute force or check against existing email-password lists.
I think it's most likely that these services are avoiding the "that username exists but it's not actually yours" conundrum while keeping code (and UX) complexity to a minimum.
True, but many site use the email address as the username and require you to validate that email address before you can do anything anyway. Those sites, at least, have nothing to lose by adopting this approach.
Let them signup again. Then send them an email asking that they signed up for a second time and if they wish to update the existing information with the new information provided in the "fake" signup process.
This is why I like federated login with the options of Google and Facebook. Why go through the hassle of creating a new password and sending a verification email, when the user can just click a couple buttons to sign in with a service indefinitely? The username can be chosen afterwards and never has to be re-typed.
I know, but it's so much easier. It's not like I can't look up someones email account manually without federated login, plus then I no longer have to store passwords.
Of course, aside from my own projects, the only service I've seen that exclusively does this is Fancy Hands.
I agree that it's easier, and if you're only getting a unique identifier from that service (as well as a token), then it's really not unsafe. For the purposes of login, data sharing is unidirectional.
The problem is that Facebook totally mismanaged their apps when they first launched, and a lot of people were permanently turned off to "Connect to Facebook" functionality by random apps posting under the user's name.
My account was recently abused by Glassdoor, which fervently promised not to post anything to my friends, and then immediately did so.
My trouble with these things is that they invariably support multiple services, all of which I have accounts with, and I can never remember which one I'm using for any particular service.
This doesn't really work that well, I realize - when users mistype their e-mail, they get their registration sent to some random address, and they get zero feedback on what went wrong. From their perspective, the registration worked and they just got no e-mail. Bad experience.
Security is all about trade-offs. Sending emails puts a bigger barrier between signup and first sign in. It is probably a better business move to slightly inconvenience some existing customers rather than slightly inconvenience all potential new customers.
What I'm saying is that every "signup" event should appear as if it was a valid, brand-new signup as far as the web user is concerned.
The email will be sent regardless. If it's a valid new signup, then the user gets a transparent experience. If the user has already signed up, send them a helpful "hey, you've already signed up" message in their inbox.
In case it was an attacker, maybe check the IP against known IPs that have had valid logins. If it's a new IP, add a section to the email message that a potential attacker may be trying to login and that no action is required, etc. Whatever fits your business case.
You're ignoring that most modern apps will give you rudimentary account access even before you confirm your email address. Which would be difficult to do if that account already exists.
My answer to this problem would be to let them in anyway. Store all session data with a cookie or (brand new) UUID, perhaps persisted via localstorage for the long-term users.
The email should still indicate new or existing user, and provide them a link that they can use to associate said UUID with their login and pull all the data onto their account as if they'd been logged in the whole time.
They'd need to be informed that all account data is accessible only on that computer, at least until they've confirmed their email address. I kind of imagine this is the existing behavior for many applications, though.
Additionally, if the service doesn't require emails to be authenticated, then they shouldn't be using them for much more than account recovery or notifications (once authenticated). Otherwise, I can sign up for that service with somebody else's email as long as they haven't signed up before, and then if that person ever wants to sign up for this service, either they're out of luck or the original (perhaps misguided) customer is out of luck.
That was the inconvenience I was referring to in my post. Either a new user needs to verify their email before using the site or you need someway to immediately tell the user that an account with that address exists.
This process also won't work for the small minority of sites that don't require email adresses. HN is one example.
And the entire point is moot for most social sites as it is trivially easy to check for the existence of a user by going to their profile page. Why bother going through all this email trouble when I can just go to twitter.com/TheUsernameIWantToCheck to see if that user account exists?
> Either a new user needs to verify their email before using the site or you need someway to immediately tell the user that an account with that address exists.
> Why bother going through all this email trouble when I can just go to twitter.com/TheUsernameIWantToCheck to see if that user account exists?
I totally agree. Twitter usernames are hardly private information, though. As I said, make sure truly private information is kept private.
Keeping in mind the UX, though, most users may not realize how easily their user id ( email/username, etc.) can be discovered. Seeing the login screen confirm that their username exists but their password is incorrect may in fact scare existing users away.
Determine what's best for your demographics, and ideally A/B test the heck out of it.
This is the actual concern. If you require an email check before someone messes around with the product, there's a potential dropoff that people can (rightly) be concerned about.
It's already pretty common to require clicking a verification link in an email to complete registration. If you're using someone else's email on the registration page, you're already doing something fishy, and this prevents you from discovering that the email is already in-use. To a legit user, everything looks normal (and to a legit user who forgot they had an account, they'll get a simple reminder in their inbox when they look for their validation link, possibly with forgot password instructions included).
Of course, this all goes out the window if you're not using emails as usernames.
I think it makes the signup process fairly simple and easy. At least, it doesn't complicate it. Email confirmations are almost standard anyway. The only difference is that by doing it this way, you don't reveal whether a user already exists with the email in question (the email is the username).
I have a hard time seeing what friction is added, though, with proper thought. If you don't require email validation but use it as a unique login identifier, then a malicious body could DOS all future users via bulk signups. DDOS required if you use rate limiting on signups. Slightly different application of the attack but still a denial of service.
Even a non-hacker could block another user from signing up by simply creating an account with someone else's email address.
If you don't use it as a unique login identifier, there's no problem at all. New users use their username to login.
This is important. It is not always necessary or appropriate to try to maintain the secrecy of otherwise public, directory information (like email addresses). Unless you are, say, FetLife, it doesn't actually make that much sense to hide the fact that joe@example.com has at one point signed up for your service.
On the other hand, associating joe@example.com with posts he thought were anonymous is an enormous violation.
Always send an email.
If that user already exists, make sure the email says "We noticed you're trying to sign up again. If you didn't do this, someone else is trying to sign up for you." If that user doesn't exist, send them the typical signup message.
The author has some great security tips in the "what should I do instead" but I don't think the instead portion is accurate. Keep private information private, and make access to public information as easy as it should be.
If emails are public, shoot, use a websocket connection to style the login field in real time and show the user whether or not the email they typed is valid.