128

The simple answer is that hashes don't ensure uniqueness. Very broadly, hashes behave like "deterministic random numbers" – deterministic in the sense that hashing the same data always gives the same answer; random in the sense that the value of the hash is basically unpredictable without actually computing it. And sufficiently unpredictable that, ...


31

None. Cryptographic hashes are not directly suitable to store password hashes. You should use a password hash (also known as a Password Based Key Derivation Function or PBKDF if it is used to derive a key) such as one of the secure variants of Argon2 to store passwords, not a generic cryptographically secure hash function. However, if you're working with ...


30

Firstly, some definitions; Pre-image resistant: given a hash value $h$ find a message $m$ such that $h=Hash(m)$. Consider storing the hashes of passwords on the server. Eg. an attacker will try to find a valid password to your account. Second Pre-image resistant: given a message $m_1$ is should be computationally infeasible to find another message $m_2$ ...


28

The current Argon2 draft RFC, I think, provides a good, reasonably brief answers to this question. TL;DR: most people will indeed want to use Argon2id and not the "pure" variants. The introduction summarizes the issues quite well: Argon2 has one primary variant: Argon2id, and two supplementary variants: Argon2d and Argon2i. Argon2d uses data-depending ...


26

Does this look like it's done by someone who knows what they're doing or is it just a case of someone throwing all the algorithms they find together and hoping it's a good solution? This is obviously someone who threw something together without knowing what they were doing. If they knew what they were doing, they wouldn't roll their own algorithm (“Dave, ...


24

First, following the "next big thing" is not generally a good idea in the world of cryptography. You should strongly prefer battle-tested code and algorithms over new ones. In this particular case, consensus is mostly that Argon2 is highly unlikely to fall victim to attacks that make it worse in practice than scrypt, bcrypt, or PBKDF2, so you're not ...


19

I'm wondering what the recommended number of iterations would be? Unlike bcrypt or traditional crypt, argon2 does not have a single iteration count, but three parameters affecting the computational cost: Number of iterations $t$, affecting the time cost. Size of memory used $m$, affecting the memory cost. Number of threads $h$, affecting the degree of ...


18

If the attacker had already begun creating a rainbow table or is engaged in some other attack which requires knowledge of the salt, then a password change with a salt change will require the attacker to start from scratch. Always assume the attacker has before and after copies of the password hash and salt. If the salt is not changed, any work the attacker ...


17

This is called Client-Independent Update, according to the Catena paper. It is desirable to be able to compute a new password hash (with some higher security parameter) from the old one (with the old and weaker security parameter), without having to involve user interaction, i.e., without having to know the password. We call this feature a client-...


16

Does the recent Balloon hashing paper and the included attack on Argon2 effectively negate the result of the Password Hashing Competition? No. The main result of the PHC was not a single new fancy password hashing function (i.e. Argon2), but a massive advancement in the research of password hashing. We understand password hashing and how to do it much ...


16

Salt-less password hashing is only a problem since the amount of passwords actually used in practice is comparably small and also not evenly distributed. Thus it is both in terms of time and memory possible to generate a table with pre-computed hashes and then check the salt-less hashes against this table to reverse the hash. The protection against this are ...


15

I have been part of several cryptographic competitions (AES, eSTREAM, SHA-3, PHC). In every single one of them, some people worded bitter reproaches and wailed and whined about the unfairness of the selection process. It's just that people are like that, and being very good at cryptography does not prevent smart cryptographers from being basically people. ...


15

KDF must produce results that have certain randomness properties, and be very difficult to reverse. Password hashes only need to satisfy the property "difficult to reverse", without randomness requirements. This is why all KDFs work as password hashes but not the other way around.


14

I'd say the key thing that you need to spell out to answer this question is this: What information does the attacker have? This ties to one of the basic concepts of cryptography, called Kerckhoffs's principle: "A cryptosystem should be secure even if everything about the system, except the key, is public knowledge." (I recommend you read that page and ...


13

I know that humans would find it impossible to maintain a 128 bit password -- however, I wonder if there is some technical reason why a 52 bit password would not be as weak as a 52-bit encryption key for that matter. First, I would argue that 128 bits is not impossible to remember. My current password manager master password is almost 100 bits (6 words from ...


12

How much entropy is enough? For a password, something around truly 96-bits of entropy is enough. After all password usually go through some slow password hashing which increases the work load for attacks significantly. And even with a super-fast verification function 96-bit should be just out of reach of attackers. How much is overkill? Going above 500-...


12

... its practically impossible to recreate a hash that for any foreseeable endeavor its fine or is there some element that I'm missing that reduces even that extremely low probability to zero? The input space of hash functions is limited, but to a ridiculously large input message size ($2^{64} - 1$ bits), this will lead to an average of $$2^{2^{64} - 1} \...


12

This home-made construction is pointless and unnecessarily complex, Complexity is often the source of vulnerabilities. In this case, for example, I’ll wager you’re not securely handling the intermediate variables as you chain the multiple password hashes together. Simply use argon2 only and increase the work factors. “Double scrypt” is fairly meaningless as ...


12

If you are unsure, then always choose Argon2id. Only choose Argon2d if you need maximum security at the expense of side-channel risk, and only choose Argon2i if side-channel attacks are the primary threat. The number of passes just increases resistance to time-memory tradeoff attacks (TMTO). What you are probably remembering is that Argon2i is more ...


10

Hexadecimal is traditional -- by this, I mean that there first were command-line tools that used hexadecimal for output, then other people using the hash functions found it fit to stick to hexadecimal, if only to be able to compare their values with the output of the aforementioned tools. That's how traditions get established: a more-or-less random choice at ...


10

So in general, isn't this equivalent to what Bcrypt and PBKDF2 do in terms of password storage security? PBKDF2, yes, pretty much. The only real difference is that salt/password are used the other way around, with the password mixed in at every step. Bcrypt, however, is different. In your case an attacker only needs a small amount of memory compared to ...


10

Pros: The only pro is that your method is very slightly better than storing passwords in plaintext. Cons: If an attacker gains access to your database, he will easily be able to recover 99% of passwords with only a bit of work, and he won't even need anything more than a laptop. The lesson here is the usual one. Never build your own crypto. Use a secure ...


10

I agree with Thomas Pornins answer, but there was one remarkable criticism on the panel. Round two of the competition actually allowed only minor tweaks. Argon switched to Argon2, which was more a new scheme and not a tweak. I welcome the unbureaucratic decision of the panel to accept Argon2, but formally this is objectionable. The answer for the second ...


9

Answering your question If an attacker have access to a copy of my users database table containing each salt and the related salted password, I can't understand how a CSPRNG would be more secure than a SHA12 hashed UUID. Can someone elaborate? I’m not sure if you only have read the question “Cryptographically Secure Pseudo-Random Number Generator in Qt/C+...


9

The short answer DO NOT DO THAT. It is not secure. The long answer Background There are three main types of attacks against password based systems: Guessing (e.g. birth date of the person, wife's name, etc.) Brute force - trying all possible inputs Dictionary attacks To prevent an outside attacker (somebody NOT having access to your web server, just ...


9

It has been implemented, of course. In addition to the reference implementation, there are some crypto libraries with it like libsodium. It has not yet seen much use in applications or protocols, because it is relatively new and security people tend to be conservative. (And two years simply is not that long.) Stronger, at least in theory. The resistance to ...


9

That particular usage of SHA-1 uses HMAC, and then iterates that as part of PBKDF2 (which is actually defined for any PRF, not just HMAC-SHA1). As of this date (2017-05-18) HMAC-SHA1 is unbroken in terms of collisions and other attacks, so PBKDF2-HMAC-SHA1 is still considered safe. The HMAC construction, along with the many iterations in PBKDF2, protects ...


9

As Maarten writes you should use specialized password hashing algorithms and not generic hash functions. But I would like to discuss the futility of planning for 50 years into the future. It's really impossible to know what the future so far ahead has in store for us. There could be all kind of changes we can't even imagine now. Nevertheless our best bet ...


8

I think you are overstating the complexity of PBKDF2, and also, not matching it feature-wise with your alternative. Let's dispatch the latter first: as gammatester's comment mentioned, PBKDF2 supports variable output size. If you built that into your proposal, it would become more complex. Once we control for that, PBKDF2 is hardly more complex than your ...


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