4 ms·

This approach would introduce more complexity than it's worth, in addition to being less secure. Instead of just one password that can be used to login to your

by marcinw 16y ago

This approach would introduce more complexity than it's worth, in addition to being less secure. Instead of just one password that can be used to login to your account, you now have two valid passwords.

AdamGibbins 16y ago
I'm not convinced its less secure, the old password invalidates the second you login using your new password. This beats the current method which just locks you out (I believe anyhow? I've not tried it personally). Its along the same lines as the URL method but without the added confusion for the user. Complexity for the developer perhaps, although you could also use the same branch of code to give you the ability to force password changes etc. And I think the added dev work is worth it for the user. Time for some A/B testing perhaps.
- marcinw 16y ago
  At any moment, you can have two valid passwords used to access your account. Do all the A/B testing you want, this is NOT how you handle password resets.* * Note that even my proposed solution is not the best way to handle password resets. Trust me on this, I've seen way too many applications do this wrong which have resulted in ability to compromise arbitrary users' accounts.
  - AdamGibbins 16y ago
    Please explain why, simply saying its not doesn't really add anything to the conversation nor convince me otherwise. I'm not sure I understand why not. With your common URL method theres still two ways to authenticate, just as there is mine. They could "guess" the reset key just as easy as they could "guess" the new generated password. You'd have both expiring so the period for attack is minimal. Please explain how my method is any less secure? Perhaps I'm missing some key security principles (likely), in which case please guide them to me. But just repeating that its less secure without backing up with some logic really doesn't convince me nor teach me anything. Edit: I forgot to mention apologies - I'm not saying the password should remain as the one that was emailed. You can and should force people to change it upon the first login with their new password. Perhaps thats where the security confusion was. People storing passwords in email is poor, theres no debate there. Though yes, at a second thought this puts an extra step in for the user - A/B testing would be of use here.
    - marcinw 16y ago
      Sorry for not explaining, maybe the following will convince you. When an application generates a password, about how long/secure are these passwords? (on average, and remember, we're staying user friendly...) Probably about 8-10 characters, alphanumeric, MAYBE a special character. Now let's say you had to only create a link as I proposed. The length of the "secure" token can be as long as you want! Because the URL is not entered manually, you don't have to worry about being so "user-friendly" (as long as your url doesn't break in mail clients..) If you fed a secure PRNG to an HMAC-SHA256/512 hash or a UUID... These values would be much, MUCH harder to guess than any password you could generate for your user. As a result, the following is not true: > They could "guess" the reset key just as easy as they could "guess" the new generated password. You bring up a good point about the password delivery over cleartext (though HN doesn't use SSL anyway, I didn't consider it at the time of posting). On a side note, does HN even have account lockout?

by marcinw 16y ago

AdamGibbins 16y ago

I'm not convinced its less secure, the old password invalidates the second you login using your new password. This beats the current method which just locks you out (I believe anyhow? I've not tried it personally). Its along the same lines as the URL method but without the added confusion for the user. Complexity for the developer perhaps, although you could also use the same branch of code to give you the ability to force password changes etc. And I think the added dev work is worth it for the user. Time for some A/B testing perhaps.

marcinw 16y ago
At any moment, you can have two valid passwords used to access your account. Do all the A/B testing you want, this is NOT how you handle password resets.* * Note that even my proposed solution is not the best way to handle password resets. Trust me on this, I've seen way too many applications do this wrong which have resulted in ability to compromise arbitrary users' accounts.
- AdamGibbins 16y ago
  Please explain why, simply saying its not doesn't really add anything to the conversation nor convince me otherwise. I'm not sure I understand why not. With your common URL method theres still two ways to authenticate, just as there is mine. They could "guess" the reset key just as easy as they could "guess" the new generated password. You'd have both expiring so the period for attack is minimal. Please explain how my method is any less secure? Perhaps I'm missing some key security principles (likely), in which case please guide them to me. But just repeating that its less secure without backing up with some logic really doesn't convince me nor teach me anything. Edit: I forgot to mention apologies - I'm not saying the password should remain as the one that was emailed. You can and should force people to change it upon the first login with their new password. Perhaps thats where the security confusion was. People storing passwords in email is poor, theres no debate there. Though yes, at a second thought this puts an extra step in for the user - A/B testing would be of use here.
  - marcinw 16y ago
    Sorry for not explaining, maybe the following will convince you. When an application generates a password, about how long/secure are these passwords? (on average, and remember, we're staying user friendly...) Probably about 8-10 characters, alphanumeric, MAYBE a special character. Now let's say you had to only create a link as I proposed. The length of the "secure" token can be as long as you want! Because the URL is not entered manually, you don't have to worry about being so "user-friendly" (as long as your url doesn't break in mail clients..) If you fed a secure PRNG to an HMAC-SHA256/512 hash or a UUID... These values would be much, MUCH harder to guess than any password you could generate for your user. As a result, the following is not true: > They could "guess" the reset key just as easy as they could "guess" the new generated password. You bring up a good point about the password delivery over cleartext (though HN doesn't use SSL anyway, I didn't consider it at the time of posting). On a side note, does HN even have account lockout?