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
|

Re: Securing Password Inputs

Jason H-3
In general you are right, however the security minded people are absent in application programming. Are these the same people who developed HTTP Auth:BASIC?

What we're talking about here isn't JS validation or parameter sanitation, it is merely that whatever password inputs you get will be pre-hashed. It is opaque to the server and application for the most part. The only issue are services that supply a new password during password reset. In these situations, a reset link is even easier, or the application can be modified to accept the double-hashed version of the password.

Currently, these passwords are sent in plain text and stored in plain text or unsalted hash. 


From: Seth Call <[hidden email]>
To: Jason H <[hidden email]>
Cc: Cameron Jones <[hidden email]>; Arthur Clifford <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Friday, August 31, 2012 11:02 AM
Subject: Re: Securing Password Inputs

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

cameronjones
In reply to this post by Jason H-3
On Fri, Aug 31, 2012 at 3:49 PM, 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.
>

You're attempting to paint everyone with the same stick. Those same
security folks are the ones who came up with the cryptographic
techniques and SSL your attempting to lean on.


On Fri, Aug 31, 2012 at 4:31 PM, Jason H <[hidden email]> wrote:

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

A salt does not "defeat" rainbow tables, it just renders the current
ones obsolete. Rainbow tables are an algorithmic cache, the values
have just already been computed.

In this case, the attacker is not attempting to target specific
individuals, they are attempting to collect username\password
combinations for use on other services because people typically reuse
the same passwords across many sites.

If the salting algorithm is known the attacker can just generate new
rainbow tables with each username based on the top passwords and have
a relatively high success rate.

If a site you use is hacked the best thing to do is change your
password, nothing will stop that. Before you even get to that point,
don't use predictable passwords and your security is up in the top
percentile.

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

A phishing site would not use a password field, send via a form or
even use HTML5.

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

The concept of having a non-readable password is good and that's why
people already hash them for storage.

The "upgrade path" you suggest is based on having original and
client-hashed passwords on file, so where is the benefit?

HTML5 pages served to HTML4 clients will not pre-hash the password and
send it plaintext as they currently do, so this won't just magically
disappear.

Having to change their authentication system for a company which
already salts passwords is not something which i expect them to
embrace.

You can't force good security practice, if people leave windows and
doors open then that is their prerogative and your choice as a
consumer as to if you want to liaise with such an organization.

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

It is changed on every use, that's the point of it.

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

Well, digest isn't going to do what you want anyway as it's only for
protecting transfer. At the end of the pipe the password is translated
back to plaintext, just with the knowledge that nobody read it,
changed it or replayed it along the way.


On Fri, Aug 31, 2012 at 4:39 PM, Jason H <[hidden email]> wrote:
> In general you are right, however the security minded people are absent in
> application programming. Are these the same people who developed HTTP
> Auth:BASIC?

There's nothing wrong with BASIC, you assume all sites need bank-level
security. Simple web forums where the only risk of breech is someone
posts something impersonating you is about as bad as it gets and they
shouldn't have to deal with unnecessary overhead.

> What we're talking about here isn't JS validation or parameter sanitation,
> it is merely that whatever password inputs you get will be pre-hashed. It is
> opaque to the server and application for the most part. The only issue are
> services that supply a new password during password reset. In these
> situations, a reset link is even easier, or the application can be modified
> to accept the double-hashed version of the password.

There are a few more issues that that, as we have discussed.

Thanks,
Cameron Jones

Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

Jason H-3
1. "just generate new rainbow tables with each username based on the top passwords and have a relatively high success rate."
Well, I understand your point, but I take issue with "just" and "high success rate". It is true that hashing common passwords is always going to be easy, so password security is never going to be without the aspect of "choose something not common". If we look at the linkin breach, we see that the top 30 passwords accounted for about 4000 users out of 6.5 million. The 30th most common password was shared with 24 individuals. In a short amount of time, 160,000 passwords were recovered (2%) by hashing weak passwords, eventually 5% were recovered. These were from UNSALTED SHA1 hashes. (http://www.zdnet.com/blog/btl/linkedin-password-breach-how-to-tell-if-youre-affected/79412) The presence of unsalted SHA1 hash databases made finding the uncommon passwords easier.

2. "A phishing site would not use a password field, send via a form or even use HTML5." Which is why we should warn the user that 1) It's not using a password field
2) using a form
3) and not using HTML5
because those are phishing site fingerprints.

