4 ms·

Regarding bcrypt - does it still make sense to do seeding on those since the key wouldn't be changing? I've also seen wrapping sha1/etc and looping it like 1000

Regarding bcrypt - does it still make sense to do seeding on those since the key wouldn't be changing? I've also seen wrapping sha1/etc and looping it like 1000+ times to introduce a time factor in, but that doesn't seem like the best solution.

tptacek 16y ago
No. Bcrypt does all of this for you.
- chime 16y ago
  Suppose I'm not able to use bcrypt for legacy reasons. Would a hash of username+password+constant_seed be good enough? What about user_dependent_seed+password+constant_seed? The user_dependent_seed could be a concat of username, account setup date, user id# etc. What hashing algo would you recommend if bcrypt is just not available?
  - cheald 16y ago
    The attraction of bcrypt is that you can tune its work factor to counter increases in computing technology, so that it's very slow to brute-force compared to an MD5/SHA/CRC, all of which are extremely fast to compute. It's counterintuitive, but the idea is that if Joe Blackhat gets your password hash, he's going to spend orders of magnitude more time chewing on it to get a result than if it were hashed with a fast hashing algorithm. Adding more salt to the hash is going to increase its time-to-crack, but swapping SHA1 for bcrypt gets you a future-hardened algorithm that can be adjusted in responses to gains in computing power.
    - chime 16y ago
      I agree why bcrypt is much, much better. No doubt about that. My question was whether there was something I could do to improve security (even if marginally) on platforms that can't/don't support bcrypt. > bcrypt gets you a future-hardened algorithm that can be adjusted in responses to gains in computing power. How would I be able to change the cost factor overtime? I don't store my user's passwords. Should I just re-bcrypt the bcrypted password using a higher cost and in my login_verify code, take that into account? Or is there something else you can do overtime to raise the cost factor?
      - bigiain 16y ago
        "How would I be able to change the cost factor overtime?" One system I built stores the workfactor used to bcrypt the current password un the user table, and allows me to increase the "system workfactor". Every time someone successfully logs in with a lower-than-current-workfactor password hash, it recomputes a new bcrypted hash using the currently known successful login password and updates the users credentials. It means if my user table is ever exposed, all frequently used accounts have up-to-date workfactors for their password hashes, and the "relatively weaker" hashes are for infrequently used (or, in this particualar case, expired subscriptions).
  - ErrantX 16y ago
    Iterate MD5 several times (i.e. 50 or so). That will introduce a similar "slow" factor (it's not a solution, but a stop gap) EDIT: I've also recommended using a random salt for each password too, but this is only a layer of security if you're code is not also stolen, then it is simply a slight additional "slow factor"
    - ErrantX 16y ago
      (I'm not sure why I said MD5... what can I say it was a monday morning :))
      - ErrantX 16y ago
        If anyone has a comment as to why this is not good advice (it honestly is decent advice if you really insist on not using Bcrypt) then I'd be happy to hear it ;)
        anthonyb 16y ago
        Because md5 is stupidly fast, even if you use a thousand cycles. As if that's not bad enough, there are FPGA implementations (http://nsa.unaligned.org/ http://nsa.unaligned.org/) which are even faster and relatively easy to come by.
        ErrantX 16y ago
        Yes, MD5 was a mistake :) I was tweaking our cluster's MD5 implementation so it was stuck in my mind. Just sub in "hash function". You could up the iteration however much is needed (say, 1000, 10,000). It's poor security countermeasure, but it was a specific scenario :) The general idea is to combine salting and iteration to produce a poor mans slow hash. (which works great for software you're distributing for use on random shared architecture a la wordpress - just to give an example) Use Bcrypt where you can.
        anthonyb 16y ago

tptacek 16y ago

No. Bcrypt does all of this for you.

chime 16y ago
Suppose I'm not able to use bcrypt for legacy reasons. Would a hash of username+password+constant_seed be good enough? What about user_dependent_seed+password+constant_seed? The user_dependent_seed could be a concat of username, account setup date, user id# etc. What hashing algo would you recommend if bcrypt is just not available?
- cheald 16y ago
  The attraction of bcrypt is that you can tune its work factor to counter increases in computing technology, so that it's very slow to brute-force compared to an MD5/SHA/CRC, all of which are extremely fast to compute. It's counterintuitive, but the idea is that if Joe Blackhat gets your password hash, he's going to spend orders of magnitude more time chewing on it to get a result than if it were hashed with a fast hashing algorithm. Adding more salt to the hash is going to increase its time-to-crack, but swapping SHA1 for bcrypt gets you a future-hardened algorithm that can be adjusted in responses to gains in computing power.
  - chime 16y ago
    I agree why bcrypt is much, much better. No doubt about that. My question was whether there was something I could do to improve security (even if marginally) on platforms that can't/don't support bcrypt. > bcrypt gets you a future-hardened algorithm that can be adjusted in responses to gains in computing power. How would I be able to change the cost factor overtime? I don't store my user's passwords. Should I just re-bcrypt the bcrypted password using a higher cost and in my login_verify code, take that into account? Or is there something else you can do overtime to raise the cost factor?
    - bigiain 16y ago
      "How would I be able to change the cost factor overtime?" One system I built stores the workfactor used to bcrypt the current password un the user table, and allows me to increase the "system workfactor". Every time someone successfully logs in with a lower-than-current-workfactor password hash, it recomputes a new bcrypted hash using the currently known successful login password and updates the users credentials. It means if my user table is ever exposed, all frequently used accounts have up-to-date workfactors for their password hashes, and the "relatively weaker" hashes are for infrequently used (or, in this particualar case, expired subscriptions).
- ErrantX 16y ago
  Iterate MD5 several times (i.e. 50 or so). That will introduce a similar "slow" factor (it's not a solution, but a stop gap) EDIT: I've also recommended using a random salt for each password too, but this is only a layer of security if you're code is not also stolen, then it is simply a slight additional "slow factor"
  - ErrantX 16y ago
    (I'm not sure why I said MD5... what can I say it was a monday morning :))
    - ErrantX 16y ago
      If anyone has a comment as to why this is not good advice (it honestly is decent advice if you really insist on not using Bcrypt) then I'd be happy to hear it ;)
      - anthonyb 16y ago
        Because md5 is stupidly fast, even if you use a thousand cycles. As if that's not bad enough, there are FPGA implementations (http://nsa.unaligned.org/ http://nsa.unaligned.org/) which are even faster and relatively easy to come by.
        ErrantX 16y ago
        Yes, MD5 was a mistake :) I was tweaking our cluster's MD5 implementation so it was stuck in my mind. Just sub in "hash function". You could up the iteration however much is needed (say, 1000, 10,000). It's poor security countermeasure, but it was a specific scenario :) The general idea is to combine salting and iteration to produce a poor mans slow hash. (which works great for software you're distributing for use on random shared architecture a la wordpress - just to give an example) Use Bcrypt where you can.
        anthonyb 16y ago