Re: New Input type proposal

On 2008-01-09, Alexander Mueller <noemail (AT) example (DOT) org> wrote:

Unfortunately Disco Octopus' posting isnt listed on my newsserver, so I
have to reply to myself .....

Disco Octopus wrote:

A few years ago we had implemented a similar concept using javascript
and hashing of the password pre posting.

As others have mentioned, it did not prevent hackers from obtaining
the hashed value, which of course was the same value as to be
retrieved on the server.

Perhaps naivety led us to feel that if the hacker did not know exactly
what was entered into the form (pre hash), then this was at least some
form of security.

Of course, attackers can obtain the hashed value, but this is a simple
replay attack and not the primary target of the hashing idea itself.
Here the replay salt comes into play.

I still don't understand the point of the hash.

Never mind the replay salt for now-- what's the basic point of the hash?
I have re-read your original post, and I still don't understand it.

The problem I have is the same as others have described: the hash is
presumably sent to the server in a query string or other kind of
formdata?

That data, which is sent in plaintext, is just as good as a password: it
gets me in. I might as well steal that. Never mind the password. I will
be able to access the site, just not by typing asterisks into the proper
form but by typing characters into the browser's location bar instead.
So what.

In comparison, the hash does not log you into a UNIX machine. You have
to type the actual password. There is supposed to be no way to get in
with just a hash. Therefore if you store hashes in the passwd file
instead of passwords it's less of a problem if the passwd file is
compromised.

But we can do just the same thing if the password comes as formdata
rather than as keyboard input. We can hash it when it gets there and
only store hashes (in fact this is just what the htpasswd program does).
No need or point or harm in hashing it on the client, but therefore no
need for <input type="hash"> that I can see.

What am I missing?

As for replay salt, why can't I just require along with the password
another special number obtained from the server earlier in the session?
Why is it necessary to munge these two numbers together into a single
hash?

On 2008-01-10, Alexander Mueller <noemail (AT) example (DOT) org> wrote:

Ben C wrote:

The problem I have is the same as others have described: the hash is
presumably sent to the server in a query string or other kind of
formdata?

Exactly, this is something you cannot prevent.


That data, which is sent in plaintext, is just as good as a password: it
gets me in. I might as well steal that. Never mind the password. I will
be able to access the site, just not by typing asterisks into the proper
form but by typing characters into the browser's location bar instead.
So what.

Thats a good point and I am glad you brought it up as this is what I
wanted, a discussion about possibly redundancies, flaws or potential
problems.

You are right that the hashing itself does not solve the replay problem
(thats what the replay salt should solve), however this is not its
primary task. The idea behind the hashing is rather not to let the
password leave the client right from the beginning but instead to
"encrypt" the password on its way to the server (particularly over
non-SSL connections) as well as to "hide" it also from the actual
destination.

All you're protecting is the identities of people's pets. There is
however some value in this as some users may use the same password for
lots of websites.

In comparison, the hash does not log you into a UNIX machine. You have
to type the actual password. There is supposed to be no way to get in
with just a hash. Therefore if you store hashes in the passwd file
instead of passwords it's less of a problem if the passwd file is
compromised.

Again, the hash is primarily to keep the password itself secret. On Unix
an Administrator can reveal the password just as easily.

Can he? I thought root could change anyone's password to something else
and log in to their account, but he can't see their actual password. The
actual password is not stored anywhere, so no-one can reveal it.

As for replay salt, why can't I just require along with the password
another special number obtained from the server earlier in the session?
Why is it necessary to munge these two numbers together into a single
hash?

If you dont do the munging you still have a replay problem. An attacker
simply takes the password along with the "special number" from his session.

Well you make each special number one-time use only. You use it once and
then get given another one, which you can also use only once.
Fortunately there are plenty of numbers.

If the number is not use-once then munging it with the password doesn't
help. The replay-attacker just needs to capture the munged
password+number.

On 2008-01-10, Alexander Mueller <noemail (AT) example (DOT) org> wrote:

Ben C wrote:

All you're protecting is the identities of people's pets. There is
however some value in this as some users may use the same password for
lots of websites.

Well, I wouldnt really call a password a pet,

I was referring to the common practice of using one pet's name as a
password.

but thats the point, the password itself should never have to leave
the client in its plain text.

Some point in that yes, but really users shouldn't use the same password
for different sites, or at least, should use one password for
low-security unimportant sites and a different one for bank accounts.

Can he? I thought root could change anyone's password to something else
and log in to their account, but he can't see their actual password. The
actual password is not stored anywhere, so no-one can reveal it.

Out-of-the-box usually not, however it is not too difficult to implement
a code-injection into the particular libraries to get the password.

Well there are all sorts of ways to get the password. The easiest is
usually just to read it from the post-it note stuck to the computer.

In principle, assuming no malfeasance, the administrator cannot reveal
the password.

