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 19  3262 
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. js*******@attglobal.net
==================
On Sep 30, 9:08 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
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...@attglobal.net
==================
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
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.
I believe that SSL is just completely silly. Take a look at numbers
(if any). Where you lose your password and your personal data is when
you get keylogged / trojaned, which means no SSL is going to secure
you. I know that from personal experience.
Why not do the following:
1. Password is sent in MD5 (password).
3. PHP checks if the password appears to be a valid md5 string
(telling it that md5 has already happened) or not. If not, it MD5s the
password, thus avoiding any bypassing.
4. PHP MD5s the MD5 along with a RANDOM salt.
When Registering:
PHP stores the MD5 Password plus the salt.
When Logging In:
PHP receives the MD5 password from the user (if js was on, else PHP
md5s on his own) and then MD5s again, applying the salt. Then it
verifies if the two hashes are exactly the same and poof ;).
Using a salt in these cases for Javascript would be useless because:
a) The user would know which salt it was, thus if he wanted to crack
the md5, he would be in the same status as if no salt was applied.
b) If it was a random salt, when logging in, Javascript wouldn't know
which salt was used before so he couldn't repeat the action ;).
Google for "challenged authentication".
The idea is this:
The server asks a question that can only be answered if you know the
password.
The server could send the client an arbitrary word that the client
should hash, using the password as salt. This salted hash is then sent
to the server for verification.
Store the generated word in the session and clear it upon successful
login. This ensures you can only login once if someone monitors the
network traffic and the pre-login session. (You DO regenerate the
session upon successful login, don't you?)
Good luck,
--
Willem Bogaerts
Application smith
Kratz B.V. http://www.kratz.nl/
The server could send the client an arbitrary word that the client
should hash, using the password as salt. This salted hash is then sent
to the server for verification.
If it's arbitrary, then odds are it will not be repeated easily.
What I mean is how does the browser know the salt he gave the user on
registration? I can register and only log the day after. The thingy
will not be in session any longer.
On 1 Oct, 06:04, klenwell <klenw...@gmail.comwrote:
On Sep 30, 9:08 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
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...@attglobal.net
==================
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
Hi Tom,
I've used a similar method before and believe its valid:
1) Is exposing the server-side salt a serious issue?
It makes it possible to mount brute fore attacks on the back of being
able to sniff traffic. And if you have the same value for all users
then the attacker only needs to crack one to get them all. I use a
randomly generated value for all users, call it s_user and to a two
stage submit - first the username gets sent to fetch s_user and the
second salt (which MUST be single use and generated server-side - so
stored in the session - call it s_s for salt(session)) then at both
ends generate a comparison value:
client:
(send username u)
server:
$s_u=retrieve_s_u($_REQUEST['u']);
if (isnull($s_u)) {
$s_u = generate_random_salt();
}
$_SESSION['s_s']=generate_random_salt();
// send back s_u, s_s
client:
enc_pass=md5(password + s_u)
sendable_pas=md5(enc_pass + s_s)
submit(u, sendable_pass)
server:
$s_u=retrieve_s_u($_REQUEST['u']);
$s_s=$_SESSION['s_s']
$enc_password=retrieve_password($_REQUEST['u']);
$comparison=md5($enc_password . $s_s);
if (comparison==$_REQUEST['sendable_pass']) { // log em in
2) Does exposing the server-side salt render hashing the password in
the database moot?
Only if you can be 100.00000000000...% sure that there is no way to
access the data - which you can't.
3) Any better ideas for accomplishing the concept outlined here?
It only protects the login credentials, and as others have pointed out
it doesn't protect against attacks outside the operational domain (but
neither does SSL). You could address the former by using a javascript
implementation of an asymmetric alogirthm (I believe there's at least
one RSA implementation, adn there are raw RSA implementations in PHP,
but life's just too short to see if they work together - SSL's much
easier). Alternatively you could just keep the password client side
and use it as a key for symmetric encryption - but you need to use
seperate frames/windows to retain state client side - which is tricky.
I'd be willing to bet though that most users would have an expectation
that this is more secure than using a self-signed SSL certificate and
getting warnings about untrusted content popping up on their browser!
Jerry wrote:
Why do you need to use the same salt (or even the same encryption
method) for the database?
You need to use the same salt putting passwords into the database as
on the first iteration of the client side hash so the results are
consistent. You don't have to use the same hash for both iterations -
but why make life more complicated than it need be? Or did I miss
something?
(PS SHA1 is generally considered more secure than md5() and in PHP it
runs faster too)
HTH
C.
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.
Ok, I see. Hashing is not everything. If you are afraid of storing
password in plaintext you can encrypt them. How you store things in a
database has little to do with the authentication process itself.
Best regards,
--
Willem Bogaerts
Application smith
Kratz B.V. http://www.kratz.nl/
klenwell wrote:
On Sep 30, 9:08 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>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...@attglobal.net
==================
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. js*******@attglobal.net
==================
Bruno Barros wrote:
>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.
I believe that SSL is just completely silly. Take a look at numbers
(if any). Where you lose your password and your personal data is when
you get keylogged / trojaned, which means no SSL is going to secure
you. I know that from personal experience.
Which is a completely different subject. SSL is not designed to cure
stupidity or carelessness.
Why not do the following:
1. Password is sent in MD5 (password).
3. PHP checks if the password appears to be a valid md5 string
(telling it that md5 has already happened) or not. If not, it MD5s the
password, thus avoiding any bypassing.
4. PHP MD5s the MD5 along with a RANDOM salt.
When Registering:
PHP stores the MD5 Password plus the salt.
When Logging In:
PHP receives the MD5 password from the user (if js was on, else PHP
md5s on his own) and then MD5s again, applying the salt. Then it
verifies if the two hashes are exactly the same and poof ;).
Using a salt in these cases for Javascript would be useless because:
a) The user would know which salt it was, thus if he wanted to crack
the md5, he would be in the same status as if no salt was applied.
b) If it was a random salt, when logging in, Javascript wouldn't know
which salt was used before so he couldn't repeat the action ;).
You're still sending the password in the clear, even if the password
itself is MD5 hashed. It would be very simple for anyone monitoring the
packets to get this information and duplicate it. You don't even need
the real password if you know the MD5 hash value that's being sent.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
On Oct 1, 2:40 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.comwrote:
On 1 Oct, 06:04, klenwell <klenw...@gmail.comwrote:
On Sep 30, 9:08 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
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...@attglobal.net
==================
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
Hi Tom,
I've used a similar method before and believe its valid:
1) Is exposing the server-side salt a serious issue?
It makes it possible to mount brute fore attacks on the back of being
able to sniff traffic. And if you have the same value for all users
then the attacker only needs to crack one to get them all. I use a
randomly generated value for all users, call it s_user and to a two
stage submit - first the username gets sent to fetch s_user and the
second salt (which MUST be single use and generated server-side - so
stored in the session - call it s_s for salt(session)) then at both
ends generate a comparison value:
client:
(send username u)
server:
$s_u=retrieve_s_u($_REQUEST['u']);
if (isnull($s_u)) {
$s_u = generate_random_salt();}
$_SESSION['s_s']=generate_random_salt();
// send back s_u, s_s
client:
enc_pass=md5(password + s_u)
sendable_pas=md5(enc_pass + s_s)
submit(u, sendable_pass)
server:
$s_u=retrieve_s_u($_REQUEST['u']);
$s_s=$_SESSION['s_s']
$enc_password=retrieve_password($_REQUEST['u']);
$comparison=md5($enc_password . $s_s);
if (comparison==$_REQUEST['sendable_pass']) { // log em in
2) Does exposing the server-side salt render hashing the password in
the database moot?
Only if you can be 100.00000000000...% sure that there is no way to
access the data - which you can't.
3) Any better ideas for accomplishing the concept outlined here?
It only protects the login credentials, and as others have pointed out
it doesn't protect against attacks outside the operational domain (but
neither does SSL). You could address the former by using a javascript
implementation of an asymmetric alogirthm (I believe there's at least
one RSA implementation, adn there are raw RSA implementations in PHP,
but life's just too short to see if they work together - SSL's much
easier). Alternatively you could just keep the password client side
and use it as a key for symmetric encryption - but you need to use
seperate frames/windows to retain state client side - which is tricky.
I'd be willing to bet though that most users would have an expectation
that this is more secure than using a self-signed SSL certificate and
getting warnings about untrusted content popping up on their browser!
Jerry wrote:
Why do you need to use the same salt (or even the same encryption
method) for the database?
You need to use the same salt putting passwords into the database as
on the first iteration of the client side hash so the results are
consistent. You don't have to use the same hash for both iterations -
but why make life more complicated than it need be? Or did I miss
something?
(PS SHA1 is generally considered more secure than md5() and in PHP it
runs faster too)
HTH
C.
Thanks for the detailed response, C. The user-specific hash is a good
idea. How do you execute the two stages? Does the user make two
submissions? Some kind of AJAX implementation?
One thing I haven't done is explore the login mechanism on the popular
open source PHP packages. Has anyone looked at these and seen
anything that they think is worthy of emulation?
Jerry, you note: if someone can see the traffic going one way, they
can see it going the other. How serious a concern is this out in the
wild -- esp. for popular sites of general interest but no specific
financial or security significance?
I see that facebook, for instance, doesn't seem to use SSL for
ordinary users, so presumably uses something like this or perhaps even
sends them plaintext. Is packet sniffing a significant vector of
attack? Any data or references on the subject?
I've read a bit on website and network security and am familiar with
many of the various hypothetical attacks. But most real-world
instances I'm familiar with involved very high-stakes military or
financial events. The famous website exploits I've read about seem to
involve things like the js-exploit on myspace that allowed that guy to
add himself to everybody's friend-list but didn't involve exploiting
the login system or XSS vulnerabilities (which wouldn't be applicable
here) or turned out to be cases of social engineering.
Anyway, just curious.
Tom
klenwell wrote:
On Oct 1, 2:40 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.comwrote:
>On 1 Oct, 06:04, klenwell <klenw...@gmail.comwrote:
>>On Sep 30, 9:08 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
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...@attglobal.net
==================
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
Hi Tom,
I've used a similar method before and believe its valid:
>>1) Is exposing the server-side salt a serious issue?
It makes it possible to mount brute fore attacks on the back of being
able to sniff traffic. And if you have the same value for all users
then the attacker only needs to crack one to get them all. I use a
randomly generated value for all users, call it s_user and to a two
stage submit - first the username gets sent to fetch s_user and the
second salt (which MUST be single use and generated server-side - so
stored in the session - call it s_s for salt(session)) then at both
ends generate a comparison value:
client:
(send username u)
server:
$s_u=retrieve_s_u($_REQUEST['u']);
if (isnull($s_u)) {
$s_u = generate_random_salt();}
$_SESSION['s_s']=generate_random_salt();
// send back s_u, s_s
client:
enc_pass=md5(password + s_u)
sendable_pas=md5(enc_pass + s_s)
submit(u, sendable_pass)
server:
$s_u=retrieve_s_u($_REQUEST['u']);
$s_s=$_SESSION['s_s']
$enc_password=retrieve_password($_REQUEST['u']);
$comparison=md5($enc_password . $s_s);
if (comparison==$_REQUEST['sendable_pass']) { // log em in
>>2) Does exposing the server-side salt render hashing the password in
the database moot?
Only if you can be 100.00000000000...% sure that there is no way to
access the data - which you can't.
>>3) Any better ideas for accomplishing the concept outlined here?
It only protects the login credentials, and as others have pointed out
it doesn't protect against attacks outside the operational domain (but
neither does SSL). You could address the former by using a javascript
implementation of an asymmetric alogirthm (I believe there's at least
one RSA implementation, adn there are raw RSA implementations in PHP,
but life's just too short to see if they work together - SSL's much
easier). Alternatively you could just keep the password client side
and use it as a key for symmetric encryption - but you need to use
seperate frames/windows to retain state client side - which is tricky.
I'd be willing to bet though that most users would have an expectation
that this is more secure than using a self-signed SSL certificate and
getting warnings about untrusted content popping up on their browser!
Jerry wrote:
>>>Why do you need to use the same salt (or even the same encryption
method) for the database?
You need to use the same salt putting passwords into the database as
on the first iteration of the client side hash so the results are
consistent. You don't have to use the same hash for both iterations -
but why make life more complicated than it need be? Or did I miss
something?
(PS SHA1 is generally considered more secure than md5() and in PHP it
runs faster too)
HTH
C.
Thanks for the detailed response, C. The user-specific hash is a good
idea. How do you execute the two stages? Does the user make two
submissions? Some kind of AJAX implementation?
One thing I haven't done is explore the login mechanism on the popular
open source PHP packages. Has anyone looked at these and seen
anything that they think is worthy of emulation?
Jerry, you note: if someone can see the traffic going one way, they
can see it going the other. How serious a concern is this out in the
wild -- esp. for popular sites of general interest but no specific
financial or security significance?
It depends. If you're concerned about it enough that you want to
encrypt your password when it's being sent, then you should be concerned
about both directions being intercepted. It's quite easy to do, and it
doesn't take much of a filter to see both sides of the conversation.
I see that facebook, for instance, doesn't seem to use SSL for
ordinary users, so presumably uses something like this or perhaps even
sends them plaintext. Is packet sniffing a significant vector of
attack? Any data or references on the subject?
They probably just send in plain text.
Packet sniffing can be done anywhere between the client and the server.
However, since every packet can theoretically take a different route,
the most common sniffers are at the ends of the link.
The server end is probably pretty safe - if you don't trust your host,
you have a problem. And they can get to your data on the server, anyway.
The client side is a lot less secure. Someone using a wireless card,
for instance, can be intercepted. Encryption might help, if it uses one
of the latest encryption schemes. But most public hot spots run
unencrypted.
Additionally, cable modems can be insecure. It would be highly unusual
for one to be the only user on a cable distribution line. More likely
there are dozens (if not hundreds). And with the right software, any
person on the link can see all data on the link.
I've read a bit on website and network security and am familiar with
many of the various hypothetical attacks. But most real-world
instances I'm familiar with involved very high-stakes military or
financial events. The famous website exploits I've read about seem to
involve things like the js-exploit on myspace that allowed that guy to
add himself to everybody's friend-list but didn't involve exploiting
the login system or XSS vulnerabilities (which wouldn't be applicable
here) or turned out to be cases of social engineering.
Of course, those are the ones which get the news. You don't hear about
Mom's Homemade Cookie Shop's website getting broken into. It just isn't
news.
Anyway, just curious.
Tom
The question here is - why do you want to encrypt the password? Is
there any reason you need it encrypted? What's on there that someone
would want?
And in that case you probably should be using SSL.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
On Oct 1, 6:38 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
klenwell wrote:
On Oct 1, 2:40 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.comwrote:
On 1 Oct, 06:04, klenwell <klenw...@gmail.comwrote:
>On Sep 30, 9:08 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
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...@attglobal.net
==================
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
Hi Tom,
I've used a similar method before and believe its valid:
>1) Is exposing the server-side salt a serious issue?
It makes it possible to mount brute fore attacks on the back of being
able to sniff traffic. And if you have the same value for all users
then the attacker only needs to crack one to get them all. I use a
randomly generated value for all users, call it s_user and to a two
stage submit - first the username gets sent to fetch s_user and the
second salt (which MUST be single use and generated server-side - so
stored in the session - call it s_s for salt(session)) then at both
ends generate a comparison value:
client:
(send username u)
server:
$s_u=retrieve_s_u($_REQUEST['u']);
if (isnull($s_u)) {
$s_u = generate_random_salt();}
$_SESSION['s_s']=generate_random_salt();
// send back s_u, s_s
client:
enc_pass=md5(password + s_u)
sendable_pas=md5(enc_pass + s_s)
submit(u, sendable_pass)
server:
$s_u=retrieve_s_u($_REQUEST['u']);
$s_s=$_SESSION['s_s']
$enc_password=retrieve_password($_REQUEST['u']);
$comparison=md5($enc_password . $s_s);
if (comparison==$_REQUEST['sendable_pass']) { // log em in
>2) Does exposing the server-side salt render hashing the password in
the database moot?
Only if you can be 100.00000000000...% sure that there is no way to
access the data - which you can't.
>3) Any better ideas for accomplishing the concept outlined here?
It only protects the login credentials, and as others have pointed out
it doesn't protect against attacks outside the operational domain (but
neither does SSL). You could address the former by using a javascript
implementation of an asymmetric alogirthm (I believe there's at least
one RSA implementation, adn there are raw RSA implementations in PHP,
but life's just too short to see if they work together - SSL's much
easier). Alternatively you could just keep the password client side
and use it as a key for symmetric encryption - but you need to use
seperate frames/windows to retain state client side - which is tricky.
I'd be willing to bet though that most users would have an expectation
that this is more secure than using a self-signed SSL certificate and
getting warnings about untrusted content popping up on their browser!
Jerry wrote:
Why do you need to use the same salt (or even the same encryption
method) for the database?
You need to use the same salt putting passwords into the database as
on the first iteration of the client side hash so the results are
consistent. You don't have to use the same hash for both iterations -
but why make life more complicated than it need be? Or did I miss
something?
(PS SHA1 is generally considered more secure than md5() and in PHP it
runs faster too)
HTH
C.
Thanks for the detailed response, C. The user-specific hash is a good
idea. How do you execute the two stages? Does the user make two
submissions? Some kind of AJAX implementation?
One thing I haven't done is explore the login mechanism on the popular
open source PHP packages. Has anyone looked at these and seen
anything that they think is worthy of emulation?
Jerry, you note: if someone can see the traffic going one way, they
can see it going the other. How serious a concern is this out in the
wild -- esp. for popular sites of general interest but no specific
financial or security significance?
It depends. If you're concerned about it enough that you want to
encrypt your password when it's being sent, then you should be concerned
about both directions being intercepted. It's quite easy to do, and it
doesn't take much of a filter to see both sides of the conversation.
I see that facebook, for instance, doesn't seem to use SSL for
ordinary users, so presumably uses something like this or perhaps even
sends them plaintext. Is packet sniffing a significant vector of
attack? Any data or references on the subject?
They probably just send in plain text.
Packet sniffing can be done anywhere between the client and the server.
However, since every packet can theoretically take a different route,
the most common sniffers are at the ends of the link.
The server end is probably pretty safe - if you don't trust your host,
you have a problem. And they can get to your data on the server, anyway.
The client side is a lot less secure. Someone using a wireless card,
for instance, can be intercepted. Encryption might help, if it uses one
of the latest encryption schemes. But most public hot spots run
unencrypted.
Additionally, cable modems can be insecure. It would be highly unusual
for one to be the only user on a cable distribution line. More likely
there are dozens (if not hundreds). And with the right software, any
person on the link can see all data on the link.
I've read a bit on website and network security and am familiar with
many of the various hypothetical attacks. But most real-world
instances I'm familiar with involved very high-stakes military or
financial events. The famous website exploits I've read about seem to
involve things like the js-exploit on myspace that allowed that guy to
add himself to everybody's friend-list but didn't involve exploiting
the login system or XSS vulnerabilities (which wouldn't be applicable
here) or turned out to be cases of social engineering.
Of course, those are the ones which get the news. You don't hear about
Mom's Homemade Cookie Shop's website getting broken into. It just isn't
news.
Anyway, just curious.
Tom
The question here is - why do you want to encrypt the password? Is
there any reason you need it encrypted? What's on there that someone
would want?
And in that case you probably should be using SSL.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
---
The question here is - why do you want to encrypt the password? Is
there any reason you need it encrypted? What's on there that someone
would want?
A couple reasons:
(1) This is being developed as part of a framework that I plan to
reuse on many of my projects. The goal is to incorporate this
enhancement more or less transparently. So if it offers even only
marginally better security, I figure it's worth the trouble.
(2) As a learning exercise.
Plus, I guess I'm just nervous by nature. :)
Tom
klenwell wrote:
On Oct 1, 6:38 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>klenwell wrote:
>>On Oct 1, 2:40 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.comwrote:
On 1 Oct, 06:04, klenwell <klenw...@gmail.comwrote:
On Sep 30, 9:08 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>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...@attglobal.net
>==================
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
Hi Tom,
I've used a similar method before and believe its valid:
1) Is exposing the server-side salt a serious issue?
It makes it possible to mount brute fore attacks on the back of being
able to sniff traffic. And if you have the same value for all users
then the attacker only needs to crack one to get them all. I use a
randomly generated value for all users, call it s_user and to a two
stage submit - first the username gets sent to fetch s_user and the
second salt (which MUST be single use and generated server-side - so
stored in the session - call it s_s for salt(session)) then at both
ends generate a comparison value:
client:
(send username u)
server:
$s_u=retrieve_s_u($_REQUEST['u']);
if (isnull($s_u)) {
$s_u = generate_random_salt();}
$_SESSION['s_s']=generate_random_salt();
// send back s_u, s_s
client:
enc_pass=md5(password + s_u)
sendable_pas=md5(enc_pass + s_s)
submit(u, sendable_pass)
server:
$s_u=retrieve_s_u($_REQUEST['u']);
$s_s=$_SESSION['s_s']
$enc_password=retrieve_password($_REQUEST['u']);
$comparison=md5($enc_password . $s_s);
if (comparison==$_REQUEST['sendable_pass']) { // log em in
2) Does exposing the server-side salt render hashing the password in
the database moot?
Only if you can be 100.00000000000...% sure that there is no way to
access the data - which you can't.
3) Any better ideas for accomplishing the concept outlined here?
It only protects the login credentials, and as others have pointed out
it doesn't protect against attacks outside the operational domain (but
neither does SSL). You could address the former by using a javascript
implementation of an asymmetric alogirthm (I believe there's at least
one RSA implementation, adn there are raw RSA implementations in PHP,
but life's just too short to see if they work together - SSL's much
easier). Alternatively you could just keep the password client side
and use it as a key for symmetric encryption - but you need to use
seperate frames/windows to retain state client side - which is tricky.
I'd be willing to bet though that most users would have an expectation
that this is more secure than using a self-signed SSL certificate and
getting warnings about untrusted content popping up on their browser!
Jerry wrote:
>Why do you need to use the same salt (or even the same encryption
>method) for the database?
You need to use the same salt putting passwords into the database as
on the first iteration of the client side hash so the results are
consistent. You don't have to use the same hash for both iterations -
but why make life more complicated than it need be? Or did I miss
something?
(PS SHA1 is generally considered more secure than md5() and in PHP it
runs faster too)
HTH
C.
Thanks for the detailed response, C. The user-specific hash is a good
idea. How do you execute the two stages? Does the user make two
submissions? Some kind of AJAX implementation?
One thing I haven't done is explore the login mechanism on the popular
open source PHP packages. Has anyone looked at these and seen
anything that they think is worthy of emulation?
Jerry, you note: if someone can see the traffic going one way, they
can see it going the other. How serious a concern is this out in the
wild -- esp. for popular sites of general interest but no specific
financial or security significance?
It depends. If you're concerned about it enough that you want to
encrypt your password when it's being sent, then you should be concerned
about both directions being intercepted. It's quite easy to do, and it
doesn't take much of a filter to see both sides of the conversation.
>>I see that facebook, for instance, doesn't seem to use SSL for
ordinary users, so presumably uses something like this or perhaps even
sends them plaintext. Is packet sniffing a significant vector of
attack? Any data or references on the subject?
They probably just send in plain text.
Packet sniffing can be done anywhere between the client and the server.
However, since every packet can theoretically take a different route,
the most common sniffers are at the ends of the link.
The server end is probably pretty safe - if you don't trust your host,
you have a problem. And they can get to your data on the server, anyway.
The client side is a lot less secure. Someone using a wireless card,
for instance, can be intercepted. Encryption might help, if it uses one
of the latest encryption schemes. But most public hot spots run
unencrypted.
Additionally, cable modems can be insecure. It would be highly unusual
for one to be the only user on a cable distribution line. More likely
there are dozens (if not hundreds). And with the right software, any
person on the link can see all data on the link.
>>I've read a bit on website and network security and am familiar with
many of the various hypothetical attacks. But most real-world
instances I'm familiar with involved very high-stakes military or
financial events. The famous website exploits I've read about seem to
involve things like the js-exploit on myspace that allowed that guy to
add himself to everybody's friend-list but didn't involve exploiting
the login system or XSS vulnerabilities (which wouldn't be applicable
here) or turned out to be cases of social engineering.
Of course, those are the ones which get the news. You don't hear about
Mom's Homemade Cookie Shop's website getting broken into. It just isn't
news.
>>Anyway, just curious.
Tom
The question here is - why do you want to encrypt the password? Is
there any reason you need it encrypted? What's on there that someone
would want?
And in that case you probably should be using SSL.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
---
>The question here is - why do you want to encrypt the password? Is
there any reason you need it encrypted? What's on there that someone
would want?
A couple reasons:
(1) This is being developed as part of a framework that I plan to
reuse on many of my projects. The goal is to incorporate this
enhancement more or less transparently. So if it offers even only
marginally better security, I figure it's worth the trouble.
(2) As a learning exercise.
Plus, I guess I'm just nervous by nature. :)
Tom
Tom,
The point being - in some ways it's worse than having no protection at
all. It provides a false sense of security.
Similar to locking your door and then leaving the key under the door
mat. It gives you a good feeling that you locked your door, but any
smart thief (and even a few dumb ones) will look there first. It really
doesn't give much more protection than leaving your door wide open.
OTOH, SSL is secure and requires no programming on your part to implement.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
If these posts get any longer we'll need to move to alt.binaries.php!
On 2 Oct, 11:33, Jerry Stuckle <jstuck...@attglobal.netwrote:
klenwell wrote:
On Oct 1, 6:38 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
klenwell wrote:
On Oct 1, 2:40 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.comwrote:
On 1 Oct, 06:04, klenwell <klenw...@gmail.comwrote:
On Sep 30, 9:08 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
klenwell wrote:
<snip>
>>>>>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.
Not if you're careful with the session salt - its unique to the
session (done properly, unique to the request) therefore eliminates
the possiblity of replay attacks.
<snip>
>Thanks for the detailed response, C. The user-specific hash is a good
idea. How do you execute the two stages? Does the user make two
submissions? Some kind of AJAX implementation?
Either would be valid (originally used 2 stage, then an iframe).
Packet sniffing can be done anywhere between the client and the server.
However, since every packet can theoretically take a different route,
the most common sniffers are at the ends of the link.
I think you'd be surprised how easy it is to compromise systems with
ICMP redirection.
<snip>
The question here is - why do you want to encrypt the password? Is
there any reason you need it encrypted? What's on there that someone
would want?
A couple reasons:
<snip>
The point being - in some ways it's worse than having no protection at
all. It provides a false sense of security.
Similar to locking your door and then leaving the key under the door
mat. It gives you a good feeling that you locked your door, but any
smart thief (and even a few dumb ones) will look there first. It really
doesn't give much more protection than leaving your door wide open.
OTOH, SSL is secure and requires no programming on your part to implement.
One very good reason which klenwell didn't mention is this: that the
password itself may have more intrinsic value than the website and its
capabilities. I use different passwords for the services I use and
keep them all in an encrypted container - most users don't. There are
people out there using the same password for hotpr0n.example.com as
ultrasafe.securebanking.com
Sure having a totally secure logon does not solve problems in the rest
of the interaction (CSRF, XSS, Session Hijack....) but to say it has
no value is at best disparaging.
Similarly to say that non high-profile sites are not the subject of
the black hats intentions is also fundamentally misleading. Only high
profile sites have the resources to investigate or even detect
incursions, and of these, only a very small subset actually publish
information about attacks.
Regarding SSL - it is conceptually secure, but it is a very complex
system and implementations vary in quality. I've been lucky and only
been rootkitted once - guess how they got in?
C.
C. ( http://symcbean.blogspot.com/) wrote:
If these posts get any longer we'll need to move to alt.binaries.php!
On 2 Oct, 11:33, Jerry Stuckle <jstuck...@attglobal.netwrote:
>klenwell wrote:
>>On Oct 1, 6:38 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
klenwell wrote:
On Oct 1, 2:40 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.comwrote:
>On 1 Oct, 06:04, klenwell <klenw...@gmail.comwrote:
>>On Sep 30, 9:08 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>>>klenwell wrote:
<snip>
>>>>>>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.
Not if you're careful with the session salt - its unique to the
session (done properly, unique to the request) therefore eliminates
the possiblity of replay attacks.
That's true if it's a one-way encryption and the salt is changed every time.
<snip>
>>>>Thanks for the detailed response, C. The user-specific hash is a good
idea. How do you execute the two stages? Does the user make two
submissions? Some kind of AJAX implementation?
Either would be valid (originally used 2 stage, then an iframe).
>>>Packet sniffing can be done anywhere between the client and the server.
However, since every packet can theoretically take a different route,
the most common sniffers are at the ends of the link.
I think you'd be surprised how easy it is to compromise systems with
ICMP redirection.
True, but to get the redirection you still need to be on a router in the
path between the client and the server. And the farther you get from
both ends, the less likely that would be.
<snip>
>>>The question here is - why do you want to encrypt the password? Is
there any reason you need it encrypted? What's on there that someone
would want?
A couple reasons:
<snip>
>The point being - in some ways it's worse than having no protection at
all. It provides a false sense of security.
Similar to locking your door and then leaving the key under the door
mat. It gives you a good feeling that you locked your door, but any
smart thief (and even a few dumb ones) will look there first. It really
doesn't give much more protection than leaving your door wide open.
OTOH, SSL is secure and requires no programming on your part to implement.
One very good reason which klenwell didn't mention is this: that the
password itself may have more intrinsic value than the website and its
capabilities. I use different passwords for the services I use and
keep them all in an encrypted container - most users don't. There are
people out there using the same password for hotpr0n.example.com as
ultrasafe.securebanking.com
Sure, I use different passwords for different things, also. But if
someone uses the same password for multiple sites, he shouldn't be
surprised if it gets broken.
Sure having a totally secure logon does not solve problems in the rest
of the interaction (CSRF, XSS, Session Hijack....) but to say it has
no value is at best disparaging.
Not at all. It's worse than no value. It creates false security.
Similarly to say that non high-profile sites are not the subject of
the black hats intentions is also fundamentally misleading. Only high
profile sites have the resources to investigate or even detect
incursions, and of these, only a very small subset actually publish
information about attacks.
I never said they weren't the subject of attacks. Read again. I said
they don't get in the news.
Regarding SSL - it is conceptually secure, but it is a very complex
system and implementations vary in quality. I've been lucky and only
been rootkitted once - guess how they got in?
C.
Properly implemented, SSL is secure. Don't blame it for your lack of
normal diligence.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
On Oct 2, 5:53 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.comwrote:
If these posts get any longer we'll need to move to alt.binaries.php!
On 2 Oct, 11:33, Jerry Stuckle <jstuck...@attglobal.netwrote:
klenwell wrote:
On Oct 1, 6:38 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>klenwell wrote:
>>On Oct 1, 2:40 am, "C. (http://symcbean.blogspot.com/)"
>><colin.mckin...@gmail.comwrote:
>>>On 1 Oct, 06:04, klenwell <klenw...@gmail.comwrote:
>>>>On Sep 30, 9:08 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>>>>>klenwell wrote:
<snip>
>>>>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.
Not if you're careful with the session salt - its unique to the
session (done properly, unique to the request) therefore eliminates
the possiblity of replay attacks.
<snip>
>>Thanks for the detailed response, C. The user-specific hash is a good
>>idea. How do you execute the two stages? Does the user make two
>>submissions? Some kind of AJAX implementation?
Either would be valid (originally used 2 stage, then an iframe).
>Packet sniffing can be done anywhere between the client and the server.
> However, since every packet can theoretically take a different route,
>the most common sniffers are at the ends of the link.
I think you'd be surprised how easy it is to compromise systems with
ICMP redirection.
<snip>The question here is - why do you want to encrypt the password? Is
>there any reason you need it encrypted? What's on there that someone
>would want?
A couple reasons:
<snip>
The point being - in some ways it's worse than having no protection at
all. It provides a false sense of security.
Similar to locking your door and then leaving the key under the door
mat. It gives you a good feeling that you locked your door, but any
smart thief (and even a few dumb ones) will look there first. It really
doesn't give much more protection than leaving your door wide open.
OTOH, SSL is secure and requires no programming on your part to implement.
One very good reason which klenwell didn't mention is this: that the
password itself may have more intrinsic value than the website and its
capabilities. I use different passwords for the services I use and
keep them all in an encrypted container - most users don't. There are
people out there using the same password for hotpr0n.example.com as
ultrasafe.securebanking.com
Sure having a totally secure logon does not solve problems in the rest
of the interaction (CSRF, XSS, Session Hijack....) but to say it has
no value is at best disparaging.
Similarly to say that non high-profile sites are not the subject of
the black hats intentions is also fundamentally misleading. Only high
profile sites have the resources to investigate or even detect
incursions, and of these, only a very small subset actually publish
information about attacks.
Regarding SSL - it is conceptually secure, but it is a very complex
system and implementations vary in quality. I've been lucky and only
been rootkitted once - guess how they got in?
C.
C.,
Do you mind outlining the iframe method you use?
Thanks,
Tom
On 2 Oct, 17:01, klenwell <klenw...@gmail.comwrote:
On Oct 2, 5:53 am, "C. (http://symcbean.blogspot.com/)"
<snip>
>
C.
C.,
Do you mind outlining the iframe method you use?
Thanks,
Tom
Page has form with input fields for username and password, a button
and and a hidden iframe (uninitialized).
User fills in username and password, clicks a button. Button calls
javascript to set the location of the iframe passing username as a GET
parameter. This location is a PHP script which generates a javascript
which is sent to back to the browser, with $s_u and $s_s. Javascript
retieves current password value from outer window and hashes it, then
puts the value back into the password field and submits the form.
C.
C. ( http://symcbean.blogspot.com/) wrote:
On 2 Oct, 17:01, klenwell <klenw...@gmail.comwrote:
>On Oct 2, 5:53 am, "C. (http://symcbean.blogspot.com/)"
<snip>
>>C.
C.,
Do you mind outlining the iframe method you use?
Thanks,
Tom
Page has form with input fields for username and password, a button
and and a hidden iframe (uninitialized).
User fills in username and password, clicks a button. Button calls
javascript to set the location of the iframe passing username as a GET
parameter. This location is a PHP script which generates a javascript
which is sent to back to the browser, with $s_u and $s_s. Javascript
retieves current password value from outer window and hashes it, then
puts the value back into the password field and submits the form.
C.
How much more complicated do you want this? Never mind that it won't
work for those with javascript disabled.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
On Oct 4, 5:07 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
C. (http://symcbean.blogspot.com/) wrote:
On 2 Oct, 17:01, klenwell <klenw...@gmail.comwrote:
On Oct 2, 5:53 am, "C. (http://symcbean.blogspot.com/)"
<snip>
>C.
C.,
Do you mind outlining the iframe method you use?
Thanks,
Tom
Page has form with input fields for username and password, a button
and and a hidden iframe (uninitialized).
User fills in username and password, clicks a button. Button calls
javascript to set the location of the iframe passing username as a GET
parameter. This location is a PHP script which generates a javascript
which is sent to back to the browser, with $s_u and $s_s. Javascript
retieves current password value from outer window and hashes it, then
puts the value back into the password field and submits the form.
C.
How much more complicated do you want this? Never mind that it won't
work for those with javascript disabled.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
Ha. I don't know. Doesn't sound absurdly complicated. I think it's
pretty ingenious myself. And we're in the age of mechanical
reproduction, so if you can proof it out once, after that it shouldn't
be much more complicated than using a regular form.
Javascript point is true, but you can inform those that don't have it
enabled of your intentions.
Thanks, C. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Chris |
last post by:
Hello all.
I'm currently working on a new site that encompasses the registration
of members. The registration is taking place through PHP interaction
with MySQL. The site is just going to be...
|
by: Ian Hickson |
last post by:
A group of us have been unofficially working on a proposal of extensions
to HTML4's Forms chapter, and would like to get input from a wider range
of people now that we think our draft proposal is...
|
by: Harry Simpson |
last post by:
Is there a way in .Net to encrypt a user id and password that comes as an
HTML request from a login page without having to use a third party solution?
In other words, when the user enters the user...
|
by: Leon |
last post by:
How can I encrypted data sent across my website from web forms without using
SSL?
Such as on Login the user enter "EmailAddress" & "Password" and Simply
Registration Form
in which the user...
|
by: fiona |
last post by:
Innovasys Ltd., a leader in help authoring and documentation tools,
today announced the inclusion of a tailored version of the Innovasys
HelpStudio help authoring product, HelpStudio Lite, in the...
|
by: Steven Cliff |
last post by:
I have started to use the new Enterprise Library (Jan 06) and have set up a
skeleton project using the DAAB. This all seems to work fine apart from when
I come to secure the app.config file via...
|
by: AppleBag |
last post by:
I'm having the worst time trying to login to myspace through code. Can
someone tell me how to do this? Please try it yourself before replying,
only because I have asked this a couple of times in...
|
by: eggie5 |
last post by:
I have a form where a user can change his password, but I'm confused
on how to prevent this from being transmitted in plain text.
Well, I know how not to transmit it in plain text - use any type...
|
by: cbeels |
last post by:
The client code is
#install SOAP-Lite and MIME-tools packages
use SOAP::Lite 'trace', 'debug';
#override version
SOAP::Lite->soapversion('1.2');
#override credentials
sub...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
