Re: Proposal for Lite Encryption for Login Form without SSL

klenwell wrote:
On Sep 30, 9:08 pm, Jerry Stuckle <jstuck...@xxxxxxxxxxxxx> wrote:
klenwell wrote:
Another request for comments here.
I'd like to accomplish something like the scheme outlined at this page
here:
http://tinyurl.com/3dtcdr
In a nutshell, the form uses javascript to hash (md5) the password
field using a random one-time salt (nonce) -- generated by php and
pasted in the form -- that is then posted with the hashed password
back to the server. This way the password is not sent to the server
in plaintext.
In the example cited above, however, the password is stored unhashed
back at the server (i.e., in the database) and it's this problem
that's been tying me in knots this evening.
The most obvious way it seems to me to cut through the knot is to
simply copy the server-side salt (sss) used to hash the pw in the
database -- the salt is constant -- within the javascript portion of
the form so that that client would:
1. ssspw = md5(sss + pw)
2. nssspw = md5(nonce + ssspw)
3. post (1) nssspw, (2) nonce, (3) username (in plaintext)
Then on the server side, php would:
1. db_ssspw = fetch hashed password from db (which should == ssspw)
using username
2. db_nssspw = md5(POST[nonce] + db_ssspw)
3. compare POST[nssspw] and db_nssspw
While this does not expose the plaintext password or the hashed
password in the database, it does make public the server-side salt
used to generate the hash password by pasting it in plaintext in the
javascript -- though it does not post it from the form back to the
server.
So questions:
1) Is exposing the server-side salt a terminal flaw in this plan?
This would be the equivalent to a public key in public key encryption
systems, no?
2) Does exposing the server-side salt render hashing the password in
the database moot?
3) If this is flawed, is it still better than nothing, accepting as
given that SSL has been ruled out? (The article above notes that
Yahoo uses a system like this.)
4) Any better ideas for accomplishing the concept outlined here?
Before I run this over to the cryptology newsgroup, I thought I'd give
it an airing here.
Thanks,
Tom
Why do you need to use the same salt (or even the same encryption
method) for the database?

Also, sending the password over an unencrypted link (even if the
password itself isn't encrypted) doesn't really give you anything. If I
want to hack into your system, all I need to do is watch the link for
the encrypted password coming over it, and create my own form (sans
javascript) to encrypt the password on my end and send it.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@xxxxxxxxxxxxx
==================

Good points:

Why do you need to use the same salt (or even the same encryption
method) for the database?

It's a one-way hash, so the input strings have to match. And I don't
think that's possible without sharing the db salt with the client.
Two-way encrypt/decrypt might solve this, but I don't know offhand a
library or function that's readily available for both js and php.

Also, sending the password over an unencrypted link (even if the
password itself isn't encrypted) doesn't really give you anything. If I
want to hack into your system, all I need to do is watch the link for
the encrypted password coming over it, and create my own form (sans
javascript) to encrypt the password on my end and send it.

Yes, true, I've misapplied this. I don't think you would even have to
hash the password. Just send those three values: (1) nssspw, (2)
nonce, (3) username and they would work every time.

Looking again at the website cited, what should happen first is:

1. Server (PHP) generates challenge value (nonce) and includes it in
form as hidden value and *saves it as a session value* so not passed
back in open via form (i.e. SESSION[nonce]).
2. User submits form with : (1) username (in plaintext) (2) password
(in plaintext) (3) nonce [this is all still private and it has not
been posted yet]
3. The server-side salt (sss) is posted in the js section of form to
hash password to match db.

Then before posting back to server, javascript kicks in client-side:

1. ssspw = md5(sss + pw)
2. nssspw = md5(nonce + ssspw)
3. POST (1) nssspw, (2) username (in plaintext)

Then on the server side, php would:

1. db_ssspw = fetch hashed password from db (which should == ssspw)
using username
2. db_nssspw = md5(SESSION[nonce] + db_ssspw)
3. compare POST[nssspw] and db_nssspw
4. unset SESSION[nonce]

So then, if an eavesdropper sends back (1) nssspw, (2) username,
request fails because there's no SESSION[nonce] value anymore.

Thanks for drawing attention to my error, Jerry. This still leaves
open the questions:

1) Is exposing the server-side salt a serious issue?

2) Does exposing the server-side salt render hashing the password in
the database moot?

3) Any better ideas for accomplishing the concept outlined here?

The article also makes the obvious point that javascript is not always
enabled. I figure this could be addressed by including a note that
recommends turning on javascript. I think it's fair to assume that
anyone savvy enough to turn it off can turn it on long enough to log
in. If not, info could just be submitted in plaintext (assuming the
safety of the nation is not at risk if someone does happen to be
eavesdropping.)

Tom


Tom,

Not a lot more secure. Someone needs to see the traffic going both ways, but if they can, it's still quite easy to do.

You may think this is a minor concern - and in most non-financial transaction instances, it is. But if someone can see the traffic going one way, they can see it going the other.

The problem with any of these ideas is the only thing it's doing is giving you a false sense of security. You're sending data across an unencrypted link, which means the information can be received, decoded and duplicated.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@xxxxxxxxxxxxx
==================
.

Relevant Pages