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
I pretty much always recommend throttling. It’s a very low severity issue generally, but of course it depends on the product. There might be some products where it is a very big deal
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
I pretty much always recommend throttling. It’s a very low severity issue generally, but of course it depends on the product. There might be some products where it is a very big deal