New Input type proposal

Hi,

the reason behind my email is the proposal of a new Input type named "hash"



I am now going into detail about why I'd consider it as important and
technical information as well as comparisons to current techniques.


What should it do and be?
-------------------------
Visually it can be identical to the known "password" type (a textbox
masking its characters). The major difference would be its technical
implementation respectively its output/result to the server.


What would be those differences?
--------------------------------
An input field of the type "password" transmits its content, just as any
other regular textbox, unencrypted to the server.

An input field of the type "hash" should hash the given text and
transmit only the hash to the server.


What would be the advantages?
-----------------------------
As mentioned, a password field only masks its text (so that it cannot be
read by bystanders) but does not actually encrypt or hash it, in order
to provide a secure transmission.

This does not only mean that the given text is transmitted in plain text
over the network (unless SSL is used) but also that the owner or
administrator of the destination server can always reveal the actual
password. Further it is making replay attacks possible or at least much
more simple.


What would be the exact technical implementation?
-------------------------------------------------
A hash input field would be defined similarly to a password field via



- The first attribute (type) would indicate that a hash field should be
displayed.

- The second attribute (hash) would indicate the hash algorithm to be
used (md5 in this example or also sha1 or any other available on the
client).

- The third attribute (salt) would be an optional (but recommended) one,
which should provide the result with the typical "hash salt" (to prevent
precalculated tables). A site using a salt would always need to indicate
the same salt, in order to get the same result.

- The fourth attribute (replaysalt) would be an optional attribute as
well, very similar to the third. However in this case the salt should be
randomly calculated on each request and stored on the server side (via
sessions for example). It is applied to the hash result of the content
and the general salt. Its primary use is to prevent replay attacks.

Note: The replay salt should only be used on read or verification
processes (like a logon) as otherwise (upon setting the password for
example) the server would never be able to determine the original or raw
hashcode.


Why a hash field if SSL already provides secure transmissions?
------------------------------------------------------------ --
It is correct, that HTTPS provides a secure way between the client and
the server. However HTTPS does not prevent that the Administrator of the
destination server is acquiring the actual plain text data. A hash input
field would do this. Additionally it provides a semi-encryption as well
as replay protection to non-SSL connections.


Are there any open technical or security issues?
------------------------------------------------
I am only aware of one, the way how client side access (via JavaScript
for example) to a hash field is handled. While write access should
probably always set the passed value, read access is a bit more
difficult. Should the returned value be the computed hash or the actual
value? Although I tend to the former, this should still be discussed.
Related to this would be whether key event handlers should be called or
not (they could be used to reveal the entered text).

Should there be other concerns, I'd really welcome opinions.




Concept Implementation
----------------------
I have developed a first very basic extension for Firefox 2. The
functionality as mentioned here is already implemented, however it does
not introduce a "hash" type but rather extends the "password" type (by
applying a hash to all password fields with a given hash attribute).

You can find "Hash Input" at http://www.alcomp.net/hashinput


Please let me know any comments or suggestions you have.

Thank you,
Alexander Mueller

Re: New Input type proposal

Alexander Mueller wrote:
> Hi,
>
> the reason behind my email is the proposal of a new Input type named "hash"
>
>
>
> I am now going into detail about why I'd consider it as important and
> technical information as well as comparisons to current techniques.

I can't see any extra advantage of your input has, more than it will just
consume more bandwidth for transporting the data. The has type will always be
the same for a site, as the passwords will always be stored in that type, a
site that uses md5 hashed passwords will never request a sh1 hashed password,
as then they can't validate the password is correct.

The method will be predictable and complicated to use and just gives a false
feel of extra security.

--

//Aho

Re: New Input type proposal

J.O. Aho wrote:
>
> I can't see any extra advantage of your input has, more than it will just
> consume more bandwidth for transporting the data.

Well, I listed the advantages in the original posting. Please reread it
again to see what I am trying to accomplish with the hash type.


> The has type will always be
> the same for a site, as the passwords will always be stored in that type, a
> site that uses md5 hashed passwords will never request a sh1 hashed password,
> as then they can't validate the password is correct.

I never talked about a mixture of hash types.

It is about the secure transmission. The hash for a password will never
be the same for a site but only for identical passwords (which is a
required behaviour).

>
> The method will be predictable and complicated to use and just gives a false
> feel of extra security.
>

Can you explain why? The only difference is that the hashing occurs
locally and so gives a much better security to the actual data. Its
neither more predictable nor complicated than the current solution.


Alexander

Re: New Input type proposal

Post removed (X-No-Archive: yes)

Re: New Input type proposal

J.O. Aho wrote:
>
> I can't see any extra advantage of your input has, more than it will just
> consume more bandwidth for transporting the data.

