Hashing ¶

Wikipedia's definition of a cryptographic hash function is as follows:

A cryptographic hash function is a deterministic procedure that takes an arbitrary block of data and returns a fixed-size bit string, the cryptographic hash value. Accidental or intentional change to the data will change the hash value. The data to be encoded is often called the "message", and the hash value is sometimes called the message digest, digest, or hash.

The ideal cryptographic hash function has four main or significant properties:

• it is easy to compute the hash value for any given message,
• it is infeasible to find a message that has a given hash (it is one-way and irreversible),
• it is infeasible to modify a message without changing its hash,
• it is infeasible to find two different messages with the same hash.

Cryptographic hash functions have many information security applications, notably in digital signatures, message authentication codes (MACs), and other forms of authentication.

This article will discuss two specific uses of hashing. First we look at hashing in authentication methods such as passwords and how to securely store passwords. For authentication hashing, applications should use a SHA-2 algorithm with a 64-bit random salt and 1000 iterations.

We will also look at hashing to ensure the integrity of binary downloads. For integrity checking, applications should use a SHA-2 algorithm, but no salt or iterations are necessary.

Hashing For Authentication¶

A typical use pattern is to store a hash of a password but not the password itself. When a user logs in with a password, the given password is hashed and compared to the stored hash. This allows the application to do password-based authentication without storing a password that could be misused if it got into the wrong hands.

What Hash Function Should I Use?¶

The short answer here is to use one of the functions in the SHA-2 family: SHA-224, SHA-256, SHA-384, or SHA-512. These are all very secure hash functions that do not have any known vulnerabilities. For authentication hashing, applications should also add "salt" to any data that is to hashed and use multiple iterations.

Salting¶

"Salting" a password with random data is necessary to prevent a couple different attacks. You should append at least 64 bits of random, secret data to a password before hashing it.

If each password is simply hashed, identical passwords will have the same hash. There are two drawbacks to this:

• Due to the birthday paradox, the attacker can find a password very quickly especially if the number of passwords the database is large
• An attacker can use a list of precomputed hashed (as in a Rainbow table) to break passwords in seconds.

In order to solve these problems, a salt can be concatenated to the password before the digest operation. A salt is a random string of a fixed bit length. This salt must be different for each stored entry, and must be stored as clear text in the persistence layer. The salt should be kept a secret and never displayed to users.

Because an attacker needs both components for either to be useful, you may also consider segmenting the salts from the password hashes. For example, having the salts and hashes on different physical servers would help prevent compromised data if an attacker gets physical access, or a backup drive of either server.

In the salted configuration, an attacker must use a brute force attack on each individual password. The database is now birthday attack/rainbow crack resistant.

The RSA PKCS #5 v2.1 draft specifies that a salt of at least 64 bits should be used. To do this, generate a random object 64 bits long, then base64 encode it. Before hashing the data, append this salt to data.

Multiple Rounds¶

Slowing down the hashing stage by hashing multiple times has minimal impact in the typical application be can seriously slow down an attacker trying to find out the message. While hashing the password n times does slow down hashing for both attackers and typical users, typical users don't really notice it because hashing is such a small percentage of their total time interacting with the system. On the other hand, an attacker trying to crack passwords spends nearly 100% of their time hashing so hashing n times gives the appearance of slowing the attacker down by a factor of n while not noticeably affecting the typical user.

A minimum of 1000 operations is recommended in the RSA PKCS #5 v2.1 draft. The stored password looks like this : hash(hash(hash(………(hash(password|salt))………)))

Hashing For Integrity¶

For large downloads where corruption could possibly take place, or sensitive downloads that you want to protect against tampering, it's a good idea to publicly post a hash value for each file. End users can then hash the file and verify its integrity.

Developers should hash the files using a SHA-2 algorithm and post the hash value along with the download link on their website. Developers should also point users to documentation on how to verify the integrity of the download and what tools they can use on their operating system.

What Hash Function Should I Use?¶

The short answer here is to use one of the functions in the SHA-2 family: SHA-224, SHA-256, SHA-384, or SHA-512. These are all very secure hash functions that do not have any known vulnerabilities.

For Windows and Mac OS X, the HashTab program can be used to verify SHA-2 hashes. Most Linux operating systems come with command-line tools corresponding to the SHA-2 hash functions such as sha224sum, sha256sum, sha384sum, and sha512sum.

---

• Version: latest
• Edited by Craig Younkins on 7/26/10 10:05 AM
• History
• Edit

Wiki content is available under a Creative Commons 3.0 License.