I'm working on my sites authentication and was thinking of using bcrypt and randomly creating a salt thats stored in my users login row on the database. I want my site to be fast but anything over using 15 to generate(takes about 1 second) is too slow so I was thinking of randomly generating a salt between say 5-14, but is that secure or is there a better way?

2 Answers
2

One major reason to use bcrypt is to prevent brute force attacks by requiring a lot of CPU time to calculate hashes. For your problem I would use a constant length salt, but with random values, this way each password takes the same amount of time to calculate.

From this you can cater your length of salt and number of stretching iterations to whatever you feel is secure enough, though I personally like to make sure the hash takes at least 1/2 second to generate on a really beefy server.

Thank you Matthew. I'm a bit new and don't quite understand what you mean by constant length salt. I can use any package if py-bcrypt isn't suited but when generating the salt they say: "# gensalt's log_rounds parameter determines the complexity. # The work factor is 2**log_rounds, and the default is 12' this is what I was referring to when using 5-14..is there something else or should I be using this a different way?
–
LostsoulJul 4 '12 at 21:24

I thought your 5-14 was the length of the salt, but I see you meant rounds (stretching). As for the number of rounds, you should pick a value that seems adequately safe yet not obscenely slow. The slower the hashing takes, the longer it will take an attacker to brute force it, either by making many web requests, or if they have access to the hashes in the database.
–
MatthewJul 4 '12 at 23:33

Nice..thanks Matthew. Am I right in assuming that I don't need to make the rounds unique per user? and I don't need to store the number of rounds? Just make the rounds as long as possible to delay cracking?
–
LostsoulJul 5 '12 at 15:33

Exactly, each hash should have the same number of rounds, otherwise you wouldn't know how many rounds to use to compare the hash with the users inputted password (unless you're saving the # of rounds in the db as well).
–
MatthewJul 5 '12 at 17:15

I thought I had to save # of rounds but instead I think I just need to use a standard amount(I think 14-15 is good). I was worried because my app is spread accross multiple app servers and wasn't sure if it was using a local key or anything to gen hashs which would make one servers hash not match another. I'll test it but don't think it'll be a problem. Thanks Matthew for your help!
–
LostsoulJul 5 '12 at 23:17

OK, so it seems the salt length and work factor are linked. bcrypt is already rather secure, but the issue is that no matter what kind of hash you use, the password strength itself is at least as important. So you should try for the best you can handle on your server with a minimum cost (strength) of 12.

Note that a cryptographically secure but fast & often reseeded RNG is needed or you might run out of random numbers.

More imporantly: make sure that the passwords have sufficient strength. Finding a password "password" takes no time at all, even with bcrypt.

No, there is no better way, except finding a faster implementation for the password hashing. An attacker will use the fastest implementation that can be found of course.