As to the traffic, yes, it will generate more traffic as long as the
actual password is shorter than the hash (32 bytes for MD5, 40 bytes for
SHA1). But considering only a 5 byte long password I would say the extra
traffic of 27-35 bytes is worth the added security (some HTTP headers
often take more).

Alexander

Re: New Input type proposal

richard wrote:
>
> You have posted this "email" to a usenet newsgroup which is not
> maintained, or staffed by any one particular company or organization.

The "email" happened because I took the text straight from a copy which
was sent to w3.org.

>
> You would need to impose your request on the creators of each
> individual browser. IE, FF, opera, pan, slrn, xnews,xananews and so
> on. Along with maybe trying to convince the w3c.org people to make it
> a viable include.

I did, see above ;)

>
> Then after a few years, it might get developed. However, no guarantees
> that it will.

Well, for Firefox there is already a concept implementation :).

Alexander

Re: New Input type proposal

Alexander Mueller wrote:
> J.O. Aho wrote:

>> The has type will always be
>> the same for a site, as the passwords will always be stored in that
>> type, a
>> site that uses md5 hashed passwords will never request a sh1 hashed
>> password,
>> as then they can't validate the password is correct.
>
> I never talked about a mixture of hash types.
>
> It is about the secure transmission. The hash for a password will never
> be the same for a site but only for identical passwords (which is a
> required behaviour).

As you mentioned your system would prevent the administrator from knowing your
password, then the password has to be hashed already at the site, and
therefore the hashing has to be the the same in the form as on the site, or
else you would always fail the login or the site has to spend long time with
cracktools to be able to find out the password and then has it the way it's
hashed on the site.


--

//Aho

Re: New Input type proposal

J.O. Aho wrote:
>
> As you mentioned your system would prevent the administrator from knowing your
> password, then the password has to be hashed already at the site, and
> therefore the hashing has to be the the same in the form as on the site, or
> else you would always fail the login or the site has to spend long time with
> cracktools to be able to find out the password and then has it the way it's
> hashed on the site.

Sorry I dont really know what you are exactly meaning.

Again, please reread my initial posting, I guess everything should be
clear then :). The system wouldnt know the plain text password (which it
doesnt need) but only the hash code. This can then be compared to the
stored hash code. The only difference is the computation of the hash
happens locally - no brute force, no same passwords.

Alexander

Re: New Input type proposal

Alexander Mueller wrote:
> J.O. Aho wrote:
>>
>> As you mentioned your system would prevent the administrator from
>> knowing your
>> password, then the password has to be hashed already at the site, and
>> therefore the hashing has to be the the same in the form as on the
>> site, or
>> else you would always fail the login or the site has to spend long
>> time with
>> cracktools to be able to find out the password and then has it the way
>> it's
>> hashed on the site.
>
> Sorry I dont really know what you are exactly meaning.

I think he's talking about the salt. Do you pass the salt with the
form submit, if you do, what is the security advantage?

All this looks a bit like unix password encryption where no one knows
the password, only if it is wrong. What would the application be?

Jeff
>
> Again, please reread my initial posting, I guess everything should be
> clear then :). The system wouldnt know the plain text password (which it
> doesnt need) but only the hash code. This can then be compared to the
> stored hash code. The only difference is the computation of the hash
> happens locally - no brute force, no same passwords.
>
> Alexander

Re: New Input type proposal

Jeff wrote:
>
> I think he's talking about the salt. Do you pass the salt with the form
> submit, if you do, what is the security advantage?

A salt is always used to have a hash which is different from the regular
hash (to prevent precomputed hash tables). In case of salt, it certainly
always have to be the same.

As to the replay salt, this would only be used to prevent replay attacks
and would or better should always be differently. Of course it wouldnt
be used to store the password hash.

>
> All this looks a bit like unix password encryption where no one knows
> the password, only if it is wrong. What would the application be?

Well, yes, hashes are used in Unix too, but it is a general solution and
most websites use a hash to store passwords with the exception that the
server is generating the hash.

Alexander

Re: New Input type proposal

J.O. Aho wrote:
> Alexander Mueller wrote:
>> Hi,
>>
>> the reason behind my email is the proposal of a new Input type named "hash"
>>
>>
>>
>> I am now going into detail about why I'd consider it as important and
>> technical information as well as comparisons to current techniques.
>
> I can't see any extra advantage of your input has, more than it will just
> consume more bandwidth for transporting the data. The has type will always be
> the same for a site,

The attribute tells the *browser* what kind of hash to create.

> as the passwords will always be stored in that type, a
> site that uses md5 hashed passwords will never request a sh1 hashed password,
> as then they can't validate the password is correct.

