Securing Password Inputs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Securing Password Inputs

Jason H-3
I'm tired of this. Security breach after security breach. Poorly developed websites expose passwords, and even the hashed passwords are no longer "good enough" due to hash databases.

It is time we do something to fix this very broken area of the web. We cannot trust our web software writers to do a quality job. Obligatory XKCDs:
http://xkcd.com/936/
http://xkcd.com/792/

792 is particularly interesting because in this one, a hostile website owner is attempting to collect passwords for guessing at other sites. This is a Huge problem.

I propose a simple technique to solve these problems, however I want it as part of HTML5.

The cryptographic solution (evolution to the solution):
For any <INPUT TYPE="PASSWORD">, we hash the contents before submit. If I enter the well-known and insecure password of "bob" the submitted contents for this are changed to "9f9d51bc70ef21ca5c14f307980a29d8" which, on an insecure site are stored as "9f9d51bc70ef21ca5c14f307980a29d8" This helps a little bit, but the hash is well-known. Therefore, we must also take the domain from the action (<FORM ACTION="arstechica.com/some/url/login.php"> = arstechnica.com) and salt the password accordingly "arstechica.com:bob" = "664b9f0d0528f5a5d2a389e5253bb992" and submit that instead of bob or his well-known hash. Now an attacker has to construct a hash database for every site that is attacked, and also must know the salt and salt method.

Importantly, all of this happens before the website owner gets to ever see the original password, and the routine is provided by the browser. Whatever the site does in addition (another hash, salt, etc) only helps to secure the site further.

I used MD5 to do the hashes above, however SHA1 should be used because it is 8 hexadecimal digits longer (40 characters, 1.786899e+62 key space).

The HTML changes needed to accomplish this:
The <INPUT> element needs to have a "SECURE"  attribute (values=[0|1]) for a transitioning period. The presence of this attribute indicates that in the case of:
0: The site knows it is not secure and the password is submitted as plain text (as it is done today) or javascript will take care of it. The browser may display a warning to the user that the site is asking for a raw password. The software can then take a raw password and after authentication produce an updated password entry by emulating the hashing behavior that would be done in the browser. The password may be truncated to fit existing password semantics.
1: The site knows it is secure and has a secure password on file for the account. It will allow 40 characters of hexadecimal digits.

If the SECURE attribute is not present, then we are in a HTML4-5 transitional area. We could process it as we do now, however I'd like to push the browsers to do the following:
For any PASSWORD input in a known URL (a URL in the history) it checks to see if it migrated this password previously. If it has, then it behaves as SECURE=1. If it hasn't then it treats it as SECURE=0. For either of these situations though, a visual override mechanism is given such that a "knowledgeable" user can choose weather or not a hashed password is submitted. The toggle mechanism will start out as insecure "unlocked" icon. They can enter text and click the icon which will change the icon to a secure "locked" icon and the password will be hashed. The user using unhashed passwords can then after logging in change the password again, using an unlocked icon for the current password,  then entering the same password for new and retyped passwords, then clicking the icon to lock and hash them. In this way a knowledgeable user can use secure passwords on a site that does not yet support this HTML5 password security. (Optionally browsers can support a second click to the icon to "unhash" it) The password field should show the 40 character length of the password.

Also, for browsers that support remembering of passwords, and this has been elected, the new password mechanism still works.

Challenges:
1. The migration phase may be messy. Browsers could make or break acceptance of this.
2. Existing password fields may truncate at 12 or fewer characters, or require a character set not in hex (punctuation)


Comments?

Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

Thomas A. Fine
Hi,

The primary problem is that you've accomplished nothing.  When the user
enters "bob" and the server stores "9f9d51bc70ef21ca5c14f307980a29d8",
this  simply becomes the new magic string that will allow login.  A
hacker interested in reusing passwords has what they need from raiding
the password database without knowing or caring that it used to be
"bob".  They can just use "9f9d51bc70ef21ca5c14f307980a29d8" to attempt
login to loads of other services.

Hashed passwords only provide protection if the REAL password goes over
the network.  In this case, knowing "9f9d51bc70ef21ca5c14f307980a29d8"
is useless unless you can invert the hash, which is supposed to be
computationally infeasible.

     tom

On 8/28/12 11:58 AM, Jason H wrote:

> I'm tired of this. Security breach after security breach. Poorly
> developed websites expose passwords, and even the hashed passwords are
> no longer "good enough" due to hash databases.
>
> It is time we do something to fix this very broken area of the web. We
> cannot trust our web software writers to do a quality job. Obligatory
> XKCDs:
> http://xkcd.com/936/
> http://xkcd.com/792/
>
> 792 is particularly interesting because in this one, a hostile website
> owner is attempting to collect passwords for guessing at other sites.
> This is a Huge problem.
>
> I propose a simple technique to solve these problems, however I want it
> as part of HTML5.
>
> The cryptographic solution (evolution to the solution):
> For any <INPUT TYPE="PASSWORD">, we hash the contents before submit. If
> I enter the well-known and insecure password of "bob" the submitted
> contents for this are changed to "9f9d51bc70ef21ca5c14f307980a29d8"
> which, on an insecure site are stored as
> "9f9d51bc70ef21ca5c14f307980a29d8" This helps a little bit, but the hash
> is well-known. Therefore, we must also take the domain from the action
> (<FORM ACTION="arstechica.com/some/url/login.php"> = arstechnica.com)
> and salt the password accordingly "arstechica.com:bob" =
> "664b9f0d0528f5a5d2a389e5253bb992" and submit that instead of bob or his
> well-known hash. Now an attacker has to construct a hash database for
> every site that is attacked, and also must know the salt and salt method.
>
> Importantly, all of this happens before the website owner gets to ever
> see the original password, and the routine is provided by the browser.
> Whatever the site does in addition (another hash, salt, etc) only helps
> to secure the site further.
>
> I used MD5 to do the hashes above, however SHA1 should be used because
> it is 8 hexadecimal digits longer (40 characters, 1.786899e+62 key space).
>
> The HTML changes needed to accomplish this:
> The <INPUT> element needs to have a "SECURE" attribute (values=[0|1])
> for a transitioning period. The presence of this attribute indicates
> that in the case of:
> 0: The site knows it is not secure and the password is submitted as
> plain text (as it is done today) or javascript will take care of it. The
> browser may display a warning to the user that the site is asking for a
> raw password. The software can then take a raw password and after
> authentication produce an updated password entry by emulating the
> hashing behavior that would be done in the browser. The password may be
> truncated to fit existing password semantics.
> 1: The site knows it is secure and has a secure password on file for the
> account. It will allow 40 characters of hexadecimal digits.
>
> If the SECURE attribute is not present, then we are in a HTML4-5
> transitional area. We could process it as we do now, however I'd like to
> push the browsers to do the following:
> For any PASSWORD input in a known URL (a URL in the history) it checks
> to see if it migrated this password previously. If it has, then it
> behaves as SECURE=1. If it hasn't then it treats it as SECURE=0. For
> either of these situations though, a visual override mechanism is given
> such that a "knowledgeable" user can choose weather or not a hashed
> password is submitted. The toggle mechanism will start out as insecure
> "unlocked" icon. They can enter text and click the icon which will
> change the icon to a secure "locked" icon and the password will be
> hashed. The user using unhashed passwords can then after logging in
> change the password again, using an unlocked icon for the current
> password, then entering the same password for new and retyped passwords,
> then clicking the icon to lock and hash them. In this way a
> knowledgeable user can use secure passwords on a site that does not yet
> support this HTML5 password security. (Optionally browsers can support a
> second click to the icon to "unhash" it) The password field should show
> the 40 character length of the password.
>
> Also, for browsers that support remembering of passwords, and this has
> been elected, the new password mechanism still works.
>
> Challenges:
> 1. The migration phase may be messy. Browsers could make or break
> acceptance of this.
> 2. Existing password fields may truncate at 12 or fewer characters, or
> require a character set not in hex (punctuation)
>
>
> Comments?
>


Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

ownedthx
I would rather:

 <input type="password" pass-check-algorithm="blah" pass-check-field="somefield">  
<span id="somefield"></span>

As a feature of complaint browsers, then, as I type, they evaluate the strength of the password using the pass-check-algorithm, and put a score in <span id="somefield"><span>  I can then script around that, style as I see fit, etc.  

I've become convinced that this problem is an end-user problem, not server-side problem. The real-time, as you type password checkers are fantastic for shaming people in to making better passwords.  The only problem I have is with the specific algorithms I come across.  Some just want a capital letter + funky character, but 8 characters is enough.  But, then, a password that is 50 characters long and all lowercase is 'weak'.   xkcd disagrees with that!! 

So in the context of HTML5, you can defer the problem of 'how the check is determined' by making the algorithm specifiable in an attribute.  Heck, maybe even it's just a javascript routine.  