Well you make each special number one-time use only. You use it once and
then get given another one, which you can also use only once.
Fortunately there are plenty of numbers.

If the number is not use-once then munging it with the password doesn't
help. The replay-attacker just needs to capture the munged
password+number.

Yes, but an attacker would get his very own special number as well, so
if the values arent "munged", he would only need to supply his number
along with the password and there you go.

How does munging alter that situation? If he can replay the first access
(by getting hold of the hash used) then won't he just get his very own
replaysalt in just the same way?

Can you describe an example, step-by-step, of a session in which the
replaysalt provides some benefit that one-time session numbers don't?

On 2008-01-10, Alexander Mueller <noemail (AT) example (DOT) org> wrote:

Ben C wrote:
[...]
How does munging alter that situation? If he can replay the first access
(by getting hold of the hash used) then won't he just get his very own
replaysalt in just the same way?

Can you describe an example, step-by-step, of a session in which the
replaysalt provides some benefit that one-time session numbers don't?

1.) The user requests a site.
2.) The server sends the login form, issues a random replay salt and
stores it in a session.
3.) The user enters the necessary information.
4.) The browser hashes the entered password and hashes the result once
more with the replay salt.
5.) The server hashes the stored hash with the previously issued replay
salt and compares the result to the given value.

So why wouldn't this work just as well:

1. The user requests a site.
2. The server sends the login form, which also contains a hidden input
whose value is a number picked out of a hat, which we call x.
3. The user enters the necessary information and submits the form.
4. The browser receives in the formdata at least two items: the password
and a number. It checks the user's password (by hashing it and
looking for it in a list of stored hashes, for the sake of argument)
and also that the number is equal to x. If either check fails it
refuses to go any further. Either way it makes a note never to accept
x again.

On Jan 11, 3:13 am, Alexander Mueller <noem... (AT) example (DOT) org> wrote:

Ben C wrote:

I was referring to the common practice of using one pet's name as a
password.

Sorry, didnt notice the pun .



Some point in that yes, but really users shouldn't use the same password
for different sites, or at least, should use one password for
low-security unimportant sites and a different one for bank accounts.

I agree, but thats another point and they usually use the same password
for different sites.



How does munging alter that situation? If he can replay the first access
(by getting hold of the hash used) then won't he just get his very own
replaysalt in just the same way?

Can you describe an example, step-by-step, of a session in which the
replaysalt provides some benefit that one-time session numbers don't?

1.) The user requests a site.
2.) The server sends the login form, issues a random replay salt and
stores it in a session.
3.) The user enters the necessary information.
4.) The browser hashes the entered password and hashes the result once
more with the replay salt.
5.) The server hashes the stored hash with the previously issued replay
salt and compares the result to the given value.

Alexander

Hi Alexander,

For clarity of my own mind, I have painted it out in colour. Could
you confirm that this is the idea...


Assuming a clear password is stored in a database/file on the server
with the username as the key to the password table.
eg...
UserName Password
ralphmalph fido
discooctopus secret
bill momoney

1. Web client requests a login page.
2. Server creates a session with a session id
3. Server creates a salt value (available for this session only) (eg.
"D8SD67586DF987FD")
4. Server creates the login page with the value as such....
<input type="hash" hash="md5" salt="D8SD67586DF987FD"
replaysalt="" />
... and serves the web page
5. Web user enters his login details as username of "discooctopus"
with a password of "secret"
6. Web browser encrypts the password using md5 with the salt
"D8SD67586DF987FD"
7. Web browser posts the login details (user name and hashed password
only (not the salt)) to the server.
8. The server then does this...
i. lookup the given user 'discooctpus' from the database. The
result is the password of 'secret'
ii. this value of 'secret' is encrypted using md5 with the salt
"D8SD67586DF987FD"
iii. Check to see if the encryptes value is the same as the hash
value posted from the web client.



Does this capture your idea simply?

On 2008-01-10, Alexander Mueller <noemail (AT) example (DOT) org> wrote:

Ben C wrote:

So why wouldn't this work just as well:

1. The user requests a site.
2. The server sends the login form, which also contains a hidden input
whose value is a number picked out of a hat, which we call x.
3. The user enters the necessary information and submits the form.
4. The browser receives in the formdata at least two items: the password
and a number. It checks the user's password (by hashing it and
looking for it in a list of stored hashes, for the sake of argument)
and also that the number is equal to x. If either check fails it
refuses to go any further. Either way it makes a note never to accept
x again.

An attacker would have determined both values, discarded the number,
send his own request which gets him his own number and sends the
password along with his number. There he goes.

I see. I think you're right, that is better. This way no replay attack
will work: no part of the code that gets you in (hash of
password+replaysalt) is ever the same twice.

This could be done in JS already (I wonder if anyone does that?) but it
would be more convenient and become more widely used if it was built
into the <input> element as you're suggesting.