The browser doesn't have pre-existing knowledge that such-and-such site
uses MD5 hashed passwords (though a default hash method could be defined
in the standard, just as there is a default value for the enctype
attribute of the form tag).

Re: New Input type proposal

Alexander Mueller wrote:
> J.O. Aho wrote:
>>
>> As you mentioned your system would prevent the administrator from
>> knowing your
>> password, then the password has to be hashed already at the site, and
>> therefore the hashing has to be the the same in the form as on the
>> site, or
>> else you would always fail the login or the site has to spend long
>> time with
>> cracktools to be able to find out the password and then has it the way
>> it's
>> hashed on the site.
>
> Sorry I dont really know what you are exactly meaning.
>
> Again, please reread my initial posting, I guess everything should be
> clear then :). The system wouldnt know the plain text password (which it
> doesnt need) but only the hash code.

OK, so the password has been left out of the server side entirely.
Instead, to access the application you need the hash value, and the
server administrator has access to *that*. So just substitute the word
"password" for the word "hash" and the server administrator is now able
to intercept the value of the hash that will give him access to the
application.

The point of an application storing a hash instead of the original
password is that it only accepts the password for authentication,
computing its hash when the it's provided and comparing it with the hash
it has in its user lookup table. If someone hacks the user table and
finds the hashes, it won't do the hacker any good because the
application doesn't provide any interface for accessing the system by
providing the hash directly. If the hacker submits the hash as though
it were the password, the application will hash the hash, and the
computed rehash won't match the stored hash. The application has to see
the password itself before it will grant access.

Re: New Input type proposal

Harlan Messinger wrote:
>
> OK, so the password has been left out of the server side entirely.
> Instead, to access the application you need the hash value, and the
> server administrator has access to *that*. So just substitute the word
> "password" for the word "hash" and the server administrator is now able
> to intercept the value of the hash that will give him access to the
> application.

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

>
> The point of an application storing a hash instead of the original
> password is that it only accepts the password for authentication,
> computing its hash when the it's provided and comparing it with the hash
> it has in its user lookup table.

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.

The point is to add security against attackers - as you mentioned - as
well as, partly, against the Administrator, so that he cannot simply
reveal the user password, which is currently possible however.

> If someone hacks the user table and
> finds the hashes, it won't do the hacker any good because the
> application doesn't provide any interface for accessing the system by
> providing the hash directly.

Correct.

> If the hacker submits the hash as though it
> were the password, the application will hash the hash, and the computed
> rehash won't match the stored hash. The application has to see the
> password itself before it will grant access.

Thats correct, but this is the typical system as it is now. How does it
apply to the mentioned solution here?

Alexander

Re: New Input type proposal

Alexander Mueller wrote:
> Harlan Messinger wrote:
>>
>> OK, so the password has been left out of the server side entirely.
>> Instead, to access the application you need the hash value, and the
>> server administrator has access to *that*. So just substitute the word
>> "password" for the word "hash" and the server administrator is now
>> able to intercept the value of the hash that will give him access to
>> the application.
>
> 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).

But since the hash, not the password, is what gets access to the
application, how is this helpful? Having the value of a string called a
"password" is not an end in itself. The point is that the administrator
has the data he needs to get into the application. And if you're talking
about a situation where the administrator has access to the application
itself (this isn't a given, but you've just added it to the scenario),
then why does it matter at all whether the administrator can see the
password or the hash or anything else?

>> The point of an application storing a hash instead of the original
>> password is that it only accepts the password for authentication,
>> computing its hash when the it's provided and comparing it with the
>> hash it has in its user lookup table.
>
> 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.
>
> The point is to add security against attackers - as you mentioned

You mentioned addressing this with SSL. Your rationale for your approach
was to shield the password from the administrator as well.

> - as
> well as, partly, against the Administrator, so that he cannot simply
> reveal the user password, which is currently possible however.

OK, this is the first time you've mentioned the issue of the
administrator giving it to someone *else* instead of just knowing it
himself.

>
>> If someone hacks the user table and finds the hashes, it won't do the
>> hacker any good because the application doesn't provide any interface
>> for accessing the system by providing the hash directly.
>
> Correct.
>
>> If the hacker submits the hash as though it were the password, the
>> application will hash the hash, and the computed rehash won't match
>> the stored hash. The application has to see the
>> password itself before it will grant access.
>
> Thats correct, but this is the typical system as it is now. How does it
> apply to the mentioned solution here?

It applies by virtue of the fact that you haven't put the administrator
at any kind of disadvantage in terms of gaining access to the
application, which is what you had been claiming was the advantage of
your approach. You finally added the missing piece, above, a case where
your approach *does* provide additional protection.

Re: New Input type proposal

