Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Invalid Username or Password”: a useless security measure (2014)

kevin.burke.dev

Post reply on HN
Print view View original

161–170 of 289 posts

Re: “Invalid Username or Password”: a useless security measure (2014)

#161

Post by patrakov »

est wrote: post #73

The best measure? Let any login pass, just generate a fake account if the credentials were wrong.

The best measure? Ditch the password. It can be reset anyway, it can be stolen, it's just unnecessary complexity, it doesn't provide any security.

You can prove ownership of the email? You can log in - worst case, after a password reset. So why have a password?

email: ______________ [Log in]

The "Log in" button results in a "Check your inbox and click the link in the email that we just sent you" page.

Source: https://appear.in/ used this flow from the very beginning, before it was destroyed in a trademark dispute. EDIT: now it is https://whereby.com/user/login

Re: “Invalid Username or Password”: a useless security measure (2014)

#162

Post by TeMPOraL »

zhfliz wrote: post #103
thomastjeffery wrote: post #99

Earlier quoted context omitted.

You shouldn't be doing long web forms before creating an account anyway.

You shouldn't be taking my email just to demand lots of information from me after I already gave my email to you. If you demand lots of information that should be clear right away.

So now you're saying web UX should actually improve and give up the major disadvantage it has over paper forms: hiding the full flow from the (l)users.

/s, but only slightly.

You're right, of course. The answer is the one nobody wants to hear: you can tell users what you'll want from them, then ask to create an account, and then ask them to do the things you outlined before registration.

As for multi-page forms, they make sense if you target non-JavaScript use, but if your site is already an SPA, you might as well present the form in full, and conditionally disable parts that don't apply based on earlier inputs. This is the way to improve over the paper UX.

Re: “Invalid Username or Password”: a useless security measure (2014)

#163

Post by ad404b8a372f2b9 »

thomastjeffery wrote: post #130
ad404b8a372f2b9 wrote: post #109

I agree with the premise but the solution has UX issues of its own. Some users, like me, have learned to use the registration form as an account checker for their own email. I don't remember if I have an account on some websites, and if I do I don't remember with which email+password combo, and the password reset page doesn't tell whether the email is correct, and it often takes 10 minutes for them to send a reset em…

You might not know if you have an account, and you might not remember your password. The solution to either problem is the same: send an email. So why not merge the two processes? Actually, any "forgot username/password" link effectively does this already. The only thing we need to do is make that more obvious. I think the easiest way would be to separate username creation from password creation. Just have a single s…

It's not a solution to the problem I described, if it were the forgot password page would already solve it.

Re: “Invalid Username or Password”: a useless security measure (2014)

#164

Post by joosters »

capableweb wrote: post #37
herendin2 wrote: post #33

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.

I think that the author is saying that it is very difficult not to disclose that a user exists, and so there is not much point obfuscating it. Validating an email address on signup is only one way to 'leak' usernames.

If you can obtain a user account on a system, then preventing checks for the existence of other users becomes much harder. e.g. if you have a login on a unix box, there are countless ways of discovering other usernames. Or a pathological case like reddit, where users have distinct URLs that are publicly visible.

Or a messaging system where you can 'friend' other users - if you allow friend requests, what do you do if someone tries to contact a mis-typed username? Do you inform them that the user doesn't exist, or silently pretend that their request is awaiting a response that will never come? That paranoia will lead to a worse user experience.

I think you can only really lock down the known user list on a very closed system, with few, trusted users, e.g. an admin control panel where you don't want to divulge who might have access to it in the first place. But that's a very different scenario to a service open to the public.

Re: “Invalid Username or Password”: a useless security measure (2014)

#165

Post by KMag »

samwillis wrote: post #150
darrinmn wrote: post #80

> 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. This is not true if the signup flow is implemented correctly. Signing up for an account should always respond with the same message "we sent an email for you to confirm your account signup". The owner of…

The vast majority of the time the number one priority is reducing friction before a conversion. As much as a email confirmation prior to completion is more secure, the business case is far less strong. Customers can fix their email later, they can contact customer support if they got something wrong. Get them in the door ASAP, and either using the account, or complete an order. Don't redirect them to their email wher…

The lowest friction workflows make data collection/entry as lazy/delayed as possible and maximize optionality. Allow users to "save as default" as part of their normal workflows on your site, rather than demanding the information up-front at signup.

