121–130 of 289 posts
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.
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.
Earlier quoted context omitted.
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".
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.
Earlier quoted context omitted.
Do most people who are throwing usernames and passwords at websites ... do that?
If they could benefit from the 'information leakage' of knowing a username exists, they would do. If they don't - then maybe this 'information leakage' worry is obsolete security advice. There's loads of obsolete security advice around. (of course there might be other, non-account-security-related reasons to make it impossible to know if an account exists. It's one thing if HN's login form reveals that user duxup exi…
Yeah that's kinda what I'm wondering about. It's possible that most of your security issues are just folks credential stuffing in the simplest way, if that's the case then the whole registration thing isn't really a realistic concern.
Hell when I was in networking and if you did your best to just block traffic to / from specific regions / nations ... you eliminated a huge % of malicious traffic. For the guy thinking deeply about security that seems odd / not specific enough, but in the real world it works...
> 99.9% of websites on the Internet will only let you create one account for each email address. So if you want to see if an email address has an account, try signing up for a new account with the same email address. This is not true if the signup flow is implemented correctly. Signing up for an account should always respond with the same message "we sent an email for you to confirm your account signup". The owner of…
This is bad in the case of online orders, where the order will usually go through anyway (vendors want to sell even when you don’t confirm your email address, and don’t care a lot about someone else getting the notification emails), because if by mistake you registered your email address as new although you already had an account with that address, the order won’t get associated with your account. Or if it does autom…
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).
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
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.
I get that people have different levels of trust for these services than I do. I'm just more cynical than most, I guess.
> 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…
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.
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 agree with the premise but the solution has UX issues of its own. Some users, like me, have learned to use the registration form as an account checker for their own email. I don't remember if I have an account on some websites, and if I do I don't remember with which email+password combo, and the password reset page doesn't tell whether the email is correct, and it often takes 10 minutes for them to send a reset em…
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.