3 ms·

Good, extensive write up. Note that correctly hashing passwords is a topic in itself and the short answer IMO is: use bcrypt. It should also mention that after

Good, extensive write up. Note that correctly hashing passwords is a topic in itself and the short answer IMO is: use bcrypt. It should also mention that after a user changes their password, all login sessions should be invalidated. This lets a user who thinks their account/password may have been compromised prevent an attacker from using prior stolen sessions. This is accomplished by including a nonce (a "number used once" which is basically just a large random number) in the user record that is also included in the auth session, and verified on each request. It gets set to a new value on password reset, and thus invalidates existing sessions. (The active session issuing the password change should ideally have its value updated to the new value automatically, though.)

hombre_fatal 8y ago
Or execute sql "update active_sessions set expired_at = now() where user_id = $1" Expiring all sessions should definitely be a critical point on anyone's checklist when building a password reset system. Spotify didn't have this for the longest time and it was insane. Someone could buy a hacked account for $1 and get pretty much unlimited access. Though a special sort of infuriating softwaregore because you had to listen to what they were listening to.
- eknkc 8y ago
  If you do not have a server side session store, only option is to use a nonce of some sort though.
  - ben-schaaf 8y ago
    Or use a access/refresh token pair
inopinatus 8y ago
For the extra conservative, rotate the nonce when the reset is requested.
- jerf 8y ago
  That opens an attack vector where I can keep someone off a site by repeatedly requesting a password reset. You don't want to take any actions on an authenticated session as a result of actions of an unauthenticated user.
  - inopinatus 8y ago
    Yes I do. Sometimes the medicine is unpleasant but necessary. For many services, a malicious denial is better than an active compromised account, both in the material consequences and the opportunities for tactical management. We similarly also lock out after X failed login attempts.
    - jerf 8y ago
      Requesting a blind password reset is not a "compromised account". "We similarly also lock out after X failed login attempts." That is not affecting an authenticated session with the actions of an unauthenticated session; that is affecting unauthenticated sessions with the actions of unauthenticated sessions. You should not cancel logged in sessions because of failed login attempts for the same reason. It is a violation of basic security principles for an unauthenticated user to be able to affect an authenticated session. You open an attack vector, one that can and has been used, and can and has been used to escalate as well: 1. Blow through the login limits on the target user's account. 2. In the interests of "security", you cancel the real life login session because of the unrelated actions of attackers. 3. Wondering what's going on, the users checks their email and see the attacker's well-crafted phishing email about how they need to reconfirm their password because of [security bibble-babble]. 4. Because it's so temporally-related, the user is much more inclined to think it's valid and click through. That's just one way to exploit it that comes to mind; statistically, that's going to be much more effective than blind emails. Don't let unauthenticated sessions affect authenticated ones. I drive in an area with some roundabouts, and a lot of polite drivers. There's a handful of drivers that think they are doing us all a favor when they "upgrade" the yield signs on the roundabouts to stop signs. They're not. You're doing much the same thing; security isn't about going in one direction all the way and being as paranoid as possible and shutting down access at the first sign of trouble. It's about getting the balance correct, because being over-paranoid can open you up to exploits too.
pcl 8y ago
I really appreciate systems that allow me to rotate passwords without invalidating existing sessions — essentially, treating passwords more like tokens (as in OAuth, or Google app-specific passwords). Of course, it’s critical to have a “reset my sessions” link, but sometimes I just want to change my password, and other times, I just want to revoke existing sessions.

hombre_fatal 8y ago

Or execute sql "update active_sessions set expired_at = now() where user_id = $1" Expiring all sessions should definitely be a critical point on anyone's checklist when building a password reset system. Spotify didn't have this for the longest time and it was insane. Someone could buy a hacked account for $1 and get pretty much unlimited access. Though a special sort of infuriating softwaregore because you had to listen to what they were listening to.

eknkc 8y ago
If you do not have a server side session store, only option is to use a nonce of some sort though.
- ben-schaaf 8y ago
  Or use a access/refresh token pair

inopinatus 8y ago

For the extra conservative, rotate the nonce when the reset is requested.

jerf 8y ago
That opens an attack vector where I can keep someone off a site by repeatedly requesting a password reset. You don't want to take any actions on an authenticated session as a result of actions of an unauthenticated user.
- inopinatus 8y ago
  Yes I do. Sometimes the medicine is unpleasant but necessary. For many services, a malicious denial is better than an active compromised account, both in the material consequences and the opportunities for tactical management. We similarly also lock out after X failed login attempts.
  - jerf 8y ago
    Requesting a blind password reset is not a "compromised account". "We similarly also lock out after X failed login attempts." That is not affecting an authenticated session with the actions of an unauthenticated session; that is affecting unauthenticated sessions with the actions of unauthenticated sessions. You should not cancel logged in sessions because of failed login attempts for the same reason. It is a violation of basic security principles for an unauthenticated user to be able to affect an authenticated session. You open an attack vector, one that can and has been used, and can and has been used to escalate as well: 1. Blow through the login limits on the target user's account. 2. In the interests of "security", you cancel the real life login session because of the unrelated actions of attackers. 3. Wondering what's going on, the users checks their email and see the attacker's well-crafted phishing email about how they need to reconfirm their password because of [security bibble-babble]. 4. Because it's so temporally-related, the user is much more inclined to think it's valid and click through. That's just one way to exploit it that comes to mind; statistically, that's going to be much more effective than blind emails. Don't let unauthenticated sessions affect authenticated ones. I drive in an area with some roundabouts, and a lot of polite drivers. There's a handful of drivers that think they are doing us all a favor when they "upgrade" the yield signs on the roundabouts to stop signs. They're not. You're doing much the same thing; security isn't about going in one direction all the way and being as paranoid as possible and shutting down access at the first sign of trouble. It's about getting the balance correct, because being over-paranoid can open you up to exploits too.

pcl 8y ago

I really appreciate systems that allow me to rotate passwords without invalidating existing sessions — essentially, treating passwords more like tokens (as in OAuth, or Google app-specific passwords). Of course, it’s critical to have a “reset my sessions” link, but sometimes I just want to change my password, and other times, I just want to revoke existing sessions.