“Invalid Username or Password”: a useless security measure (2014)(kevin.burke.dev)
kevin.burke.dev
“Invalid Username or Password”: a useless security measure (2014)
https://kevin.burke.dev/kevin/invalid-username-or-password-useless/
288 comments
Author talks about that in the article
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 where there is a good chance they will either get distracted or the email will be delayed.
That's not to say you shouldn't also have your own measures in place to detect errors, or malicious checking if an email is associated with an account.
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 where there is a good chance they will either get distracted or the email will be delayed.
That's not to say you shouldn't also have your own measures in place to detect errors, or malicious checking if an email is associated with an account.
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.
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.
> 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.
The mcdonalds app loads several dozen data collection sdks, pihole practically had a meltdown when it launched
The mcdonalds app loads several dozen data collection sdks, pihole practically had a meltdown when it launched
Even an async validation would be better. I have <common name>@gmail.com, and get several newspapers and some other subscriptions for free.
In one case, a person named Mary in Australia sends their loved one a gift card every year, and the retailer doesn’t provide any information about Mary. In another case, a student missed out on their work study job and a opportunity for early class enrollment due to a bad email.
It’s sad as all of these customers don’t even know that they have a problem.
In one case, a person named Mary in Australia sends their loved one a gift card every year, and the retailer doesn’t provide any information about Mary. In another case, a student missed out on their work study job and a opportunity for early class enrollment due to a bad email.
It’s sad as all of these customers don’t even know that they have a problem.
Validating any contact method that has the potential of sending PII, Health, or financial data should be mandatory by law.
At least once a year I get an automated phone call from a regional hospital letting me know some minor's test results. Calling the hospital's CS department in order to notify them or somehow get my phone number removed from the account is impossible, because I'm not this person nor their legal guardian and HIPAA regulations prevent me from instigating a change on someone else's medical records or accounts.
At least once a year I get an automated phone call from a regional hospital letting me know some minor's test results. Calling the hospital's CS department in order to notify them or somehow get my phone number removed from the account is impossible, because I'm not this person nor their legal guardian and HIPAA regulations prevent me from instigating a change on someone else's medical records or accounts.
An extra problem there is that phone numbers get reused. They might have verified the number at the time the previous person still had it.
I get all kinds of messages to someone called Amy from multiple sources, so I believe Amy really had my phone number earlier. No medical results yet, but healthcare appointment reminders for sure.
I get all kinds of messages to someone called Amy from multiple sources, so I believe Amy really had my phone number earlier. No medical results yet, but healthcare appointment reminders for sure.
Don't call CS. File a HIPAA complaint. The provider who is sharing PHI illegally will certainly care. They have no duty to validate the phone number, but they do have to respond to a complaint saying they shared PHI with a person who is not THE person.
Discussions of friction and login/signup always drive me crazy. Like I get the need to get people to sign up. But security is always an afterthought - it always loses to lower friction.
And don't get me started when the PM starts lowering friction to the point where they are basically trying to trick the user.
And don't get me started when the PM starts lowering friction to the point where they are basically trying to trick the user.
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.
I’ve had my Reddit account for 15 years. Never given them an email.
Not true for end to end encrypted stuff, the server can't reset anything.
If the site doesn't need email for anything besides that, then it doesn't need email for that either. Let the user set an email for account recovery if they want, but don't require it. If users who choose not to give an email forget their password, they can simply create another account.
This is the way HN works. It's the way most websites used to work, until maybe 15 years ago, give or take. Today almost all sites ask for verified email addresses, but this used to not be the case.
Besides the commercial value of having user email addresses, I think it's mostly done for the webdev's ego:
> Users need to hear about my new update! (Because if I don't spam their inbox, nobody will notice or care about the thing I just did.)
This is the way HN works. It's the way most websites used to work, until maybe 15 years ago, give or take. Today almost all sites ask for verified email addresses, but this used to not be the case.
Besides the commercial value of having user email addresses, I think it's mostly done for the webdev's ego:
> Users need to hear about my new update! (Because if I don't spam their inbox, nobody will notice or care about the thing I just did.)
I think the webdevs are right about this one. People lose or forget passwords all the time (in general not using password managers). Permanently losing access to an account sucks a lot. Tying account ownership to email primarily with passwords being more or less an optional convenience saving you the email roundtrip seems worth it.
> Permanently losing access to an account sucks a lot.
But mostly that's all. Usually it's a minor inconvenience. Occasionally it sucks a bit. Rarely it sucks a lot. Almost never is anything of value lost. It can be wholly eliminated by good data practices e.g. backups. (No one backs up their Amazon account data. It isn't designed for it. Because the "webdevs" think of the data as their boss's - squarequoting "webdev" because the effective decision is the CEO's and the "webdev" is just taking some abstract, ill-thought-through decision and making the ramifications concrete.)
On the other hand, it also sucks a lot when your gratuitously collected private information is taken to the darkweb. As countries become more accustomed to dealing with databreaches, they are beginning to consider legislating harsh compensation requirements and painful fines. Once that's happened, almost all of the private data that the user has in their account? Let the user keep it. We webdevs and our mortal enemies in business/sales/product will have to innovate new decentralised databases - where each node is a users' computer. And yeah, some things will be harder or not even possible (for the user). Other things will become possible that aren't at the moment (for the user). And at least you won't go bankrupt when a state level actor decides your database is valuable.
But mostly that's all. Usually it's a minor inconvenience. Occasionally it sucks a bit. Rarely it sucks a lot. Almost never is anything of value lost. It can be wholly eliminated by good data practices e.g. backups. (No one backs up their Amazon account data. It isn't designed for it. Because the "webdevs" think of the data as their boss's - squarequoting "webdev" because the effective decision is the CEO's and the "webdev" is just taking some abstract, ill-thought-through decision and making the ramifications concrete.)
On the other hand, it also sucks a lot when your gratuitously collected private information is taken to the darkweb. As countries become more accustomed to dealing with databreaches, they are beginning to consider legislating harsh compensation requirements and painful fines. Once that's happened, almost all of the private data that the user has in their account? Let the user keep it. We webdevs and our mortal enemies in business/sales/product will have to innovate new decentralised databases - where each node is a users' computer. And yeah, some things will be harder or not even possible (for the user). Other things will become possible that aren't at the moment (for the user). And at least you won't go bankrupt when a state level actor decides your database is valuable.
There are some exceptions to this. Notably, Amazon is ruthless in enforcement of their "One Person, One Account" policy (worded not so eloquently in their official terms).
If you lose access to your Amazon account and open a new account, there's a non-trivial chance they shut it down without explanation. If your account ever participated in the marketplace from a seller side, then this policy is even more ruthlessly enforced.
Which means... email address verification is necessary for Amazon to at least guard against type-o's and other common form data-entry errors.
If you lose access to your Amazon account and open a new account, there's a non-trivial chance they shut it down without explanation. If your account ever participated in the marketplace from a seller side, then this policy is even more ruthlessly enforced.
Which means... email address verification is necessary for Amazon to at least guard against type-o's and other common form data-entry errors.
Is this policy for a specific kind of Amazon account? I didn't recall seeing anything in the TOS, and they appear to have first class support for people with multiple accounts.
https://www.amazon.com/gp/help/customer/display.html%3FnodeI...
https://www.amazon.com/gp/help/customer/display.html%3FnodeI...
Most people need to back up is a receipt for their transaction, and the main method people expect for receiving it is... email.
I worked for a big fintech.
- Zero email validation at signup measurably reduces friction. [1]
- Require email validation for bank deposits, once your customer is further onboarded and invested in the product.
- Encourage 2FA and other measures as the customer grows.
[1] (Much to the chagrin of all security-adjacent, marketing, account owning, risk, ATO prevention, etc. teams. I was directly in the path of these decisions, and it was interesting to see the various stakeholders argue their points. Growth funnel wears the pants.)
- Zero email validation at signup measurably reduces friction. [1]
- Require email validation for bank deposits, once your customer is further onboarded and invested in the product.
- Encourage 2FA and other measures as the customer grows.
[1] (Much to the chagrin of all security-adjacent, marketing, account owning, risk, ATO prevention, etc. teams. I was directly in the path of these decisions, and it was interesting to see the various stakeholders argue their points. Growth funnel wears the pants.)
Yeah you may not realize that a significant fraction of people don't remember passwords at all and need to reset on every login. If you don't allow self serve password resets you're creating a huge customer service burden.
Users are trained to put in their email. Making them choose a username increases friction if the username is non-public (i.e. it's not instagram). Ideally, using SSO speeds the whole thing up, but if not, then it's better to just use email.
> 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.
Not the only reason. It adds friction for people trying to create an army of sockpuppet accounts.
Not the only reason. It adds friction for people trying to create an army of sockpuppet accounts.
Not a lot of friction. Especially if you don't restrict the allowed email providers.
I'd say that depends on what 'a conversion' is - if it's buying physical things (and getting shipping confirmations for them), an email is maybe not absolutely required, but most of your customers would probably still rather they got those?
Maybe they want SMS updates to their shipping, does that mean you should ask for confirmed phone numbers on signup? Of course not. Let them enter their email or phone number for shipping updates when they're confirming their purchase.
Ideally you shouldn't require users to make an account to make a purchase at all. There should be a "guest" path for purchases. Some sites still get this right. I can buy anything from plane tickets to pizzas without having an account on the company's website. Meanwhile half the "Show HN" non-commercial toy websites I come across seem to require a confirmed email for no good reason at all (probably because the webdev is hoping his little toy website somehow becomes a real business, and then he can spam my inbox with updates about this and turn me into a paying customer.)
Off the top of my head, here are some companies that don't require me to confirm my email address when making a purchase or an account: Southwest Airlines. Dominos Pizza, Hacker News, Reddit.
If those guys don't need a confirmed email address, probably your site doesn't either.
Ideally you shouldn't require users to make an account to make a purchase at all. There should be a "guest" path for purchases. Some sites still get this right. I can buy anything from plane tickets to pizzas without having an account on the company's website. Meanwhile half the "Show HN" non-commercial toy websites I come across seem to require a confirmed email for no good reason at all (probably because the webdev is hoping his little toy website somehow becomes a real business, and then he can spam my inbox with updates about this and turn me into a paying customer.)
Off the top of my head, here are some companies that don't require me to confirm my email address when making a purchase or an account: Southwest Airlines. Dominos Pizza, Hacker News, Reddit.
If those guys don't need a confirmed email address, probably your site doesn't either.
These are not good examples of everyday websites.
Southwest Airlines knows an awful lot more information about you than you provide them. They don't need your email address because they know who you are - and they make it your responsibility to monitor changes to your schedule/flight.
Dominos Pizza allows you to monitor in real time the status of your delivery on their website after checkout. You can provide an email address to access the tracking status page again if you close it.
Hacker News is not a good representation of anything outside of a very tech-focused forum. It's designed to be anonymous, there is nothing to keep track of (order status etc) and if you lose your password to HN, you might just be SOL. That's not going to fly for the general public.
Reddit is focused on eyeballs and clicks - nothing else. You're not buying things on Reddit and waiting for them to deliver to your house or whatever. Reddit just needs you to click and look at things to make money. Reddit also requires an email address, but if you don't provide a real one then you're SOL if you lose access. Again, not going to fly for the general public.
The reality is, most regular sites do need a reliable way to contact you for business reasons. Some are even required to have your contact information (for international shipments, as one example).
Your email inbox does a good job of holding emails for you, so let's stop pretending it's a huge burden to get an email... and if you find your way onto some newsletter list just click the unsubscribe button. It's not that hard...
Southwest Airlines knows an awful lot more information about you than you provide them. They don't need your email address because they know who you are - and they make it your responsibility to monitor changes to your schedule/flight.
Dominos Pizza allows you to monitor in real time the status of your delivery on their website after checkout. You can provide an email address to access the tracking status page again if you close it.
Hacker News is not a good representation of anything outside of a very tech-focused forum. It's designed to be anonymous, there is nothing to keep track of (order status etc) and if you lose your password to HN, you might just be SOL. That's not going to fly for the general public.
Reddit is focused on eyeballs and clicks - nothing else. You're not buying things on Reddit and waiting for them to deliver to your house or whatever. Reddit just needs you to click and look at things to make money. Reddit also requires an email address, but if you don't provide a real one then you're SOL if you lose access. Again, not going to fly for the general public.
The reality is, most regular sites do need a reliable way to contact you for business reasons. Some are even required to have your contact information (for international shipments, as one example).
Your email inbox does a good job of holding emails for you, so let's stop pretending it's a huge burden to get an email... and if you find your way onto some newsletter list just click the unsubscribe button. It's not that hard...
Dominos Pizza allows you to monitor in real time the status of your delivery on their website after checkout
Dominos doesn't even verify that you own an email address when you register one. I have received Dominos delivery updates sent to my email address for pizzas delivered to a person who doesn't even live in the same country as me. These updates contained a bunch of PII information about the customer including their exact home address depicted on a map inside the email.
Web developers: verify that people own the email addresses or phone numbers that they register!
Dominos doesn't even verify that you own an email address when you register one. I have received Dominos delivery updates sent to my email address for pizzas delivered to a person who doesn't even live in the same country as me. These updates contained a bunch of PII information about the customer including their exact home address depicted on a map inside the email.
Web developers: verify that people own the email addresses or phone numbers that they register!
> Dominos doesn't even verify that you own an email address when you register one
Considering that Domino's doesn't verify you're actually at the physical address you're having a pizza delivered to, I doubt they are sweating an email addy
Considering that Domino's doesn't verify you're actually at the physical address you're having a pizza delivered to, I doubt they are sweating an email addy
> The reality is, most regular sites do need a reliable way to contact you for business reasons.
In these cases, which I think are more unusual than usual, a email can be required during checkout. There's almost never a valid reason to require a confirmed email account during account creation, before the user has even decided if they want to make a purchase.
In these cases, which I think are more unusual than usual, a email can be required during checkout. There's almost never a valid reason to require a confirmed email account during account creation, before the user has even decided if they want to make a purchase.
We might be envisioning very different types of websites then. Some random dude's blog - no you don't need to enter your email address.
Buying something online or subscribing to a service? The company does need a way to contact you... which is going to be email.
Email addresses are more-or-less globally unique, which makes them very handy for identifying an individual customer. Verifying the email address is an extra step that can provide the business with more confidence when dealing with a new potential customer. Certain types of fraud vanish or are greatly impeded with email verification, such as carding attacks. Customer support tasks can be performed more reliably and with identity confidence of who they are dealing with, stopping account impersonation attacks and more.
With all that said, sites that choose not to verify email addresses put a greater burden onto the customer for support needs. Password resets, order tracking, cancelling subscriptions etc. all become more difficult if the email address entered by the customer had a type-o for example, or belongs to someone else.
That doesn't mean all sites should verify email addresses - but it does mean railing against any site that does is misguided.
Buying something online or subscribing to a service? The company does need a way to contact you... which is going to be email.
Email addresses are more-or-less globally unique, which makes them very handy for identifying an individual customer. Verifying the email address is an extra step that can provide the business with more confidence when dealing with a new potential customer. Certain types of fraud vanish or are greatly impeded with email verification, such as carding attacks. Customer support tasks can be performed more reliably and with identity confidence of who they are dealing with, stopping account impersonation attacks and more.
With all that said, sites that choose not to verify email addresses put a greater burden onto the customer for support needs. Password resets, order tracking, cancelling subscriptions etc. all become more difficult if the email address entered by the customer had a type-o for example, or belongs to someone else.
That doesn't mean all sites should verify email addresses - but it does mean railing against any site that does is misguided.
Twitter or discord, why do these require me to confirm an email or phone number when reddit doesn't? Why do shop websites like Etsy require me to confirm my email address before I even decide to purchase or sell anything? If you're worried about credit card fraud, confirm my identity when I give you my payment info, not when I'm merely registering an account.
What you propose would lead to increased cart abandonment. No business wants that.
Account registration is the perfect time to do email verification, if the business is going to do it. The user already is in that "mindset"... and clicking a link is really not very difficult. Everyone in that flow understands what is going on.
Sites like Etsy probably have a significant fraud problem... and as previously discussed verifying email addresses goes a very long way towards minimizing risk.
Companies like Twitter and Discord likely require verification for the same reasons - fraud/abuse. I am aware Twitter has had a history of abusing that data, but the initial reason for verification remains the same.
I'm actually surprised more websites don't require verification. It's easy to do, and the benefits are very obvious. Most users aren't bothered by it either...
Smaller ecommerce sites still keep the Guest Checkout flow available because they would rather not impede checkout for any reason - although that means they take on additional risk. Major ecommerce sites require accounts (think Amazon, Newegg, Etsy, Walmart, Zappos, Chewy) and some do require verification. At their scale, fraud and abuse become very difficult problems that require a lot of time/resources.
OAuth/Social Login has removed some of the need to verify email addresses at the business level. This is because a trusted 3rd party Identity Provider has already done that for you, and most OIDC IDP's already provide an "email_verified" flag of sorts. Depending on your trust level (connecting to Google's IDP vs. random IDP), you can just use this data and assume it's been verified, removing that step for the customer.
Account registration is the perfect time to do email verification, if the business is going to do it. The user already is in that "mindset"... and clicking a link is really not very difficult. Everyone in that flow understands what is going on.
Sites like Etsy probably have a significant fraud problem... and as previously discussed verifying email addresses goes a very long way towards minimizing risk.
Companies like Twitter and Discord likely require verification for the same reasons - fraud/abuse. I am aware Twitter has had a history of abusing that data, but the initial reason for verification remains the same.
I'm actually surprised more websites don't require verification. It's easy to do, and the benefits are very obvious. Most users aren't bothered by it either...
Smaller ecommerce sites still keep the Guest Checkout flow available because they would rather not impede checkout for any reason - although that means they take on additional risk. Major ecommerce sites require accounts (think Amazon, Newegg, Etsy, Walmart, Zappos, Chewy) and some do require verification. At their scale, fraud and abuse become very difficult problems that require a lot of time/resources.
OAuth/Social Login has removed some of the need to verify email addresses at the business level. This is because a trusted 3rd party Identity Provider has already done that for you, and most OIDC IDP's already provide an "email_verified" flag of sorts. Depending on your trust level (connecting to Google's IDP vs. random IDP), you can just use this data and assume it's been verified, removing that step for the customer.
Could part of the pattern for requiring an email address (or phone number) at time of purchase be reduced customer support costs for the vendor.
With an email address the customer can reset their own password for using their account with self service features - like get a duplicate invoice or view/change/cancel a reservation or similar stuff.
Without an email address / phone number / something to link a customer to their order, the customer will need to phone up a call centre or visit a store or use live chat to get what they need.
Southwest probably have a call centre or live chat anyway. Dominos have stores (and presumably a customer service department) and a pizza order is probably only interesting for a short time.
If the customer can't sort their order out or get it sorted out, they will complain or give bad feedback. Even if it was their choice not to leave an email as they were too busy.
Your business without any of these things has no incentive to get them if it can just collect emails instead and let users use self service features. Even if you already have call centers / live chat / stores then your cost of dealing with the customer via a self service portal is probably way cheaper than using them.
With an email address the customer can reset their own password for using their account with self service features - like get a duplicate invoice or view/change/cancel a reservation or similar stuff.
Without an email address / phone number / something to link a customer to their order, the customer will need to phone up a call centre or visit a store or use live chat to get what they need.
Southwest probably have a call centre or live chat anyway. Dominos have stores (and presumably a customer service department) and a pizza order is probably only interesting for a short time.
If the customer can't sort their order out or get it sorted out, they will complain or give bad feedback. Even if it was their choice not to leave an email as they were too busy.
Your business without any of these things has no incentive to get them if it can just collect emails instead and let users use self service features. Even if you already have call centers / live chat / stores then your cost of dealing with the customer via a self service portal is probably way cheaper than using them.
You're missing his point. He's saying that the whole point of having an "account" is often not actually necessary. Domino's and Southwest are much more focused on making it as easy as possible to buy a pizza or a plane ticket, without an account being mandatory.
I was attempting to say it may be more convenient / less expensive for the vendor if all customers are forced to have self-service accounts rather than having to complain to manned customer service or via twitter or whatever.
sending those messages is part of the same business case as reducing friction by not confirming the address :)
>spam users with nonsense like product updates
IMHO, not all product updates are nonsense.
IMHO, not all product updates are nonsense.
[x] - Send me emails about product updates.
(Receiving these emails should be opt-in. But companies often find lame excuses to ignore this preference so I prefer to not hand over my email address at all.)
(Receiving these emails should be opt-in. But companies often find lame excuses to ignore this preference so I prefer to not hand over my email address at all.)
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 automatically get associated with the account (or after confirmation), then that’s bad as well if you really entered someone else’s email address, because your order will then get associated with their account.
This is the reason why attempting to sign up for an existing account generally fails right away, at least for online retailers.
This is the reason why attempting to sign up for an existing account generally fails right away, at least for online retailers.
Not sure exactly what you mean? Are you referring to a purchase flow where you are buying something and also given the option to checkout as guest or signin/signup?
I am only speaking to the typical signup flow that anyone can access signed out without putting in any information besides email/pw. If you are in a purchase flow where valid credit card info is already entered and is going to result in actual purchase $$, you've already excluded bots/hackers who would be trying to brute force account enumeration. It would be totally fine to confirm the existence of an account in a web form in this situation as it is not a flow that can be easily brute forced for free with little effort or info needed (like a credit card).
I am only speaking to the typical signup flow that anyone can access signed out without putting in any information besides email/pw. If you are in a purchase flow where valid credit card info is already entered and is going to result in actual purchase $$, you've already excluded bots/hackers who would be trying to brute force account enumeration. It would be totally fine to confirm the existence of an account in a web form in this situation as it is not a flow that can be easily brute forced for free with little effort or info needed (like a credit card).
> 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.
> 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.
Woocommerce plug-in of Wordpress solved that issue. You can checkout as a guest with someone else’s email, you won’t see other orders from that email and if you do want to see them then you need to sign up for an account
What if it wasn’t someone else’s email, but your own with an existing account? Can you re-associate your order with the existing account?
It can only be done manually by admin upon request. Otherwise if you are not logged in then you have a guest order.
That exact strategy is described in the second paragraph but the author argues (and I agree) that it is so arduous it will cause you to lose many users for questionable benefit.
Yes but the exact quote is confusing as he specifically mentions email addresses (in bold text). I know the author mentions usernames elsewhere in the article and I agree with the author this isn't applicable to websites that allow username signup since anyone can pick any random string... But for email address signup, as the exact quote mentions, there is no additional context switching since you already need to confirm the email address regardless.
Often you don’t need to confirm the e-mail address to complete whatever workflow you’re doing.
Sure, companies are free to make their own choices based on their business incentives. But if you can create an account and be logged in without verifying an email address, then arguably the email address wasn't needed in the first place and you should just allow any type of username string. If the goal of your website is for email address to be the username, the you should confirm the user actually owns the email address they claim first - since anyone could lie and put a random email they don't own.
In simple registrations this is fine. In multi-page registrations with long forms, it can waste the user's time by making them input all the data again when it wasn't needed, though.
Except in really critical applications like payments, etc., as a user I'd rather have the convenience of being warned early about already having an account that the little extra security.
Except in really critical applications like payments, etc., as a user I'd rather have the convenience of being warned early about already having an account that the little extra security.
How often does it happen that you fill out a multi-page registration form just to notify you that you already have an account? I rarely bump into the issue of already having an account that I forgot.
Is saving that extra amount of work in a rare case a concern in practice? Sure, it would annoy me a bit if it happened to me, but I'd be more like "man, I'm stupid" instead of "man, this site is stupid, I'll never go there again."
Is saving that extra amount of work in a rare case a concern in practice? Sure, it would annoy me a bit if it happened to me, but I'd be more like "man, I'm stupid" instead of "man, this site is stupid, I'll never go there again."
It has happened to me sometimes with ecommerce websites that I only use once every few years.
Only a mild annoyance, but still more annoying than it would be to have someone access my account on such websites (which would be basically negligible, as I don't store payment information there, and you have to multiply it by the also negligible probability that the information leak from the login form is key in letting the bad dudes access my account).
Only a mild annoyance, but still more annoying than it would be to have someone access my account on such websites (which would be basically negligible, as I don't store payment information there, and you have to multiply it by the also negligible probability that the information leak from the login form is key in letting the bad dudes access my account).
You shouldn't be doing long web forms before creating an account anyway.
This is commonly the case for online shopping, where account creation is optional and may only occur after confirmation, but the order will be placed regardless.
But in that case, there is still an account (just without login ability), and you are probably even sending an email.
So in the email you can include a link to optional account (username/password) creation.
And if you aren't sending an email, then the user has clearly decided not to create an account.
So in the email you can include a link to optional account (username/password) creation.
And if you aren't sending an email, then the user has clearly decided not to create an account.
The problem is if an account for that email already exists, see https://news.ycombinator.com/item?id=33720063.
See my comment https://news.ycombinator.com/item?id=33720405
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.
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.
/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.
I can sympathize with your frustration about long web forms, but that seems to me like a separate issue with a separate solution.
People shouldn't be making long forms part of account creation unless absolutely necessary; in which case it should already be obvious to the user that it is.
If it's somehow necessary but not obvious, you can put up a friendly warning. Maybe something like, "Step 1/12" or "expected registration time 15min."
People shouldn't be making long forms part of account creation unless absolutely necessary; in which case it should already be obvious to the user that it is.
If it's somehow necessary but not obvious, you can put up a friendly warning. Maybe something like, "Step 1/12" or "expected registration time 15min."
[deleted]
While clever, this system has UI tradeoffs, if I need to break my signup flow in order to click on a link and return to the signup page.
I believe this is also non-standard right now.
I believe this is also non-standard right now.
Are you saying your signup flow would automatically log the user in without confirming their email address (verify later)? I wouldn't suggest that for most websites as that would allow someone to signup with an email address they don't own.
For most websites transacting with potentially sensitive information, having an email sent to confirm you own the email address should already be part of the normal flow, so I'm not suggesting any extra step here. I was only suggesting an alternative email response in the situation you try to signup with an email that already exists. The normal happy path signup flow for a new account is not affected at all by my comment.
For most websites transacting with potentially sensitive information, having an email sent to confirm you own the email address should already be part of the normal flow, so I'm not suggesting any extra step here. I was only suggesting an alternative email response in the situation you try to signup with an email that already exists. The normal happy path signup flow for a new account is not affected at all by my comment.
I think the sibling post by samwillis explains my view the clearest.
Basically, the business case for breaking the signup flow to require users to check their email is low. It interrupts flow and reduces conversion rates.
The suggestion then is yes, you are allowed to use emails you don't own to sign up for an account. The reason this is allowable is that who would want to do it? The account would be broken and the real owner of that account can pop your password.
Basically, the business case for breaking the signup flow to require users to check their email is low. It interrupts flow and reduces conversion rates.
The suggestion then is yes, you are allowed to use emails you don't own to sign up for an account. The reason this is allowable is that who would want to do it? The account would be broken and the real owner of that account can pop your password.
Could you please elaborate? What's the standard best practice for signup now?
And then what happens when the user tries to login with the password they just "created". They will get the same error message as before, but be extremely confused since they just "registered" with that password. Not to mention their browser may have prompted and stored the fake registration password, etc.
What do you mean login? I'm talking about the signup flow. The signin flow would be consistent with what is discussed in the article "invalid username or pw".
What do users usually do after registering an account? They try to login with it (assuming they aren't automatically logged in after registration which is what I would generally prefer / expect as a user).
You are giving the user so many chances to just say "forget this" and move on to a different website. Especially if they are on mobile, registering for services is a huge pain in the butt.
My basic point is you are severely impairing the UX to prevent what I think is an extremely minor and generally irrelevant piece of information leakage.
You are giving the user so many chances to just say "forget this" and move on to a different website. Especially if they are on mobile, registering for services is a huge pain in the butt.
My basic point is you are severely impairing the UX to prevent what I think is an extremely minor and generally irrelevant piece of information leakage.
The flow is
1. Sign up for an account 2. Enter the email 3. Receive a confirmation email 4. Create password 5. Sign in
This is what op means. You just ingest step 2 without confirming the email is used or not. The actual account creation should occur only after email confirmation.
1. Sign up for an account 2. Enter the email 3. Receive a confirmation email 4. Create password 5. Sign in
This is what op means. You just ingest step 2 without confirming the email is used or not. The actual account creation should occur only after email confirmation.
Gotcha. That does make more sense and basically signup and reset password are essentially the same process. If the user doesn't have an account previously at that point you collect the information needed to proceed. I personally would not want to break up my onboarding experience like this but I can see other people making the trade off.
If the GP is assuming that initial password setting is done via the verification link sent in the verification email, then the workflow they're proposing won't cause the confusion you describe. In other words, the "verify my email address" link is to a form that says "Create and verify password to confirm your email address."
If you're assuming that initial password entry is done before email verification, then there's a possibility for confusion there.
Honestly, the lowest friction workflows collect information lazily. Don't require setting a password (if at all... expiring login links in emails are a nice alternative) until the email is verified. Don't require a mailing address or credit card number at all, but have a "save for later" checkbox/button as part of the checkout workflow, etc.
If you're assuming that initial password entry is done before email verification, then there's a possibility for confusion there.
Honestly, the lowest friction workflows collect information lazily. Don't require setting a password (if at all... expiring login links in emails are a nice alternative) until the email is verified. Don't require a mailing address or credit card number at all, but have a "save for later" checkbox/button as part of the checkout workflow, etc.
On my site it works this way...
1. Choose desired plan.
2. Enter username, password, checkbox for terms of service.
3. Get prompted to enter the 6 digit confirmation code that was emailed to you (if you were already registered, it says you have an account and links to the login and password reset pages if required).
4. Registration is complete and the user is automatically signed in.
The username or email address isn't blocked until someone completes a registration with it.
1. Choose desired plan.
2. Enter username, password, checkbox for terms of service.
3. Get prompted to enter the 6 digit confirmation code that was emailed to you (if you were already registered, it says you have an account and links to the login and password reset pages if required).
4. Registration is complete and the user is automatically signed in.
The username or email address isn't blocked until someone completes a registration with it.
The user should be automatically logged in after successful registration if the flow is implemented correctly.
You’d defer password setting if you were doing this I would think.
Another method is to delegate the registration and login flow to external providers, using OAuth.
If you have to log in to a website via one of Microsoft, Google, Facebook, Twitter, etc. then, if implemented properly, there's no way of knowing if an account associated with this external identity exists already.
If you have to log in to a website via one of Microsoft, Google, Facebook, Twitter, etc. then, if implemented properly, there's no way of knowing if an account associated with this external identity exists already.
Most of those are trying to track me around the net for their own purposes. I'm not volunteering any extra information for them to profile me with. No thanks.
The only extra information you would be volunteering is that you signed in to a specific website. In most cases, this is not really a big deal.
If I don't want them knowing I surfed to somewebsite.com, why would I want them to know that I actually logged in to someotherwebsite.com?
I get that people have different levels of trust for these services than I do. I'm just more cynical than most, I guess.
I get that people have different levels of trust for these services than I do. I'm just more cynical than most, I guess.
You are also trusting the Oauth provider to never login as you for their own inscrutable purposes.
Absolutely. In the case of Facebook, it's easy to imagine them logging into websites as you to slurp up your contact list on that site. Don't worry, you agreed to it somewhere in the thousand pages of small print!
Or as the case of twitter demonstrates, you're also trusting all future owners of the Oauth provider, whoever they may be. If an erratic billionaire with a penchant for breaking the rules whenever it suits him buys your Oauth provider, who's to say what he'll do with his new access? He could treat your accounts as his personal toys. Better hope you don't earn his personal ire when he's on another wine and ambien bender.
Or as the case of twitter demonstrates, you're also trusting all future owners of the Oauth provider, whoever they may be. If an erratic billionaire with a penchant for breaking the rules whenever it suits him buys your Oauth provider, who's to say what he'll do with his new access? He could treat your accounts as his personal toys. Better hope you don't earn his personal ire when he's on another wine and ambien bender.
Linked in used to (maybe still does) encourage you to provide them login details to your email so that they can scan it for potential matches.
> this is not really a big deal.
If it's not a big deal, then why do they offer this service "for free"?
It's all part of their commercial panopticon. You're missing the forest for the trees.
If it's not a big deal, then why do they offer this service "for free"?
It's all part of their commercial panopticon. You're missing the forest for the trees.
[deleted]
True. Moreover, even if a site implemented this in a naive way, they made the UX much worse for the attacker.
And that constitutes a significant issue, if we follow the reasoning of the article.
It does, actually: it hampers casual attackers -- those looking for any account in. On the other hand, attackers out to break into a specific account will not be deterred. Then again: they are not deterred in either case, so you might as well go with the version that impacts some attackers.
It does, actually: it hampers casual attackers -- those looking for any account in. On the other hand, attackers out to break into a specific account will not be deterred. Then again: they are not deterred in either case, so you might as well go with the version that impacts some attackers.
If you did implement it like this it would be helpful to receive an email telling you that somebody has tried to re-register the email address you already have an account with.
That's the option #2 they described.
Exactly, if you reveal that an account exists when you just type in an email address, then you have a privacy failure and probably a security failure.
For example, the OpenSSF's secure software development fundamentals course <https://openssf.org/training/courses/> in its section on minimizing feedback <https://github.com/ossf/secure-sw-dev-fundamentals/blob/main...> says:
* If a user tries to create an account using an email address, don't tell the user if an account with that email address already exists. Similarly, if a user tries to do a password reset using an email address, don't tell the user if there is no account with that email address. Providing that information would allow an attacker to determine if a specific email address is being used (or not) by some existing account.
Now for the unpopular take: not everyone lives in the US. The GDPR requires protection of personally-identifying information, and in many cases that includes email addresses that identify individuals. There are exceptions, but it's typically better to keep email addresses private unless the user specifically authorizes it.
For example, the OpenSSF's secure software development fundamentals course <https://openssf.org/training/courses/> in its section on minimizing feedback <https://github.com/ossf/secure-sw-dev-fundamentals/blob/main...> says:
* If a user tries to create an account using an email address, don't tell the user if an account with that email address already exists. Similarly, if a user tries to do a password reset using an email address, don't tell the user if there is no account with that email address. Providing that information would allow an attacker to determine if a specific email address is being used (or not) by some existing account.
Now for the unpopular take: not everyone lives in the US. The GDPR requires protection of personally-identifying information, and in many cases that includes email addresses that identify individuals. There are exceptions, but it's typically better to keep email addresses private unless the user specifically authorizes it.
Sure, I guess? But the overwhelming majority of sites on the internet do not do this. Primarily because their new signup flow has priorities that matter an order of magnitude higher for them than avoiding leaking whether an account already exists.
I've used exactly one site ever that had this sign-up flow, and hundreds that had the stupid "invalid username or password" error.
By your definition almost no popular website - including Google - implements signup flow correctly.
[deleted]
0.1% representing!
I got some code to fix.
I got some code to fix.
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.
The website doesn't always know which one you got wrong, and assuming one way or the other just makes things worse.
> If you mistype your username, you might have entered another, existing username.
That's a good point, but there is no way the website can detect that situation, and I suspect it is much less likely than typing your correct username and the wrong password.
> The website doesn't always know which one you got wrong, and assuming one way or the other just makes things worse.
If the website doesn't know which one you got wrong, then yes, it should just tell you so; the article is not arguing otherwise.
That's a good point, but there is no way the website can detect that situation, and I suspect it is much less likely than typing your correct username and the wrong password.
> The website doesn't always know which one you got wrong, and assuming one way or the other just makes things worse.
If the website doesn't know which one you got wrong, then yes, it should just tell you so; the article is not arguing otherwise.
> there is no way the website can detect that situation
Why? The website can salt, hash, match your password against all the hashed passwords for all the closest usernames within a certain edit distance.
Not saying this is a good idea security-wise, but it's not impossible.
Why? The website can salt, hash, match your password against all the hashed passwords for all the closest usernames within a certain edit distance.
Not saying this is a good idea security-wise, but it's not impossible.
Apart from the security issues you've yourself noted, it's possible that the entered password matches another account's password coincidentally, not because the user intended to log in to that account.
If your account has the same password as another account that's 1 or 2 letters different, it's not really the site's job to protect you. You screwed up.
This is not a very big problem security-wise. It makes online attacks slightly easier, but you can limit online attempts pretty easily. It doesn't affect offline attempts at all.
The downvotes dheera got are extra inappropriate because they were just saying it's doable.
This is not a very big problem security-wise. It makes online attacks slightly easier, but you can limit online attempts pretty easily. It doesn't affect offline attempts at all.
The downvotes dheera got are extra inappropriate because they were just saying it's doable.
It's also a terrible idea from a performance standpoint.
I remember some system on the coding horrors site or similar that would tell you “password already used” if anyone had it.
That could allow “bad username” if you got the password right!
That could allow “bad username” if you got the password right!
comprev(9)
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 exist, so hiding that data point is not much good for security.
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 exist, so hiding that data point is not much good for security.
> 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.
The parent poster already addressed that though:
“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.”
If you inform the user the username they typed exists, the chance of them not thinking about double-checking they didn’t mistype their own username increases.
The parent poster already addressed that though:
“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.”
If you inform the user the username they typed exists, the chance of them not thinking about double-checking they didn’t mistype their own username increases.
>The parent poster already addressed that
Thank you for your comment, but I don't agree
"telling the user that the username they typed exists, but they haven't offered the correct password for it" - is extremely different from Just telling the user 'wrong password'. It's different because it provides more information
>If you inform the user the username they typed exists, the chance of them not thinking about double-checking they didn’t mistype their own username increases.
That seems to be a user problem first of all, because it's based on the user's mistaken belief about the uniqueness of usernames. If possible, it would be best to help the user understand this.
Thank you for your comment, but I don't agree
"telling the user that the username they typed exists, but they haven't offered the correct password for it" - is extremely different from Just telling the user 'wrong password'. It's different because it provides more information
>If you inform the user the username they typed exists, the chance of them not thinking about double-checking they didn’t mistype their own username increases.
That seems to be a user problem first of all, because it's based on the user's mistaken belief about the uniqueness of usernames. If possible, it would be best to help the user understand this.
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.
Depending on your particular service, there's a better alternative for not leaking the existing account. A service I worked on previously was super sensitive and we didn't want to leak the existence of an existing account. What we did instead was asked for the email on the first page of signup, we verified the email was active by sending an email and a link to continue signup. If they already have an account we'd inform them in that email that they already have an account.
This way, the attacker actually has to have access to the email in question to know that an existing account is present on the service.
If you do the whole signup process on a single page and validate the email there then yea, you're gonna have a rough time.
This way, the attacker actually has to have access to the email in question to know that an existing account is present on the service.
If you do the whole signup process on a single page and validate the email there then yea, you're gonna have a rough time.
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.
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.
That was presented as an option, but explicitly not recommended.
> …you can make the signup process email based.…I don't recommend this, because of the context switches, though you can implement it.
> …you can make the signup process email based.…I don't recommend this, because of the context switches, though you can implement it.
practically all website that use an email as username nowadays require email confirmation, so already include the context switch. Because in the end, sending an email is the only way to verify that the email address is correct and you don't want an incorrect email address in your database if you rely on that communication channel.
Now, if you have accounts in places where email addresses are not required and usernames take the place, the calculus may change. But using the context switch as an argument here is just weak.
Now, if you have accounts in places where email addresses are not required and usernames take the place, the calculus may change. But using the context switch as an argument here is just weak.
I don't get it. It's fine to leak/allow user enumeration on the login page because it's leaked elsewhere anyway? That's a pretty big assumption.
One way to allow users to register using their email address without leaking any information is to just say "user created, please check your inbox to confirm your email address" or something like that. If the user already exists, swap the confirmation email for a warning email if they already have an account.
Or am I missing something?
One way to allow users to register using their email address without leaking any information is to just say "user created, please check your inbox to confirm your email address" or something like that. If the user already exists, swap the confirmation email for a warning email if they already have an account.
Or am I missing something?
In a sense, yes. If you’re revealing an account’s existence on one page, your system isn’t made more secure if you hide its existence on another page. If you think it does, you’re fooling yourself. Better to use other tools (like rate limiting) to improve security.
And yes, you’re missing the second part of the article where the author mentions the registration flow you describe and then points out that it’s not a great user experience.
And yes, you’re missing the second part of the article where the author mentions the registration flow you describe and then points out that it’s not a great user experience.
[deleted]
There is also the question of leaking whether a given user has an account on a website or not.
Maybe I don't want my employer to know that I have an account on competitor-service.com, or my partner to know that I have an account on kinky-thing.website.
It might not be a security issue, but it could be a privacy issue.
Maybe I don't want my employer to know that I have an account on competitor-service.com, or my partner to know that I have an account on kinky-thing.website.
It might not be a security issue, but it could be a privacy issue.
> Unfortunately this assumes that there's no other way for an attacker to discover whether a username/email address is registered for a service. This assumption is incorrect.
> 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 point is undermined by the sign-up workflow informing of whether an account is registered under a given username.
> 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 point is undermined by the sign-up workflow informing of whether an account is registered under a given username.
That depends on the sign-up workflow. It is possible to not provide the information "user already exist" on sign-up and instead just say "we sent you an email, please confirm". In this scenario a potential attacker who just wants to check for existing email addresses has no access to the email addresses he wants to check.
The contents of the email could be something like "Hey you just tried to register with this email address, but we already have an existing account with this email address ... Was that you? ... Maybe you have forgotten got your password?"
The contents of the email could be something like "Hey you just tried to register with this email address, but we already have an existing account with this email address ... Was that you? ... Maybe you have forgotten got your password?"
The author explains in the article that you're not protected from that case either, as the attacker can try to sign up with your email and find out anyway if that email is already registered.
Many services let you sign up with an existing email and just send a “you tried to sign up, but you seem to have an address already.” to the account owner. In that case it’s indistinguishable for the attacker.
Many services already require email confirmation to finalize the signup process so the extra effort is low.
Many services already require email confirmation to finalize the signup process so the extra effort is low.
And those services also plug the forgotten-password information leak by just informing you "if you have an account, you got an email" instead of giving you an explicit success or error message.
I guess the better point for the article would be "many websites cargo-cult the login error message without understanding why it's there and how that should impact the rest of the service"
I guess the better point for the article would be "many websites cargo-cult the login error message without understanding why it's there and how that should impact the rest of the service"
sounds like a nightmare for someone who forgot their password and has multiple emails, and isn't sure which one is right. did i use the wrong email, did it land in the spam folder, or did my email provider just quietly delete the email (which unfortunately does happen, and not just with dodgy emails/IPs)
I have multiple emails, and this never turned out to be an issue - worst case i just try all of them.
But if you want to improve the implementation, the provide can also decide to send an email in case no account is registered with that email address - "Hey, someone tried a password reset for this email, but there's no associated account. If it was you, ..., if not, ignore this email."
But if you want to improve the implementation, the provide can also decide to send an email in case no account is registered with that email address - "Hey, someone tried a password reset for this email, but there's no associated account. If it was you, ..., if not, ignore this email."
> And those services also plug the forgotten-password information leak by just informing you "if you have an account, you got an email" instead of giving you an explicit success or error message.
This might be a better approach, but one problem I see with it is: what if the email is not actually delivered because of an internal bug in the website? How would users know they didn't receive an email they were supposed to have received, and take the appropriate action (trying again or contacting help), versus that they entered a wrong or unregistered email?
This might be a better approach, but one problem I see with it is: what if the email is not actually delivered because of an internal bug in the website? How would users know they didn't receive an email they were supposed to have received, and take the appropriate action (trying again or contacting help), versus that they entered a wrong or unregistered email?
Email might not be delivered for many reasons that may not all be in control of the sender. It may be classified as spam somewhere along the way. It may simply drop into a black hole. Eventually the user will try again.
That same problem can happen regardless of whether the password reset flow checks for user existence before sending the email.
Those sites probably prompt the attacker with a "We have sent you an email with an activation link" and the owner receives the "you tried to sign up, but you seem to have an address already" message. In this way they don't leak anything to the attacker.
By the way, I've been stuck for years with an ecommerce site that thinks I already registered with them using my email. They're telling me that I must activate the account. I click the link to send me the activation message again but then they say that my email is not registered with them. I'm still stuck and will probably never buy from them because I can't.
By the way, I've been stuck for years with an ecommerce site that thinks I already registered with them using my email. They're telling me that I must activate the account. I click the link to send me the activation message again but then they say that my email is not registered with them. I'm still stuck and will probably never buy from them because I can't.
With this approach, I imagine slightly less technically savvy users might be confused as to whether a new account was actually created before they were also informed of the old account. In other words, they might not know if a new password they entered is also usable for the original account.
Off the top of my head, I cannot remember any site I use that works that way (which is also basically what TFA is suggesting to do as a trade-off implementation)
Not necessarily. You can design the sign up process by way of always ending with a message that says you will be notified.
Xylakant explains how to cope with that in a sibling comment. Note that email is personal information often containing name, surname and maybe a likely year of birth ([email protected]). Leaking it is not OK in several legislations so we should take special care before telling someone that some person is or is not in our database.
He gives a solution for that and says it is "too cumbersome".
This is a huge problem - if I know your email, and can get the error pages, I can find out where you have accounts; sometimes I can even find out the account name with that.
Even worse with phone numbers.
If you want to confirm a user is the same as another user on a different site, and you know their phone number, often part of the recovery process will reveal part of the phone (a text has been sent to *-*-*33, eg).
Even worse with phone numbers.
If you want to confirm a user is the same as another user on a different site, and you know their phone number, often part of the recovery process will reveal part of the phone (a text has been sent to *-*-*33, eg).
> Maybe I don't want my employer to know that I have an account on competitor-service.com, or my partner to know that I have an account on kinky-thing.website.
In that case, maybe employ the basic opsec measure of having a separate email account for competitor-service.com and kinky-thing.website?
In that case, maybe employ the basic opsec measure of having a separate email account for competitor-service.com and kinky-thing.website?
Sure, but if we are talking about improving user experience, I don't see how this helps.
OPSEC and user experience are completely unrelated things.
If you have something to hide (from anyone at all), you have to employ opsec measures. Using an email account that can't be immediately linked back to you is the most basic of them (and would be perfectly sufficient in the scenario described).
It wouldn't even matter if the website didn't leak in any way that an email is registered with them, because data breaches happen, and should one happen, you'd be fucked from that perspective anyway. Remember the Ashley Madison leak?
If you have something to hide (from anyone at all), you have to employ opsec measures. Using an email account that can't be immediately linked back to you is the most basic of them (and would be perfectly sufficient in the scenario described).
It wouldn't even matter if the website didn't leak in any way that an email is registered with them, because data breaches happen, and should one happen, you'd be fucked from that perspective anyway. Remember the Ashley Madison leak?
Are they unrelated?
The article is about a tradeoff between security and user experience, claiming that a given practice is bad experience without any security gain.
The Ashley Madison leak shows that there are plenty of vulnerable users who are not educated to even "the most basic" things to do to protect their privacy.
It's also a question of user experience to protect users against themselves, or against threats they don't know about.
Saying "it's up to the user to do the right thing" isn't really helpful in the context of discussing account creation/login UIs.
The article is about a tradeoff between security and user experience, claiming that a given practice is bad experience without any security gain.
The Ashley Madison leak shows that there are plenty of vulnerable users who are not educated to even "the most basic" things to do to protect their privacy.
It's also a question of user experience to protect users against themselves, or against threats they don't know about.
Saying "it's up to the user to do the right thing" isn't really helpful in the context of discussing account creation/login UIs.
> Are they unrelated?
Perhaps not when considering only the points made in the article, but in the grand scheme of things, yes.
If you’re worried about your opsec (not the sites, and if you’re worried about your opsec, you should treat the site as having no security measures whatsoever), ux is secondary to you, because in the case of a leak you should be in a position where you can plausibly deny everything. And you shouldn’t expect the site to help you with it.
Perhaps not when considering only the points made in the article, but in the grand scheme of things, yes.
If you’re worried about your opsec (not the sites, and if you’re worried about your opsec, you should treat the site as having no security measures whatsoever), ux is secondary to you, because in the case of a leak you should be in a position where you can plausibly deny everything. And you shouldn’t expect the site to help you with it.
While I agree in general that this is the better way, it’s in the end out of the sites control. The could notify the user, but cannot implement any measures that can help to protect the user. Avoiding information leaks is under the sites control - you just need to consider whether you can truly avoid this leak.
For the vast majority of people, this is a bridge too far.
It is an advantage of using things like the apple-generated randomized emails for accounts.
It is an advantage of using things like the apple-generated randomized emails for accounts.
One of the comments there says:
> Heh, after an independent security review we are being forced to take this even further; We lock people out for five minutes after three invalid login attempts. We are no longer allowed to tell users they have been locked out. So, even if they do remember their password (or even does a reset) we just have to tell them their uid/pwd is wrong when they try to log in. And for “forgot password”? Just tell the user “we have sent you an email – IF we recognised the email you put in”.
This sounds absolutely horrible, and now I'm wondering if I've been subject to this behaviour. Couldn't remember my password (for a trivial site where I use one of my reuse passwords and didn't put it in KeePass), started doubting if I had the correct email, eventually reset the whole thing, reset the password to the password that I thought it should have been, and got an error telling me the new password couldn't be the same as the old one.
> Heh, after an independent security review we are being forced to take this even further; We lock people out for five minutes after three invalid login attempts. We are no longer allowed to tell users they have been locked out. So, even if they do remember their password (or even does a reset) we just have to tell them their uid/pwd is wrong when they try to log in. And for “forgot password”? Just tell the user “we have sent you an email – IF we recognised the email you put in”.
This sounds absolutely horrible, and now I'm wondering if I've been subject to this behaviour. Couldn't remember my password (for a trivial site where I use one of my reuse passwords and didn't put it in KeePass), started doubting if I had the correct email, eventually reset the whole thing, reset the password to the password that I thought it should have been, and got an error telling me the new password couldn't be the same as the old one.
I felt this with LastPass. It put in some secret locked mode, and wouldnt let me login even wit h right password. 3-4 hours later, it just started working. I was a paying customer, didnt get any replies to my emails.
It pissed me off so much I moved to 1Password AND Bitwarden -- 2 in parallel, so if anyone pulls this on me again I can immedietely move to the other
It pissed me off so much I moved to 1Password AND Bitwarden -- 2 in parallel, so if anyone pulls this on me again I can immedietely move to the other
> Unfortunately this assumes that there's no other way for an attacker to discover whether a username/email address is registered for a service. This assumption is incorrect.
Security is never perfect, it is always about making it annoying enough that people don't bother. So yes, there are other ways to see if someone has an account. But odds are the person attacking your site is not singling out one account to hack, they are trying bulk attacks with many accounts. So you avoid leaking info to not give the script any more ammo on what else to try. And hopefully the attacker will move on to some site that did give it more ammo.
Security is never perfect, it is always about making it annoying enough that people don't bother. So yes, there are other ways to see if someone has an account. But odds are the person attacking your site is not singling out one account to hack, they are trying bulk attacks with many accounts. So you avoid leaking info to not give the script any more ammo on what else to try. And hopefully the attacker will move on to some site that did give it more ammo.
Maybe instead of saying the email address is already in use on the site, just let the "sign up" happen and tell them to check the email for a confirmation link, and in the confirmation email say "someone is attempting to sign up with this email that is already signed up, if this was you, use the Forgot Password link to reset the password for the existing account. If it was not, click here to report this incident."
> it is always about making it annoying enough that people don't bother.
> But odds are the person attacking your site is not singling out one account to hack, they are trying bulk attacks with many accounts.
I feel like these two statements are at odds with each other. A regular user is going to get annoyed. An attacker using a script and multiple attempts is simply going to include the other way of verifying if an address is real in the script.
> But odds are the person attacking your site is not singling out one account to hack, they are trying bulk attacks with many accounts.
I feel like these two statements are at odds with each other. A regular user is going to get annoyed. An attacker using a script and multiple attempts is simply going to include the other way of verifying if an address is real in the script.
"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.
Yes, but signing up is a more cumbersome process and usually has a CAPTCHA attached to it, unlike logging in.
> 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.
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.
> but checking if the email/username already exists is a separate endpoint that the frontend hits
I'm sure this happens in some cases, but it's definitely not a good practice, would hopefully get flagged by any pentesting or security audit, and also, most people use some sort of framework for auth (devise for Rails, Spring Security for JVM, or similar) - and those usually don't work in that way.
I'm sure this happens in some cases, but it's definitely not a good practice, would hopefully get flagged by any pentesting or security audit, and also, most people use some sort of framework for auth (devise for Rails, Spring Security for JVM, or similar) - and those usually don't work in that way.
Yep. One site I infrequently visit moved from their own account system to the "check your email for a pass code".
This just made me to visit and login even more infrequently.
This just made me to visit and login even more infrequently.
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.
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.
Yes, it's my VPN triggering it. I run my own Wireguard on a DigitalOcean box, and I'm the only user--so not exactly a lot of bad traffic coming off of my IP (may have in the past, though).
With the prevalence of Cloudfare now, it's pretty onerous to captcha every visit to a new site just because VPN. You would think Cloudfare could at least give me a "session" that persisted across the web, if they're going gatekeep the whole fucking thing.
With the prevalence of Cloudfare now, it's pretty onerous to captcha every visit to a new site just because VPN. You would think Cloudfare could at least give me a "session" that persisted across the web, if they're going gatekeep the whole fucking thing.
> I run my own Wireguard on a DigitalOcean box, and I'm the only user
May I ask why you bother doing this? At best, unless Wireguard is also filtering your traffic, the only privacy you're getting is hiding your home IP address. Trackers will still track you by IP and build a profile based on it.
> You would think Cloudfare could at least give me a "session" that persisted across the web, if they're going gatekeep the whole fucking thing.
Yeah, that would make sense.
May I ask why you bother doing this? At best, unless Wireguard is also filtering your traffic, the only privacy you're getting is hiding your home IP address. Trackers will still track you by IP and build a profile based on it.
> You would think Cloudfare could at least give me a "session" that persisted across the web, if they're going gatekeep the whole fucking thing.
Yeah, that would make sense.
I'm just tunneling, really. I prefer the logs on my WG box vs the local ISP and whoever else in-between. I don't think my webhost is really in the business of tracking down VPN users and selling out their browsing history, although it's possible. I do think my ISP probably is cashing in on people's browsing history, though, in some form or fashion.
I use a pi-hole as well to block the trackers etc as much as possible, and so I don't leak DNS requests to the ISP either.
I use a pi-hole as well to block the trackers etc as much as possible, and so I don't leak DNS requests to the ISP either.
Exactly. And please don't add CAPTCHAs to login.
I've worked in infosec for over 15 years. I've built security programs from the ground up at two companies.
I've learned much of compliance/security is cargo culting and/or streetlight effect, if not radicalized.
You can debate the standards, just like you can debate with your retired uncle who watches way too much fox news.
The better solution is to find good enough solutions that let infosec teams check their boxes and move on to more important work.
I've learned much of compliance/security is cargo culting and/or streetlight effect, if not radicalized.
You can debate the standards, just like you can debate with your retired uncle who watches way too much fox news.
The better solution is to find good enough solutions that let infosec teams check their boxes and move on to more important work.
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 email so I still don't know whether I'm registered with the email I entered and should just wait or not registered at all and no email was sent. So instead I just try to register and bam, instant answer.
In addition to that, the context switch to emails increases friction significantly during registration. It's much easier for the user to be logged-in immediately and not have to check their email. That's not even taking into account the wasted time of having to re-enter all your info.
Disclaimer: I know the first issue is solved with a password manager and a faster email service, that's not the point.
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 email so I still don't know whether I'm registered with the email I entered and should just wait or not registered at all and no email was sent. So instead I just try to register and bam, instant answer.
In addition to that, the context switch to emails increases friction significantly during registration. It's much easier for the user to be logged-in immediately and not have to check their email. That's not even taking into account the wasted time of having to re-enter all your info.
Disclaimer: I know the first issue is solved with a password manager and a faster email service, that's not the point.
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 sign-up prompt asking for an email address, and put the link to the password creation page into the sent email.
Set the title/content of the email to clearly show whether an account exists already (with a password reset link) or doesn't (with a password/account creation link).
If the user stops there (the account creation email answered their question: they don't have an account with this email), then you can simply expire the password-set link without ever creating the account.
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 sign-up prompt asking for an email address, and put the link to the password creation page into the sent email.
Set the title/content of the email to clearly show whether an account exists already (with a password reset link) or doesn't (with a password/account creation link).
If the user stops there (the account creation email answered their question: they don't have an account with this email), then you can simply expire the password-set link without ever creating the account.
It's not a solution to the problem I described, if it were the forgot password page would already solve it.
> it often takes 10 minutes for them to send a reset email
That's the only part of your description I can see that I didn't account for. For any of this to work, the email must be sent quickly.
That's the only part of your description I can see that I didn't account for. For any of this to work, the email must be sent quickly.
Yes that's a crucial part of the issue, because many websites send their emails very slowly. So the lack of email can mean both:
"No account for this email"
"Yes, there is an account for this email but it'll become apparent much later"
And your website might send emails fast, but that won't solve the issue because as a user I don't know if your website is fast or slow, so if I'm not registered with the email I entered, I'll see no email in my inbox and I'll have to assume it's one of the slow websites and wait 10 minutes refreshing to be sure.
That's why as a user I use the sign-up form to check if I already have an account instantly, and I'd be dissatisfied by an email-based system.
I guess it's for the website admins to weigh ease of use against security, but I feel often using email worsens the U.X in a way that's not justified by the security benefits.
"No account for this email"
"Yes, there is an account for this email but it'll become apparent much later"
And your website might send emails fast, but that won't solve the issue because as a user I don't know if your website is fast or slow, so if I'm not registered with the email I entered, I'll see no email in my inbox and I'll have to assume it's one of the slow websites and wait 10 minutes refreshing to be sure.
That's why as a user I use the sign-up form to check if I already have an account instantly, and I'd be dissatisfied by an email-based system.
I guess it's for the website admins to weigh ease of use against security, but I feel often using email worsens the U.X in a way that's not justified by the security benefits.
There's only one UX path that doesn't involve email, apart from just logging in, and that's when you do know the password, but don't know the email. In that case, you probably only have few enough email addresses to try that that isn't an issue.
In every other path, you will definitely be waiting (hopefully not long) for an email, so what does it matter?
In every other path, you will definitely be waiting (hopefully not long) for an email, so what does it matter?
Imagine you're an average person and you have 3 emails and 3 passwords that you typically (and repeatedly) use, in any combination. (That's pretty much every non-software person I know, and me on every site before I started using a password manager)
To login you have to try 9 combinations, but your account will be frozen after 3 wrong tries.
The log-in screen does not tell you whether you have the wrong email or the wrong password.
With the sign-up screen you can immediately know which email you used, then you only have to try the 3 passwords, and then you're in.
If you don't remember the password you can go to the forgot password screen and be confident you'll get the reset email, since you know the right address to enter.
To login you have to try 9 combinations, but your account will be frozen after 3 wrong tries.
The log-in screen does not tell you whether you have the wrong email or the wrong password.
With the sign-up screen you can immediately know which email you used, then you only have to try the 3 passwords, and then you're in.
If you don't remember the password you can go to the forgot password screen and be confident you'll get the reset email, since you know the right address to enter.
1. Password reuse is bad.
2. Not getting the email immediatly is an edge case. Any reasonably good system will send it immediatly.
3. You would save yourself a lot of time and energy just using a password manager. No more trying. No more remembering.
2. Not getting the email immediatly is an edge case. Any reasonably good system will send it immediatly.
3. You would save yourself a lot of time and energy just using a password manager. No more trying. No more remembering.
Please read the disclaimer in the first message of this thread (which has not been edited since you replied to it).
I am describing real, widespread user behaviour, and real numerous websites. Responding "the user is dumb" or "the problem does not exist" is not how you design good U.X for your users.
I am describing real, widespread user behaviour, and real numerous websites. Responding "the user is dumb" or "the problem does not exist" is not how you design good U.X for your users.
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.
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.
Not really. The points the author makes are only valid if you presuppose they are correct in that "account e-mails for a site are already public elsewhere", and that isn't a problem on its own.
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.
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.
How do you know the user typed the wrong password and didn't mistype his user name that happens to be someone else's user name?
> 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.
So why not just send an email upon signup with existing email and just show success on signup? I'm guessing email would state that you already have an account there, maybe you need to reset password and email would provide instructions. Using this approach there would be no leakage of information and you can inform the user someone tried signing up with their email.
Edit: This would work only if only email is required for signup, but it would not work with usernames.
So why not just send an email upon signup with existing email and just show success on signup? I'm guessing email would state that you already have an account there, maybe you need to reset password and email would provide instructions. Using this approach there would be no leakage of information and you can inform the user someone tried signing up with their email.
Edit: This would work only if only email is required for signup, but it would not work with usernames.
The article suggests this. But also says you're going to make sign-up a lot more lossy because the context-switching may make some people give up.
Or just allow multiple accounts to use the same email (with an upper limit)
Already people can chuck a + in the user part and register with the same email like [email protected] so really there's not much point trying to maintain a 1:1 user to email ratio.
Already people can chuck a + in the user part and register with the same email like [email protected] so really there's not much point trying to maintain a 1:1 user to email ratio.
That's what I've always done, with an upper limit of 1.
More seriously, this just kicks the can a little bit.
"Already people can chuck a + in the user part...so really there's not much point trying to maintain a 25:1 user to email ratio"
More seriously, this just kicks the can a little bit.
"Already people can chuck a + in the user part...so really there's not much point trying to maintain a 25:1 user to email ratio"
I don't think saying "but these popular sites let you enumerate registered email addresses via this other form" is justification to be lax about protecting against user enumeration attacks on your own site.
The actual take away should be more like "I found a security issue in the registration form of these popular sites, they should fix it"
Enumerating valid emails, even if rate limited, lets an attacker build a contact book for targeted phishing attacks, connecting leaked passwords, brute forcing and is also useful in recon to determine what sites a person may have an account with, and more. It's worth protecting against as much as possible.
The actual take away should be more like "I found a security issue in the registration form of these popular sites, they should fix it"
Enumerating valid emails, even if rate limited, lets an attacker build a contact book for targeted phishing attacks, connecting leaked passwords, brute forcing and is also useful in recon to determine what sites a person may have an account with, and more. It's worth protecting against as much as possible.
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.
That was my first thought as well. The application that I maintain is invitation-only, so I think the rest of the argument is irrelevant to me.
I'm not sure what this brings to the conversation. I don't develop any web application, so the rest of the argument is also irrelevant for me. Should I broadcast that everywhere?
It brings to our attention that there is a whole class of applications - "invite only" ones - where the main argument of the article does not apply. And therefore the conclusion ("The login user interface should distinguish bad user handle vs bad password") does not apply either. The article just mentions "99.9% of all websites" somewhere near the beginning, and that number may be way too high.
I would in fact be interested in an analysis of how many web sites do and don't follow recommendations like "do NOT distinguish bad user handle vs bad password", which are widely considered best practices. I wouldnt take a guess, could be anywhere between 10 and 90 percent.
I would in fact be interested in an analysis of how many web sites do and don't follow recommendations like "do NOT distinguish bad user handle vs bad password", which are widely considered best practices. I wouldnt take a guess, could be anywhere between 10 and 90 percent.
The argumentation is faulty.
Users cannot be enumerated using the login, but using the signup. The author then argues that they should add the user enumeration function to the login.
This is similar to: The door is locked, but the window is open. And then consequently it makes no sense to close the door at all, as an attacker can sneak through the window.
Instead, the window should be locked as well, i.e., it should be impossible to enumerate users with the signup function.
Users cannot be enumerated using the login, but using the signup. The author then argues that they should add the user enumeration function to the login.
This is similar to: The door is locked, but the window is open. And then consequently it makes no sense to close the door at all, as an attacker can sneak through the window.
Instead, the window should be locked as well, i.e., it should be impossible to enumerate users with the signup function.
I'd prefer the error to be "invalid username" if the typed username is not registered, and "wrong username or password" if it is.
The system only knows if the username is valid or not; it doesn't know whether it's wrong (i.e. mistyped).
I'd prefer to not create brute force vulnerability that leaks the site's list of user email addresses to an attacker.
On this topic, I've noticed a lot of sites have split their sign-in forms into a two step process (submit username, then submit password). Does anyone know what this achieves? It seems like it would be trivial for an automated script to submit the form twice, but as a human I often have to open 1Password multiple times to navigate the process.
For example: https://myaccount.nytimes.com/auth/login
For example: https://myaccount.nytimes.com/auth/login
This is for SSO reasons. When you enter your email address they check whether SSO is activated for your email address (or whole company domain) and will redirect you. It is better for usability than requiring your users to enter some random password or keep the password input empty.
2-step signins are so annoying for those of us who don't use it. I imagine they are also annoying for people who use it because they still have to first type in their email address instead of just going to the google/fb/apple/etc page where they click on their identity.
Usually it is to detect the user is registered to (or their domain is mapped to) an account with SSO or Social Auth and prompt them for that login mechanism. If the user is being required to go via the SSO provider, it makes sense to ask for the email first before they input their password so that they can be redirected it neccesary.
This is useful when you have multiple methods to authenticate.
Maybe this user should be redirected to an oauth2 identity provider or maybe they should enter a password.
Good implementations of this will have a hidden password field for password managers to fill along with the username. You'll still need to press enter twice though.
Maybe this user should be redirected to an oauth2 identity provider or maybe they should enter a password.
Good implementations of this will have a hidden password field for password managers to fill along with the username. You'll still need to press enter twice though.
Just reading the title, I expected OP to be talking about invalid passwords, i.e. when a password's text can't be used because it's too short/long or has/doesn't have specific characters. That's a discussion I would be much more interested in; mostly because I'm sick of seeing long passwords be completely broken.
A better title for their post would be "incorrect", not "invalid".
A better title for their post would be "incorrect", not "invalid".
[deleted]
> Unfortunately this assumes that there's no other way for an attacker to discover whether a username/email address is registered for a service. This assumption is incorrect.
The assertion is incorrect. Closing a means to account name guessing does not presuppose that there are no other means available.
Locking my front door does not assume I have no other doors.
The assertion is incorrect. Closing a means to account name guessing does not presuppose that there are no other means available.
Locking my front door does not assume I have no other doors.
I'm not sure if someone has mentioned this already, but if someone has gone down the path to allow enumeration (username check during signup, which is immediately returned ton the user), I would say this is a strong argument where you could protect yourself against enumeration more easily..
The amount of times a user will likely type their username/password incorrectly is going to be a lot higher than those who attempt to re-signup for an account. Therefore adding additional protection to the signup page (hard rate limiting, bot-protection) then aids to stop this username/email enumeration without the need to be as strict on a login page. This is also compiled with ip-based rate limiting/bot protection that can get very frustrating for users within a corporation that have single public IPs for all their users.
The amount of times a user will likely type their username/password incorrectly is going to be a lot higher than those who attempt to re-signup for an account. Therefore adding additional protection to the signup page (hard rate limiting, bot-protection) then aids to stop this username/email enumeration without the need to be as strict on a login page. This is also compiled with ip-based rate limiting/bot protection that can get very frustrating for users within a corporation that have single public IPs for all their users.
What if Google won't let you have your gmail account back? I broke my cellphone, so I went to the same carrier and purchased another Samsung, same phone number, but different model. So when I go to log into my Google account with the new cell, Google sends me a two way code, But to the old cellphone!
After days of trying to get into my account, I finally have to create a new account and email address. (yes, I know NOW there are ways to create a safety backup.) The phrase, "Invalid Username or Password" started showing up in my dreams.
After days of trying to get into my account, I finally have to create a new account and email address. (yes, I know NOW there are ways to create a safety backup.) The phrase, "Invalid Username or Password" started showing up in my dreams.
So what we've done by promoting "Invalid username or password" is made our login form UX much, much worse, without increasing the security of our product.
Much, much worse? Not at all. It doesn't matter if you've forgotten your user name, email address or password; if you've forgotten your credentials, you reset your password, not keep guessing until you give up. The password reset will also clue you in as to if you've got the right email address.
Much, much worse? Not at all. It doesn't matter if you've forgotten your user name, email address or password; if you've forgotten your credentials, you reset your password, not keep guessing until you give up. The password reset will also clue you in as to if you've got the right email address.
Usability always seems to lose to security. Then we complain that the users can't use the system.
I have come to think that every decision of this sort should first be an attempt to increase usability. Security is ultimately about usability. They are not actually at odds. Too often there is no analysis done after a potential security issue is identified past directly resolving the issue. Rarely will there be an attempt to reevaluate the usability after the change.
I have come to think that every decision of this sort should first be an attempt to increase usability. Security is ultimately about usability. They are not actually at odds. Too often there is no analysis done after a potential security issue is identified past directly resolving the issue. Rarely will there be an attempt to reevaluate the usability after the change.
Does it matter given that browsers can remember the username/password anyhow?
On the other hand it's probably more important for user experience to encourage secure (long) memorable passwords rather than the fashion of impossible-to-remember short random ones. i.e I understand that something like "Iamafunnysailorwithalittlereddog" is better than "4kbjk5rv!" simply because length makes any password much harder to crack than the variety of each character.
On the other hand it's probably more important for user experience to encourage secure (long) memorable passwords rather than the fashion of impossible-to-remember short random ones. i.e I understand that something like "Iamafunnysailorwithalittlereddog" is better than "4kbjk5rv!" simply because length makes any password much harder to crack than the variety of each character.
> Does it matter given that browsers can remember the username/password anyhow?
No.
The only thing that matters is having two public APIs: one that creates an account (failing if the account already exists), and another that checks if the password matches the username for an existing account. If you have those two APIs then there's no benefit to the second refusing to elaborate on whether the login is wrong or the password is wrong, and it might be useful to users.
However I'm not convinced. For many applications I think a better solution is to merge password-recovery with sign-up: Ask for the email/phone number, then send them an email to confirm which logs them in at the same time. That link, then creates the account if it doesn't exist. This way, no information is leaked, and you don't waste resources creating accounts that never get used.
If you want a fully knowledge-based authentication system, you won't have password recovery, but you might not need usernames at all: I have an app like that, it uses webauthn/client certs/a couple other tricks to authenticate devices, and has one UI function to "log in on another machine" (by taking or displaying a QR code), a separate UI function to "share this view with another user" which creates the user (or selects an existing one that this user created), and a third function to add an existing user (using a meetme code). It only matters what users call each other, not that there are two (or more) geocar's in the system, and so the login API in this system doesn't need to differentiate between an invalid or expired code, nor can it reveal the existence of any internal account IDs because the client never actually sees them anyway.
HN is a social space though, and in this case the username represents some kind of land reservation, so it is important to know if land is taken before claiming it, and it's in this scenario I think I can agree that the login API should tell you if the username is wrong or if it's the password. But I don't think Amazon or Shoprunner more should be like HN even if I usually like it here.
No.
The only thing that matters is having two public APIs: one that creates an account (failing if the account already exists), and another that checks if the password matches the username for an existing account. If you have those two APIs then there's no benefit to the second refusing to elaborate on whether the login is wrong or the password is wrong, and it might be useful to users.
However I'm not convinced. For many applications I think a better solution is to merge password-recovery with sign-up: Ask for the email/phone number, then send them an email to confirm which logs them in at the same time. That link, then creates the account if it doesn't exist. This way, no information is leaked, and you don't waste resources creating accounts that never get used.
If you want a fully knowledge-based authentication system, you won't have password recovery, but you might not need usernames at all: I have an app like that, it uses webauthn/client certs/a couple other tricks to authenticate devices, and has one UI function to "log in on another machine" (by taking or displaying a QR code), a separate UI function to "share this view with another user" which creates the user (or selects an existing one that this user created), and a third function to add an existing user (using a meetme code). It only matters what users call each other, not that there are two (or more) geocar's in the system, and so the login API in this system doesn't need to differentiate between an invalid or expired code, nor can it reveal the existence of any internal account IDs because the client never actually sees them anyway.
HN is a social space though, and in this case the username represents some kind of land reservation, so it is important to know if land is taken before claiming it, and it's in this scenario I think I can agree that the login API should tell you if the username is wrong or if it's the password. But I don't think Amazon or Shoprunner more should be like HN even if I usually like it here.
Length doesn't make it harder to crack, entropy does.
Length is a good way to add entropy if the characters are not predictable.
"Ava234ncqli3h23rn2f" is a lot stronger than "Ava234ncqli3"
"DonaldTrump" is barely stronger than "Donald"
Hopefully that makes sense.
Length is a good way to add entropy if the characters are not predictable.
"Ava234ncqli3h23rn2f" is a lot stronger than "Ava234ncqli3"
"DonaldTrump" is barely stronger than "Donald"
Hopefully that makes sense.
> "DonaldTrump" is barely stronger than "Donald"
I mean, this is only true if you know your target is a raging Trump supporter.
Obviously, that's a very cherry-picked example, but generally, length IS entropy, even if the characters are somewhat predictable when seen by a human, as long as you have no reason to predict the password based on the things the person likes.
To give another example, "Inmyyoungerandmorevulnerableyears" is going to be an insecure password despite its length if your entire personality revolves around how much you like The Great Gatsy.
On the other hand, something based on random words like "defaultsocksillegalinstalledconnections" is going to be VERY secure, despite how readable it is, because it's still gibberish and is long.
I mean, this is only true if you know your target is a raging Trump supporter.
Obviously, that's a very cherry-picked example, but generally, length IS entropy, even if the characters are somewhat predictable when seen by a human, as long as you have no reason to predict the password based on the things the person likes.
To give another example, "Inmyyoungerandmorevulnerableyears" is going to be an insecure password despite its length if your entire personality revolves around how much you like The Great Gatsy.
On the other hand, something based on random words like "defaultsocksillegalinstalledconnections" is going to be VERY secure, despite how readable it is, because it's still gibberish and is long.
If the signup or reset process enables user enumeration, we tend to ding you on that in audits the same way we ding you for enumeration via the login form.
Captchas, timeouts and rate limits are all well and good, but given the attack tools (eg: SentryMBA, OpenBullet) used by the lowest common denominator solve for those (by using captcha API's and residential proxy networks)... Breaking user enumeration vectors becomes super useful.
Captchas, timeouts and rate limits are all well and good, but given the attack tools (eg: SentryMBA, OpenBullet) used by the lowest common denominator solve for those (by using captcha API's and residential proxy networks)... Breaking user enumeration vectors becomes super useful.
Is there a use case for passwords at all? Passwords have the downsides of being guessable and hackable, as well as forgotten. I’d like to avoid the “correct horse battery staple” malarkey if possible.
In most cases, control of the account email is equivalent to control of the account because I can reset the password if I control the email. So it seems that magic links or OTPs are strictly better. Am I missing something?
In most cases, control of the account email is equivalent to control of the account because I can reset the password if I control the email. So it seems that magic links or OTPs are strictly better. Am I missing something?
I think you are, yes. These situations spring to mind, all of which make email OTP a worse solution imo:
Shared account without both having access to email.
Email OTP is more time and effort than entering a password.
Email can be down.
You may not have access to email for another reason (different device, etc).
Shared account without both having access to email.
Email OTP is more time and effort than entering a password.
Email can be down.
You may not have access to email for another reason (different device, etc).
This is a bit like the “don’t write your passwords” stuff. It doesn’t matter how obvious the arguments against it are — the author of this piece is not the first to note the absurdity of this setup — it is engrained as “best practice” and you will be fighting an uphill battle as a heretic trying to do anything else. I’ve lost similar arguments for similar reasons.
A tangentially related question. I have, embarrassingly, not kept up with fido. What does it provide? I am guessing it provides a spec for a iOS keychain equivalent where passwords are stored in a dongle (or software) and “let out” based on user approval. I remember reading it also provides a new password-less auth mechanism. Is it out yet? If so is it adopted?
I'd say it's wrong to assume it's even a security measure. I'm fairly sure it goes like this
if (db->query("SELECT * FROM `users` WHERE `email` = '[email protected]' AND `password` = MD5('hunter2')") {
with nobody giving it a second thought.
if (db->query("SELECT * FROM `users` WHERE `email` = '[email protected]' AND `password` = MD5('hunter2')") {
login(username);
error('invalid username or password');
with nobody giving it a second thought.
As someone who written countless of this authentication mechanisms or led teams that have, there has been 0 times the vague message have been by accident like you described and 100% on purpose to prevent information leakage. But that's just one (20+) anecdote(s).
> MD5(‘****’)
That’s cool HN censors passwords like this
That’s cool HN censors passwords like this
If the goal is to log in new users immediately after registration, is it possible to not leak whether a username is already registered?
If [email protected] is not registered and I register it, I will be logged in (even if it does not belong to me).
If [email protected] is already registered, the site can neither let me register it nor log me in.
If [email protected] is not registered and I register it, I will be logged in (even if it does not belong to me).
If [email protected] is already registered, the site can neither let me register it nor log me in.
True but aren't username/password passe? Username should be 'account details' like mother's maiden name or zipcode, not a security feature.
And short passwords you change a lot - what a weak system!
How about provide a cryptographic key and that's it. It's right or it's wrong.
Or heck, if it's not recognized then just create a new empty account.
And short passwords you change a lot - what a weak system!
How about provide a cryptographic key and that's it. It's right or it's wrong.
Or heck, if it's not recognized then just create a new empty account.
I used to think this as well. BUT, revealing _any_ information to attacker is a security problem.
Take this scenario: Someone might not want their employer knowing they (legally) gamble online. The employer could simply browse to popular online gambling sites and probe the service with their email or username to see if an account exists.
Take this scenario: Someone might not want their employer knowing they (legally) gamble online. The employer could simply browse to popular online gambling sites and probe the service with their email or username to see if an account exists.
> 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
that may explain why my gmail keeps getting signed up for obscure cypto services :(
that may explain why my gmail keeps getting signed up for obscure cypto services :(
Would not go as far as saying 99.9% does this. A third-party pentest company we use does not consider this a security issue. I am not sure. I think it is information leak. I think the idea is that at some scale Everybody has an account so it does not really matter.
> 99.9% of websites on the Internet will only let you create one account for each email address.
Is it common? That seems like useless and impractical limit. E.g. for e-shops, one would like to have separate accounts for personal purchases and for business/corporate purchases.
Is it common? That seems like useless and impractical limit. E.g. for e-shops, one would like to have separate accounts for personal purchases and for business/corporate purchases.
It's kind of weird when you can login to different accounts with the same username, which is typically the email address. I mean, amazon lets you do it, and I've had two accounts with the same email address and password there; but it's still pretty weird. IIRC, I had two accounts with different addresses and changed them into the same address. A lot of accounts don't let you change your email address at all, so they solve the problem that way.
Yes, it really is like 99.9% of websites.
If you need multiple accounts, use multiple emails addresses, 1 each. You should keep your personal and corporate email separate anyhow.
If you need multiple accounts, use multiple emails addresses, 1 each. You should keep your personal and corporate email separate anyhow.
Discussed at the time:
“Invalid username or password” is a useless security measure - https://news.ycombinator.com/item?id=8683003 - Dec 2014 (182 comments)
“Invalid username or password” is a useless security measure - https://news.ycombinator.com/item?id=8683003 - Dec 2014 (182 comments)
Related question: what's the deal with having a login form that only takes a username, and then only shows a password field after you've pressed enter? I find this very annoying and can't come up with a benefit.
If username is an e-mail then an app probably checks if e-mail domain has configured single sign on (SSO) and, if it has, it redirect you to your company authentication server instead of asking for password.
thanks
[deleted]
Not a UX'er. But speaking of UX - it is inherently very annoying to sign in with username/password in general. At least in 2022. 2014 was perhaps different.
Another reason to use unique email addresses for each service is that it’s almost impossible for someone to discover if you’ve already signed up
> Check submitted passwords against a dictionary of common passwords (123456, monkey, etc) and ban that traffic extra hard.
> Give guidance to users about creating strong passwords
Yeah, if I just want to talk about a propane with some folks I would eagerly wait to be lectured about IT security, scolded at my passwords of choice, go out of my way to appease site administrator's password policy...
> Give guidance to users about creating strong passwords
Yeah, if I just want to talk about a propane with some folks I would eagerly wait to be lectured about IT security, scolded at my passwords of choice, go out of my way to appease site administrator's password policy...
Or with any modern password manager - including the one built into Apple devices - you could just click on “choose strong password” and have one generated for you and stored.
That works fine till you have the access to your password manager.
If you ever find yourself without it... imagine your Apple device got broken/stolen. You would be fine wihtout an ability to talk on some forum, but what about critical banking, e-gov sites?
If you ever find yourself without it... imagine your Apple device got broken/stolen. You would be fine wihtout an ability to talk on some forum, but what about critical banking, e-gov sites?
My passwords are synced between all of my devices - iPad, iPhone, and Mac.
Even if I lost all of my devices, I could walk into a store, buy a new device and log in and all of my passwords with be in sync.
Even if I lost all of my devices, I could walk into a store, buy a new device and log in and all of my passwords with be in sync.
> buy a new device
Lol.
You lost your cards with the phones/wallet. Or perhaps you didn't even had one, because Apple Pay. Well, at least you have one at home, so now you just must make it back... without money. Oh, somehow you have given enough cash to buy a new iDevice, great. Do you still remember the password, after years of FaceID?
You just never been in the situation where you lost your "IT life", along with "bank life" and "any government accepted ID life". Try it for a day or two, report back.
Lol.
You lost your cards with the phones/wallet. Or perhaps you didn't even had one, because Apple Pay. Well, at least you have one at home, so now you just must make it back... without money. Oh, somehow you have given enough cash to buy a new iDevice, great. Do you still remember the password, after years of FaceID?
You just never been in the situation where you lost your "IT life", along with "bank life" and "any government accepted ID life". Try it for a day or two, report back.
I have lost my ID once. There are ways to get your government ID when it’s lost. They have your picture and your information. There are procedures to verify it.
I also had to go to the bank first to get money without my ID to get my ID. There are ways to verify that too.
I also had to go to the bank first to get money without my ID to get my ID. There are ways to verify that too.
> There are ways to verify that too
I'm glad what that worked for you, but here you would be told to get back with a proper ID. Nobody at the bank would risk their job even for $150.
> There are ways to get your government ID when it’s lost
Yes, sure, just like hundreds of years before? The question here is what without an ID you can't get the same phone number => you can't request password recovery for bazillions of services which treats SMS as 2FA for the password recovery. Banking apps are one of those.
I would repeat again, but try to 'lose' your wallet and the phone, preferably in some place 500+km from your home. Your opinion on some account/password policies would change.
I'm glad what that worked for you, but here you would be told to get back with a proper ID. Nobody at the bank would risk their job even for $150.
> There are ways to get your government ID when it’s lost
Yes, sure, just like hundreds of years before? The question here is what without an ID you can't get the same phone number => you can't request password recovery for bazillions of services which treats SMS as 2FA for the password recovery. Banking apps are one of those.
I would repeat again, but try to 'lose' your wallet and the phone, preferably in some place 500+km from your home. Your opinion on some account/password policies would change.
> The question here is what without an ID you can't get the same phone number.
I’ve never shown my ID to get a phone for T-mobile or walked into the store. I even switched my service with the same number from AT&T to Verizon back in 2011 without going into the store. I entered some verification information and Verizon sent me an iPhone 4S. I logged into my iPhone 4S with my Apple ID and everything downloaded from iCloud - data, apps, and the screen layout. My Verizon phone became active and my AT&T phone deactivated with the same number.
> you can't request password recovery for bazillions of services which treats SMS as 2FA for the password recovery. Banking apps are one of those.
I can log into any Apple device with my Apple ID and receive SMS messages - not just iMessages. Currently, if I get an SMS message, it goes to my phone, my cellular Apple Watch, my iPad and my Mac.
If I forget my iCloud password , my wife can help me recovery it (https://support.apple.com/en-us/HT212515).
My wife and I would have to lose six cellular equipped devices between us and both of our wallets not to have any access to anything.
> I would repeat again, but try to 'lose' your wallet and the phone, preferably in some place 500+km from your home. Your opinion on some account/password policies would change.
Well, seeing that my “home” right now is whatever city I happen to be in with my wife this week (doing the whole digital nomad thing across the US), I’ve thought a lot about that.
If I lost my wallet and needed cash, I call American Express and take advantage of my Global Assist privileges (https://www.americanexpress.com/content/dam/amex/us/credit-c...) that come with the Amex Platinum.
If I lost my phone. Hopefully I wasn’t mugged and I still have my Watch where I can make calls (at least in the US) from the same number and receive texts. My iPad also has a cellular connection that receives SMS messages from the same number. While it doesn’t have a dialer for regular calls, you can call a number from your contacts.
I’ve never shown my ID to get a phone for T-mobile or walked into the store. I even switched my service with the same number from AT&T to Verizon back in 2011 without going into the store. I entered some verification information and Verizon sent me an iPhone 4S. I logged into my iPhone 4S with my Apple ID and everything downloaded from iCloud - data, apps, and the screen layout. My Verizon phone became active and my AT&T phone deactivated with the same number.
> you can't request password recovery for bazillions of services which treats SMS as 2FA for the password recovery. Banking apps are one of those.
I can log into any Apple device with my Apple ID and receive SMS messages - not just iMessages. Currently, if I get an SMS message, it goes to my phone, my cellular Apple Watch, my iPad and my Mac.
If I forget my iCloud password , my wife can help me recovery it (https://support.apple.com/en-us/HT212515).
My wife and I would have to lose six cellular equipped devices between us and both of our wallets not to have any access to anything.
> I would repeat again, but try to 'lose' your wallet and the phone, preferably in some place 500+km from your home. Your opinion on some account/password policies would change.
Well, seeing that my “home” right now is whatever city I happen to be in with my wife this week (doing the whole digital nomad thing across the US), I’ve thought a lot about that.
If I lost my wallet and needed cash, I call American Express and take advantage of my Global Assist privileges (https://www.americanexpress.com/content/dam/amex/us/credit-c...) that come with the Amex Platinum.
If I lost my phone. Hopefully I wasn’t mugged and I still have my Watch where I can make calls (at least in the US) from the same number and receive texts. My iPad also has a cellular connection that receives SMS messages from the same number. While it doesn’t have a dialer for regular calls, you can call a number from your contacts.
In 3rd world countries that would be a whole different story...
Doesn’t Android also have a built in password manager that gets synced to Google servers?
I'm not sure but it's really hard to remember. Especially when you have to access a new device and you can't access the old one.
The internet you want no longer exists.
Stealing your account talking about propane sounds like a great way for me to inject spam/propaganda right in the middle of a group of trusted individuals. And this is exactly what we see countless times. Accounts with bad passwords get compromised, spam, then banned.
You're using a shared resource, you need to use it responsibly.
Stealing your account talking about propane sounds like a great way for me to inject spam/propaganda right in the middle of a group of trusted individuals. And this is exactly what we see countless times. Accounts with bad passwords get compromised, spam, then banned.
You're using a shared resource, you need to use it responsibly.
Except it is always a magnitude easier to register a new account than to hunt down for an existing one. Conversion is way too low.
> Accounts with bad passwords get compromised, spam, then banned
Just like any other account with a proper good password (10 char, 3/4? Certain e-gov site recently forced me for a 12-char, 4/4 without any 3 chars of the sitename in a row) on a proper good one-time/one-use email address... which was compromised by a malware running on the user's machine. Forcing a stupid password policies only increases the friction for a new (and sometimes existing) users, while not providing a meaningful increase in 'non-compromising'.
> Accounts with bad passwords get compromised, spam, then banned
Just like any other account with a proper good password (10 char, 3/4? Certain e-gov site recently forced me for a 12-char, 4/4 without any 3 chars of the sitename in a row) on a proper good one-time/one-use email address... which was compromised by a malware running on the user's machine. Forcing a stupid password policies only increases the friction for a new (and sometimes existing) users, while not providing a meaningful increase in 'non-compromising'.
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
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
That would make things waaaay more difficult for users. "Okay, I'm logged in, let me do something.... Now it says I don't have permission?? Did my account get deactivated??? What am I doing wrong????"
Hah, I did this ages ago in notebook application that I wrote for myself..
Though the amount of times I went a long time between logging in, got the wrong credentials and got scared very quickly when all of my notes had vanished :P
Though the amount of times I went a long time between logging in, got the wrong credentials and got scared very quickly when all of my notes had vanished :P
If we can't manage to make password managers standard, we should try to make them required.
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.
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.
Not about handles.
HN doesn't reveal people's e-mail addresses, unless they choose to put it in their bio.
This might need (2014) in the title
Agreed. OWASP now advises developers on how to avoid account enumeration, so this take no longer makes sense.
> 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.
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.
Exactly! McDonald's (US app) is using a login system like this. Worse, they automatically log out all other logins once someone logs in on one device. Eventually I became the designated pickup person of my house.
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
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
Forwarding assumes I am checking email every time they want to login.
The auto-setup is a cool idea though.
The auto-setup is a cool idea though.
Of course I meant "automatic forwarding" rather than manually forwarding everything, missed to add that word there someone, corrected :)
My approach is to have a shared email account for these situations.
In 2022, building your own user signup/sign in flows is almost as bad as rolling your own crypto.
Edit: a rebuttal is mightier than a downvote.
Edit: a rebuttal is mightier than a downvote.
[deleted]
(2014)
The article makes a good point, were it not for security auditors (SAs).
SA: You leak information and therefore violate policy by disclosing on the login form whether an account exists or not!
Me: Yeah, but figuring out if an account exists is really simple anyway: just a query to a different endpoint...
SA: NEVERMIND, MY LAD: disclosing account existence upon login violates BEST PRACTICES!
Me: OK, yeah, whatever, we'll just change the error message to "something you may or not have entered may or may not be valid information, try again, or not"
SA: cool beans! WE ARE NOW INDUSTRY LEADERS
SA: You leak information and therefore violate policy by disclosing on the login form whether an account exists or not!
Me: Yeah, but figuring out if an account exists is really simple anyway: just a query to a different endpoint...
SA: NEVERMIND, MY LAD: disclosing account existence upon login violates BEST PRACTICES!
Me: OK, yeah, whatever, we'll just change the error message to "something you may or not have entered may or may not be valid information, try again, or not"
SA: cool beans! WE ARE NOW INDUSTRY LEADERS
Every well known credit card / credit data breach has been of a PCI-DSS compliant party.
To any SAs reading this: you're not secure because you're compliant.
To any SAs reading this: you're not secure because you're compliant.
The big issue there is that they store credit card data at all.
And of course that some simple public number is enough to authorise payment.
And of course that some simple public number is enough to authorise payment.
First of all, Fuck 2FA! 2FA = companies fishing for phone numbers to identify and track you.
This post is from 2014.
Meanwhile I suggested that an any login attempt you would receive an email, you don't have to know your password to the service.
Effectively Microsoft is the only company doing it like this. You don't need a password, every time you log in you can opt to have a login link sent to your email address instead of using a password.
That IMHO makes sense. And I'd go one step further. Anytime anyone tries to use your service, don't ask a password, just ask for their email address. The most detrimental or annoying part of a sign up process is picking a password and worse, some stupid services demand you repeat your email or password.
Let the user sign up effortlessly.
I won't even start about how awful captcha is. If you use a JS form and means of sign up or login you don't need captcha.
This post is from 2014.
Meanwhile I suggested that an any login attempt you would receive an email, you don't have to know your password to the service.
Effectively Microsoft is the only company doing it like this. You don't need a password, every time you log in you can opt to have a login link sent to your email address instead of using a password.
That IMHO makes sense. And I'd go one step further. Anytime anyone tries to use your service, don't ask a password, just ask for their email address. The most detrimental or annoying part of a sign up process is picking a password and worse, some stupid services demand you repeat your email or password.
Let the user sign up effortlessly.
I won't even start about how awful captcha is. If you use a JS form and means of sign up or login you don't need captcha.
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 that email address then receives an email - either 1) normal signup process, or 2) "did you just try to sign up? You already have a valid account for this email address."
This way you cannot tell via the signup web form alone whether an account exists or not. You need to have access to the email address.