3 ms·

1. Using recent django (1.4+) will get you _very good_ password storing security. Use HTTPS and you're "as good as anybody else". no persona/openid needed 2. Dj

by izak30 14y ago

1. Using recent django (1.4+) will get you _very good_ password storing security. Use HTTPS and you're "as good as anybody else". no persona/openid needed 2. Django has signed cookie sessions (optional to be used) and a solid signing library. This ensures that the data that is returned is the same as the data that was stored. This doesn't mean that a cookie can't be hijacked, so you should take care to have acceptable timeouts and such. These two things are the building blocks of secure sessions and passwords that work well in distributed systems.

shabble 14y ago
It does use the 'do fancy things with HMAC signed tokens' to handle password reset though, which (as a general scheme) has been criticised vs the 'store random dumb token, details in the DB' method, for being difficult to do right and open to subtle flaws. Obviously I'm not aware of any Django-specific issues with it (or I'd have reported them already), but it's a design decision I've wondered about.
- izak30 14y ago
  Any details on the criticism? All curiosity for me at this point.
  - shabble 14y ago
    There was some discussion in a thread a few days back[1] in which I asked a similar question. It boils down to "possible, but very easy to screw up, and for what is probably relatively small benefit." The only benefits I can think of for the info-in-token approach are: * Less database hits to validate a token. Given that password resets are probably only a small part of your site load, I'm dubious as to the utility of this optimisation. * No server-stored tokens to secure - If an attacker manages to dump or partially break your database (SQLi, logic bug, whatever), they could extract the reset tokens and use them to gain access. Obviously, a full db exploit would make this unnecessary, and a proper reset implementation (that expires the tokens after use, sends confirm emails on use, etc) means unauthorised use would hopefully be detected. In the info-hash-token, the only place it's ever actually stored is in the user's mail-box (and every email server involved in the process along the way, potentially), which might reduce the risk of disclosure, especially bulk (server dump) disclosure. Any other advantages I might have missed? It's possible to do things like token expiry, invalidate on use, invalidate outstanding tokens using hashed tokens, but all of those things are fraught with danger. [1] https://news.ycombinator.com/item?id=5033266 https://news.ycombinator.com/item?id=5033266

by izak30 14y ago

shabble 14y ago

It does use the 'do fancy things with HMAC signed tokens' to handle password reset though, which (as a general scheme) has been criticised vs the 'store random dumb token, details in the DB' method, for being difficult to do right and open to subtle flaws. Obviously I'm not aware of any Django-specific issues with it (or I'd have reported them already), but it's a design decision I've wondered about.

izak30 14y ago
Any details on the criticism? All curiosity for me at this point.
- shabble 14y ago
  There was some discussion in a thread a few days back[1] in which I asked a similar question. It boils down to "possible, but very easy to screw up, and for what is probably relatively small benefit." The only benefits I can think of for the info-in-token approach are: * Less database hits to validate a token. Given that password resets are probably only a small part of your site load, I'm dubious as to the utility of this optimisation. * No server-stored tokens to secure - If an attacker manages to dump or partially break your database (SQLi, logic bug, whatever), they could extract the reset tokens and use them to gain access. Obviously, a full db exploit would make this unnecessary, and a proper reset implementation (that expires the tokens after use, sends confirm emails on use, etc) means unauthorised use would hopefully be detected. In the info-hash-token, the only place it's ever actually stored is in the user's mail-box (and every email server involved in the process along the way, potentially), which might reduce the risk of disclosure, especially bulk (server dump) disclosure. Any other advantages I might have missed? It's possible to do things like token expiry, invalidate on use, invalidate outstanding tokens using hashed tokens, but all of those things are fraught with danger. [1] https://news.ycombinator.com/item?id=5033266 https://news.ycombinator.com/item?id=5033266