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:33:47 UTC