Seth

On Tue, Aug 28, 2012 at 5:00 PM, Thomas A. Fine <[hidden email]> wrote:
Hi,

The primary problem is that you've accomplished nothing.  When the user enters "bob" and the server stores "9f9d51bc70ef21ca5c14f307980a29d8", this  simply becomes the new magic string that will allow login.  A hacker interested in reusing passwords has what they need from raiding the password database without knowing or caring that it used to be "bob".  They can just use "9f9d51bc70ef21ca5c14f307980a29d8" to attempt login to loads of other services.

Hashed passwords only provide protection if the REAL password goes over the network.  In this case, knowing "9f9d51bc70ef21ca5c14f307980a29d8" is useless unless you can invert the hash, which is supposed to be computationally infeasible.

    tom


On 8/28/12 11:58 AM, Jason H wrote:
I'm tired of this. Security breach after security breach. Poorly
developed websites expose passwords, and even the hashed passwords are
no longer "good enough" due to hash databases.

It is time we do something to fix this very broken area of the web. We
cannot trust our web software writers to do a quality job. Obligatory
XKCDs:
http://xkcd.com/936/
http://xkcd.com/792/

792 is particularly interesting because in this one, a hostile website
owner is attempting to collect passwords for guessing at other sites.
This is a Huge problem.

I propose a simple technique to solve these problems, however I want it
as part of HTML5.

The cryptographic solution (evolution to the solution):
For any <INPUT TYPE="PASSWORD">, we hash the contents before submit. If
I enter the well-known and insecure password of "bob" the submitted
contents for this are changed to "9f9d51bc70ef21ca5c14f307980a29d8"
which, on an insecure site are stored as
"9f9d51bc70ef21ca5c14f307980a29d8" This helps a little bit, but the hash
is well-known. Therefore, we must also take the domain from the action
(<FORM ACTION="arstechica.com/some/url/login.php"> = arstechnica.com)
and salt the password accordingly "arstechica.com:bob" =
"664b9f0d0528f5a5d2a389e5253bb992" and submit that instead of bob or his
well-known hash. Now an attacker has to construct a hash database for
every site that is attacked, and also must know the salt and salt method.

Importantly, all of this happens before the website owner gets to ever
see the original password, and the routine is provided by the browser.
Whatever the site does in addition (another hash, salt, etc) only helps
to secure the site further.

I used MD5 to do the hashes above, however SHA1 should be used because
it is 8 hexadecimal digits longer (40 characters, 1.786899e+62 key space).

The HTML changes needed to accomplish this:
The <INPUT> element needs to have a "SECURE" attribute (values=[0|1])
for a transitioning period. The presence of this attribute indicates
that in the case of:
0: The site knows it is not secure and the password is submitted as
plain text (as it is done today) or javascript will take care of it. The
browser may display a warning to the user that the site is asking for a
raw password. The software can then take a raw password and after
authentication produce an updated password entry by emulating the
hashing behavior that would be done in the browser. The password may be
truncated to fit existing password semantics.
1: The site knows it is secure and has a secure password on file for the
account. It will allow 40 characters of hexadecimal digits.

If the SECURE attribute is not present, then we are in a HTML4-5
transitional area. We could process it as we do now, however I'd like to
push the browsers to do the following:
For any PASSWORD input in a known URL (a URL in the history) it checks
to see if it migrated this password previously. If it has, then it
behaves as SECURE=1. If it hasn't then it treats it as SECURE=0. For
either of these situations though, a visual override mechanism is given
such that a "knowledgeable" user can choose weather or not a hashed
password is submitted. The toggle mechanism will start out as insecure
"unlocked" icon. They can enter text and click the icon which will
change the icon to a secure "locked" icon and the password will be
hashed. The user using unhashed passwords can then after logging in
change the password again, using an unlocked icon for the current
password, then entering the same password for new and retyped passwords,
then clicking the icon to lock and hash them. In this way a
knowledgeable user can use secure passwords on a site that does not yet
support this HTML5 password security. (Optionally browsers can support a
second click to the icon to "unhash" it) The password field should show
the 40 character length of the password.

Also, for browsers that support remembering of passwords, and this has
been elected, the new password mechanism still works.

Challenges:
1. The migration phase may be messy. Browsers could make or break
acceptance of this.
2. Existing password fields may truncate at 12 or fewer characters, or
require a character set not in hex (punctuation)


Comments?




Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

Jason H-3
In reply to this post by Thomas A. Fine
I am not sure I was clear in explaining the problem that this is supposed to solve. The problem being solved is not a new way to login, rather it is preventing the knowing of password, a password that all too often is shared among other sites.

Also note, that your example is true only in the case where a service would be storing plaintext passwords. Clearly, this is bad practice, even 10 years ago, much less today. One single re-hash of "9f9d51bc70ef21ca5c14f307980a29d8" is all that is needed to blow the dictionaries out of the water. So let's assume that no one is storing plaintext, and everyone is storing a hash. "10fd9fbe1c6861fb0a14a57e78f871c5" is stored instead of "9f9d51bc70ef21ca5c14f307980a29d8". Now, lets see them come up with a dictionary that encompasses all of the MD5 (or SHA1) key space. It's just not feasible and won't be for years to come. In this way, the attacker cannot ever know what the secret is so send over the wire. This won't fix man-in-the-middle attacks, but will prevent a replay attack. SSL will cover the main-in-the-middle. Combined, we have the problem solved.

