I work in an organization that must meet FISMA requirements for FIPS-enabled systems. One of the thing that I am trying to do is implement a hash algorithm for our passwords. I have many choice on this: SHA-2, MD5, bcrypt (with Blowfish), RIPE, etc.
Reading through the various NIST publication, there is NOTHING that FISMA stated that I must use a specific algorithm to meet their requirements.
However, FIPS 180-4 specifies WHICH hash algorithm is considered secure according to FISMA, which is SHA-1 to SHA-512/256. NIST SP 800-132 also recommend the use of PBKDS2.
So does this mean that:
a). I HAVE to use SHA for the hash algorithm to pass the FISMA audit / requirements?
...OR...
b). I CAN use any algorithm as long as it is BETTER than SHA? I.e. don't use MD5, but bcrypt or RIPE is OK.
How about both? Hash/salt your passwords using bcrypt to take advantage of its work factor features to provide future-proofing against massively parallel brute force attacks. Then SHA-512 the result from bcrypt and store that.
You get your protection from bcrypt, and you check the FISMA/FIPS box because you're storing a hash generated with their accepted algorithm.
Even if someone could brute-force SHA-512 to find an input that generates the same hash you've got stored in the database, that input isn't a working password that can log a user into the system.
Yes, you have to use SHA. SP 800-53 references FIPS 140-2 all over the place, implying that you must use SHA-256 or SHA-512. (Avoid SHA-1).
It's spelled out clearly in the MEMORANDUM FOR HEADS OF EXECUTIVE DEPARTMENTS AND AGENCIES from the Executive Office of the President:
11. Is use of National Institute of Standards and Technology (NIST) publications
required?
Yes. For non-national security programs and information systems, agencies
must follow NIST standards and guidelines. ...
12. Are NIST guidelines flexible?
Yes. While agencies are required to follow NIST standards and guidelines in
accordance with OMB policy, there is flexibility within NIST’s guidelines
(specifically in the 800-series) in how agencies apply them. However,
Federal Information Processing Standards (FIPS) are mandatory. ...
(And think about it. NIST didn't publish SHA as a standard so that you could go and use something else instead...)
Also, SHA and Bcrypt aren't really directly comparable. SHA is a set of hashing algorithms. Bcrypt is more of a process to produce a hash with the Blowfish algorithm at its core. The FIPS equivalent of Bcrypt is PBKDF2, which uses SHA as its core algorithm.
Related
Our software has a functionality to calculate unique parts of some data.
To do that we use md5 hash function, store all hashes and eliminate those which are duplicated.
We do not use md5 for passwords hashing or in other security-critical use cases.
Will our software pass FIPS certification if we have only these use cases?
I know that md5 is not FIPS-approved algorithm, but as far as I know it is only critical when there are security risk, for example if someone is using it to hash passwords.
As per FIPS 140-2 compliance, it is strongly suggested to use only FIPS approved algorithms for digests that is listed in FIPS-180. I see you're not using it for passwords but FIPS never said that these algorithms are only meant for password hashes. Hence, MD5 should not be used in the entirety of application.
I am security analyst and I had been asked this question Is SHA1(3DES-CBC) a good encryption for storing passwords in database?
However, to my knowledge I feel use of salt for storing any sensitive information. And I feel CBC mode is vulnerable on certain protocols. And I feel this is the best pratice https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
Please correct my understanding of the above.
However, I am trying to understand the technical implication of SHA1(3DES-CBC) to better explain my team of its issues in implimentation. Please advise me on the same.
Fast hashing algorithms like SHA* are never a good choice to hash passwords, instead you should use a slow key-derivation function with a cost factor like BCrypt or PBKDF2.
I couldn't find much information about "3DES-CBC" in combination with SHA1, but both (SHA1 and DES) are hash functions without iterating.
However, to my knowledge I feel use of salt for storing any sensitive information ...
John Stevens of OWASP put together a good document on server password security and storage. It walks through the attacks and threats, and then adds steps to neutralize the threats. Here are the references to the OWASP material (you only referenced one of them):
Password Storage Cheat Sheet
Secure Password Storage Threat Model
And I feel CBC mode is vulnerable on certain protocols...
I don't believe this is correct. A block cipher operated in CBC mode is a pseudo random function. It posses the PRP-notion of security. However, it can't be used in a vacuum. Hence, the reason you need understand the material in the two OWASP references.
SHA1(3DES-CBC)...
I'm not sure what the purpose of the composite function is. You'll have to ask the developers what their security goals are, and what threat it neutralizes. Naively, I'm going to say AES/CBC or 3DES/CBC alone should have been sufficient.
You also have the key storage problem to contend with. Its known as the "Unattended Key Storage" problem, and its a problem without a solution. See Peter Gutmann's Engineering Security.
NO!
If you're storing passwords in a database, you should be using bcrypt or scrypt. bcrypt has been analyzed by numerous cryptographers over the years, and is the 'defacto' password hashing algorithm.
SHA1 is bad because:
It can be run quickly (bad, makes it vulnerable to brute force).
It is susceptible to collision attacks (this means attackers don't even need to brute force the password).
It can be easily reversed if you're not using a salt (rainbow tables).
bcrypt is great because:
It's very slow (slows down attackers trying to brute force).
It requires a lot of CPU (this means attackers need many computers, with large CPUs).
It has no collisions.
scrypt is just like bcrypt, but also requires a lot of memory to compute a hash, further slowing down attackers. scrypt is relatively new, however, so you might want to stick with bcrypt for now.
I know it's not possible to reverse an MD5 hash back to its original value. But what about generating a set of random characters which would give the exact same value when hashed? Is that possible?
Finding a message that matches a given MD5 hash can happen in three ways:
You guess the original message. For passwords and other low entropy messages this is often relatively easy. That's why we use use key-stretching in such situations. For sufficiently complex messages, this becomes infeasible.
You guess about 2^127 times and get a new message fitting that hash. This is currently infeasible.
You exploit a pre-image attack against that specific hash function, obtained by cryptoanalyzing it. For MD5 there is one, with a workfactor of 2^123, but that's still infeasible.
There is no efficient attack on MD5's pre-image resistance at the moment.
There are efficient collision attacks against MD5, but they only allow an attacker to construct two different messages with the same hash. But it doesn't allow him to construct a message for a given hash.
Yes it is possible to come up with a collision (since you map from a larger space to a smaller this is something that you can assume to happen eventually). Actually MD5 is already considered as "broken" in this respect.
From wiki:
However, it has since been shown that MD5 is not collision
resistant;[3] as such, MD5 is not suitable for applications like SSL
certificates or digital signatures that rely on this property. In
1996, a flaw was found with the design of MD5, and while it was not a
clearly fatal weakness, cryptographers began recommending the use of
other algorithms, such as SHA-1—which has since been found also to be
vulnerable. In 2004, more serious flaws were discovered in MD5, making
further use of the algorithm for security purposes
questionable—specifically, a group of researchers described how to
create a pair of files that share the same MD5 checksum.[4][5] Further
advances were made in breaking MD5 in 2005, 2006, and 2007.[6] In
December 2008, a group of researchers used this technique to fake SSL
certificate validity,[7][8] and US-CERT now says that MD5 "should be
considered cryptographically broken and unsuitable for further
use."[9] and most U.S. government applications now require the SHA-2
family of hash functions.[10]
In one sense, this is possible. If you have strings that are longer than the hash itself, then you will have collisions, so such a string will exist.
However, finding such a string would be equivalent to reversing the hash, as you would be finding a value that hashes to a particular hash, so it would not be any more feasible than reversing a hash any other way.
For MD5 specifically? Yes.
Several years ago, an article was published on an exploit of the MD5 hash that allowed easy generation of data which, when hashed, gave a desired MD5 hash (well, what they actually discovered was an algorithm to find sets of data with the same hash, but you get how that can be used the other way around). You can read an overview of the principle here. No similar algorithm has been found for SHA-2, although that may change in the future.
Yes, what you're talking about is called a collision. A collision in any hashing mechanism is when two different plaintexts create the same hash after being run through a hashing algorithm.
So passwords should not be stored in plaintext but many do anyway. For the others is there a standard way passwords are stored? I mean a SHA1 hash or MD5 hash and if so what will the salt size be? Is there a better place to ask this?
I am trying to pick the brains of sys admins and consultants working on directory services. I am trying to see if there is a pattern or not.
EDIT: I would like to clarify that I am not trying to learn how to store the passwords better myself but more trying to see how many different ways they are stored and if there is a standard if any.
MD5 has been broken for a while and SHA-1 also has problems.
If you want to store a hash that will be secure for a long time to come, SHA-256 or SHA-512 (part of the SHA-2 family of hashes, designed as secure replacements for SHA-1) are a good choice and somewhere between 128 and 256 bits of salt are standard.
However, the use of plain hashes is not the best way to do this nowadays. Adaptive hashes are specifically designed for this type of storage as the amount of time necessary to compute a result can be made to slow down with additional computations. This is a very important trait to have to prevent brute-force attacks against your stored passwords. A strong, and standard, implementation of an adaptive hash is bcrypt, based on modifications to the Blowfish encryption algorithm to make it suitable for this purpose (which is explained well here).
Passwords should be hashed and the hashes should be stored in the database.
However SHA* and MD5 are too fast a hashing algorithms to be used for the purpose of hashing passwords.
For hashing passwords, you'd ideally want something much slower which doesn't lend itself well to brute force/rainbow table attacks.
You can sure hash a password 1000s of times before storing the hash to make it time and computationally intensive but why bother doing that when you have algorithms like bcrypt that do the job for you.
You should use bcrypt to hash your password. Read more about it at
http://codahale.com/how-to-safely-store-a-password/
In bcrypt, since the salt is appended to hash - you don't even need two columns 'password_hash' and 'salt' in the table. Just 'password_hash'. The less clutter the better.
You can see this question for the answer to how long the salt should be (between 128-256 bits seems to be the consensus).
As far as what algorithm to use, you should definitely use SHA1. MD5 was considered broken long ago even though it is still commonly used (see wikipedia MD5.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm looking at hashing algorithms, but couldn't find an answer.
Bcrypt uses Blowfish
Blowfish is better than MD5
Q: but is Blowfish better than SHA512?
Thanks..
Update:
I want to clarify that I understand the difference between hashing and encryption. What prompted me to ask the question this way is this article, where the author refers to bcrypt as "adaptive hashing"
Since bcrypt is based on Blowfish, I was led to think that Blowfish is a hashing algorithm. If it's encryption as answers have pointed out, then seems to me like it shouldn't have a place in this article. What's worse is that he's concluding that bcrypt is the best.
What's also confusing me now is that the phpass class (used for password hashing I believe) uses bcrypt (i.e. blowfish, i.e. encryption). Based on this new info you guys are telling me (blowfish is encryption), this class sounds wrong. Am I missing something?
It should suffice to say whether bcrypt or SHA-512 (in the context of an appropriate algorithm like PBKDF2) is good enough. And the answer is yes, either algorithm is secure enough that a breach will occur through an implementation flaw, not cryptanalysis.
If you insist on knowing which is "better", SHA-512 has had in-depth reviews by NIST and others. It's good, but flaws have been recognized that, while not exploitable now, have led to the the SHA-3 competition for new hash algorithms. Also, keep in mind that the study of hash algorithms is "newer" than that of ciphers, and cryptographers are still learning about them.
Even though bcrypt as a whole hasn't had as much scrutiny as Blowfish itself, I believe that being based on a cipher with a well-understood structure gives it some inherent security that hash-based authentication lacks. Also, it is easier to use common GPUs as a tool for attacking SHA-2–based hashes; because of its memory requirements, optimizing bcrypt requires more specialized hardware like FPGA with some on-board RAM.
Note: bcrypt is an algorithm that uses Blowfish internally. It is not an encryption algorithm itself. It is used to irreversibly obscure passwords, just as hash functions are used to do a "one-way hash".
Cryptographic hash algorithms are designed to be impossible to reverse. In other words, given only the output of a hash function, it should take "forever" to find a message that will produce the same hash output. In fact, it should be computationally infeasible to find any two messages that produce the same hash value. Unlike a cipher, hash functions aren't parameterized with a key; the same input will always produce the same output.
If someone provides a password that hashes to the value stored in the password table, they are authenticated. In particular, because of the irreversibility of the hash function, it's assumed that the user isn't an attacker that got hold of the hash and reversed it to find a working password.
Now consider bcrypt. It uses Blowfish to encrypt a magic string, using a key "derived" from the password. Later, when a user enters a password, the key is derived again, and if the ciphertext produced by encrypting with that key matches the stored ciphertext, the user is authenticated. The ciphertext is stored in the "password" table, but the derived key is never stored.
In order to break the cryptography here, an attacker would have to recover the key from the ciphertext. This is called a "known-plaintext" attack, since the attack knows the magic string that has been encrypted, but not the key used. Blowfish has been studied extensively, and no attacks are yet known that would allow an attacker to find the key with a single known plaintext.
So, just like irreversible algorithms based cryptographic digests, bcrypt produces an irreversible output, from a password, salt, and cost factor. Its strength lies in Blowfish's resistance to known plaintext attacks, which is analogous to a "first pre-image attack" on a digest algorithm. Since it can be used in place of a hash algorithm to protect passwords, bcrypt is confusingly referred to as a "hash" algorithm itself.
Assuming that rainbow tables have been thwarted by proper use of salt, any truly irreversible function reduces the attacker to trial-and-error. And the rate that the attacker can make trials is determined by the speed of that irreversible "hash" algorithm. If a single iteration of a hash function is used, an attacker can make millions of trials per second using equipment that costs on the order of $1000, testing all passwords up to 8 characters long in a few months.
If however, the digest output is "fed back" thousands of times, it will take hundreds of years to test the same set of passwords on that hardware. Bcrypt achieves the same "key strengthening" effect by iterating inside its key derivation routine, and a proper hash-based method like PBKDF2 does the same thing; in this respect, the two methods are similar.
So, my recommendation of bcrypt stems from the assumptions 1) that a Blowfish has had a similar level of scrutiny as the SHA-2 family of hash functions, and 2) that cryptanalytic methods for ciphers are better developed than those for hash functions.
I agree with erickson's answer, with one caveat: for password authentication purposes, bcrypt is far better than a single iteration of SHA-512 - simply because it is far slower. If you don't get why slowness is an advantage in this particular game, read the article you linked to again (scroll down to "Speed is exactly what you don’t want in a password hash function.").
You can of course build a secure password hashing algorithm around SHA-512 by iterating it thousands of times, just like the way PHK's MD5 algorithm works. Ulrich Drepper did exactly this, for glibc's crypt(). There's no particular reason to do this, though, if you already have a tested bcrypt implementation available.
Blowfish is not a hashing algorithm. It's an encryption algorithm. What that means is that you can encrypt something using blowfish, and then later on you can decrypt it back to plain text.
SHA512 is a hashing algorithm. That means that (in theory) once you hash the input you can't get the original input back again.
They're 2 different things, designed to be used for different tasks. There is no 'correct' answer to "is blowfish better than SHA512?" You might as well ask "are apples better than kangaroos?"
If you want to read some more on the topic here's some links:
Blowfish
SHA512
Blowfish isn't better than MD5 or SHA512, as they serve different purposes. MD5 and SHA512 are hashing algorithms, Blowfish is an encryption algorithm. Two entirely different cryptographic functions.
I would recommend Ulrich Drepper's SHA-256/SHA-512 based crypt implementation.
We ported these algorithms to Java, and you can find a freely licensed version of them at ftp://ftp.arlut.utexas.edu/java_hashes/.
Note that most modern (L)Unices support Drepper's algorithm in their /etc/shadow files.