221–230 of 289 posts
> 99.9% of websites on the Internet will only let you create one account for each email address. So if you want to see if an email address has an account, try signing up for a new account with the same email address. This is not true if the signup flow is implemented correctly. Signing up for an account should always respond with the same message "we sent an email for you to confirm your account signup". The owner of…
I got some code to fix.
Earlier quoted context omitted.
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"
> 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 t…
Earlier quoted context omitted.
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 n…
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 r…
Earlier quoted context omitted.
Any site that requires a password will need an email for password resets.
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 a…
Earlier quoted context omitted.
Any site that requires a password will need an email for password resets.
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 a…
- 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.)
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
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?
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.
Earlier quoted context omitted.
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…
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.
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.
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.
Earlier quoted context omitted.
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 a…
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.
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.