3. A hashed password is good for storage as both you and I have shown. But this is made better if it is double-hashed and salted.

In fact, I was not ready to talk about it, but a minor incremental improvement to the algorithm is if we repeatedly hash it some unknown number of times. Then what is stored server side is one of those hash iterations. The double-hash is the most important,  but repeatedly hashing it then storing it. This does not increase they keyspace of the attack - if a complete keyspace were known, it'd be trivial. However it does change one thing slightly. The attacker does not know how many times he'll have to un-hash the password. That is, if he successfully implements an unhash function (be it dictionary lookups or whatever) the result is another hash. He has a choice now -  move on to another user or continually unhash the hashes until he gets to something like a password. (The funny part here is, if someone uses a hash as their password, he would loop right past it. I find that immensely humorous. Anyway...)  We can easily hash 100-times. We don't even need to know exactly how many iterations we need, just that we'll eventually come across it. Example: we send my double hash to the server, the server stores 98 iterations of this hash. I login, it starts with the double hash and continues to hash until it finds it. It of course matches in the 98th iteration, which is good because the 100th iteration is the cut off for a wrong password. No two accounts need to use the same number of iterations either.

An in the case that computing power increases, we can change the average iteration and max iteration accordingly, WITHOUT regard to the existing user passwords. Say avg=90 and max=100 , in three years, we can up that to 250 and 300, and the old user entries work, they just get matched quicker.  This introduction of an unknown hash iteration really complicates things. True, common passwords will still be discovered but they can be made "X" times slower where X is the hash iteration average. We can change X at any time, and tune X to the hardware available to both the application and the hackers. If say, we have an average of 86400 user logins per day, and an average response time of 1 second, and we want to be really secure, then we can use one of those GPU accelerated hash algorithms that does 525 million hashes a second. We then know, that an attacker will spend 1 second per password attempt to get the right password if it a common one.  A simple wordlist runs about 50k entries. Let's  assume a complex word list round that up to 86400. So the hacker will spend all day going over a dictionary for one user assuming he knows to try 525million hashes. That's a significant cost. And if he doesn't know the exact number and falls short, stopping at 500 million hashes, he will never ever find it. If he chooses 600million hashes then he is penalized 75 million hashes for every wrong guess. And he'll be making a wrong guess a very substantial part of the time. This is the ultimate mathematical control we can wield over attackers. We can be even so lazy to maintain that variable that our software adds 1000 hashes a day, so it just remains secure over time.

Once the infrastructure is installed to handle the double-hash, we only need to ever change X. We could skip the double-hash and install just the X logic if we could trust everyone, but we can't. 

One more idea I was playing with along with X lines, was what if the client had its own X as well? Suppose I drop the double-hash, and went X-hash as well. We'd get the benefits of X both server and client side. But there is a complication in that my phone, my laptops (home, work etc) and any borrowed computer would have to know what X to send from the client side. While some browsers are now capable of that, I am not ready to recommend anything more than a double hash at this time. Let me call the client X-hash iteration "W". That is W+X the total iteration count for the stored hash. Now, W must be less than the invalid password iteration threshold. We then have only one rule: W<=Z. (Where Z is max iteration count - the invalid password cut-off) We can come up with all kinds of ways to determine W. But what this does is some amount of processing is done on the client, and then some more processing is done on the server to match the credential. Mobile clients can choose a small W, (min=2, max=100?) laptops and desktops can be much larger. The server must be the biggest of them all, but never smaller than the largest client value. People much smarter than myself can make these determinations, however for example purposes, if we assume a function of months since Jan 1 1970, e.g. months_since^2, and a slightly faster function for the server, (months_since^2.01)+(months_since*GPU) we can be assured that W<=Z. Incidentally for these functions today, we would be adding 1025 client hash iterations a month to a base of 262,144, the server would have 16,874 hash iterations to add to the client's. I added a term for those who want to add some more hashes if you use a GPU Anyway, returning from that example, we have substantially stepped up hashing troubles for the hackers. Hashes observed in transit must be matched by hashing to the client maximum, or found first. As the function grows exponentially they have to add hardware exponentially to match it. Now the low hanging fruit becomes the oldest insecure passwords. Did I mention under guessing is completely penalized? :-) . The cool thing that also comes out is as the Z is increased, sites can bump-hash the oldest passwords, to keep them from getting too old. That is, take the hash, and add 100,000 iterations to it monthly. Now you have a user database that can always be up to-the-day secure.

