Page 1 of 1

Secure registration login

Posted: Mon Nov 21, 2005 1:58 pm
by DoubleAce3
I want to be able to set up a secure site with a registration page and login. I need to get more information concerning securely logging in with one way encryption MD5 or SSH1. I've been reading some stuff on the web and I"m still a bit confused. For example, when we create a registration page are we sending the password to the server encrypted with md5?? If that's the case are we saving this into a table on the server? I have a some more questions but would defer to have a response before continuing.

Re: Secure registration login

Posted: Mon Nov 21, 2005 2:18 pm
by Roja
DoubleAce3 wrote:I want to be able to set up a secure site with a registration page and login. I need to get more information concerning securely logging in with one way encryption MD5 or SSH1.
You have a bunch of things wrong there. First, I think you meant SHA-1, not SSH-1.

SHA-1, like MD5, is a hashing algorithm. SSH is a different beast, that lets you choose multiple encryption types, handles end-to-end encryption, authentication, and a whole lot more.

Now, if we are talking about SHA-1 and MD5, neither are encryption. Enciphering is arguably correct, and one-way is certainly arguably correct. The best-fit term would be "Hashing" functions. Just like compression isn't (arguably) encryption, hashing isn't either. However, a hash function is one-way, and does provide what you are (probably) looking for: Confidentiality of data in transit.
DoubleAce3 wrote:For example, when we create a registration page are we sending the password to the server encrypted with md5??
That depends on your goals. For maximum security, you'd want to send (from the client) their password (hashed), and a unique salt, which is added to the hashed password, and the combined elements are then hashed.

Then on the server side, you take the stored hashed password (no cleartext storage, please!), combine it with the same unique salt, and do the same hash the client did. Compare the two, and you are all set. It sounds more complicated than it is.. here's a quickly sample code:

Code: Select all

--client--
$password = "secret";
$hash = "secrethash"; // received from the server
$hashstep1 = sha1($password) . $hash;
$superhash = sha1($hashstep1);

--server--
$hashed_password = "5ebe2294ecd0e0f08eab7690d2a6ee69";
$hash = "secrethash"; // sent to the client as well
$hashstep1 = $hashed_password . $hash;
$superhash = sha1($hashstep1);

if ($superhash == $_POST['superhash'])
{
    echo "Success!";
}
DoubleAce3 wrote:If that's the case are we saving this into a table on the server? I have a some more questions but would defer to have a response before continuing.
Yes, you sure can. Thats the beauty of the above method.. storing the password would be a high-risk situation, while storing the hash of the password is lower risk.

Do take the time to read my tutorial on md5: viewtopic.php?t=25624

Secure registration login

Posted: Mon Nov 21, 2005 2:59 pm
by DoubleAce3
Thank you - I understand how a secure login works now... my next questions is: "How do you create a secure registration?". Since md5 & sha-1 is 1-way hashing how do you store/retrieve the original plain text password..... otherwise wouldn't the intercepted information (during registration) be enough to reverse engineer whatever client-side logic you may have (eg: javascript md5) and use that to successfully login?
Ex:
I have md5(plaintext password)
I know the random seed (shows up in html form)
I can then create my own form passing md5(md5(plaintext password) + seed) ???

Re: Secure registration login

Posted: Mon Nov 21, 2005 4:25 pm
by Roja
DoubleAce3 wrote:Thank you - I understand how a secure login works now... my next questions is: "How do you create a secure registration?".
That one, I won't answer, but let me explain why.

"Secure" is highly misleading. Working in Information Security, you learn that thinking of things in terms of "Secure" and "Insecure" is extremely unfair. First, the only truly secure computer is one that is turned off, unplugged, and locked in a vault. Since thats not realistic, there must be a gray area inbetween Insecure and Secure, right?

Which is where you end up with the concept of Risk, and Controls. In any system there is an acknowledged amount of risk, and you put controls around that risk to contain the potential exposure. In that sense, the most important part would be identifying the risks, right? I mean, if you don't know the risk is there, you can't build a control to mitigate that risk.

Thankfully, the risks in a login system are fairly well known. Plaintext storage of credentials. Plaintext passing of credentials. Session replay attacks. Session fixation attacks. etc. etc.

Each requires a control, and most of the concepts around them are fairly well explained on the net. The problem is that some of the controls outweigh the risks in a particular problem. I program a web-based game, and plaintext storage and transmission were actively being exploited. Obviously, the risk there was very high. So that was a primary concern, and one we made a hefty control for (javascript based sha-hashing for password transmission). It had a large impact (user inconvenience), but it was worth it because of the cost the risk was generating.

Now, if you ask me how we are handling session replay attacks, I'll be honest and say we do little to fix the situation. Mostly because many of the controls that would fix it (properly) would also deeply impact the playing style of many of the current players.

So, I won't tell you how to build controls for your situation, because I can't identify your risks *and* I can't make the decision on balance between controls and impact for you.

We can however discuss implementation details, which may be all you need to build your own. :)
DoubleAce3 wrote:Since md5 & sha-1 is 1-way hashing how do you store/retrieve the original plain tex password..... otherwise wouldn't the intercepted information (during registration) be enough to reverse engineer whatever client-side logic you may have (eg: javascript md5) and use that to successfully login?
You don't store the original plaintext password. Thats bad.

You store the hashed version of the password, like I showed in the example previously. Now, as to your question about being able to replay (not reverse engineer, thats a different concern) the session with the right knowledge, yes, it is a concern.

However, we solve it by using a unique, one-time salt. (You could in this case also call it a PAD). By using a value that is only valid for a single transaction (the login), you ensure that if an attacker attempted to replay it, they would fail.

So, to use your example:
DoubleAce3 wrote: I have md5(plaintext password)
I know the random seed (shows up in html form)
I can then create my own form passing md5(md5(plaintext password) + seed) ???
The seed has expired by the time you attempt to login with that seed again.

Now, most security experts hearing the phrase "by the time you.." think race condition, so let me qualify it.. You need to lock the row on the db when you check the login, and during that lock, remove the value from the table, ideally all in one transaction.

That way, there is no race condition, and each seed is truly one-time/unique. Without an accurate seed, they can't get the hash. Plus, they don't gain access to the hashed password (sent to the server hashed *with* the seed).

Which means that the authentication information is one-time-use-only.

Was that more clear?

Secure registration login

Posted: Tue Nov 22, 2005 11:23 am
by DoubleAce3
Much clearer now! I appreciate your help.

Posted: Wed Nov 23, 2005 2:49 am
by Maugrim_The_Reaper
See tutorial in signature for a secure login scheme (SHA256 + Salt) for sending passwords from client to server.

</shamelessplug>