The welcome/email verification email should have an expiring passwordless sign-in link (and maybe a way to set password if you decide to support passwords). If I use your site rarely enough, I don't even save your information into my password manager. Your password reset workflow is my normal sign-in workflow. Kudos to sites that don't force me to generate a one-time random password for this sign-in workflow. In practice, I think a lot of people accidentally use this as their login procedure on rarely visited sites.

If account creation is part of the ordering workflow, make the most significant 6 (or more) digits of the order ID a secure message authentication code of the rest of the digits and delay verification of the email address. That allows you to delay email address verification and still securely correct email address typos (of recent orders) if the user records their order ID.

If your site has made birthday mandatory but you haven't demanded a government ID for verification or run a credit check, I've lied to you about my birthday.

If your site demanded a mailing address but you're not shipping anything to me, I've lied to you about my address.

If you're demanding to over-collect information, and I'm polluting your data lake, that's on you.

Side note: the McDonald's app is nice in not requiring (or apparently even allowing) passwords to log in. However, there's a problem with its state transition, where the user needs to exit from the dialog that sends the sign-in link before they go to their email and click on the sign-in link, otherwise the user gets dumped to the next step without having actually signed in.

Re: “Invalid Username or Password”: a useless security measure (2014)

#166

Post by Sohcahtoa82 »

mod wrote: post #158
bluenotebo0k wrote: post #31

"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.

Half the web has a CAPTCHA just to view content. Thanks, Cloudfare.

The only site that has ever asked me to solve a CAPTCHA before browsing content was pcpartpicker.com, and even that one stopped making me solve a CAPTCHA.

Do you browse the web behind a VPN, Tor, or something else to hide your IP? That's been known to trigger CF's CAPTCHAs.

Re: “Invalid Username or Password”: a useless security measure (2014)

#167

Post by lucideer »

layer8 wrote: post #104
darrinmn wrote: post #80

> 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. This is not true if the signup flow is implemented correctly. Signing up for an account should always respond with the same message "we sent an email for you to confirm your account signup". The owner of…

This is bad in the case of online orders, where the order will usually go through anyway (vendors want to sell even when you don’t confirm your email address, and don’t care a lot about someone else getting the notification emails), because if by mistake you registered your email address as new although you already had an account with that address, the order won’t get associated with your account. Or if it does autom…

> the order will usually go through anyway

> vendors want

If security is not a priority for the vendor, then yes. Otherwise, no, the order will not go through anyway.

I'm very aware that in many many cases, the former is true in the real world, but that doesn't change the fact. This isn't a good justification for the op's dismissal of the practice.

Re: “Invalid Username or Password”: a useless security measure (2014)

#168

Post by throwaway09223 »

This is an extremely silly observation for HN, given that the usernames are published openly with every comment. My username is quite obviously "throwaway09223." There's no need to enumerate anything.

Avoiding username enumeration is a reasonable goal for some sites in terms of hiding PII, but it is very obviously not a necessary security measure.

Re: “Invalid Username or Password”: a useless security measure (2014)

#169

Post by marcosdumay »

MichaelCollins wrote: post #160
samwillis wrote: post #150

Earlier quoted context omitted.

The vast majority of the time the number one priority is reducing friction before a conversion. As much as a email confirmation prior to completion is more secure, the business case is far less strong. Customers can fix their email later, they can contact customer support if they got something wrong. Get them in the door ASAP, and either using the account, or complete an order. Don't redirect them to their email wher…

If reducing friction is the priority, then maybe skip email completely. Let people sign up with any username and don't require an email at all, like HN allows. Most sites that require an email don't need an email, and only ask for it so they can spam users with nonsense like product updates.

Any site that requires a password will need an email for password resets.

Re: “Invalid Username or Password”: a useless security measure (2014)

#170

Post by crazygringo »

throwaway09223 wrote: post #168

This is an extremely silly observation for HN, given that the usernames are published openly with every comment. My username is quite obviously "throwaway09223." There's no need to enumerate anything. Avoiding username enumeration is a reasonable goal for some sites in terms of hiding PII, but it is very obviously not a necessary security measure.

The article is about usernames as email addresses.

Not about handles.

HN doesn't reveal people's e-mail addresses, unless they choose to put it in their bio.

Post reply on HN