... <skipping some>

6. I wish that we could have bank-level security everywhere, for free. I think it is a mistake to assume that banks are the most valuable and other sites not. Values change over time. My facebook account and twitter accounts are relatively worthless when they started. They are somewhat meaningful now. We can't assume our values won't change, therefore, I want to give everything the best security for the cheapest cost.


Thank you for the dialog and have a great weekend. I'll be back on Monday.






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 1:13 PM
Subject: Re: Securing Password Inputs

On Fri, Aug 31, 2012 at 3:49 PM, 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.
>

You're attempting to paint everyone with the same stick. Those same
security folks are the ones who came up with the cryptographic
techniques and SSL your attempting to lean on.


On Fri, Aug 31, 2012 at 4:31 PM, Jason H <[hidden email]> wrote:

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

A salt does not "defeat" rainbow tables, it just renders the current
ones obsolete. Rainbow tables are an algorithmic cache, the values
have just already been computed.

In this case, the attacker is not attempting to target specific
individuals, they are attempting to collect username\password
combinations for use on other services because people typically reuse
the same passwords across many sites.

If the salting algorithm is known the attacker can just generate new
rainbow tables with each username based on the top passwords and have
a relatively high success rate.

If a site you use is hacked the best thing to do is change your
password, nothing will stop that. Before you even get to that point,
don't use predictable passwords and your security is up in the top
percentile.

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

A phishing site would not use a password field, send via a form or
even use HTML5.

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

The concept of having a non-readable password is good and that's why
people already hash them for storage.

The "upgrade path" you suggest is based on having original and
client-hashed passwords on file, so where is the benefit?

HTML5 pages served to HTML4 clients will not pre-hash the password and
send it plaintext as they currently do, so this won't just magically
disappear.

Having to change their authentication system for a company which
already salts passwords is not something which i expect them to
embrace.

You can't force good security practice, if people leave windows and
doors open then that is their prerogative and your choice as a
consumer as to if you want to liaise with such an organization.

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

It is changed on every use, that's the point of it.

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

Well, digest isn't going to do what you want anyway as it's only for
protecting transfer. At the end of the pipe the password is translated
back to plaintext, just with the knowledge that nobody read it,
changed it or replayed it along the way.


On Fri, Aug 31, 2012 at 4:39 PM, Jason H <[hidden email]> wrote:
> In general you are right, however the security minded people are absent in
> application programming. Are these the same people who developed HTTP
> Auth:BASIC?

There's nothing wrong with BASIC, you assume all sites need bank-level
security. Simple web forums where the only risk of breech is someone
posts something impersonating you is about as bad as it gets and they
shouldn't have to deal with unnecessary overhead.

> What we're talking about here isn't JS validation or parameter sanitation,
> it is merely that whatever password inputs you get will be pre-hashed. It is
> opaque to the server and application for the most part. The only issue are
> services that supply a new password during password reset. In these
> situations, a reset link is even easier, or the application can be modified
> to accept the double-hashed version of the password.

There are a few more issues that that, as we have discussed.

Thanks,
Cameron Jones


Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

cameronjones
On Fri, Aug 31, 2012 at 8:51 PM, Jason H <[hidden email]> wrote:
> ...
[snip]

Jason, you're very good at ignoring points and steamrolling ahead. You
missed this point which effectively illustrates that what you want to
achieve impossible:

