Tag Info

Hot answers tagged

36

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


35

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


15

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


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


12

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

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


10

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


10

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

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


7

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


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

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

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.


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

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


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

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


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

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


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

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


3

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


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


3

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


3

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


3

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


2

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


2

Reusing the password as part of the salt is, on a general basis, not recommended. The password is secret, and information may leak that way, depending on the internal details of the hash function. I suggest you refrain from it. The username is, by itself, a not-too-good salt, but if you only have that, then use it. The one and only property of salts is ...


2

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


2

Comparison is complex because scrypt and bcrypt don't play on the same parameters. For bcrypt, the computation involves doing a lot of operations over a 4 kB array of RAM. The array is accessed in a pseudorandom way, so the only way to make this run at a decent speed is to have an actual block of RAM of at least that size. This is true for normal CPU, that ...



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