Grigor
Grigor

Reputation: 4059

Safe Password Storing

Let's say I have thousands of users and I want to make the passwords very secure. Now, I've learned that md5() is not the safest to use, however what I think can be done to be safe is salt it (I know this is nothing new). So for this I was thinking of creating two tables, one called accounts which will have all information associated with accounts and a table column called salt and the second table would be called something like auth and have the fields account_id, password

to start, I create a salt upon registration (generated randomly)

$salt = "#52/sBsO8";

then all the provided information goes to accounts salt being one of them

then after successfully putting the information in database, I create the password that is going to be stored in auth table, this way the password is not the md5 of the password the user enters, rather its the md5 of the salt and the password user enters

so the password in auth is

$password = md5($user_entered_password . $salt);

Test strings: PHP Code

$password = "123";
$salt = "#52/sBsO8";
echo md5($password) ." / ";
echo md5($password . $salt);

output: 202cb962ac59075b964b07152d234b70 / dfbf0b257c5182af0ae893c2680f4594

The question is: Is this a pretty safe way of dealing with passwords? Because of md5() decrypting websites, there are so many ways to guess the passwords. And the decrypting websites don't actually decrypt the md5() they just have the md5 hashes of millions of strings.

Upvotes: 3

Views: 367

Answers (3)

Razor
Razor

Reputation: 29668

md5 is likely to be the least safe among "popular" hashing algorithms.
Since you're using PHP, a better option would be crypt: http://php.net/manual/en/function.crypt.php

crypt($password, $salt)

For a good comparison of various hashing methods, see Jeff Atwood's post about password hashing

Excerpt about brute forcing benchmarks:

MD5 23070.7 M/s
SHA-1 7973.8 M/s
SHA-256 3110.2 M/s
SHA-512 267.1 M/s
NTLM 44035.3 M/s
DES 185.1 M/s
WPA/WPA2 348.0 k/s

the lower, the better, although DES is too short to be considered nowadays (56bit, thanks @thebod).

EDIT:

Although it isn't listed in the benchmarked methods above, the best hashing method that crypt supports is blowfish, here's an example to use it:

// $salt has to be built with exactly these components:
// '$2a$' . $2DigitsNumberAroundTen . '$' . $TwentyTwoLetters
$salt = '$2a$07$somesillystringforsalt';
crypt( $password, $salt );

Upvotes: 1

martinstoeckli
martinstoeckli

Reputation: 24151

  1. Hash functions for passwords should be slow (need some computing time). Most hash algorithms are designed to be fast, but this makes it easier to create rainbow tables for every salt.
  2. The salt should be random, and should be generated separately for every stored password. This salt has to be stored together with the hash, but is not secret (can be plain text). The salt makes dictionary attacks more difficult, and different salts make rainbow tables impracticable.
  3. Ideally, you can adjust the computing time later for new hardware, without breaking existing hashes.

That's why you should use bcrypt to hash your passwords, it was designed especially for hashing password. And don't be afraid to use bcrypt! It is not for high security sites only, and using it can be as easy, as using an md5 hash.

It's recommended to use a well established library like phpass, and if you want to understand how PHP can generate such hashes, you can read this article.

Upvotes: 1

Ed Heal
Ed Heal

Reputation: 60037

Why do you think that this is more secure? The user types in a password. One assumes that the user is not an idiot and choses something that (s)he only knows. How is that different if that individual typed it in with the salt?

This actually makes it more insecure because if a person gets hold of the table that person has something to work on.

You are better off spending your engergies on ensuring that the computer is secure, your network is secure and teaching your users on sensible and secure passwords.

Upvotes: -1

Related Questions