New Input type proposal

[Ben C]

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



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?

 

[Alexander Mueller]

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.

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.

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.

Alexander

 

[Ben C]

Exactly, this is something you cannot prevent.


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.

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.

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.

 

[Alexander Mueller]

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, but thats the point, the
password itself should never have to leave the client in its plain text.

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 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.

Alexander

 

[Ben C]

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.

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.

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?

 

[Alexander Mueller]

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

 

[Ben C]

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.

 

[Alexander Mueller]

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.

Alexander

 

[Disco Octopus]

Sorry, didnt notice the pun .




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





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?

 

[Harlan Messinger]

Correct, but the Administrator always has access to the application
under any user account, if he wants. The point is, he does not have
access to the actual password (nor does anyone using a sniffer).


Sorry, but thats not exactly the point. For the application it wouldnt
matter if it has to compare the hash of a given password with a stored
hash or simply the given plain text password with a stored plain text
password.

Right, that's what I already said (see below): both would be equally
weak situations. It's for that reason that a truly secure application
*stores* the *hash* but *expects* the *password*. Your proposal is
compatible only with an application that has this other security hole.

 

[Alexander Mueller]

Does this capture your idea simply?

Yes, almost, there are some slight differences but I guess it would work
this way probably as well.

The passwords are stored hashed in the database. If they were hashed
using a salt, the salt always needs to be passed in the "salt"
attribute. Additionally, a random session based replay salt can be
defined to prevent replay attacks.

The rest is more or less as you stated. If you use Firefox 2, please
feel free to install Hash Input to see how it works.

Alexander

 

[Alexander Mueller]

Right, that's what I already said (see below): both would be equally
weak situations. It's for that reason that a truly secure application
*stores* the *hash* but *expects* the *password*. Your proposal is
compatible only with an application that has this other security hole.

Sorry, but what should be weak about this? You havent backed your
statement with nothing. Please state facts and not only rumors.

 

[Alexander Mueller]

Sorry, but what should be weak about this? You havent backed your
statement with nothing. Please state facts and not only rumors.

In case you were referring to the potential problem that the password
database is being attacked, then yes, this is admittedly a weak point by
design and shared with the well known Digest Authentication. If you have
a suggestion or idea on how to solve it it would be most welcome however.

Except for this one point however, it still keeps the password itself
secret and prevents replay attacks as well.

Alexander

 

[Harlan Messinger]

Sorry, but what should be weak about this? You havent backed your
statement with nothing. Please state facts and not only rumors.

I explained it already. Sorry if it went by you.

 

[Ben C]

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.

 

[Andy Dingley]

the reason behind my email is the proposal of a new Input type named "hash"
<input type="hash" />

This is an excellent idea for web design, and a bad idea for HTML.

Your idea has merit overall. However it's also simple to implement it
by well-established client-side scripting techniques, such as
JavaScript and the DOM. There is thus no need to add it to HTML. Maybe
XForms should consider it. This will work for anyone with a credible
browser platform (i.e. reasonably modern) who has JS enabled. That's
enough people and excludes sufficiently few JS-avoiders that it
doesn't justify a major addition to a long-established standard, such
as the list of HTML input types.

 

[Alexander Mueller]

I explained it already. Sorry if it went by you.

Please see my second reply from 1:52.

 

[Alexander Mueller]

A little addition has been made to the proposal in order to provide a
password policy check without actually exposing the password.

Please see the regular expression paragraph at the website.

Alexander

 

[Neredbojias]

Well bust mah britches and call me cheeky, on Wed, 23 Jan 2008 14:03:06 GMT
Alexander Mueller scribed:

A little addition has been made to the proposal in order to provide a
password policy check without actually exposing the password.

Proposal? Oh, this is so sudden...

Please see the regular expression paragraph at the website.

Coitainly. But I don't do kink in any case.

 

[Travis Newbury]

Coitainly. But I don't do kink in any case.

right.....