Page 1 of 1

Login script using md5 encryption

Posted: Thu Feb 26, 2004 7:46 am
by phreud
I've written a small login script using md5 encryption and I want to know the weakness of this kind of approach. There must be a reason people usually store username and password in a database?

Anyway, here is the code. Please comment:

Code: Select all

<?php

$uname_entry = md5($_POST&#1111;"uname"]);
$passwd_entry = md5($_POST&#1111;"passwd"]);

$uname = "f542af5d23c2f90b1d2c8d519144b509";
$passwd = "c3c20e2d371b2cfea1bbd80d1d474cd6";

if (($uname_entry == $uname) AND ($passwd_entry == $passwd)) 
&#123;
	//Logged in
&#125;
else
&#123;
               //Not logged in
&#125;

?>
/ phreud

Posted: Thu Feb 26, 2004 8:01 am
by Illusionist
Usually usernames and passwords are stored in a database because its more than a one person login.

Posted: Thu Feb 26, 2004 8:04 am
by phreud
Ok, but, would you say in a single-user login, this is equally safe?

Posted: Thu Feb 26, 2004 8:20 am
by Illusionist
ya, thats how i did it for one of my small projects!

Posted: Thu Feb 26, 2004 8:24 am
by JayBird
i wouldn't say equally safe, becuase if you used a DB, someone would have to hack that before aquiring your MD5's password. But for a small scale application. i think your method would suffice.

Mark

Posted: Thu Feb 26, 2004 8:45 am
by Tubby
Bech100 wrote:i wouldn't say equally safe, becuase if you used a DB, someone would have to hack that before aquiring your MD5's password. But for a small scale application. i think your method would suffice.

Mark
Well with access to the source of your script (which is what they'd need to get the password in this case) they could probably get the database username/pass easily because most scripts store those in plain text.

Posted: Thu Feb 26, 2004 8:53 am
by JayBird
true, true

Like the Avatar BTW :)

Mark

MD5 password security

Posted: Thu Feb 26, 2004 9:15 am
by Roja
Password protection is about preventing attacks. There are numerous types of attacks to prevent, some more important than others.

First and foremost is db-compromise. An attacker gains access to the DB, and as a result, gets all of the user passwords. That's Bad. So, you store the password in a non-cleartext fashion. For example, using md5, like you have. One attack down.

Second is clear-text intercept. An attacker 'sniffs' the traffic between the user and the server that issues the logins. They take the traffic (username and password), and use it to login as that user. The way to prevent that is to use a client-side javascript function for md5 sum - like this one. That way, the password being sent isnt cleartext, so all they get is the md5 hash of it.. however, that doesnt prevent them from simply sending the md5 hash - like the user is doing! For that we need..

Replay attacks - An attacker 'sniffs' the traffic between the user, and the server that issues the logins. They take the traffic, and repeat it as if they were the user - and by doing so, the server thinks they ARE the user. The way to avoid a replay attack is to use a per-session salt. In simple terms, every time you come to my server, I am going to send you a "secret number". You are going to take that number, combine it with your password, and md5 the result - and I, knowing your password, will do the same thing, and see if they match. (They will).

If the attacker sniffed the traffic and replayed it, he wouldnt be let in - the secret number doesnt match! So all he got was a hash that at one point in time worked for your users login.

If you use all three (secure storage, hashed transmission, and shared-secret login), you have implemented a CHAP login system - which is the very same system used in most linux and unix systems.

Overly complex? Definitely. Overkill for most applications? By far.

However, it is a very secure way to do a login system.

Posted: Thu Feb 26, 2004 9:42 am
by phreud
Thanks for all the answers. This is not a very security critical system, so I'll go with my approach then. Nevertheless, Roja's post was very interesting. Maybe I'll try to implement it on my next project.

/phreud