41–50 of 289 posts
But the error message can be true. If you mistype your username, you might have entered another, existing username. Just telling the user 'wrong password' will mean they are less likely to check that the username was correct. The website doesn't always know which one you got wrong, and assuming one way or the other just makes things worse.
Quoted post unavailable.
For example: https://myaccount.nytimes.com/auth/login
"99.9% of websites on the Internet will only let you create one account for each email address. So if you want to see if an email address has an account, try signing up for a new account with the same email address." Yes, but signing up is a more cumbersome process and usually has a CAPTCHA attached to it, unlike logging in.
My guess of what is most common is that the actual trying to create a user in the backend/database is protected by a captcha, but checking if the email/username already exists is a separate endpoint that the frontend hits while filling out the signup form, before trying to create the actual user.
But it's just a guess, and I can already think of many examples where that doesn't happen, which is for good reasons.
Earlier quoted context omitted.
You can provide a more helpful error message by explicitly informing the user that the username they typed exists but they haven't offered the correct password for it. Unless the site searches to find out which username the entered password actually corresponds to (which is a whole new, terribly dangerous, can of worms), it can't do better than that Because any malicious player can easily check whether usernames exis…
It doesn't seem like the author is arguing that just because you can instead validate if the email exists on a platform via the signup page instead of the login page, the vague message can be removed, but rather that the signup page should remove the information leakage as well, so there is no leakage anywhere.
> …you can make the signup process email based.…I don't recommend this, because of the context switches, though you can implement it.
> Here is an actual UX/security tradeoff: you can make the signup process email based. Great. Now I can’t share passwords any more with significant others. Instead I have to send them login credentials every time they want to login.
Personally I have my email setup so everything mentioning Netflix/HBO/Disney/$streaming-service/$shared-service gets automatically forwarded to our family inbox that everyone in the household has access to, in case they need to reset the password or do something related to those services
Edit: added "automatic" to "forwarding" as that's the vital piece here
> Here is an actual UX/security tradeoff: you can make the signup process email based. Great. Now I can’t share passwords any more with significant others. Instead I have to send them login credentials every time they want to login.
Automatic forwarding solves this problem for you :) Personally I have my email setup so everything mentioning Netflix/HBO/Disney/$streaming-service/$shared-service gets automatically forwarded to our family inbox that everyone in the household has access to, in case they need to reset the password or do something related to those services Edit: added "automatic" to "forwarding" as that's the vital piece here
The auto-setup is a cool idea though.
"99.9% of websites on the Internet will only let you create one account for each email address. So if you want to see if an email address has an account, try signing up for a new account with the same email address." Yes, but signing up is a more cumbersome process and usually has a CAPTCHA attached to it, unlike logging in.
This just made me to visit and login even more infrequently.
Earlier quoted context omitted.
Quoted post unavailable.
This is mentioned in the submission. The argument is as follows: If you're vague on the login page but still do the validation on the signup page, the information leakage happens regardless, just on the signup page rather than login, as most websites only allow one account per email.
Oh boy. This is actually a good point. I guess having the nondescript error message has always been "best practices" or maybe it has crossed the road and has become cargo cult now.
Many best practices are already what the author suggests: If a user signs up and doesn't already exist, send them an e-mail to confirm they own the e-mail. If that user already has an account, send their e-mail a message to the effect of "Someone tried to sign up to our service as you, is this you? If not, it's safe to ignore this message. Here's how to reset your password in case you lost that: ..."
The thing the author is missing here is the same failure I see at a lot of companies: they take the approach that they're only there to protect their application, rather than doing what they can to protect the users of the application. Something as simple as knowing a user uses a service can become an easy spearphishing attack, for example, which the author doesn't mention.
The general recommendations are good but defense in depth is key.
This is assuming that the service allows new users to sign up themselves. Also, testing it via signup sends a lot of emails to the victim (if the attacker tries a number of services), so the victim at least knows that something is up.