Re: Securing Password Inputs

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 <cmhjones@gmail.com>
To: Jason H <scorp1us@yahoo.com>
Cc: Seth Call <sethcall@gmail.com>; Thomas A. Fine <fine@head.cfa.harvard.edu>; "public-html-comments@w3.org" <public-html-comments@w3.org>
Sent: Thursday, August 30, 2012 4:33 PM
Subject: Re: Securing Password Inputs

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

Received on Thursday, 30 August 2012 20:56:15 UTC