Tag Info

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 ...

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 ...

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 ...

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 ...

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 ...

Nope because you run it in memory not from the hard drive. The only form of hash cracking I know so far which uses a hard drive, are table lookups like Rainbowtables. Even in that case the benefit of an SSD is limited since it's read in sequentially. SSDs are good for random reads and writes.

For your specific question of combining scrypt and bcrypt, remember that these functions have a configurable cost, and you want to raise that cost as much as possible, while keeping it tolerable for your specific usage. For instance, if you can use bcrypt with up to X iterations (beyond which it is too expensive for your server and your average number of ...

As far as I can tell, your scheme is this: Compute scrypt(pass) and store it as the authentication key in your database. Compute sha256(scrypt(pass)) and use that as your data encryption key. The problem with this technique is that an attacker with access to your database can simply compute the SHA256 hash of your scrypt hashes to gain the encryption ...

Anytime you increase the complexity of an algorithm or even add more lines of code, you increase the points of failure in your application. There may be unintended consequences of combining algorithms. This may lead to certain tells or other signs which can actually weaken the cryptographic strength of the system. The more libraries you use in your ...

You can speed it up, but not with an SSD or a hard drive. The fastest calculations today are done with video cards and GPU programming. So if you get a cheap video card and run Cuda or OpenCL you can get quite a lot of performance. That being said GPU processing vs regular processing have similar limitations when using scrypt because the most efficient way ...

If you apply unsafe operations to a secure algorithm, you can definitely break the hashing function. Your new function could even be far worse than the weakest link. Why don't attackers use this to break secure functions? It doesn't help them. For example, if I overwrite the first 440 bits of a password safely stored using bcrypt with zeroes, I can easily ...

Hash functions are built by cryptographers and destroyed by cryptographers. There are many strong hash functions as well as weak ones still being use today. Programmers should trust the cryptographers and the hash function. If there was ever a vulnerability in the hash function, then you would surely hear about it on the internet or through co-workers and ...

Scrypt is supposed to be "better" than bcrypt, but is is also much more recent, and that's bad (because "more recent" inherently implies "has received less scrutiny"). All these password hashing schemes try to make processing of a single password more expensive for the attacker, while not making it too expensive for your server. Since your server is, ...

Combining dilutes your advantage. This slow-hashing business is about fighting the attacker on equal grounds, your CPU against his CPU; scrypt further equalizes things by optimizing the password hashing for the kind of hardware that you use (a PC) instead of letting the attacker optimize things on his side with non-PC hardware. If you spend half your CPU ...

HMAC is designed to be very fast and is in this context a good way to add salt to password instead of just appending it. Bcrypt is much slower due to slow initialization, while scrypt is even slower than Bcrypt because it is intentionally designed in such a way. Scrypt is designed to make brute forcing it very computationally expensive. It consumes a lot of ...

Unfortunately, the wide variety of hardware prevents building tables like the one you want unless you first make a survey of all existing hardware architectures and the best bcrypt/scrypt/PBKDF2 implementations for that architecture. Even the table in the scrypt article is not what you want: it does not tell you how much it would cost for an attacker; it ...

With scrypt in addition to increasing computation you can increase the amount of memory needed to compute the hash. This doesn't bother software implementations much but is much harder to implement with hardware - which is what a dedicated attacker is likely to develop and use. bcrypt (and PBKDF2) use constant, and small, amounts of memory. -Orip Per ...

Both options are secure but the first is preferable. Your first proposal is to use scrypt(password) as the encryption key and SHA256(scrypt(password)) as the password verifier. This is fine. Since it's computationally infeasible to calculate a SHA256 preimage it will not be possible for an attacker to calculate the encryption key from the password verifier. ...

Well, for starters, you're missing an argument to pbkdf2 - that is, the length of the output. This is quite literally controlled by truncating to n blocks of the input function after it has gone through the pbkdf2 algorithm The reason I bring this up is that combining the two functions like this could potentially be your undoing. If, let's say ...

This doesn't provide as much of a benefit as you might think. You're just as vulnerable to any type of attack on inner hash which reduces its security significantly, because it allows manipulation of the data in a way that makes the inner hash abnormally. A better solution is to xor the outputs of the two hashes. h1 = M_a(m, salt1, params_a) h2 = M_b(m, ...

I don't see any point in using scyrpt with pkdf2. scrypt allows you to define the amount of CPU and Memory required to produce a particular hash. In order to do this, scrypt is behaving much like pbkdf2, in that it is cycling over a hash function to produce this output. pkdf2+bcrypt is a great password storage method, but I think scrypt better than ...

Seeing that I wrote that blog post I thought I would chime in. First, let me explain that it was a quick 5-minute writeup so it was not some well-analyzed theory, more of an off-the cuff comment. I wrote it because I had seen several discussions at the time arguing which specific algorithm was best. The original point was, rather than argue which one is ...

HMAC is a message authentication code; it uses a key. Bcrypt does not. Thus, the choice is not neutral; you cannot think of it all things being otherwise equal, because they are not. Although nominally for integrity checks, it so happens that HMAC (when used with a reasonably secure hash function, e.g. SHA-256 or even SHA-1) behaves somehow like "a hash ...

Using your target hardware, I would select a cost that causes the algorithm to take about 1/10th of a second. Implement a delay after failed login attempts. It won't be cost-effective to brute force any password that isn't awfully chosen (e.g. the username, site name, "password"). The actual value you choose will depend on your target hardware.