Re: Securing Password Inputs

On Fri, Aug 31, 2012 at 3:49 PM, Jason H <scorp1us@yahoo.com> 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 <scorp1us@yahoo.com> 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 <scorp1us@yahoo.com> 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

Received on Friday, 31 August 2012 17:13:48 UTC