Salting takes care of using "9f9d51bc70ef21ca5c14f307980a29d8" for other services, as what I propose was hashing "domain.com:user:password" ("3e56fe2ea51f26818092aba8905f54f6"). "Other services" to be attacked will no use the same salt, therefore, "3e56fe2ea51f26818092aba8905f54f6" cannot be expected work at other places. (i.e "anotherdomain.com:user:password"="d4f0fdba546361007074fc7f3ef6c4c9" even if the user and password are the same.





From: Thomas A. Fine <[hidden email]>
To: [hidden email]
Sent: Tuesday, August 28, 2012 6:00 PM
Subject: Re: Securing Password Inputs

Hi,

The primary problem is that you've accomplished nothing.  When the user
enters "bob" and the server stores "9f9d51bc70ef21ca5c14f307980a29d8",
this  simply becomes the new magic string that will allow login.  A
hacker interested in reusing passwords has what they need from raiding
the password database without knowing or caring that it used to be
"bob".  They can just use "9f9d51bc70ef21ca5c14f307980a29d8" to attempt
login to loads of other services.

Hashed passwords only provide protection if the REAL password goes over
the network.  In this case, knowing "9f9d51bc70ef21ca5c14f307980a29d8"
is useless unless you can invert the hash, which is supposed to be
computationally infeasible.

    tom

On 8/28/12 11:58 AM, Jason H wrote:

> I'm tired of this. Security breach after security breach. Poorly
> developed websites expose passwords, and even the hashed passwords are
> no longer "good enough" due to hash databases.
>
> It is time we do something to fix this very broken area of the web. We
> cannot trust our web software writers to do a quality job. Obligatory
> XKCDs:
> http://xkcd.com/936/
> http://xkcd.com/792/
>
> 792 is particularly interesting because in this one, a hostile website
> owner is attempting to collect passwords for guessing at other sites.
> This is a Huge problem.
>
> I propose a simple technique to solve these problems, however I want it
> as part of HTML5.
>
> The cryptographic solution (evolution to the solution):
> For any <INPUT TYPE="PASSWORD">, we hash the contents before submit. If
> I enter the well-known and insecure password of "bob" the submitted
> contents for this are changed to "9f9d51bc70ef21ca5c14f307980a29d8"
> which, on an insecure site are stored as
> "9f9d51bc70ef21ca5c14f307980a29d8" This helps a little bit, but the hash
> is well-known. Therefore, we must also take the domain from the action
> (<FORM ACTION="arstechica.com/some/url/login.php"> = arstechnica.com)
> and salt the password accordingly "arstechica.com:bob" =
> "664b9f0d0528f5a5d2a389e5253bb992" and submit that instead of bob or his
> well-known hash. Now an attacker has to construct a hash database for
> every site that is attacked, and also must know the salt and salt method.
>
> Importantly, all of this happens before the website owner gets to ever
> see the original password, and the routine is provided by the browser.
> Whatever the site does in addition (another hash, salt, etc) only helps
> to secure the site further.
>
> I used MD5 to do the hashes above, however SHA1 should be used because
> it is 8 hexadecimal digits longer (40 characters, 1.786899e+62 key space).
>
> The HTML changes needed to accomplish this:
> The <INPUT> element needs to have a "SECURE" attribute (values=[0|1])
> for a transitioning period. The presence of this attribute indicates
> that in the case of:
> 0: The site knows it is not secure and the password is submitted as
> plain text (as it is done today) or javascript will take care of it. The
> browser may display a warning to the user that the site is asking for a
> raw password. The software can then take a raw password and after
> authentication produce an updated password entry by emulating the
> hashing behavior that would be done in the browser. The password may be
> truncated to fit existing password semantics.
> 1: The site knows it is secure and has a secure password on file for the
> account. It will allow 40 characters of hexadecimal digits.
>
> If the SECURE attribute is not present, then we are in a HTML4-5
> transitional area. We could process it as we do now, however I'd like to
> push the browsers to do the following:
> For any PASSWORD input in a known URL (a URL in the history) it checks
> to see if it migrated this password previously. If it has, then it
> behaves as SECURE=1. If it hasn't then it treats it as SECURE=0. For
> either of these situations though, a visual override mechanism is given
> such that a "knowledgeable" user can choose weather or not a hashed
> password is submitted. The toggle mechanism will start out as insecure
> "unlocked" icon. They can enter text and click the icon which will
> change the icon to a secure "locked" icon and the password will be
> hashed. The user using unhashed passwords can then after logging in
> change the password again, using an unlocked icon for the current
> password, then entering the same password for new and retyped passwords,
> then clicking the icon to lock and hash them. In this way a
> knowledgeable user can use secure passwords on a site that does not yet
> support this HTML5 password security. (Optionally browsers can support a
> second click to the icon to "unhash" it) The password field should show
> the 40 character length of the password.
>
> Also, for browsers that support remembering of passwords, and this has
> been elected, the new password mechanism still works.
>
> Challenges:
> 1. The migration phase may be messy. Browsers could make or break
> acceptance of this.
> 2. Existing password fields may truncate at 12 or fewer characters, or
> require a character set not in hex (punctuation)
>
>
> Comments?
>




Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

Jason H-3
In reply to this post by ownedthx
I must not have been clear. This in no way changes the way server-side authentication happens. This only changes what is sent as a "password" to the server. The idea when applied would obsolete the "score" because 36^40 is a very high score. All scores are the same regardless of "bob" or "Sdf3er3dSdse32e3dsfsfvbgs" because they are all moved into the hash's hashspace (always 40 chars, base 36).

This is NOT an end-user problem. If that is the case then we are out of luck when it comes to security because all passwords will be dictionary attack vulnerable.

You could do this today for a site in javascript, yes, but the problem with that is you're going to have a million algorithms, some not as secure as the others, and you have no idea when it is going to be applied. If it goes into the HTML spec, then you know it is compliant.



From: Seth Call <[hidden email]>
To: Thomas A. Fine <[hidden email]>
Cc: [hidden email]
Sent: Tuesday, August 28, 2012 6:11 PM
Subject: Re: Securing Password Inputs

I would rather:

 <input type="password" pass-check-algorithm="blah" pass-check-field="somefield">  
<span id="somefield"></span>

As a feature of complaint browsers, then, as I type, they evaluate the strength of the password using the pass-check-algorithm, and put a score in <span id="somefield"><span>  I can then script around that, style as I see fit, etc.  

I've become convinced that this problem is an end-user problem, not server-side problem. The real-time, as you type password checkers are fantastic for shaming people in to making better passwords.  The only problem I have is with the specific algorithms I come across.  Some just want a capital letter + funky character, but 8 characters is enough.  But, then, a password that is 50 characters long and all lowercase is 'weak'.   xkcd disagrees with that!! 

So in the context of HTML5, you can defer the problem of 'how the check is determined' by making the algorithm specifiable in an attribute.  Heck, maybe even it's just a javascript routine.  

Seth

On Tue, Aug 28, 2012 at 5:00 PM, Thomas A. Fine <[hidden email]> wrote:
Hi,

The primary problem is that you've accomplished nothing.  When the user enters "bob" and the server stores "9f9d51bc70ef21ca5c14f307980a29d8", this  simply becomes the new magic string that will allow login.  A hacker interested in reusing passwords has what they need from raiding the password database without knowing or caring that it used to be "bob".  They can just use "9f9d51bc70ef21ca5c14f307980a29d8" to attempt login to loads of other services.

Hashed passwords only provide protection if the REAL password goes over the network.  In this case, knowing "9f9d51bc70ef21ca5c14f307980a29d8" is useless unless you can invert the hash, which is supposed to be computationally infeasible.

    tom


On 8/28/12 11:58 AM, Jason H wrote:
I'm tired of this. Security breach after security breach. Poorly
developed websites expose passwords, and even the hashed passwords are
no longer "good enough" due to hash databases.

It is time we do something to fix this very broken area of the web. We
cannot trust our web software writers to do a quality job. Obligatory
XKCDs:
http://xkcd.com/936/
http://xkcd.com/792/

792 is particularly interesting because in this one, a hostile website
owner is attempting to collect passwords for guessing at other sites.
This is a Huge problem.

I propose a simple technique to solve these problems, however I want it
as part of HTML5.

The cryptographic solution (evolution to the solution):
For any <INPUT TYPE="PASSWORD">, we hash the contents before submit. If
I enter the well-known and insecure password of "bob" the submitted
contents for this are changed to "9f9d51bc70ef21ca5c14f307980a29d8"
which, on an insecure site are stored as
"9f9d51bc70ef21ca5c14f307980a29d8" This helps a little bit, but the hash
is well-known. Therefore, we must also take the domain from the action
(<FORM ACTION="arstechica.com/some/url/login.php"> = arstechnica.com)
and salt the password accordingly "arstechica.com:bob" =
"664b9f0d0528f5a5d2a389e5253bb992" and submit that instead of bob or his
well-known hash. Now an attacker has to construct a hash database for
every site that is attacked, and also must know the salt and salt method.

Importantly, all of this happens before the website owner gets to ever
see the original password, and the routine is provided by the browser.
Whatever the site does in addition (another hash, salt, etc) only helps
to secure the site further.

I used MD5 to do the hashes above, however SHA1 should be used because
it is 8 hexadecimal digits longer (40 characters, 1.786899e+62 key space).

The HTML changes needed to accomplish this:
The <INPUT> element needs to have a "SECURE" attribute (values=[0|1])
for a transitioning period. The presence of this attribute indicates
that in the case of:
0: The site knows it is not secure and the password is submitted as
plain text (as it is done today) or javascript will take care of it. The
browser may display a warning to the user that the site is asking for a
raw password. The software can then take a raw password and after
authentication produce an updated password entry by emulating the
hashing behavior that would be done in the browser. The password may be
truncated to fit existing password semantics.
1: The site knows it is secure and has a secure password on file for the
account. It will allow 40 characters of hexadecimal digits.

If the SECURE attribute is not present, then we are in a HTML4-5
transitional area. We could process it as we do now, however I'd like to
push the browsers to do the following:
For any PASSWORD input in a known URL (a URL in the history) it checks
to see if it migrated this password previously. If it has, then it
behaves as SECURE=1. If it hasn't then it treats it as SECURE=0. For
either of these situations though, a visual override mechanism is given
such that a "knowledgeable" user can choose weather or not a hashed
password is submitted. The toggle mechanism will start out as insecure
"unlocked" icon. They can enter text and click the icon which will
change the icon to a secure "locked" icon and the password will be
hashed. The user using unhashed passwords can then after logging in
change the password again, using an unlocked icon for the current
password, then entering the same password for new and retyped passwords,
then clicking the icon to lock and hash them. In this way a
knowledgeable user can use secure passwords on a site that does not yet
support this HTML5 password security. (Optionally browsers can support a
second click to the icon to "unhash" it) The password field should show
the 40 character length of the password.

Also, for browsers that support remembering of passwords, and this has
been elected, the new password mechanism still works.

Challenges:
1. The migration phase may be messy. Browsers could make or break
acceptance of this.
2. Existing password fields may truncate at 12 or fewer characters, or
require a character set not in hex (punctuation)


Comments?






Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

cameronjones
On Wed, Aug 29, 2012 at 1:05 AM, Jason H <[hidden email]> wrote:

> I must not have been clear. This in no way changes the way server-side
> authentication happens. This only changes what is sent as a "password" to
> the server. The idea when applied would obsolete the "score" because 36^40
> is a very high score. All scores are the same regardless of "bob" or
> "Sdf3er3dSdse32e3dsfsfvbgs" because they are all moved into the hash's
> hashspace (always 40 chars, base 36).
>
> This is NOT an end-user problem. If that is the case then we are out of luck
> when it comes to security because all passwords will be dictionary attack
> vulnerable.
>
> You could do this today for a site in javascript, yes, but the problem with
> that is you're going to have a million algorithms, some not as secure as the
> others, and you have no idea when it is going to be applied. If it goes into
> the HTML spec, then you know it is compliant.
>

I'm not sure what you are stating this achieves, but the idea for
client-side hashing of passwords has been discussed before and was
generally accepted as a non-compelling enhancement as it does not
protect against simple replay attacks. The most recent discussions
have been on the whatwg:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032109.html

The use of the origin as a salt is also not a good approach as the
password is tied to the origin preventing the site from moving domains
or otherwise restructuring their site, domain use or providing single
sign-on across multiple domains.

There is the additional problem of having a mix of html4 and html5
users - the password would either be a hash or plaintext depending on
what browser the user used to login, how can the site reconcile this?

If there is no salt, encrypting the passwords on the client side would
amount to a dictionary translation and still be susceptible to rainbow
tables.

As an alternative solution for sites wanting greater security, there
is a progressing issue in HTML5 for declarative HTTP authentication
within forms. This allows sites to provide HTML interfaces for
capturing credentials which are then encoded by the browser into
either BASIC or DIGEST headers. These authentication schemes employ
either simple base64 encoding against trivial password sniffing, or
with DIGEST there is proper cryptographic hashing using nonce values.
Sites employing these authentication schemes will exhibit the
enhancement to security you are looking for. Mandating the use of
crypto hashing for all passwords is not possible and, as always with
security, users must apply prudence to the sites they interact with
and credentials they use or give out as a matter of explicit trust and
self defense.

The issue is tracked here:

http://www.w3.org/html/wg/tracker/issues/195

Thanks,
Cameron Jones

Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

Jason H-3
Thanks for the feedback.

Reactions:
0. The intent is not to prevent replay attacks (as I understand in this context), but to prevent the obtaining of passwords from user table breaches due to insecure design. The fact that Sony, Yahoo, LinkedIn (big players) cannot get it right shows that the technology overall is failing. We are cursed with different password rules at every site, different lengths (some even implementing max lengths). People resort to software to manage passwords, or worse, give up on security. This is not good.
Could you elaborate on the replay attack you are considering here?

1. I was relatively appauled at the summary "generally accepted as a non-compelling enhancement as it does not
protect against simple replay attacks." Passwords are essentially useless now, and I think that is compelling enough. Fixing it at the HTTP level may be the right solution, but there's no reason why it can't be layered. It is also easier to accomplish in HTML on an application basis, rather than making everyone upgrade their servers AND applications.

2. I did not suggest the origin as the salt, I suggested the action domain as the salt. They are not necessarily equal. Furthermore changing the action domain is a very rare occurrence, and there are mitigation strategies if it really is that important. (Location header, DNS alias, proxy etc.)

3. Transition from v4 to v5 would be eased if the scheme was adopted for v5, then applications could back-port via javascript the same functionality. Having a simple, clear mechanism like hashing "domain.com:password" for can be trivially done by a standard javascript routine inlcuded in the page, or a browser plugin, or the browser itself. When a v5 page is detected the plugin/browser becomes a no-op. if the javascript technique is used (application supported), then that is moot as well because the application page will be HTML version specific, which will then simply not include the JavaScript function by matter of design.

4. The digest mechanism is an excellent approach in terms of security, but I fear it will be too much work to properly implement. Salting passwords is trivial and we can't even get that out of the big players. As I understand it, all authentication should be over HTTPS anyway. Implementing hased passwords over SSL seems much easier to achieve than both redesigning protocols and servers and applications.

Thank you for your reply, and I look forward to continuing this conversation with you.



From: Cameron Jones <[hidden email]>
To: Jason H <[hidden email]>
Cc: Seth Call <[hidden email]>; Thomas A. Fine <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Thursday, August 30, 2012 10:16 AM
Subject: Re: Securing Password Inputs

On Wed, Aug 29, 2012 at 1:05 AM, Jason H <[hidden email]> wrote:

> I must not have been clear. This in no way changes the way server-side
> authentication happens. This only changes what is sent as a "password" to
> the server. The idea when applied would obsolete the "score" because 36^40
> is a very high score. All scores are the same regardless of "bob" or
> "Sdf3er3dSdse32e3dsfsfvbgs" because they are all moved into the hash's
> hashspace (always 40 chars, base 36).
>
> This is NOT an end-user problem. If that is the case then we are out of luck
> when it comes to security because all passwords will be dictionary attack
> vulnerable.
>
> You could do this today for a site in javascript, yes, but the problem with
> that is you're going to have a million algorithms, some not as secure as the
> others, and you have no idea when it is going to be applied. If it goes into
> the HTML spec, then you know it is compliant.
>

I'm not sure what you are stating this achieves, but the idea for
client-side hashing of passwords has been discussed before and was
generally accepted as a non-compelling enhancement as it does not
protect against simple replay attacks. The most recent discussions
have been on the whatwg:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032109.html

The use of the origin as a salt is also not a good approach as the
password is tied to the origin preventing the site from moving domains
or otherwise restructuring their site, domain use or providing single
sign-on across multiple domains.

There is the additional problem of having a mix of html4 and html5
users - the password would either be a hash or plaintext depending on
what browser the user used to login, how can the site reconcile this?

If there is no salt, encrypting the passwords on the client side would
amount to a dictionary translation and still be susceptible to rainbow
tables.

As an alternative solution for sites wanting greater security, there
is a progressing issue in HTML5 for declarative HTTP authentication
within forms. This allows sites to provide HTML interfaces for
capturing credentials which are then encoded by the browser into
either BASIC or DIGEST headers. These authentication schemes employ
either simple base64 encoding against trivial password sniffing, or
with DIGEST there is proper cryptographic hashing using nonce values.
Sites employing these authentication schemes will exhibit the
enhancement to security you are looking for. Mandating the use of
crypto hashing for all passwords is not possible and, as always with
security, users must apply prudence to the sites they interact with
and credentials they use or give out as a matter of explicit trust and
self defense.

The issue is tracked here:

http://www.w3.org/html/wg/tracker/issues/195

Thanks,
Cameron Jones



Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

cameronjones
On Thu, Aug 30, 2012 at 4:38 PM, Jason H <[hidden email]> wrote:

> Thanks for the feedback.
>
> Reactions:
> 0. The intent is not to prevent replay attacks (as I understand in this
> context), but to prevent the obtaining of passwords from user table breaches
> due to insecure design. The fact that Sony, Yahoo, LinkedIn (big players)
> cannot get it right shows that the technology overall is failing. We are
> cursed with different password rules at every site, different lengths (some
> even implementing max lengths). People resort to software to manage
> passwords, or worse, give up on security. This is not good.
> Could you elaborate on the replay attack you are considering here?

The replay attack is based on someone listening to the HTTP stream and
using the password contained within to initiate new requests using the
same credentials. Even if the password is hashed by the browser thus
hiding the original plaintext password, the interceptor can still
issue commands via curl or some other non-browser HTTP client to run
privileged actions as the user. So there is no difference between
plaintext and client-side hashing, in this regard.

>
> 1. I was relatively appauled at the summary "generally accepted as a
> non-compelling enhancement as it does not
> protect against simple replay attacks." Passwords are essentially useless
> now, and I think that is compelling enough. Fixing it at the HTTP level may
> be the right solution, but there's no reason why it can't be layered. It is
> also easier to accomplish in HTML on an application basis, rather than
> making everyone upgrade their servers AND applications.
>

The inability of large organizations to protect their infrastructure
and users is a concern i share, however given that the source of the
breach is their lack of implementation of security best practices the
consensus was that it is better to promote the "best practice" rather
than add another semi-secure method.

The approach you suggest is essentially an attempt not to protect the
transfer of passwords but to obscure the original password from the
site it is sent to because it is regarded as insecure. The problem
with this is unfortunately it requires the action of the site in order
to implement it, so why would a site implement something which does
not benefit them?


> 2. I did not suggest the origin as the salt, I suggested the action domain
> as the salt. They are not necessarily equal. Furthermore changing the action
> domain is a very rare occurrence, and there are mitigation strategies if it
> really is that important. (Location header, DNS alias, proxy etc.)
>

Using any part of the domain or action as salt is non-transferrable.
You could use some crafty redirects or whatever, but this is based on
the assumption that the original domain is still under their control.
Given that companies are acquired, merged or split there is no
migration strategy other than requiring users to re-register with the
new domain. From a user experience and relations perspective this is
abhorrent. This is also the attack vector used by phishing emails and
sites which make requests like this and try to get users to re-enter
their credentials.

> 3. Transition from v4 to v5 would be eased if the scheme was adopted for v5,
> then applications could back-port via javascript the same functionality.
> Having a simple, clear mechanism like hashing "domain.com:password" for can
> be trivially done by a standard javascript routine inlcuded in the page, or
> a browser plugin, or the browser itself. When a v5 page is detected the
> plugin/browser becomes a no-op. if the javascript technique is used
> (application supported), then that is moot as well because the application
> page will be HTML version specific, which will then simply not include the
> JavaScript function by matter of design.
>

The problem i see is that the service only has the hashed password on
file so they are incapable of validating the original. They could
implement their own javascript to apply the encoding for older
browsers but this imposes more work on them for a start, and does not
cater for non-javascript clients.

> 4. The digest mechanism is an excellent approach in terms of security, but I
> fear it will be too much work to properly implement. Salting passwords is
> trivial and we can't even get that out of the big players. As I understand
> it, all authentication should be over HTTPS anyway. Implementing hased
> passwords over SSL seems much easier to achieve than both redesigning
> protocols and servers and applications.
>

Yes, the only secure method is to ensure authentication happens over
SSL. Using DIGEST, while more work to setup , provides sites with
another authentication option which is relatively secure yet does not
impose the overhead of SSL. Sites using BASIC will have at least some
level of security over sending plaintext passwords in the clear.

Hashing and sending over SSL does not provide any additional benefit
as the entire request is encoded anyway so plaintext is fine to use,
from a transfer perspective.


> Thank you for your reply, and I look forward to continuing this conversation
> with you.
>
>

Thanks,
Cameron Jones

Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

Jason H-3
0. For the replay, this is what SSL is for. (Though I do see value in a non-SSL approach)

1. But it does benefit them. When they are breached they can tell their users it's no big deal.  In fact, if it is as effective and I think ti will be, it eliminate breaches that are focused on obtaining user credentials.

2. The phishing angle is interesting. For v5 pages, it is a non issue, as it would PREVENT the password from being sent. The phisher would only get a hash, which he would have to have a dictionary of the salted key space, which is computationally unfeasible. If it is deemed feasible, then we can double hash it, so that what they get on the server side is not an element of a dictionary, but something already in the hash keyspace (36^40 in the case of SHA1). This double-hash effectively eliminates phishing since they won't be able to reverse the hash. This is reason alone to adopt this approach.

3. The service does not need to have the password, or even the hashed password on file. Authentication and self-services (password reset) mechanisms work transparently, exactly as they do now. Whatever hash gets sent over the wire from the client has the same functions applied and the same equivalency results. That is to say, a zero-security site that stores the password as-is will end up storing the salted hash and later comparing to it. A semi-secure site that hashes the password will hash the salted hash and storing that and comparing to that. The back-end logic remains unchanged. The only change is if they send a random password to the user, the user will either have to be able to enter this without hashing (bad idea) or the back-end is changed to expect the hash based on that random password (better idea).

Would it appease you if it were suggested that the standard be, that if no SALT attribute is supplied on the INPUT field (zero length or not present), the domain name of the ACTION attribute is used. In this way, you can accomplish those consolidations and divestments between domains?

So with this approach we kill off phishing, keep it invisible to the user, keep the application development light, and the backends are virtually unchanged.



________________________________
From: Cameron Jones <[hidden email]>
To: Jason H <[hidden email]>
Cc: Seth Call <[hidden email]>; Thomas A. Fine <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Thursday, August 30, 2012 1:10 PM
Subject: Re: Securing Password Inputs

On Thu, Aug 30, 2012 at 4:38 PM, Jason H <[hidden email]> wrote:

> Thanks for the feedback.
>
> Reactions:
> 0. The intent is not to prevent replay attacks (as I understand in this
> context), but to prevent the obtaining of passwords from user table breaches
> due to insecure design. The fact that Sony, Yahoo, LinkedIn (big players)
> cannot get it right shows that the technology overall is failing. We are
> cursed with different password rules at every site, different lengths (some
> even implementing max lengths). People resort to software to manage
> passwords, or worse, give up on security. This is not good.
> Could you elaborate on the replay attack you are considering here?

The replay attack is based on someone listening to the HTTP stream and
using the password contained within to initiate new requests using the
same credentials. Even if the password is hashed by the browser thus
hiding the original plaintext password, the interceptor can still
issue commands via curl or some other non-browser HTTP client to run
privileged actions as the user. So there is no difference between
plaintext and client-side hashing, in this regard.

>
> 1. I was relatively appauled at the summary "generally accepted as a
> non-compelling enhancement as it does not
> protect against simple replay attacks." Passwords are essentially useless
> now, and I think that is compelling enough. Fixing it at the HTTP level may
> be the right solution, but there's no reason why it can't be layered. It is
> also easier to accomplish in HTML on an application basis, rather than
> making everyone upgrade their servers AND applications.
>

The inability of large organizations to protect their infrastructure
and users is a concern i share, however given that the source of the
breach is their lack of implementation of security best practices the
consensus was that it is better to promote the "best practice" rather
than add another semi-secure method.

The approach you suggest is essentially an attempt not to protect the
transfer of passwords but to obscure the original password from the
site it is sent to because it is regarded as insecure. The problem
with this is unfortunately it requires the action of the site in order
to implement it, so why would a site implement something which does
not benefit them?


> 2. I did not suggest the origin as the salt, I suggested the action domain
> as the salt. They are not necessarily equal. Furthermore changing the action
> domain is a very rare occurrence, and there are mitigation strategies if it
> really is that important. (Location header, DNS alias, proxy etc.)
>

Using any part of the domain or action as salt is non-transferrable.
You could use some crafty redirects or whatever, but this is based on
the assumption that the original domain is still under their control.
Given that companies are acquired, merged or split there is no
migration strategy other than requiring users to re-register with the
new domain. From a user experience and relations perspective this is
abhorrent. This is also the attack vector used by phishing emails and
sites which make requests like this and try to get users to re-enter
their credentials.

> 3. Transition from v4 to v5 would be eased if the scheme was adopted for v5,
> then applications could back-port via javascript the same functionality.
> Having a simple, clear mechanism like hashing "domain.com:password" for can
> be trivially done by a standard javascript routine inlcuded in the page, or
> a browser plugin, or the browser itself. When a v5 page is detected the
> plugin/browser becomes a no-op. if the javascript technique is used
> (application supported), then that is moot as well because the application
> page will be HTML version specific, which will then simply not include the
> JavaScript function by matter of design.
>

The problem i see is that the service only has the hashed password on
file so they are incapable of validating the original. They could
implement their own javascript to apply the encoding for older
browsers but this imposes more work on them for a start, and does not
cater for non-javascript clients.

> 4. The digest mechanism is an excellent approach in terms of security, but I
> fear it will be too much work to properly implement. Salting passwords is
> trivial and we can't even get that out of the big players. As I understand
> it, all authentication should be over HTTPS anyway. Implementing hased
> passwords over SSL seems much easier to achieve than both redesigning
> protocols and servers and applications.
>

Yes, the only secure method is to ensure authentication happens over
SSL. Using DIGEST, while more work to setup , provides sites with
another authentication option which is relatively secure yet does not
impose the overhead of SSL. Sites using BASIC will have at least some
level of security over sending plaintext passwords in the clear.

Hashing and sending over SSL does not provide any additional benefit
as the entire request is encoded anyway so plaintext is fine to use,
from a transfer perspective.


> Thank you for your reply, and I look forward to continuing this conversation
> with you.
>
>

Thanks,
Cameron Jones

Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

cameronjones
On Thu, Aug 30, 2012 at 7:21 PM, Jason H <[hidden email]> wrote:
> 0. For the replay, this is what SSL is for. (Though I do see value in a non-SSL approach)

Yes, SSL can be used to protect against replay attacks, amongst
others. The use case here is obscuring passwords from the site which
uses them, so we can just examine this.

>
> 1. But it does benefit them. When they are breached they can tell their users it's no big deal.  In fact, if it is as effective and I think ti will be, it eliminate breaches that are focused on obtaining user credentials.

This doesn't eliminate rainbow tables, it just restricts their use to
a single domain (or whatever the salt is based on). If a site is
attacked and its user\password table leaked, the attacker can generate
a new rainbow table for the site,or use a precomputed one, since they
know what the salt is. This is why it is good security practice to
have a secret salt and change the salt for each user. Since the salt
algorithm must be published for interoperability this negates the
purpose of the salt which is to augment the password with additional
unknown data making rainbow tables too expensive to compute,
effectively doubling the size of the password.

>
> 2. The phishing angle is interesting. For v5 pages, it is a non issue, as it would PREVENT the password from being sent. The phisher would only get a hash, which he would have to have a dictionary of the salted key space, which is computationally unfeasible. If it is deemed feasible, then we can double hash it, so that what they get on the server side is not an element of a dictionary, but something already in the hash keyspace (36^40 in the case of SHA1). This double-hash effectively eliminates phishing since they won't be able to reverse the hash. This is reason alone to adopt this approach.

But you assume that the phishing site uses password fields and that
they have enabled the client-side hashing, which was optional. They
will be able to capture the plaintext password and use directly on the
host site, no curl or direct HTTP necessary.

>
> 3. The service does not need to have the password, or even the hashed password on file. Authentication and self-services (password reset) mechanisms work transparently, exactly as they do now. Whatever hash gets sent over the wire from the client has the same functions applied and the same equivalency results. That is to say, a zero-security site that stores the password as-is will end up storing the salted hash and later comparing to it. A semi-secure site that hashes the password will hash the salted hash and storing that and comparing to that. The back-end logic remains unchanged. The only change is if they send a random password to the user, the user will either have to be able to enter this without hashing (bad idea) or the back-end is changed to expect the hash based on that random password (better idea).

This is assuming only new registrations, what about users who are
already registered and have their password already stored as a
server-computer hash? These users have to re-register again. There is
no upgrade path for existing services.

>
> Would it appease you if it were suggested that the standard be, that if no SALT attribute is supplied on the INPUT field (zero length or not present), the domain name of the ACTION attribute is used. In this way, you can accomplish those consolidations and divestments between domains?

Using no salt has no value since the same rainbow table can be used as is today.

Using an advertised salt value is insecure if it is static otherwise
it becomes a nonce value. This is then getting very close to what
DIGEST already is, yet that is provided on the protocol level and does
not require manipulating form inputs and so can be provided by apache
mods instead of being bound in the application and requiring
application-level integration.

Using the action binds the service to a specific domain which can not
be changed. I contend that no business will implement this purely from
the imposed lack of deployment flexibility and inability to change.

Thanks,
Cameron Jones

Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

Jason H-3

1. It does eliminate rainbow tables. [1] http://en.wikipedia.org/wiki/Rainbow_table#Defense_against_rainbow_tables Mybe the word "eliminate" is too strong but computationally infeasible. You' d have to generate a rainbow table specific to the site as you note, but it takes time and memory to do that. When you double hash it, you move the keyspaces to increcible sizes, 1.7 *10^62 entries, which is 6.3 *10^48 PETAbytes in size.

2. I'm suggesting that HTML5  make it not optional, and we'll get there "eventually". What kind of phishing attack uses the host site? All the ones I know use a copy. No big deal, I enter my password into the phishing site, the HTML5 password protocol kicks in, they get a double-hashed password. Then they have to unhash the first hash (impossible) then unhash that hash (also impossible) then unsalt it (trivial). Only after they perform two impossible steps will they know my password.

3. If they are already registered and have a server-computed hash, then there are a couple approaches. How the site is configured now will greatly influence the method. The easiest is to add a column to the user table and indicate if it is the new style or not, and continue to apply the corresponding algorithm. This seems overkill unless a user has a 40 character hexadecimal password already, otherwise the software can detect this pattern and know how to use it. The application can then encourage the user to update their password. I would consider this an upgrade path.

It does not mean that the salt is a nonce. Unless we somehow figure out a way to have the entire SHA1 keyspace (which is 6.8 *10^48 petabytes in size) mapped to the hash space  (another 6.8 *10^48 petabytes)  and do the fast look-up it has significant value.






----- Original Message -----
From: Cameron Jones <[hidden email]>
To: Jason H <[hidden email]>
Cc: Seth Call <[hidden email]>; Thomas A. Fine <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Thursday, August 30, 2012 3:09 PM
Subject: Re: Securing Password Inputs

On Thu, Aug 30, 2012 at 7:21 PM, Jason H <[hidden email]> wrote:
> 0. For the replay, this is what SSL is for. (Though I do see value in a non-SSL approach)

Yes, SSL can be used to protect against replay attacks, amongst
others. The use case here is obscuring passwords from the site which
uses them, so we can just examine this.

>
> 1. But it does benefit them. When they are breached they can tell their users it's no big deal.  In fact, if it is as effective and I think ti will be, it eliminate breaches that are focused on obtaining user credentials.

This doesn't eliminate rainbow tables, it just restricts their use to
a single domain (or whatever the salt is based on). If a site is
attacked and its user\password table leaked, the attacker can generate
a new rainbow table for the site,or use a precomputed one, since they
know what the salt is. This is why it is good security practice to
have a secret salt and change the salt for each user. Since the salt
algorithm must be published for interoperability this negates the
purpose of the salt which is to augment the password with additional
unknown data making rainbow tables too expensive to compute,
effectively doubling the size of the password.

>
> 2. The phishing angle is interesting. For v5 pages, it is a non issue, as it would PREVENT the password from being sent. The phisher would only get a hash, which he would have to have a dictionary of the salted key space, which is computationally unfeasible. If it is deemed feasible, then we can double hash it, so that what they get on the server side is not an element of a dictionary, but something already in the hash keyspace (36^40 in the case of SHA1). This double-hash effectively eliminates phishing since they won't be able to reverse the hash. This is reason alone to adopt this approach.

But you assume that the phishing site uses password fields and that
they have enabled the client-side hashing, which was optional. They
will be able to capture the plaintext password and use directly on the
host site, no curl or direct HTTP necessary.

>
> 3. The service does not need to have the password, or even the hashed password on file. Authentication and self-services (password reset) mechanisms work transparently, exactly as they do now. Whatever hash gets sent over the wire from the client has the same functions applied and the same equivalency results. That is to say, a zero-security site that stores the password as-is will end up storing the salted hash and later comparing to it. A semi-secure site that hashes the password will hash the salted hash and storing that and comparing to that. The back-end logic remains unchanged. The only change is if they send a random password to the user, the user will either have to be able to enter this without hashing (bad idea) or the back-end is changed to expect the hash based on that random password (better idea).

This is assuming only new registrations, what about users who are
already registered and have their password already stored as a
server-computer hash? These users have to re-register again. There is
no upgrade path for existing services.

>
> Would it appease you if it were suggested that the standard be, that if no SALT attribute is supplied on the INPUT field (zero length or not present), the domain name of the ACTION attribute is used. In this way, you can accomplish those consolidations and divestments between domains?

Using no salt has no value since the same rainbow table can be used as is today.

Using an advertised salt value is insecure if it is static otherwise
it becomes a nonce value. This is then getting very close to what
DIGEST already is, yet that is provided on the protocol level and does
not require manipulating form inputs and so can be provided by apache
mods instead of being bound in the application and requiring
application-level integration.

Using the action binds the service to a specific domain which can not
be changed. I contend that no business will implement this purely from
the imposed lack of deployment flexibility and inability to change.

Thanks,
Cameron Jones

Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

cameronjones
On Thu, Aug 30, 2012 at 8:49 PM, Jason H <[hidden email]> wrote:
>
> 1. It does eliminate rainbow tables. [1] http://en.wikipedia.org/wiki/Rainbow_table#Defense_against_rainbow_tables Mybe the word "eliminate" is too strong but computationally infeasible. You' d have to generate a rainbow table specific to the site as you note, but it takes time and memory to do that. When you double hash it, you move the keyspaces to increcible sizes, 1.7 *10^62 entries, which is 6.3 *10^48 PETAbytes in size.
>

The keyspace may be theoretically large but the volume of used
passwords is relatively small. Attackers generally focus on the top X
number of most common passwords. Generating rainbow tables for the
most popular sites with the most popular passwords is moving to less
than "computationally unfeasible".

> 2. I'm suggesting that HTML5  make it not optional, and we'll get there "eventually". What kind of phishing attack uses the host site? All the ones I know use a copy. No big deal, I enter my password into the phishing site, the HTML5 password protocol kicks in, they get a double-hashed password. Then they have to unhash the first hash (impossible) then unhash that hash (also impossible) then unsalt it (trivial). Only after they perform two impossible steps will they know my password.

Phishing attack will direct users to a fake version of the site, they
can implement this in any way they like as long as it looks like same
site. When the user enters their credentials the phishing site can do
anything it wants with the plaintext, it definitely won't send it
through a one-way hashing algorithm.

>
> 3. If they are already registered and have a server-computed hash, then there are a couple approaches. How the site is configured now will greatly influence the method. The easiest is to add a column to the user table and indicate if it is the new style or not, and continue to apply the corresponding algorithm. This seems overkill unless a user has a 40 character hexadecimal password already, otherwise the software can detect this pattern and know how to use it. The application can then encourage the user to update their password. I would consider this an upgrade path.

HTML *never* implements new features which break existing sites, too
many sites never get updated. The only possibility is to implement new
features and get people to use them, the new features must be
compelling for people to even take the time to know what they are let
alone implement them. Added to this, authentication processes in
servers (good ones) are heavily audited and severely locked down. The
concept of introducing a new password mechanism is logistically
impossible to roll out on a global scale.

>
> It does not mean that the salt is a nonce. Unless we somehow figure out a way to have the entire SHA1 keyspace (which is 6.8 *10^48 petabytes in size) mapped to the hash space  (another 6.8 *10^48 petabytes)  and do the fast look-up it has significant value.
>

The nonce is a value which changes over time to avoid replay attacks,
and rainbow tables. Its way more secure to use than a salt and you get
it for free with mod_digest, no application changes, database changes
or password introspection.

Thanks,
Cameron Jones

Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

Jason H-3
1. That's a very good point. However the attacker needs a list of accounts. I'll assume he has that and the salt, and starts churning away usign the top 1000 most common passwords. What state are we in compared to today? We still do not advise *common* passwords. Thsi is different. No one uses "bob" as a password which is both weak and rare. So as weak as "bob" is, it won't be guessed. Unless he runs though a dictionary, and I put dictionary words in the "common" genre.


2. When this is accepted by he community, I expect browsers to warn the user appropriately that this page does not look legit because it's using old weak mechanisms, just like they do for self-signed certificates now. Phishing sites have limited efficacy now because of the phishing databases built into browsers. If we can highlight suspect pages dur to non-compliance then we'll make some more progess.

3. These features won't break existing sites, but how do you define existing sites? HTML traditionally was for visual layout. If someone makes the DTD of their login page 5.0, then they should have the migration strategy in place. They can continue to serve the 4.01 page until they are ready. 

4. The nonce can still be ignored.  Cracking a single user is hard enough, maybe they can get some low-hanging fruit with common passwords. But over what interval of time do you change the nonce? 1 week, 1 year? With a key space of 1.5 *10^62 entries you can comfortably wait decades. 

5. Mod_digest does nothing for HTML, just HTTP. Who uses HTTP auth? Very few people many more uses application-based authentication. I'm not targeting mod_digest. it works well. People just don't use it. Out of all the services I consume, there is only one site that uses mod_digest and it bring sup that very ugly dialog, that if it doesn't succeed take you to a very lame 401 page.





----- Original Message -----
From: Cameron Jones <[hidden email]>
To: Jason H <[hidden email]>
Cc: Seth Call <[hidden email]>; Thomas A. Fine <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Thursday, August 30, 2012 4:33 PM
Subject: Re: Securing Password Inputs

On Thu, Aug 30, 2012 at 8:49 PM, Jason H <[hidden email]> wrote:
>
> 1. It does eliminate rainbow tables. [1] http://en.wikipedia.org/wiki/Rainbow_table#Defense_against_rainbow_tables Mybe the word "eliminate" is too strong but computationally infeasible. You' d have to generate a rainbow table specific to the site as you note, but it takes time and memory to do that. When you double hash it, you move the keyspaces to increcible sizes, 1.7 *10^62 entries, which is 6.3 *10^48 PETAbytes in size.
>

The keyspace may be theoretically large but the volume of used
passwords is relatively small. Attackers generally focus on the top X
number of most common passwords. Generating rainbow tables for the
most popular sites with the most popular passwords is moving to less
than "computationally unfeasible".

> 2. I'm suggesting that HTML5  make it not optional, and we'll get there "eventually". What kind of phishing attack uses the host site? All the ones I know use a copy. No big deal, I enter my password into the phishing site, the HTML5 password protocol kicks in, they get a double-hashed password. Then they have to unhash the first hash (impossible) then unhash that hash (also impossible) then unsalt it (trivial). Only after they perform two impossible steps will they know my password.

Phishing attack will direct users to a fake version of the site, they
can implement this in any way they like as long as it looks like same
site. When the user enters their credentials the phishing site can do
anything it wants with the plaintext, it definitely won't send it
through a one-way hashing algorithm.

>
> 3. If they are already registered and have a server-computed hash, then there are a couple approaches. How the site is configured now will greatly influence the method. The easiest is to add a column to the user table and indicate if it is the new style or not, and continue to apply the corresponding algorithm. This seems overkill unless a user has a 40 character hexadecimal password already, otherwise the software can detect this pattern and know how to use it. The application can then encourage the user to update their password. I would consider this an upgrade path.

HTML *never* implements new features which break existing sites, too
many sites never get updated. The only possibility is to implement new
features and get people to use them, the new features must be
compelling for people to even take the time to know what they are let
alone implement them. Added to this, authentication processes in
servers (good ones) are heavily audited and severely locked down. The
concept of introducing a new password mechanism is logistically
impossible to roll out on a global scale.

>
> It does not mean that the salt is a nonce. Unless we somehow figure out a way to have the entire SHA1 keyspace (which is 6.8 *10^48 petabytes in size) mapped to the hash space  (another 6.8 *10^48 petabytes)  and do the fast look-up it has significant value.
>

The nonce is a value which changes over time to avoid replay attacks,
and rainbow tables. Its way more secure to use than a salt and you get
it for free with mod_digest, no application changes, database changes
or password introspection.

Thanks,
Cameron Jones


Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

Arthur Clifford
In reply to this post by Jason H-3
Why not request the salt from the server?
The server could choose whether to always use the same salt or to have rotating salts etc. 
The problem with specifying how to encrypt things in a public specification is that everybody knows how it is done, and therefore all you are doing is resetting the timer for hackers to figure things out. There should be something provided by servers that the server knows and trusts.


-Art C


On Aug 30, 2012, at 11:21 AM, Jason H wrote:

Would it appease you if it were suggested that the standard be, that if no SALT attribute is supplied on the INPUT field (zero length or not present), the domain name of the ACTION attribute is used. In this way, you can accomplish those consolidations and divestments between domains?

Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

Jason H-3
I'm trying to accomplish this with as little work on the server side as possible. If we could get proper salting working on the server side as it *should* be, a substantial number of the reasons for this method would be eliminated.

The server still can, and I hope it does, however the goal here is to move it client side and get the server out of it.

Well, we know the method of public key cryptography, it does not make it less numerically secure.  Yes, I am resetting the timer on when they can get it figured out. Right now that time is 0 seconds to oh, say a day. Meanwhile it can take companies several weeks to find, research and announce the breach. That timer moves to a decade in the very least, probably more like 50 years. In a decade, I expect services to crumble (i.e. facebook replaced with something), password policy to require a password change at least once a decade, so no password discovered is still valid by the time it is found.

In addition, with buy-in from browsers it stops phishing. All login pages should be pushed to HTML5, and use this proposed feature, then any page not in compliance is considered insecure, just like self-signed certs are considered insecure now by browsers.




From: Arthur Clifford <[hidden email]>
To: [hidden email]
Sent: Thursday, August 30, 2012 7:19 PM
Subject: Re: Securing Password Inputs

Why not request the salt from the server?
The server could choose whether to always use the same salt or to have rotating salts etc. 
The problem with specifying how to encrypt things in a public specification is that everybody knows how it is done, and therefore all you are doing is resetting the timer for hackers to figure things out. There should be something provided by servers that the server knows and trusts.


-Art C


On Aug 30, 2012, at 11:21 AM, Jason H wrote:

Would it appease you if it were suggested that the standard be, that if no SALT attribute is supplied on the INPUT field (zero length or not present), the domain name of the ACTION attribute is used. In this way, you can accomplish those consolidations and divestments between domains?



Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

cameronjones
In reply to this post by Jason H-3
On Thu, Aug 30, 2012 at 9:55 PM, Jason H <[hidden email]> wrote:
> 1. That's a very good point. However the attacker needs a list of accounts. I'll assume he has that and the salt, and starts churning away usign the top 1000 most common passwords. What state are we in compared to today? We still do not advise *common* passwords. Thsi is different. No one uses "bob" as a password which is both weak and rare. So as weak as "bob" is, it won't be guessed. Unless he runs though a dictionary, and I put dictionary words in the "common" genre.
>

An attacker doesn't need the list of accounts to per-compute a rainbow
table since all of the information is know beforehand and defined by
specification. Using the username within the salt does not add any
additional information so can just be added as a pre-step to the hash
algorithm which already performs multiple passes over the input data.

>
> 2. When this is accepted by he community, I expect browsers to warn the user appropriately that this page does not look legit because it's using old weak mechanisms, just like they do for self-signed certificates now. Phishing sites have limited efficacy now because of the phishing databases built into browsers. If we can highlight suspect pages dur to non-compliance then we'll make some more progess.
>

There is no way for a browser to detect "non-compliant" form usage.
Such use of forms is completely compliant from a standards POV. The
phishing databases are maintained like virus databases and are always
out of date because you can't predict what a virus looks like or how a
phishing site works.


> 3. These features won't break existing sites, but how do you define existing sites? HTML traditionally was for visual layout. If someone makes the DTD of their login page 5.0, then they should have the migration strategy in place. They can continue to serve the 4.01 page until they are ready.
>

You are trying to push a new password mechanism onto sites which is
more complex than just salting their hashes. The technological cost vs
gain is negative. More complex means bugs happen, password management
is best kept as simple as possible. As soon as you are going to change
what password you accept based on what browser or HTML version is
being sent you risk opening new, unknown, security vulnerabilities.
This will never pass security audits.

The security issue behind the use case is a secondary attack vector
after the attacker has already gained access to the system.

> 4. The nonce can still be ignored.  Cracking a single user is hard enough, maybe they can get some low-hanging fruit with common passwords. But over what interval of time do you change the nonce? 1 week, 1 year? With a key space of 1.5 *10^62 entries you can comfortably wait decades.

A nonce is only used once.

>
> 5. Mod_digest does nothing for HTML, just HTTP. Who uses HTTP auth? Very few people many more uses application-based authentication. I'm not targeting mod_digest. it works well. People just don't use it. Out of all the services I consume, there is only one site that uses mod_digest and it bring sup that very ugly dialog, that if it doesn't succeed take you to a very lame 401 page.
>

The proposal on the table exposes HTTP auth direct to HTML thus
bridging the gap and integrating well established security protocols
with a mechanism which can support new schemes in future, is
server-controlled and can be integrated in server mods and does not
require application-level programming.

The method of client-side hashing, does not protect the transfer of
passwords, can not be moved between domains, does not provide greater
cryptographic security and requires complex application-level
integration.

I suggest not trying to reinvent the wheel, build an axle.

Thanks,
Cameron Jones

Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

cameronjones
In reply to this post by Arthur Clifford
On Fri, Aug 31, 2012 at 12:19 AM, Arthur Clifford <[hidden email]> wrote:
> Why not request the salt from the server?

Why would the server implement a salt to be applied on the client
which it can't verify itself?

Server programming is based on the principle that as soon as data
leaves the server it is not to be trusted. HTTP request\repsonse
cycles must essentially be treated independently.

> The server could choose whether to always use the same salt or to have
> rotating salts etc.

They can't change the salt because they don't know what the original
password was to compare against. This suggestion wasn't to protect
transfer but to obscure storage.

> The problem with specifying how to encrypt things in a public specification
> is that everybody knows how it is done, and therefore all you are doing is
> resetting the timer for hackers to figure things out. There should be
> something provided by servers that the server knows and trusts.

Exactly. There is a reason why security folks are cagey.

>
>
> -Art C
>
>

Thanks,
Cameron Jones

Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

Jason H-3
They might be cagey, but they are completely absent in implementation in the storage routines of user credentials for most sites.

Moving security to the browser is much easier because there are less browsers than applications.


From: Cameron Jones <[hidden email]>
> The problem with specifying how to encrypt things in a public specification
> is that everybody knows how it is done, and therefore all you are doing is
> resetting the timer for hackers to figure things out. There should be
> something provided by servers that the server knows and trusts.

Exactly. There is a reason why security folks are cagey.


Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

ownedthx
There is no such thing as moving security to the browser, because it is a client-side application.  If you disagree, OK,  go right ahead... but  this is a server-side mindset and I'd assert you will never, ever win that argument with security-minded folks.

If you want to make it easy to implement server-side code, then by all means contribute to bcrypt (or other good password encryption technology), or language/framework adoption of it.

But in the context of HTML5 and browsers, I can only recommend:

Make end users aware of the importance of passwords. This is the basis of my suggestion, earlier in the thread, on making a standardized way to give users feedback on the strength of their password.

On Fri, Aug 31, 2012 at 9:49 AM, Jason H <[hidden email]> wrote:
They might be cagey, but they are completely absent in implementation in the storage routines of user credentials for most sites.

Moving security to the browser is much easier because there are less browsers than applications.


From: Cameron Jones <[hidden email]>
> The problem with specifying how to encrypt things in a public specification
> is that everybody knows how it is done, and therefore all you are doing is
> resetting the timer for hackers to figure things out. There should be
> something provided by servers that the server knows and trusts.

Exactly. There is a reason why security folks are cagey.



Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

Jason H-3
In reply to this post by cameronjones
1. I don't think you understand how rainbow tables works. As I've shown a salt defeats rainbow tables, meaning you have to rute force it. Even if you know you're going to attack the account of alice on domain.com, you have to start decades earlier to discover any usable portion of the hash table for that domain/user. The odds are astronomical low that you'll get a hash hit.
15 * 10^62, being hashed (I'm using bitcoin mining numbers here) at 525 million hashes/second comes out to be 1 * 10^46 years for the hash table to be complete. If you double hash it, your odds are 1/10,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 that in a year, you'll find a password. I like those odds. Even with computing advances, even if we divide that by 10^23, I still like those odds.

2. The browser has a variety of ways to detect non-compliance, however phishers are crafty, and I don't feel I anyone can fully anticipate the changes. The simplest for me, would be to JS-override the keystrokes so they are captured and submitted seperately. The current use of this is for password strength checking. But the double-hash renders that unnecessary. So we could disallow JS reading or writing of these inputs. And again, the DTD will be V5 so we know when to apply these semantics.

3. I am not trying to push these on sites, I am trying to push this in the browser. The sites will follow. This technique was designed to require minimal changes to the sites as possible, with maximal gain. It is not NEGATIVE. it is substantially better than what we have now. It's beter for the companies and for the users.

It's pretty cool that even with access to the system, that they cannot gain access to my password.

4. A Nonce is used only once, but it's value is changed periodically, generally every time it is used. Based on the math above, I a am comfortable with changing the none every 100 years.

5. And the HTTP auth proposal doesn't require more changes? It in fact requires *substantial* changes to applications, authentication knowledge, and servers. That's moving a mountain. Adoption will be glacial.

SSL already prevents the hash from being snooped, and requires no application changes.

I charge that the digest authentication is more work than the application level changes, and the MitM attacks are moot because we already have SSL. Only applications that both 1) send a  new password and 2) wanting to support the double hash need to modify the login page to v5 DTD, and then tweak the routing to expect the double-hash of their password. Application that just supply a "reset" link work unmodified.



