views:

248

answers:

4

Hi, I am going to generate a random password for my users. Probably I will use salt and sha1 method. But I found that there are other version of sha1, like sha256, sha512 etc.

What is the differences between the sha versions? Which one better, more secure, and faster (performances)? Which one should I use??

EDIT:

I am php user, thanks :)

A: 

here's the wiki you can read about sha

there it talks about sha-2 family being algorithmically similar, however sha-1 is more popular.

ghostdog74
Have you generate random password? What method do you use? Can write a sample code here please?
jingleboy99
+2  A: 

Password generation is not as straightforward as you may think. For instance, if you're generating a password for a site which can be accessed from a mobile phone (or any device with only a numerical keyboard) you should ensure that no two consecutive characters in your password are on the same key since that would be a huge UI flaw.

An example: consider dfe4Pl7 as a password. In order to type it in, a used should press 3 once, than wait, then press 3 three times, then wait again and press '3' two more times. This sucks.

In more general terms, password should be generated so that misinterpretation is avoided as much as possible. For example, I'd personally avoid including 1's and l's, 0's and O's, etc.

The bottomline is: hashing algorithms will be of a very little help here. What you need is a good random-number generator and a UI-wise solid generation algorithm.

Anton Gogolev
Well, maybe I could not grab what are you trying to say, but I feel that you are not directly answer my question. But your answer has given me a new solution for generating password. Thanks for that, but I still cant vote you as best answer yet..
jingleboy99
+1  A: 

Encryption algorithm security doesn't mean anything if you are simply using them to make random letters and numbers for a password. You are better off making a random password function, it would be MUCH more efficient.... Why are you salting anyway?

Here is a SIMPLE password generator written in PHP.

function RandomPassword( $length )
{
    $characters = "abcdefghjklmnpqrstuvwxyz23456789";
    $result = "";
    for( $i=0; $i < $length; $i++ )
    {
        $result .= $characters[ rand( 0, strlen( $characters )-1 ) ];
    }

    return $result;
}

NOTE: i,1,0 and o are intentionally missing as they are easily mistaken as each other.

Kane Wallmann
I saw some tutorials on the net using salt method, thats why I include it, but I am not sure I am doing the right thing, thus I post this question here..
jingleboy99
Hey no worries, i've included a simple password generator in my answer you might find helpful.
Kane Wallmann
Thank you so much for the code. Much appreciated
jingleboy99
+2  A: 

You are confusing two issues here. Random password generation, which is basically picking random symbols of a certain (minimum) length, and password storage, which in practical terms involve storing a hash of the password with a salt so that the plaintext password can't be discover just by reading the database.

Generation

To pick random symbols, you have an array of all the symbols, get a random number and subscript into the array using that number as index to return a symbol. This is what Kane Wallmann suggested earlier. However, for security related application such as password generation, one need a cryptographically strong pseudo-random number generation, which rand() is not.

Storage

As noted earlier, password shouldn't be stored in plaintext in the database. Otherwise, anyone with access to it can just read it and know what the password of any and all particular user password are. What happen is a hash of the password is store instead. When a user attempt to login, their password is hash and compare to the value in the database to see if it's the same. The hashing function is what's call a one-way function. You can hash the password to get a hashed value, but you can't get the password from the hash value without trying all possible combination to see if it matches. (At least, that's the idea anyway.) It's more complicated than that of course, since hash value output is fixed length, whereas the possible input while in practical terms isn't infinite is definitely more than the possible number of output.

Now, where salt comes in is because simple hashing of the password alone isn't secure either. For one, such a method would give the same hashed value for any two users with the same password. Compromise of one account would result in the compromise of the other. Secondly, what an attacker can do is to build what is called a rainbow table ahead of time. While this take time, it only have to be done once for any storage algorithm, and he or she don't have to do it themselves. The work can be spilt over many computers, and there's in fact websites on the internet where you can download such rainbow tables for weak password hashing system such as LM and NTLM. After that, the attacker can just look up any particular hash value against the table and determine the plaintext password. So to protect against that, a random (per user) salt value is added to the password before it is hashed. This makes the input different even for the same password, so prevent the first problem. It also mitigate against the second problem if the salt & password combined is long enough as the length of the input is such that it would become computationally infeasible to brute force it.

As to the question of which particular SHA, or for that matter, other hashing algorithms to use. SHA is a US NIST standard, and are acknowledged to be pretty good. There's been a little theoretical breakthrough into SHA-1, but in practice it's still secure enough for most purpose. The SHA-2 algorithms are better than SHA-1, with no known breakthrough. Which variant to choose are down to various things including size. They produce different length output, and different amount to calculate because of the size difference. PHP have native implementation of SHA-1, SHA-256, 384, and 512, among a number of others hashing algorithms.

After all that, in practice, which of the SHA algorithms you choose probably doesn't matter as the weak point in your system are likely elsewhere. Users writing down their passwords. Users using the same password across different systems. Programming flaw that allow things like XSS and SQL injection. Etc. etc.

KTC