Lets start with the baaad examples:

The user we have is named "Bob", he likes to use his password "donuts".

Force users to use secure passwords

This is the first point where we have to interact. It does not matter how good our system will encrypt or hash Bobs password, with a simple one like this it does not make sense at all. We need to force Bob to use a more secure password. Good password contain of upper and lowercase letters, numbers and maybe even special chars. But this is not the subject of this article, so we continue with our bad examples.

We forced Bob to use a more secure password like "IlikeD0nuts".

Plain text passwords

The simplest way to store and validate Bobs password would be saving it "as is". The only good thing about this method is, we can send him his password back in case he forgot it. (Hint: If you ever use a "Remember password" function and they send your plain password back, the used some kind of this bad technique.)
The bad thing about this is, if a attacker gets read access to the database, he can read out Bobs password. The attacker is now able to login as Bob and do whatever he wants with Bobs account. If Bob has used the password also for his Email account or anything else the attacker can find out, Bob might get in serious trouble.
As you can see, storing plain text passwords is very bad and should NOT be done.

MD5 / SHA1 passwords

The next better way to store a password, is NOT to store the password. Yes, do NOT store the password, store something that is equivalent to the password but cant be reconverted to the password again.
This one way encryption method is called "hashing". Most famous and versatile hashing methods are MD5 and SHA1. Both can do a one way encryption like this: The MD5 of the string "abc" is: md5('abc') = 900150983cd24fb0d6963f7d28e17f72. The MD5 of "abc" will always be 900150983cd24fb0d6963f7d28e17f72. But if only one char changes, the MD5 will also change. md5('abd') = 4911e516e5aa21d327512e0c8b197616. So this function can create a hash out of a string which is "unique" for this string. But there is NO function like this: unmd5('4911e516e5aa21d327512e0c8b197616') = "abd" because it is a one way encryption. Like a one way flight, you cant get back home when you are at your destination.
You can play around a little bit with these function on: http://php-functions.com/
This feature of a hash can be used to validate a password. So if Bob registers his new account, we do NOT save his password "donuts" in our database, we save md5('donuts') = 6c493f3632cf8c85348ebd89d1e3cafa. A attacker cant see directly what 6c493f3632cf8c85348ebd89d1e3cafa means. If Bob wants to login, we just have to check if md5($password_bob_entered) = 6c493f3632cf8c85348ebd89d1e3cafa. When it is true, Bob must have entered "donuts".
This way of saving password is the first step in the right direction, but still no good practice. The problem is, that a MD5 will always be the same for a specific string, this hole is used by several online pages and programs to reverse a md5. Just search for "md5 cracker" and you will find tons of ways for cracking MD5 or SHA1 hashes. This plus the fatal use of simple passwords like "donuts" (Google: "donuts") will make cracking only a matter of time. So once again, storing simple MD5 or SHA1 hashes is NOT secure.

MD5 / SHA1 hashes with salt

This technique is similar to the previous, with one difference, store something additionally called "salt". Like salt in a soup this extra string will make cracking password catchier. The procedure goes like this:
Bob registers with his password "donuts". We generate a random(!) salt, like "8ft$U3", and will hash his password like this: md5("donuts"."8ft$U3") = 9aaa94551048442a835f5ae875687714. Now we save his name, the salt and the salted password hash in our database. The clever ones of you might have noticed, we just made a secure password out of the simple "donuts". This technique is popular today and sometimes called "good practice". But this is dead wrong. In times of multicore CPUs and incredible fast graphic cards, breaking such a salted hash needs, if the password is not too complex, only a few hours. Current highend graphic cards are able to calculate billions of md5 per second, so breaking thousands of hashes is only a matter of time before a attacker can start his raid against all the cracked user account. So do NOT use simple salted hashes.

MD5 / SHA1 hashes with salt hashed multiple times

As we learned from the previous technique, cracking hashes is only a matter of time. So what takes cracking hashes longer? It is complexity. We can add these complexity by rehashing the hash again and again till we reached a level where cracking such a hash will take ages.
I wrote this PHP class for demonstration, you can use it wherever you want, but keep the copyright header:

PHP Secure Hash Class

The class is using everything what makes a hash complex enough to save it from being cracked. Salts are completely generated from special chars. Salts are random. Hashes are rehashed random multiple times. The whole hash is stored in a special format which can be saved easily in a database. The format looks like this: $method$salt$iterations$hash$.

Ideas for even more secure hashes

I wrote about storing hashes in a database. The common way nowadays for an attacker is to find a SQL injection to read out your database. This is a major hole in security of websites. The whole password verification data is stored inside a database. My idea is to add another vector to this data which is not saved inside the database. Something like a global salt for all password hashes. This way, a attacker needs access to the database and to the source of the config files.
This idea is also implemented in my secure_hash php class.

Pitfalls of password hashing

There a a few pitfalls you have to care about when using hashes.

First, the charset of the password string is important. You have to understand how a hashing function works. It is not just randomizing a string and producing some chars. A hashing function does NOT work with chars, it works with their byte interpretation. It is also possible to create a MD5 from a file. So if your website is using the LATIN charset, your passwords will be hashed with the LATIN byte interpretation of these chars. If you use UTF8, these hashes can be completely different! A example: the umlaut 'ä' is in LATIN "961fa22f61a56e19f3f5f8867901ac8cf5e6d11f" but in UTF8 is is "89d39ea0600180286a2f794d8b2c4d5b02450ed9". Keep this in mind if you want to change the charset of your site.

Check for system chars! If i say system chars, i mean things like blanks, tabs, newlines and carriage returns. For example the string 'a' will be this SHA1: "89d39ea0600180286a2f794d8b2c4d5b02450ed9", but the string 'a ' will be "9384a39d69d104db5d1db7ccceae2ce0cb6c01c2".
To reduce this risk use the trim() function to remove this chars from the passwords.

Other Algorithms than MD5 or SHA1 (Update)

Jani Hartikainen mentioned in his comment, that there are more algorithms than just md5 and sha1 and some of them are very slow compared to md5.
That is a good point, which has some up and downsides.

Using a uncommon algorithm brings more security, because a attacker might not know the algorithm or have a tool for cracking it. Also is a slower hashing routine a problem for the attacker.

There might be a problem with uncommon algorithms, if you want to move to an other hoster, he might not support your hashing routine.

If you want to use something else then MD5 or SHA1, just have a look at MHash or Hash PHP modules.

If you want to use your own hashing method, my PHP Secure Hash Class supports it. Just have a look at the example class "secure_hash_example".

Personally, i would not use something like whirlpool, tiger or haval, because they create dependencies which make the whole system more complex. I would let the simplicty win here.

I hope you learned how to store passwords secure and will make the Internet a safer place.

Download / Source

http://juliusbeckmann.de/code/class.password.phps
http://juliusbeckmann.de/code/class.password.php.txt

Usage / Example

Background

What is a "salt" good for?
A salt adds a pretty random string so passwords to make the hash more secure.
The saltless password grandma becomes a5d19cdd5fd1a8f664c0ee2b5e293167.
If you use the salt="!24sf+fs5SDG65-54" then grandma!24sf+fs5SDG65-54 becomes bab9015f430ad28f420581f069f5736f
And nobody would know that bab9015f430ad28f420581f069f5736f was "grandma"

Check it yourself:
Google a5d19cdd5fd1a8f664c0ee2b5e293167 = "grandma"
Google bab9015f430ad28f420581f069f5736f = "grandma!24sf+fs5SDG65-54"
You can clearly see yourself the salted password hash is not known by Google.

What are iterations good for?
Iterations mean you make a hash from a hash.
Again the "grandma" example:
md5(grandma) = a5d19cdd5fd1a8f664c0ee2b5e293167
md5(a5d19cdd5fd1a8f664c0ee2b5e293167) = ce807f095fa160ccce736e007fe74ff1
md5(ce807f095fa160ccce736e007fe74ff1) = e720fe3e6cc002a0eaabf5300283bd56
md5(e720fe3e6cc002a0eaabf5300283bd56) = ...
But be carefull, plain rehashing is not more secure than single hashing.
What makes rehashing more secure is using the salt again what makes the new hash dependent from the previous hash AND the salt.