On Fri, Aug 31, 2012 at 6:13 PM, Cameron Jones <[hidden email]> wrote:
>
> The "upgrade path" you suggest is based on having original and
> client-hashed passwords on file, so where is the benefit?
>

Thanks,
Cameron Jones

Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

Arthur Clifford
While I think that securing password iinputs is a good idea in principal I don't think it is an HTML problem it is more a browser problem.

Passwords should never be sent in plain text, and should be sent via SSL so that the transfer is encrypted. The problem then is how is the password stored in memory having been entered and prior to transfer to the server.

It would be nice if the browser did encrypt password fields in some 2-way encryption scheme so that the browser could decrypt it prior to sending it via ssl to the server. However, I would not broadcast what encryption it is using by including anything in HTML which anybody can read by viewing source or using the developer tools now in every browser.

I would also not have any hashing or any other encryption algorithm in JavaScript for the same reason. Anything done client side is painfully visible.

The only way protecting the password fields through any new algorithm would be reliable is if a) the user-agents do not use one but multiple undocumented encryption routines and choose which to use by some super secret algorithm that changes with some regularity perhaps between browser updates. b) it becomes impossible for js, plugin, or other non browser-developer to have programmatic or developer tool access to the password input fields.

In fact, there may be justification for something called a SecureForm in which case all inputs are locally encrypted and completely unavailable to anything other than an ssl stream during a post to a target script.  If the HTML 5 spec included such a form then it should not specify the encyrption method but rather suggest it is up to the user-agents to provide encryption and perhaps recommend some good practices.  It would also suggest something like a noscript tag, perhaps nosecureform ,that would allow you to put up a message saying that your page requires an HTML 5 browser for security purposes thus addressing people who insist on using IE 6.

Any other solution seems convoluted and absurd and too in-plain-sight to be viable.

Art C


Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

Arthur Clifford
> This isn't about securing them for transport, this is only how to store them in a way such that the effects of a breach are negligible, eliminating phishing and coming up with a more consistent password solution.


Like much of the HTML spec and the conversations on this list I think this conversation is trying to go in a couple directions at the same time and yielding typically wierd mishmash of ideas.

A "consistant" password solution is an oxymoron. If everybody is doing the same thing then you have simplified the problem space for a hacker. This is like asexual vs sexual reproduciton. asexual reproduction is more efficient but if a disease affects one organism it will wipe out all of them. Only by mixing things up and causing mutations and randomization do you have some hope of protection and longevity.

Furhtermore, whatever you do, you don't want to encode it in an html page and/or javascript.  The reason why server side solutions are preferred is because it is significantly more complicated to look at the traffic,internals, or scripts on a server than it is in a client especially in the age of developer tools.

My point was that the time in need of protection is the point between data entry and submission. Because it is then that a password is vulnerable.

I honestly think the password stuff is more an OS keychain level problem than an HTML problem. I recommend you check out 1password or similar software as a model and recommend adapting the relationship between OS, browser, and server via whatever protocols are involved.

User agents can adopt some password protection schema, but ultimately if the passwords are retrievable by anything other than whatever is posting content to a server it doesn't matter what you do.

To be clear, I think the conversation is important. But it probably needs to be split into specific threads and distributed to appropriate lists.
 


Art C


On Aug 31, 2012, at 3:53 PM, Jason H wrote:

