Hot answers tagged

50

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


44

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


32

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


21

In order to give you a proper idea of the problems and subtleties of computing password hashes, as well as why HMAC isn't suitable for this problem, I'll provide a much broader answer than is really necessary to directly answer the question. A HMAC hash algorithm is, essentially, just a keyed version of a normal hash algorithm. It is usually used to verify ...


14

The short answer is : no. That is not what I said, nor what I implied. Using the tradeoff that I identified and talked about, you can trade memory for CPU time. So yes, you can reduce a particular derivation from 16MiB to 8KiB (approximately). However doing so will require several orders of magnitude more logic to be executed by the CPU. Some efficiency is ...


13

Scrypt has mostly survived. It is not bad; it just turns out that the touted advantages of scrypt over the competition (mainly bcrypt and PBKDF2) might not be as marvellous as first claimed. As always, it is a trade-off: like any password hashing function, its role is to make password hashing expensive for everybody, attackers and defenders alike. Scrypt ...


13

No. Litecoin uses an algorithm called scrypt which has variables that determine the amount of CPU/RAM required to compute hash. Litecoin's scrypt parameters are fixed at N = 1024; p = 1; r = 1. (http://cryptocur.com/litecoin/) Users of Scypt for password hashing purposes should have the parameters set much, much higher which will put password cracking out ...


12

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


12

I would take the "Scrypt is 4000 times slower than BCrypt" assertion with a grain of salt. First, both of these algorithms are variably-complex; even if that "4000x" figure holds, you can make BCrypt just as slow by adding an additional 11 rounds to the key derivation. Second, at some point both SCrypt and BCrypt are limited by how long it takes to ...


11

I created the Node Scrypt module. HMAC adds additional security. Using it also lends the scheme to be used as a header in an encrypted file format (like it is done in tarsnap) and not just in an authentication server's database. Also, Colin Percival (who created scrypt) uses this scheme to verify (I actually just copied it from him). To explain why HMAC is ...


10

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


9

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


9

You shouldn't mess with the algorithm like this. I can't think about what the impact of this method is but it does scream insecurity. At the very least, it would allow an attacker to move roughly 256 times as fast since CRC is a relatively simple math function and then of course faster on the database part. You're a few whiteboard coding exercises away from ...


8

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


7

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


6

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


6

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.


6

The theory of password hashing is that the whole problem is an arms race between attacker and defender. The password hashing function (bcrypt, scrypt...) is made deliberately slow, as much as the defender can tolerate on his hardware. We assume that the attacker can buy the same kind of hardware as the defender, so he can always be at least as efficient as ...


6

Perhaps it's also important to point out the breaches that have occurred where there was no evidence of compromised data. LastPass, for example, used "5,000 rounds of PBKDF2-SHA256" and a random salt (https://blog.lastpass.com/2015/06/lastpass-security-notice.html/). Since the breach, there have been no indications that the master passwords were broken. ...


6

PBKDF2, scrypt and bcrypt are all configurable; they can be made as slow as you want. The limiting point is not the computer, but the user's patience. For example, suppose that the user will go irate if the password processing (e.g. to unlock an archive file) takes more than 6 seconds. If you use bcrypt only, then you can tune it up so that it takes 6 ...


5

A fair bit of the inherent safety in scrypt is that it doesn't make any specific promises but is already effectively guaranteed to be at least as good as the existing alternatives. So in the worst-case scenario, scrypt is only as good as existing iterative hash composition techniques. Since scrypt is, itself, an iterative composition technique, and since ...


5

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


5

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 http:/...


4

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


4

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


4

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


4

The usual problem with cascading password hashing functions is that they compete for CPU. Each password hashing function with a configurable iteration count should be set as high as possible, the limit being the combination of your available processing power and your patience, as a user. If you combine bcrypt (or scrypt) with what PGP will do (its S2K ...


4

I do not believe you will find examples of a breach/password cracking as you have requested. HMAC of a 256bit SHA-2 salted hash is currently consider acceptably strong to meet, for example, NIST standards for the federal government. [The federal standard requires that the HMAC is at least 112 bits, BTW.] However, your concern has merit, IMO, for the ...


4

In an authoritarian dystopian environment, the authorities aren't going to permit every network transmission they can't prove is harmful, they're going to use a default-deny rule, and only permit transmissions they can prove are safe. In such an environment, you'll need to disguise your transmission as a known-safe protocol, such as HTTP or Telnet. Even ...


3

With Thomas Pornin's most excellent answer in mind, one interim option is to use a mechanism that will thwart today's GPU-based cracking systems, but with the expectation of migrating to the results of the password hashing competition once those become available. For example, using PBKDF2-HMAC-SHA512 will prevent cracking on today's GPUs by virtue of using ...



Only top voted, non community-wiki answers of a minimum length are eligible