In der wp-login.php gibt es die Möglichkeit mit den Paramatern: ?action=rp&key=LANGER_KEY ein Passwort zurücksetzten zu lassen. Bedingung hierfür ist jedoch dass der key in der Datenbank gefunden wurde.

Code:

Schauen wir uns mal den Code genauer an:

Erklärung:

Der Parameter $key kommt direkt von $_GET['key']. Dieser wird jetzt mit preg_replace() aller Zeichen ausser a-zA-Z0-9 bereinigt. Und hier liegt auch schon das Problem. Dummerweise akzeptiert preg_replace() auch Arrays als Parameter wo dann jeder einzelne Eintrag des Arrays abgearbeitet wird. Link zur PHP Doku: http://de.php.net/manual/en/function.preg-replace.php.

Was manche nicht wissen, es ist möglich auch ein Array per GET zu übergeben. Man müsste dazu in der URL schreiben: &key[]=eintrag.

Wenn man dies nun macht wird nach dem preg_replace $key ein Array sein mit genau einem Element drin. Da aber Arrays mit mindestens einem Element drin als true gewertet werden liefert empty($key) hier false und es wird KEINE Fehlermeldung ausgespuckt.
Was danach passiert ist teils auch nicht so ganz offensichtlich. Im Aufruf von $wpdb->prepare wird $key benutzt welches, da es ein Array und kein String ist nicht korrekt geparsed welches zu folgender Query führt: "SELECT * FROM jb_v1_users WHERE user_activation_key = ''". Es steht jetzt am Schluss = '' - diese Query findet also den ersten Datensatz in der user Tabelle wo die Spalte user_activation_key leer ist. Dies ist meistens der Admin. Im Nachfolgenden Code wird jetzt das Passwort des Admins geändert was auch schon den ganzen Exploit ausmacht. Der Admin kann sich vorerst nicht mehr einloggen.

Beheben lässt sich das ganze indem der Admin einfach seinen Passwort Hash in der Datenbank ändert und sich so wieder einloggen kann.

Fix:

Um diese Lücke zu fixen gibt es mehrere Möglichkeiten:

Wir machen aus:

was uns dann immer einen String zurückliefern wird. Zwar würde im Fall dass $key ein Array ist nachher "Array" drin stehen, aber diesen Key wird bestimmt keiner als user_activation_key haben.

Oder wir machen aus:

welches die Fehlermeldung ausgeben wird wenn $key fälschlicherweise ein Array ist.

Der Bug ist echt nicht auf den ersten Blick zu sehen, daher auch keine Schande über die Wordpress Programmierer. Mein Rat an dieser Stelle, lieber ein paar mal mehr casten als zu wenig.

In der phpMyAdmin Dokumentation fand sich den auch der Grund, der Login mit leeren Passwörtern ist ab Version 3 per default nicht gestattet:

http://www.phpmyadmin.net/documentation/#config

Die Einstellung um dies zu deaktivieren lautet:

Allow attempt to log in without password when a login with password fails. This can be used together with http authentication, when authentication is done some other way and phpMyAdmin gets user name from auth and uses empty password for connecting to MySQL. Password login is still tried first, but as fallback, no password method is tried.

Ich finde diese Einstellung macht Sinn da es sonst bei einer unbewussten Installation von Mysql einem möglichen Angreifer ein unnötiges Tor öffnet.

Es wird empfohlen alle betroffenen Systeme mit der OpenSSL Schwachstelle upzudaten: Ubuntu Linux LTS 8.04 und Kubuntu, Edubuntu, and Xubuntu.

Das Updaten geht so:

Damit die Änderungen auch übernommen werden ein Neustart:

Quelle:
http://www.linuxsecurity.com/content/view/139127?rdf