> This isn't about securing them for transport, this is only how to store them in a way such that the effects of a breach are negligible, eliminating phishing and coming up with a more consistent password solution.
>
>
>
>
> ----- Original Message -----
> From: Arthur Clifford <[hidden email]>
> To: [hidden email]
> Cc:
> Sent: Friday, August 31, 2012 6:35 PM
> Subject: Re: Securing Password Inputs
>
> While I think that securing password iinputs is a good idea in principal I don't think it is an HTML problem it is more a browser problem.
>
> Passwords should never be sent in plain text, and should be sent via SSL so that the transfer is encrypted. The problem then is how is the password stored in memory having been entered and prior to transfer to the server.
>
> It would be nice if the browser did encrypt password fields in some 2-way encryption scheme so that the browser could decrypt it prior to sending it via ssl to the server. However, I would not broadcast what encryption it is using by including anything in HTML which anybody can read by viewing source or using the developer tools now in every browser.
>
> I would also not have any hashing or any other encryption algorithm in JavaScript for the same reason. Anything done client side is painfully visible.
>
> The only way protecting the password fields through any new algorithm would be reliable is if a) the user-agents do not use one but multiple undocumented encryption routines and choose which to use by some super secret algorithm that changes with some regularity perhaps between browser updates. b) it becomes impossible for js, plugin, or other non browser-developer to have programmatic or developer tool access to the password input fields.
>
> In fact, there may be justification for something called a SecureForm in which case all inputs are locally encrypted and completely unavailable to anything other than an ssl stream during a post to a target script.  If the HTML 5 spec included such a form then it should not specify the encyrption method but rather suggest it is up to the user-agents to provide encryption and perhaps recommend some good practices.  It would also suggest something like a noscript tag, perhaps nosecureform ,that would allow you to put up a message saying that your page requires an HTML 5 browser for security purposes thus addressing people who insist on using IE 6.
>
> Any other solution seems convoluted and absurd and too in-plain-sight to be viable.
>
> Art C


Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

Thomas A. Fine
In reply to this post by Jason H-3
Let's reset.

Where can passwords be compromised?

Step 1. Data entry.  Passwords can be trapped by key loggers, and
various other nefarious attacks like shared libraries and things that
take over the kernel or some part of the application.  HTML can not fix
anything here.

Step 2. Data transmission.  Passwords can be intercepted as they travel
over the computer network.  SSL takes care of this.  If a developer
fails to use HTML for password entry forms, any kind of hashing method
used on the client end will be useless, as the evildoer will get to see
whatever it is that is needed for login, whether that thing is a thing
that is clear text or has been hashed once or a million times.  Whatever
it is they can see it and use it.

Step 3. Data storage.  I think this is what you have been worrying
about.  Dumb developers store the password as transmitted to them, so
that if hackers manage to steal their database, they get all these
usernames and passwords.  Worse, most of them will most likely work as
is on other websites.

The correct fix is for the developer to stop storing plain passwords,
and store a hash instead.  This way if hackers get the stored passwords,
they are only useful if the hacker can manage to invert the hash.
Depending on the hashing algorithm this may or may not be feasible.  But
here's the critical part.  If the hacker can not invert
the hash, these password hashes are useless.  They can not be used to
login here ore anywhere else.

What you are proposing is that, in case developers are too stupid to do
things correctly, the client performs some kind of hash prior to
transmitting the password.  The first problem here (compared to the
correct solution) is that the hash no longer provides protection,
because now the hash itself can be used to log in.  In the correct
solution, the real password must be sent to login.  In your proposed
band-aid, the hash can be used to log in.  All you've done is create a
new password of a different form.  It's just as vulnerable as ever
during steps one and two above.  During step one when the user enters
their real password, a hacker can watch the web browser perform the
hash, and then grab the hash from memory.  A hacker can also grab the
hash during step two, transmission.  And in both cases, it can be used
to log in to the website, just as a plain text password could be.  This
is no better than the plaintext passwords stored in clear text on the
server.

But you say the server could hash the hash before it stores it.  True,
but if they knew to do that, then they would have known to do it with
the plain text password and the problem you are trying to solve doesn't
exist at all.

You also point out that instead of just hashing the password you could
hash user:password:domain, and this would prevent hackers from being
able to notice two users with the same password (because user is
hashed), or from using this password on another domain (because server
domain is hashed).  But how would this be implemented in HTML.  First,
you can't actually just use the domain.  We have a server that answers
to foo.com, bar.com, www.foo.com, www.bar.com, and www.foo.bar.com.  So
if the user logs in once from one domain, then their password won't work
from the other?  The only feasible fix is to add a HTML attribute that
lets the web developer specify a value for "domain" in the hashed
string.  But what if they don't because they're a dumb developer?  A
smart developer is already hashing the password so we don't care about
them.  The dumb developer will screw this up too, and you end up with
some default which will either break their site if accessed by more than
one domain, or fail to give any cross-site password reuse protection
(e.g if the default domain is the empty string).

