5 ms·

It is certainly possible to allow for password resets and account creation as well without revealing whether an account exists. Password reset: 1. User enters

It is certainly possible to allow for password resets and account creation as well without revealing whether an account exists. Password reset: 1. User enters email in password reset form. 2. Website shows the same message whether the password was reset or not. 3. Email is what differs. If the account exists, send a password reset link. If it does not, send an email asking them if they want to create an account (and offer an unsubscribe link so people can't spam signup emails). Signup: 1. User enters email in signup form. 2. Website states it is sending an email to verify the account. 3. If it already exists, send a message saying they already have an account. If not, send the normal email verification link and then they can complete filling in their account details. This prevent someone without access to the email from finding that the account exists, and also keeps the owner of the email filled in if they just forgot which email they used for the account or that they already had an account.

kolev 13y ago
Yes, this is the right workflow, but, you'll be surprised how very few services implement this properly! Another thing that most services don't implement is providing geolocation and other pieces of info in password reset emails and the ability to report that you didn't request that with some basic flagging (even as simple as flagging that session), which would prevent that guy of keep resetting it. The ability to add login email notification is also priceless.
jakejake 13y ago
I agree 100% this is the right way to do it. And it's really not any more difficult to implement. The problem is the convenience tradeoff. Take a site that has an instant green/red indicator that a username is already taken. People love the instant feedback, but it creates an attack vector. If you had to wait around for an email to see if you had already signed up - I bet a "Show HN" would have people here telling you that your site was user hostile! Even though it is unquestionably more secure. I do think what Coinbase is doing now is not out of line with standard practices. But for a financial site they might be wise to start erring in the direction of security at the expense of a little convenience.

kolev 13y ago

Yes, this is the right workflow, but, you'll be surprised how very few services implement this properly! Another thing that most services don't implement is providing geolocation and other pieces of info in password reset emails and the ability to report that you didn't request that with some basic flagging (even as simple as flagging that session), which would prevent that guy of keep resetting it. The ability to add login email notification is also priceless.

jakejake 13y ago

I agree 100% this is the right way to do it. And it's really not any more difficult to implement. The problem is the convenience tradeoff. Take a site that has an instant green/red indicator that a username is already taken. People love the instant feedback, but it creates an attack vector. If you had to wait around for an email to see if you had already signed up - I bet a "Show HN" would have people here telling you that your site was user hostile! Even though it is unquestionably more secure. I do think what Coinbase is doing now is not out of line with standard practices. But for a financial site they might be wise to start erring in the direction of security at the expense of a little convenience.