Harlan Messinger wrote:
>
> But since the hash, not the password, is what gets access to the
> application, how is this helpful?

Please! Reread my initial posting, all your questions should be answered
there. All advantages are listed there.

> Having the value of a string called a
> "password" is not an end in itself. The point is that the administrator
> has the data he needs to get into the application.

Its not about getting into an application. This is always possible. Its
about protecting the password and preventing replay attacks.

> And if you're talking
> about a situation where the administrator has access to the application
> itself (this isn't a given, but you've just added it to the scenario),

It isnt a given? In most cases the Administrator has access to the
application itself. Whether he is allowed to access it directly is
another issue.

> then why does it matter at all whether the administrator can see the
> password or the hash or anything else?

Password and Replay protection.

>
> You mentioned addressing this with SSL. Your rationale for your approach
> was to shield the password from the administrator as well.

In terms of SSL, yes. But for HTTP it would also provide additional
security layers.

>
> OK, this is the first time you've mentioned the issue of the
> administrator giving it to someone *else* instead of just knowing it
> himself.

Not only necessarily to someone else, but also abusing it for other
accounts of the user.

Alexander

Re: New Input type proposal

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 think it is a great idea that you have, and I do hope that it will
> be at least investigated to the nth.

Thank you, if you use Firefox 2 please have a look at the mentioned
extension to see the actual concept.

Alexander

Re: New Input type proposal

Alexander Mueller wrote:
> Harlan Messinger wrote:
>>
>> But since the hash, not the password, is what gets access to the
>> application, how is this helpful?
>
> Please! Reread my initial posting, all your questions should be answered
> there. All advantages are listed there.
>
>> Having the value of a string called a "password" is not an end in
>> itself. The point is that the administrator has the data he needs to
>> get into the application.
>
> Its not about getting into an application. This is always possible. Its
> about protecting the password and preventing replay attacks.
>
>> And if you're talking about a situation where the administrator has
>> access to the application itself (this isn't a given, but you've just
>> added it to the scenario),
>
> It isnt a given? In most cases the Administrator has access to the
> application itself.

I mean "access" in the way we're using it to apply to anyone
else--access to *use* the application.

Re: New Input type proposal

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 think it is a great idea that you have, and I do hope that it will
> be at least investigated to the nth.

Thank you, if you use Firefox 2 please have a look at the mentioned
extension to see the actual concept.

Alexander

Re: New Input type proposal

Harlan Messinger wrote:
>
> I mean "access" in the way we're using it to apply to anyone
> else--access to *use* the application.

Okay, but then we are in a completely different area. Administrative
access is always more than just user access.

Alexander

Re: New Input type proposal

On 2008-01-09, Alexander Mueller 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 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?

Re: New Input type proposal

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.

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

Re: New Input type proposal

On 2008-01-10, Alexander Mueller 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.

Re: New Input type proposal

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

Re: New Input type proposal

On 2008-01-10, Alexander Mueller 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?

Re: New Input type proposal

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

Re: New Input type proposal

On 2008-01-10, Alexander Mueller 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.

Re: New Input type proposal

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.

Alexander

Re: New Input type proposal

Alexander Mueller wrote:
> Harlan Messinger wrote:
>>
>> OK, so the password has been left out of the server side entirely.
>> Instead, to access the application you need the hash value, and the
>> server administrator has access to *that*. So just substitute the word
>> "password" for the word "hash" and the server administrator is now
>> able to intercept the value of the hash that will give him access to
>> the application.
>
> 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).
>
>>
>> The point of an application storing a hash instead of the original
>> password is that it only accepts the password for authentication,
>> computing its hash when the it's provided and comparing it with the
>> hash it has in its user lookup table.
>
> 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.

> The point is to add security against attackers - as you mentioned - as
> well as, partly, against the Administrator, so that he cannot simply
> reveal the user password, which is currently possible however.
>
>> If someone hacks the user table and finds the hashes, it won't do the
>> hacker any good because the application doesn't provide any interface
>> for accessing the system by providing the hash directly.
>
> Correct.

Re: New Input type proposal

Disco Octopus wrote:
>
> 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

Re: New Input type proposal

Harlan Messinger wrote:
>
> 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.

Re: New Input type proposal

Alexander Mueller wrote:
>
> 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

Re: New Input type proposal

Alexander Mueller wrote:
> Harlan Messinger wrote:
>>
>> 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.

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

Re: New Input type proposal

On 2008-01-10, Alexander Mueller 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 element as you're suggesting.

Re: New Input type proposal

Harlan Messinger wrote:
>
> I explained it already. Sorry if it went by you.

Please see my second reply from 1:52.

Re: New Input type proposal

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

Re: New Input type proposal

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.

--
Neredbojias
Riches are their own reward.