From: Cameron Jones <[hidden email]>
To: Jason H <[hidden email]>
Cc: Seth Call <[hidden email]>; Thomas A. Fine <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Friday, August 31, 2012 10:04 AM
Subject: Re: Securing Password Inputs

On Thu, Aug 30, 2012 at 9:55 PM, Jason H <[hidden email]> wrote:
> 1. That's a very good point. However the attacker needs a list of accounts. I'll assume he has that and the salt, and starts churning away usign the top 1000 most common passwords. What state are we in compared to today? We still do not advise *common* passwords. Thsi is different. No one uses "bob" as a password which is both weak and rare. So as weak as "bob" is, it won't be guessed. Unless he runs though a dictionary, and I put dictionary words in the "common" genre.
>

An attacker doesn't need the list of accounts to per-compute a rainbow
table since all of the information is know beforehand and defined by
specification. Using the username within the salt does not add any
additional information so can just be added as a pre-step to the hash
algorithm which already performs multiple passes over the input data.

>
> 2. When this is accepted by he community, I expect browsers to warn the user appropriately that this page does not look legit because it's using old weak mechanisms, just like they do for self-signed certificates now. Phishing sites have limited efficacy now because of the phishing databases built into browsers. If we can highlight suspect pages dur to non-compliance then we'll make some more progess.
>

