9 ms·
The right answer isn't a blanket "sites should do this super-secret e-mail-only shuffle and not tell you anything". First, you should define your threat model:
by pornel 9y ago
The right answer isn't a blanket "sites should do this super-secret e-mail-only shuffle and not tell you anything".
First, you should define your threat model: which information is considered secret and which isn't, and treat any violations as security vulnerabilities.
If usernames are public by design, then don't hide them in one form, and expose in URLs elsewhere on the site.
If exposing who's registered on your site really is a threat, then by all means have a weird registration (and password reminder) that doesn't tell whether it worked or not. But if your site is for cookie receipies and you don't consider exposing who's a fan of cookies a privacy violation, then just use most helpful messages you can.
- pqh 9y agodefault to privacy though, please
- ryanbrunner 9y agoNot really. "Default to privacy" is what gives you insane useless UXes like the one in the article, where you're making login (already a frustrating experience) more painful with absolutely zero gain in security. Default to knowing your threat model. Default to balancing security concerns with UX, and make an informed decision instead of blindly following best practices.
- perfmode 9y agoI don’t want others to know all of the places where I have accounts. That’s an easy way to be targeted.
- stordoff 9y agoThat's the point of the article though - for a large percentage of services, if you know the username/email address you are targeting, you can just try to register them and see if it works. Obfuscating the login process makes little difference.
- testvox 9y agoWhich is why they shouldn't leak this information on the registration page... Instead they should pretend the registration always succeeds and then disallow login until the email has been verified.
- mnarayan01 9y agoThe point is that sites generally leak this anyway via signup. With github it's even easier, e.g. https://github.com/someuser https://github.com/someuser -- I looked through my settings and their doesn't appear to be any way to "be invisible", though I could be missing something. When you can do a simple query like that, sacrificing UI at sign-in seems totally pointless.
- cjwhite 9y agoYou're missing the point. Fix the signup form instead of just giving up.
- ivanbakel 9y agoI'm not sure the point made was as much "use this blanket solution" as "if you're aiming to do this, go all the way". Obviously, Github and Stripe aren't actually enforcing these messages as part of some larger security policy, or if they are, they're doing it very poorly. But if they were, the email shuffle is what they ought to be doing.
- travisjeffery 9y agoYou got it. You can be about security or UX. And when the accounts are public I'm especially in favor of taking advantage UX-wise. The issue's when both are half-assed.
- sp332 9y agoRight, for example if you run an email service, your usernames (addresses) should be hidden. That's because a spammer could use your login page to find valid usernames and then send spam to them. They don't have to guess passwords to cause damage.
- koolba 9y agoThey could also use your signup page to attempt to create an account for user@example.com. Since you can't allow duplicates that rejection gives them the same information. Might as well let a user logging in that the username is incorrect to make the legit use case, i.e. user has a typo and/or misremembers their username, more pleasant. I usually suggest clearing the username field on failed logins as well. That way if there is a typo, the user doesn't try it again thinking only the password is wrong.
- Someone1234 9y agoOr just use the SMTP specification and or bounce-backs to do the same...
- ballenf 9y agoThe other right answer is do not let someone create an account with an email they don't have access to. My short gmail address gets a signup on some random website a couple times a month and they're often nigh unto impossible to delete. Fitbit is one of the worst for this.
- steanne 9y agooh yes, i get french people ordering cabs from paris.
- ecesena 9y agoI think there is an important point which is ignored, in the article and here in the thread: typos. Unfortunately, when designing a login flow (and a signup one), you can’t assume that the user always inputs the right things. Try logging in into facebook, for example, mistyping gmail or with your password with the wrong case, like all uppercase. In many cases... you get in! This is to prove that they had to “improve” their flow to account for wrong user input. Because user input can be wrong in both email or password, the error message should account for both.
- derimagia 9y agoA lot of places separate out the email/username field so it's a 2-step form. They will show you your avatar and maybe some other public info when you enter the password. This is a better way to do this I believe, although it does make logging in with a password manager [slightly] more annoying.
- lathiat 9y agoThis is often done to support SAML or other federated sign in
- failrate 9y agoI take issue with your cookie site example, because the user of the cookie site is probably using the same credentials on an important, sensitive site.