this post was submitted on 10 Apr 2026
9 points (90.9% liked)
Programmer Humor
32479 readers
285 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Being able to determine if a username is valid without a valid password is a security flaw
Even something as simple as taking longer to validate the password when the username is a valid one can also lead to user enumeration
I keep hearing that, yet the websites will gladly tell you that the username is taken when trying to register
I'd assume the spam protection for signing up is a lot tighter than the one for logging in
There are also a lot of websites where you first just enter a username and only when that is valid they ask for a password
Many of those will progress to password even if the user doesn't exist
And this fucks with password managers as they usually expect both fields on the same page.
Which ones? Both Keeper and KeepassXC will work just fine with it and the latter is FOSS.
I was having a chat about this with a UX guy. His argument for using a similar flow was that the username/email will have to be validated at the point of registration anyway so you might as well make it easier for the user when the email is wrong. I couldn't really refute this logic.
If you throttle both login and registration, then surely the risk is minimised while keeping the user happy?
You see the registration problem in so many places. If the username is an email, the proper way to validate it without revealing if an account exists is to accept any email address and if it already exists say that in the registration email you would send anyway. With the appropriate throttling if needed.
Compared to login or password reset, you rarely see the email validate before register flow, especially for mobile apps etc. That makes it pretty hard to make the case that this needs to be actioned from a security perspective when even the big companies are not following it either.
i think these days the best practice for mobile apps re retention (other than sso or passkey) is to just ask for an email, then from the validate link continue with register
reason being that more steps to register means more ways people are likely to drop out of the flow, and this is basically about as short as it can be
when the user has validated their email, then they’re more invested so they are more likely to complete
that also fits nicely with what we’re talking about with good security
Just to clarify, would you mean to have the email/validate stage as part of the flow to access the app, or let them continue with just the email with a limited functionality?
either… some apps have just started to do single factor login with just email, profile options can be optional, if there are required fields or terms of service to agree to then that can come after email validation