Hot answers tagged bcrypt
214
/** Dave's Home-brew Hash^H^H^H^H^Hkinda stupid algorithm */
// user data
$user = '';
$password = '';
// timestamp, "random" #
$time = date('mdYHis'); // known to attackers - totally pointless
// ^ also, as jdm pointed out in the comments, this changes daily. looks broken!
// different hashes for different days? huh? or is this stored as a salt?
$rand = ...
108
Advantages of a public protocol:
Probably written by smarter people than you
Tested by a lot more people (probably some of them smarter than you)
Reviewed by a lot more people (probably some of them smarter than you), often has mathematical proof
Improved by a lot more people (probably some of them smarter than you)
At the moment just one of those ...
86
If Dave is really "your" developer, as in you have the authority to fire him, then you have the authority to direct him to use a more well-documented scheme, and you should.
In cryptography, the fewer secrets that are required to be kept, the better. This applies especially to "hard-coded" secrets, such as the hash function itself, which are not secrets as ...
47
To be fair to Dave, in terms of homebrew password security this is one of the better cases as all it just a little obsfuscation (and really not much) masking hash = SHA1(salt + MD5'(Password)) where MD5' does a reversible swap of the order of the bytes of the MD5 hash. Now the username/time/random/crypt-part is just used to generate a salt, and the only ...
45
See the related Security Meme post
While this may seem very simplistic, the rules hold true - designing crypto algorithms and implementing them correctly/securely is very hard. Even the ones designed by experts and picked at by thousands of people over years have holes discovered in them eventually.
So Do Not Roll Your Own Crypto is good advice for ...
28
In cryptography, "new" is not synonymous to "good". That bcrypt is twelve years old (12 years... is that really "old" ?) just means that it sustained 12 years of public exposure and wide usage without being broken, so it must be quite robust. By definition, a "newer" method cannot boast as much. As a cryptographer, I would say that 12 years old is just about ...
26
The fact that you need to ask this question is the answer itself - you do not know what is wrong with stacking these primitives, and therefore cannot possibly know what benefits or weaknesses there are.
Let's do some analysis on each of the examples you gave:
md5(md5(salt) + bcrypt(password))
I can see a few issues here. The first is that you're MD5'ing ...
22
OK, fire Dave. At the very least hit him with a very large clue-bat. Open protocols are good because anyone can look and attempt to find vulnerabilities and structural problems, and implement fixes. The visibility improves the protocol. Good security means that everyone can know how the system works and it is still secure.
11
bcrypt is slow, which definitely increases the risk of an easy DoS attack, but there are a number of ways you could rate-limit clients before they get to the bcrypt step:
Keep track of IP addresses and ignore anyone trying to log in too quickly (maybe start out by pausing for certain amount of time before authenticating, then work your way up to a ...
11
Hashing on the client side doesn't solve the main problem password hashing is intended to solve - what happens if an attacker gains access to the hashed passwords database. Since the (hashed) passwords sent by the clients are stored as-is in the database, such an attacker can impersonate all users by sending the server the hashed passwords from the database ...
10
Convince him with good reasoning. Don't berate him.
You have to think about why we are hashing passwords: The reason is to protect the original password by making the hashing process take a lot of CPU time to execute. Brute force is the way the passwords are typically recovered.
If the attacker is able to steal your password database then they've managed ...
9
Mixing the two functions would not really help. Bcrypt and PBKDF2 both have a configurable cost: you are supposed to set the number of iterations at the maximum value which is still tolerable in your situation, given the available hardware and the environmental constraints (e.g. average user patience). If you want to use both function together, then they ...
9
2 - the original BCrypt, which has been deprecated because of a security issue a long time before BCrypt became popular.
2a - the official BCrypt algorithm and a insecure implementation in crypt_blowfish
2x - suggested for hashes created by the insecure algorithm for compatibility
2y - suggested new marker for the fixed crypt_blowfish
So 2a hashes created ...
9
The accepted mechanism is "don't do it".
What is bcrypt good at ? It is good at being slow. Why would you want a cryptographic function, or just any function, to be slow ? This makes sense only when the input to the function is a low-entropy secret, which means "some value which the adversary could conceivably, and realistically, explore exhaustively". ...
9
While we can find plenty of flaws with Dave's algorithm, it really isn't horrible because it isn't 100% home brew; he does use hashing protocols that (albeit weak) are based on solid principles. On the other hand, he takes steps that increase complexity for the developer but do little to improve the security of his algorithm.
But the reason I am adding ...
8
Why can't SHA512 be used in a password algorithm if we iterate it enough to create it slow? Example is to SHA512 the password 100k times.
There isn't any reason why this cannot work. This is what PBKDF2 essentially is.
Why is PBKDF2 or bcrypt recommended instead of doing the above? Or why is it not?
PBKDF2 is essentially taking a SHA hash and ...
8
Crypto primitives can be stacked safely, and increase security if, and only if, you know the primitives well enough to understand their weaknesses and how those weaknesses interact. If you don't know them, or don't understand the details - well, that's how you get Dave's protocol.
The problem is very few people know them all well enough to judge if a ...
7
If your plan is to keep the specifics of your encryption method secret, no, it won't work and it's a very bad idea. If you don't have the method peer reviewed, you will never be confident that it doesn't lose information and leave the passwords weaker.
For example, your pre-processing might not be as resistant to collisions as you expect it to be, leading ...
6
Then md5 was proven to have collisions so people started moving to SHA1 and so on.
Note that collision resistance is not required for password hashing. Still there is no reason to use a weaker than necessary hash.
Why can't SHA512 be used in a password algorithm if we iterate it enough to create it slow? Example is to SHA512 the password 100k ...
6
Generally speaking, cascading algorithms is rarely a good idea. Cascading works very well at making software more complex and less responsive, which is hardly desirable. The usual "justification" of cascading is that it should somehow (possibly magically) resist complete breakage of one of the algorithm, but not of the other. In practice, this is not so, for ...
6
I think you're wasting your time and adding needless complexity. I don't think the reasons you give are sufficient to warrant this kind of client-side password hashing mechanism.
Instead, I suggest keeping it simple. Send the password over a SSL-encrypted link. When it comes to security, simple is good. Needless complexity is the enemy of security, ...
6
You do not want to use a fixed salt for a given user because it could lead to salt reuse, which is bad (that's the capital sin of salts, since the whole idea of salts is not to be reused; they have no other function). Salt reuse can occur, practically, for the two following reasons:
If a user changes his password, the new password will use the same salt ...
6
Your three methods are correct. The third (with HMAC) might be a tad more "elegant", mathematically speaking: it would make it easier to prove the security of the construction, relatively to those of bcrypt and HMAC.
Beware, though, of null bytes. A given bcrypt implementation might expect a character string and stop at the first byte of value 0, which may ...
6
PBKDF2 and bcrypt are configured with an "iteration count", which means that they can be made as slow as you want. Therefore, there cannot be a table which shows how fast they go. What you need to do, instead, is to decide how much time you allocate to the function (e.g. you want it to take 0.05 seconds on your server) and then set the iteration count ...
6
In addition to Adam's answer, I'd like to also mention that any time you use cryptography, you should have a strong and unavoidable reason to do so. In your examples above, this does not exist.
md5(md5(salt) + bcrypt(password))
scrypt(bcrypt(password + salt))
The bcrypt and scrypt algorithms are already strong enough, and considered effectively ...
6
Execution time in bcrypt does not depend on the input size; internally, the input string is padded into a fixed-length sequence of bytes, and that sequence is then used throughout the algorithm.
It would be a problem if execution time depended on input size, because the "cost factor" parameter is adjusted to make the execution time as high as is tolerable. ...
5
bcrypt depends on Eksblowfish alghoritm which is defined as:
Eksblowfish(cost, salt, key)
state = InitState()
state = ExpandKey(state, salt, key)
repeat (2^cost)
state = ExpandKey(state, 0, key)
state = ExpandKey(state, 0, salt)
return state
This code shows the number of iterations.
As bcrypt usage is: bcrypt(cost, salt, key), the cost ...
5
PBKDF2 and Bcrypt do not support increasing the cost, starting from the output at a given iteration count, without knowledge of the password. There is no intrinsic reason for that; a password hashing process could allow for such offline stretching while still be "good". But these algorithms happen not to allow it.
What can be done is the following: a normal ...
5
If the server doesn't rate limit anything it looks like even from a single machine / IP it wouldn't be too hard to force the server into doing lots of computation.
DoS is a risk with any service. The more processing it requires, the more important rate limiting is whether we're talking about hashing passwords or making database queries.
When ...
5
There are few time when client-side hashing is worthwhile. One such circumstance is when the hash process is computationally intensive, which can be the case with PBKDF2.
Addressing your concerns:
Also avoid unvalidated suggestions about cryptography you find on the internet. (Disclaimer: I am not Bruce Schneier.)
Deterministic salts aren't a problem--the ...
Only top voted, non community-wiki answers of a minimum length are eligible