The situation is the same for the user.  How does the web form know what
the user name is?  You have to specify an attribute in the HTML of
another form field to pull this from.  You can't realistically suggest
that some hackish guess of looking for fields named "user", "name",
"login", "email", etc. be an established part of the HTML standard. So a
dumb developer will skip this step, and lose the protection here too.

Your proposed goal as I understood it was to protect passwords even on
sites written by dumb developers.  The problem is, the solution is
unworkable.  Even if by some miracle a developer was smart enough to use
this new hash setup correctly specifying the user field and domain and
hashing algorithm to use, you still have a "solution" which is not as
good as the developer who simply hashes the passwords at the server end.

To reiterate, hashing on the server end requires the hacker to enter a
string that is different than what is stored in the database.  Hashing
on the client end allows the hacker to use the string stored in the
database for login.  The rest of what you've said is just useless
obfuscation.

It's just not possible to legislate away stupidity.

      tom


Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

Jason H-3
That's a pretty good summary, though I think it needs a few corrections.
1. My original proposal is just to hash passwords on the client side. The extended hashing  on the server side is something that can be done later. The important bit here is that it is transparent to the server if it is prehashed or not. Either way the attacker has to defeat at least 2 hashes. The proper solution is to still salt and hash what you got from the browser.

2. As you point out if you are serving two domains this can cause a problem that an attribute is needed to fix. However this is only the case if the POST action needs to be accessible both domains. If you are on bar.com and use "http://foo.com/login.php"  as your action then you have already solved the problem. I expect this to be the case for aliased domains.

3. As the problem exists, even at large sites, the education factor is not winning. I should be able to know my passwords are stored properly. With this feature I can know that. As it stands now I do not know until after a breach, and after the company acknowledges the breach. It took LinkedIn long enough (hours) that by the time it was acknowledged 160,000 accounts were compromised.

4. This sucks and someone needs to do something about it. The browser people have been very pro-active and there are far fewer browser platforms (Opera, IE, Chrome(webkit), Safari(webkit), Firefox (gecko)) than there are websites to screw this up. That's why I am advocating a client-side approach.




From: Thomas A. Fine <[hidden email]>
To: [hidden email]
Sent: Monday, September 3, 2012 9:44 PM
Subject: Re: Securing Password Inputs

Let's reset.

Where can passwords be compromised?

Step 1. Data entry.  Passwords can be trapped by key loggers, and various other nefarious attacks like shared libraries and things that take over the kernel or some part of the application.  HTML can not fix anything here.

Step 2. Data transmission.  Passwords can be intercepted as they travel over the computer network.  SSL takes care of this.  If a developer fails to use HTML for password entry forms, any kind of hashing method used on the client end will be useless, as the evildoer will get to see whatever it is that is needed for login, whether that thing is a thing that is clear text or has been hashed once or a million times.  Whatever it is they can see it and use it.

Step 3. Data storage.  I think this is what you have been worrying about.  Dumb developers store the password as transmitted to them, so that if hackers manage to steal their database, they get all these usernames and passwords.  Worse, most of them will most likely work as is on other websites.

The correct fix is for the developer to stop storing plain passwords, and store a hash instead.  This way if hackers get the stored passwords, they are only useful if the hacker can manage to invert the hash. Depending on the hashing algorithm this may or may not be feasible.  But here's the critical part.  If the hacker can not invert
the hash, these password hashes are useless.  They can not be used to
login here ore anywhere else.

What you are proposing is that, in case developers are too stupid to do things correctly, the client performs some kind of hash prior to transmitting the password.  The first problem here (compared to the correct solution) is that the hash no longer provides protection, because now the hash itself can be used to log in.  In the correct solution, the real password must be sent to login.  In your proposed band-aid, the hash can be used to log in.  All you've done is create a new password of a different form.  It's just as vulnerable as ever during steps one and two above.  During step one when the user enters their real password, a hacker can watch the web browser perform the hash, and then grab the hash from memory.  A hacker can also grab the hash during step two, transmission.  And in both cases, it can be used to log in to the website, just as a plain text password could be.  This is no better than the plaintext passwords stored in clear text on the server.

