Comments on: Handling passwords safely in PHP http://phpit.net/article/handling-passwords-safely-php/ PHPit has dozens of PHP articles, codesnippets and FAQ's. Fri, 01 Aug 2008 23:56:21 +0000 http://wordpress.org/?v=2.0.4 by: Joe http://phpit.net/article/handling-passwords-safely-php/#comment-7734 Mon, 17 Jul 2006 11:11:33 +0000 http://phpit.net/article/handling-passwords-safely-php/#comment-7734 Wow I really a complete beginner on all of this, can someone tell me what passwords we are talking about here? Are they the passwords that users of a forum use to login to a forum or are they admin passwords? I sorry if I've missed something here, as I've said I'm a complete beginner. Thanks Joe Wow I really a complete beginner on all of this, can someone tell me what passwords we are talking about here?

Are they the passwords that users of a forum use to login to a forum or are they admin passwords?

I sorry if I’ve missed something here, as I’ve said I’m a complete beginner.

Thanks

Joe

]]> by: Vong http://phpit.net/article/handling-passwords-safely-php/#comment-7293 Tue, 11 Jul 2006 11:40:21 +0000 http://phpit.net/article/handling-passwords-safely-php/#comment-7293 I don't think MD5 or SHA-1 can be this easily decrypted. You can read this blog about breaking SHA-1 http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html . What md5encryption.com does, IMHO, is building a dictionary online. When you hash a message, it would store it along its hash, either SHA-1 or MD5, then, when you "decrypt" it, it would simply retrieve the text. Just try hashing something on your machine, and then "decrypting" it... So be smart, and don't fuel the dictionary... I don’t think MD5 or SHA-1 can be this easily decrypted. You can read this blog about breaking SHA-1 http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html .

What md5encryption.com does, IMHO, is building a dictionary online. When you hash a message, it would store it along its hash, either SHA-1 or MD5, then, when you “decrypt” it, it would simply retrieve the text.

Just try hashing something on your machine, and then “decrypting” it…

So be smart, and don’t fuel the dictionary…

]]> by: Errol http://phpit.net/article/handling-passwords-safely-php/#comment-6052 Thu, 29 Jun 2006 20:23:48 +0000 http://phpit.net/article/handling-passwords-safely-php/#comment-6052 Why not just add to the hash by corrupting it? For example, if you remove characters or add them to the hashed string, then you can't decrypt them (unless you know what was lost or added). Why not just add to the hash by corrupting it? For example, if you remove characters or add them to the hashed string, then you can’t decrypt them (unless you know what was lost or added).

]]> by: Nilesh http://phpit.net/article/handling-passwords-safely-php/#comment-5699 Mon, 26 Jun 2006 18:19:12 +0000 http://phpit.net/article/handling-passwords-safely-php/#comment-5699 SH1 or MD5 can be decrypted , so be smart and dont use the raw info as the cookie info or whatever, see here is the way you can decrypt the SH1 or MD5 crypted text, http://www.md5encryption.com/?mod=decrypt you been warned :) SH1 or MD5 can be decrypted , so be smart and dont use the raw info as the cookie info or whatever,

see here is the way you can decrypt the SH1 or MD5 crypted text,
http://www.md5encryption.com/?mod=decrypt

you been warned :)

]]> by: nesianstyles http://phpit.net/article/handling-passwords-safely-php/#comment-1391 Tue, 25 Apr 2006 23:50:30 +0000 http://phpit.net/article/handling-passwords-safely-php/#comment-1391 Just a note, doing something like md5(md5($data)) does not make it any more secure. In fact, it actually makes it less secure because there is more chance of a collision. Just a note, doing something like md5(md5($data)) does not make it any more secure.
In fact, it actually makes it less secure because there is more chance of a collision.

]]> by: Arnold Daniels http://phpit.net/article/handling-passwords-safely-php/#comment-1127 Wed, 12 Apr 2006 20:54:10 +0000 http://phpit.net/article/handling-passwords-safely-php/#comment-1127 As long as a user doesn't turn off (standby, sleepmode, etc) his computer, the computer will keep his IP lease. So browsing through the app shouldn't give any problems. If the user goes for a cup of coffee and returns to his computer, he might need to re-enter his username and password when he return. This is very rare though, since an ip-lease usualy last for 24 hours, meaning you have to turn your computer off for 24 hours to loose your ip and get a new one. Saving the user agent, language, etc. does not add security, because there parameters are send by the client to the browser in the http-request. A hacker may simply copy the parameters (or even the whole http-header) of the client. Please have a look at: http://web-sniffer.net/. To the contrary, the ip is grapped from the socket connection, being the actual ip which is connected. Faking another ip is impossible... or atleast very hard. If you realy want you could simply leave out the ip from the session_pwd without reducing a lot of security, since the cookie identifies the computer. Arnold Daniels http://www.helderhosting.nl As long as a user doesn’t turn off (standby, sleepmode, etc) his computer, the computer will keep his IP lease. So browsing through the app shouldn’t give any problems. If the user goes for a cup of coffee and returns to his computer, he might need to re-enter his username and password when he return.
This is very rare though, since an ip-lease usualy last for 24 hours, meaning you have to turn your computer off for 24 hours to loose your ip and get a new one.

