Re: Securing Password Inputs

On Thu, Aug 30, 2012 at 9:55 PM, Jason H <scorp1us@yahoo.com> 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

Received on Friday, 31 August 2012 14:05:16 UTC