But you say the server could hash the hash before it stores it.  True, but if they knew to do that, then they would have known to do it with the plain text password and the problem you are trying to solve doesn't exist at all.

You also point out that instead of just hashing the password you could hash user:password:domain, and this would prevent hackers from being able to notice two users with the same password (because user is hashed), or from using this password on another domain (because server domain is hashed).  But how would this be implemented in HTML.  First, you can't actually just use the domain.  We have a server that answers to foo.com, bar.com, www.foo.com, www.bar.com, and www.foo.bar.com.  So if the user logs in once from one domain, then their password won't work from the other?  The only feasible fix is to add a HTML attribute that lets the web developer specify a value for "domain" in the hashed string.  But what if they don't because they're a dumb developer?  A smart developer is already hashing the password so we don't care about them.  The dumb developer will screw this up too, and you end up with some default which will either break their site if accessed by more than one domain, or fail to give any cross-site password reuse protection (e.g if the default domain is the empty string).

The situation is the same for the user.  How does the web form know what the user name is?  You have to specify an attribute in the HTML of another form field to pull this from.  You can't realistically suggest that some hackish guess of looking for fields named "user", "name", "login", "email", etc. be an established part of the HTML standard. So a dumb developer will skip this step, and lose the protection here too.

Your proposed goal as I understood it was to protect passwords even on sites written by dumb developers.  The problem is, the solution is unworkable.  Even if by some miracle a developer was smart enough to use this new hash setup correctly specifying the user field and domain and hashing algorithm to use, you still have a "solution" which is not as good as the developer who simply hashes the passwords at the server end.

To reiterate, hashing on the server end requires the hacker to enter a string that is different than what is stored in the database.  Hashing on the client end allows the hacker to use the string stored in the database for login.  The rest of what you've said is just useless obfuscation.

It's just not possible to legislate away stupidity.

    tom




Reply | Threaded
Open this post in threaded view
|

Re: Securing Password Inputs

Thomas A. Fine
On 9/4/12 9:31 AM, Jason H wrote:
> That's a pretty good summary, though I think it needs a few corrections.
> 1. My original proposal is just to hash passwords on the client side.
> The extended hashing on the server side is something that can be done
> later. The important bit here is that it is transparent to the server if
> it is prehashed or not. Either way the attacker has to defeat at least 2
> hashes. The proper solution is to still salt and hash what you got from
> the browser.

But it is pointless.  You still can't force the developer to do an extra
round of hashing.  All you've accomplished is substituting one clear
text password for a different clear text password.  If a hacker steals
the stored password that was only hashed on the client, it is exactly as
good as a stored password that was not hashed at all on the client.  If
you are envisioning a future where all passwords are sent hashed and all
browsers conform to this behaviour, this still does not prevent hackers
from writing software that does not adhere to this standard so that they
can use the hashed password directly.  You gain nothing at all.

> 4. This sucks and someone needs to do something about it. The browser
> people have been very pro-active and there are far fewer browser
> platforms (Opera, IE, Chrome(webkit), Safari(webkit), Firefox (gecko))
> than there are websites to screw this up. That's why I am advocating a
> client-side approach.

I agree that it sucks.  There are many technological solutions available
but all of these things are only useful in the hands of developers that
actually know (and care about) what they are doing.  Apple, Google,
Facebook, and Twitter are all well-positioned for providing
off-the-shelf third party authentication solutions, and to varying
degrees they are all making moves in that direction.  The compelling
motivation for customers is actually simplified logins rather than
improved security, but the improved security will happen given the
reputations of these big companies.  Personally, I have some privacy
concerns there as these entities become increasingly "Big-Brother-ish".
  But it's the most likely path out of the mess you're looking at.

        tom

12