Saving the user agent, language, etc. does not add security, because there parameters are send by the client to the browser in the http-request. A hacker may simply copy the parameters (or even the whole http-header) of the client.
Please have a look at: http://web-sniffer.net/.
To the contrary, the ip is grapped from the socket connection, being the actual ip which is connected. Faking another ip is impossible… or atleast very hard.

If you realy want you could simply leave out the ip from the session_pwd without reducing a lot of security, since the cookie identifies the computer.

Arnold Daniels
http://www.helderhosting.nl

]]> by: Dennis Pallett http://phpit.net/article/handling-passwords-safely-php/#comment-1125 Wed, 12 Apr 2006 19:00:36 +0000 http://phpit.net/article/handling-passwords-safely-php/#comment-1125 Hey Arnold, You're pretty much right about most things, but I disagree about tying Sessions to IP address, because it doesn't work in practice. Many big ISP's (like AOL) actually share IP address among its thousands of users, and even worse, it's possible for a user to get a different IP address between pageviews. If their session is tied to their IP address, they'd keep losing their session data. That's why I opted to use other data, like the user agent and language set in the browser, because that's much less likely to change. Also, hashing on the client side can work, if you don't use a salt on the server side. When hashing the password on the client side, you should include the timestamp in the hash (i.e. md5(password+timestamp), and send the timestamp along. On the server side you check the hash, but you also check to make sure the timestamp is recent enough (.e.g older than 30 seconds, and its invalid). This means any one who intercepts the request can't do much with the hash. Nor can they change the timestamp, as the hash won't match then. Hey Arnold,

You’re pretty much right about most things, but I disagree about tying Sessions to IP address, because it doesn’t work in practice. Many big ISP’s (like AOL) actually share IP address among its thousands of users, and even worse, it’s possible for a user to get a different IP address between pageviews. If their session is tied to their IP address, they’d keep losing their session data.

That’s why I opted to use other data, like the user agent and language set in the browser, because that’s much less likely to change.

Also, hashing on the client side can work, if you don’t use a salt on the server side. When hashing the password on the client side, you should include the timestamp in the hash (i.e. md5(password+timestamp), and send the timestamp along. On the server side you check the hash, but you also check to make sure the timestamp is recent enough (.e.g older than 30 seconds, and its invalid). This means any one who intercepts the request can’t do much with the hash. Nor can they change the timestamp, as the hash won’t match then.

]]> by: Arnold Daniels http://phpit.net/article/handling-passwords-safely-php/#comment-1103 Wed, 12 Apr 2006 01:01:35 +0000 http://phpit.net/article/handling-passwords-safely-php/#comment-1103 <code> $ip = getenv('REMOTE_ADDR'); $key = md5(microtime()); setcookie('session_key', $key); $_SESSION['user_id'] = $user['id']; $_SESSION['ip'] = $ip; $_SESSION['session_pwd'] = md5($user['salt'] . $user['id'] . session_id() . $ip . $key); </code>
$ip = getenv('REMOTE_ADDR');
$key = md5(microtime());
setcookie('session_key', $key);
$_SESSION['user_id'] = $user['id'];
$_SESSION['ip'] = $ip;
$_SESSION['session_pwd'] = md5($user['salt'] . $user['id'] . session_id() . $ip . $key);

]]> by: Arnold Daniels http://phpit.net/article/handling-passwords-safely-php/#comment-1102 Wed, 12 Apr 2006 00:59:54 +0000 http://phpit.net/article/handling-passwords-safely-php/#comment-1102 It's me again :) Having another look at my Authenticator class, i've noticed that I've done you a bit short telling that simply saving a random key in a cookie and save the hash of that key in the session would protect you from file-editing attacks. Since the hacker can simply set his own cookie and change the hash to match, this has isn't making you app more secure. Instead you want to prevent the hacker from changing the authorizing data in the sessionfile. By creating a hash combining user salt, user id, session id, ip and key, it is not possible for the hacker to change any of this data without knowing the user salt. K, hope it helps. Arnold It’s me again :)

Having another look at my Authenticator class, i’ve noticed that I’ve done you a bit short telling that simply saving a random key in a cookie and save the hash of that key in the session would protect you from file-editing attacks. Since the hacker can simply set his own cookie and change the hash to match, this has isn’t making you app more secure.

Instead you want to prevent the hacker from changing the authorizing data in the sessionfile. By creating a hash combining user salt, user id, session id, ip and key, it is not possible for the hacker to change any of this data without knowing the user salt.

K, hope it helps.
Arnold

]]> by: Arnold Daniels http://phpit.net/article/handling-passwords-safely-php/#comment-1081 Tue, 11 Apr 2006 00:14:09 +0000 http://phpit.net/article/handling-passwords-safely-php/#comment-1081 I didn't think <form> tags would stick. I'll retry to post the form using html entities. Lets see what happens ;) <code> <form action="http://www.yoursite.com/login.php" method="POST"> <b>Username: </b> <input type="text" name="username" /> <b>Password: </b> <input type="text" name="secure_password" id="password" /> <input type="submit" name="submit" value="Login" /> </form> </code> I didn’t think <form> tags would stick. I’ll retry to post the form using html entities. Lets see what happens ;)


<form action="http://www.yoursite.com/login.php" method="POST">
<b>Username: </b> <input type="text" name="username" />
<b>Password: </b> <input type="text" name="secure_password" id="password" />

<input type="submit" name="submit" value="Login" />
</form>

]]>