There is no way for a browser to detect "non-compliant" form usage.
Such use of forms is completely compliant from a standards POV. The
phishing databases are maintained like virus databases and are always
out of date because you can't predict what a virus looks like or how a
phishing site works.


> 3. These features won't break existing sites, but how do you define existing sites? HTML traditionally was for visual layout. If someone makes the DTD of their login page 5.0, then they should have the migration strategy in place. They can continue to serve the 4.01 page until they are ready.
>

You are trying to push a new password mechanism onto sites which is
more complex than just salting their hashes. The technological cost vs
gain is negative. More complex means bugs happen, password management
is best kept as simple as possible. As soon as you are going to change
what password you accept based on what browser or HTML version is
being sent you risk opening new, unknown, security vulnerabilities.
This will never pass security audits.

The security issue behind the use case is a secondary attack vector
after the attacker has already gained access to the system.

> 4. The nonce can still be ignored.  Cracking a single user is hard enough, maybe they can get some low-hanging fruit with common passwords. But over what interval of time do you change the nonce? 1 week, 1 year? With a key space of 1.5 *10^62 entries you can comfortably wait decades.

A nonce is only used once.

>
> 5. Mod_digest does nothing for HTML, just HTTP. Who uses HTTP auth? Very few people many more uses application-based authentication. I'm not targeting mod_digest. it works well. People just don't use it. Out of all the services I consume, there is only one site that uses mod_digest and it bring sup that very ugly dialog, that if it doesn't succeed take you to a very lame 401 page.
>

The proposal on the table exposes HTTP auth direct to HTML thus
bridging the gap and integrating well established security protocols
with a mechanism which can support new schemes in future, is
server-controlled and can be integrated in server mods and does not
require application-level programming.

The method of client-side hashing, does not protect the transfer of
passwords, can not be moved between domains, does not provide greater
cryptographic security and requires complex application-level
integration.

I suggest not trying to reinvent the wheel, build an axle.

Thanks,
Cameron Jones



12