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?

[–] LeapSecond@lemmy.zip 14 points 1 month ago (1 children)

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.

[–] theo@lemmy.world 0 points 1 month ago (1 children)

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.

[–] pupbiru@aussie.zone 2 points 3 weeks ago (1 children)

i think these days the best practice for mobile apps re retention 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

[–] theo@lemmy.world 1 points 3 weeks ago (1 children)

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?

[–] pupbiru@aussie.zone 1 points 3 weeks ago

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

[–] cactusupyourbutt@lemmy.world 7 points 1 month ago (3 children)

I keep hearing that, yet the websites will gladly tell you that the username is taken when trying to register

[–] meekah@discuss.tchncs.de 5 points 1 month ago

I'd assume the spam protection for signing up is a lot tighter than the one for logging in

[–] marius@feddit.org 1 points 1 month ago (2 children)

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

[–] psud@aussie.zone 2 points 4 weeks ago

Many of those will progress to password even if the user doesn't exist

[–] dbx12@programming.dev 0 points 1 month ago (1 children)

And this fucks with password managers as they usually expect both fields on the same page.

[–] lord_ryvan@ttrpg.network 1 points 1 week ago

Which ones? Both Keeper and KeepassXC will work just fine with it and the latter is FOSS.

[–] howrar@lemmy.ca -1 points 1 month ago* (last edited 1 month ago)

That's easy to do. You just check that the username exists. If someone enters a wrong username/password pair, you can still check that the username exists, but how do you know that the user intended to log in with that username? You would also have to check every other username to see if the password matches, and that can't be done with a simple search because you need to compute a different hash for each user you check. Then if the username exists and the password also happens to match someone else's password, then what do you report? Should you even report it? Because doing so reveals that someone had that specific password, and if the list of usernames is publicly available (which they often are, or could become public through a leak of some sort), then you can brute force over a small set of usernames to match them up.