Use of a One-Way Hash without a Salt Năstase George-Daniel MSI2

One way function A one-way function is a function that is easy to compute on every input, but hard to invert given the image of a random input. Can also be collision resistant(optional) Example: discrete logarithm: given a prime p and an integer y between 0 and p−1, find x such that 2x = y Other examples: Multiplication and factoring, modular squaring.

Hash function A hash function is any function that can be used to map data of arbitrary size to data of fixed size. You don’t need a cryptographic hash function for this.

One-way cryptographic hash function The ideal cryptographic hash function has four main properties: it is easy to compute the hash value for any given message it is infeasible to generate a message that has a given hash(=>one way function) it is infeasible to modify a message without changing the hash it is infeasible to find two different messages with the same hash. Ex: MD5, SHA-1, etc.

Rainbow Tables Are a compromise between pre-computing all plaintexts to hashes and looking up through a table of [plaintext, hash]. 493823--H-->222f00dc--R-->22200--H-->920ecf5y The table only stores the starting plaintext, and the final hash you choose to end with, and so a chain "containing" millions of hashes can be represented with only a single starting plaintext, and a single finishing hash.

Rainbow Tables – How to use We have a hash and want to find the plaintext, so we search the saved hashes. If we find that hash, we reconstruct the hash-chain and obtain the plaintext. If we don’t find that hash, we start building a new hash-chain and after each new generated hash we search though the saved hashes to see if we already know it.

Vulnerabilities Some hash functions have become vulnerable(MD5, SHA-1). Along with the mistake of not using a salt this makes it easier for attackers to pre-compute the hash value using dictionary attack techniques such as rainbow tables. Its should be noted that, despite common perceptions, using a salt with a hash does not sufficiently increase the protection level. An attacker who is targeting an individual password, or who has a large amount of computing resources available can still pre- compute the hash. The use of a salt only slightly increases the computing requirements for an attacker compared to other strategies such as adaptive hash functions.

Vulnerabilities (2) The real danger is "offline" cracking. Hackers break into a system to steal the encrypted password file or eavesdrop on an encrypted exchange across the Internet. They are then free to decrypt the passwords without anybody stopping them. If an attacker can obtain the hashes through some other method (such as SQL injection on a database that stores hashes), then the attacker can store the hashes offline and use various techniques to crack the passwords by computing hashes efficiently. (CWE-916: Use of Password Hash With Insufficient Computational Effort)

Detection Source code Weakness Analyzer (ex: flawfinder, clang, etc.) Context-configured Source Code Weakness Analyzer Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies (less efficient)

Example 1 A user is logged in if their given password matches a stored password: unsigned char *check_passwd(char *plaintext) { ctext = simple_digest("sha1",plaintext,strlen(plaintext), ... ); //Login if hash matches stored hash if (equal(ctext, secret_password())) { login_user(); } This code does not provide a salt to the hashing function, thus increasing the chances of an attacker being able to reverse the hash and discover the original password.

Example 1 fixed unsigned char *check_passwd(char *plaintext) { strcpy(stext,plaintext); strcat(stext,salt); ctext = simple_digest("sha1",stext,strlen(stext), ... ); //Login if hash matches stored hash if (equal(ctext, secret_password())) { login_user(); }

Example 2 In this example, a new user provides a new username and password to create an account. The program hashes the new user's password then stores it in a database. unsigned char *add_db(char *user, char *pass) { cpass = simple_digest("sha1", pass,strlen(pass), ... ); update_db(user,cpass); } Because there is no salt provided to the hashing function, the chances of an attacker being able to reverse the hash and discover the original password if the database is compromised.

Example 2 fixed unsigned char *add_db(char *user, char *pass) { strcpy(spass,pass); strcat(spass,salt); cpass = simple_digest("sha1", spass,strlen(spass), ... ); update_db(user,cpass); }

Adaptive hash function Can be configured change the number of iterations ("stretching"). (md5(md5(“plain”)) Can be configured to randomize the salt. The number of iterations and salt are saved in the database along with the hash. Ex: bcrypt, scrypt, PBKDF2, etc.

Adaptive hash function (2) While there is active debate about which of these functions is the most effective, they are all stronger than using salts with hash functions with very little computing overhead. Note that using these functions can have an impact on performance, so they require special consideration to avoid denial-of-service attacks.

References http://cwe.mitre.org/data/definitions/759.html http://kestas.kuliukas.com/RainbowTables/ http://Wikipedia.org