Re: Securing Password Inputs

Thanks for the feedback.

Reactions:
0. The intent is not to prevent replay attacks (as I understand in this context), but to prevent the obtaining of passwords from user table breaches due to insecure design. The fact that Sony, Yahoo, LinkedIn (big players) cannot get it right shows that the technology overall is failing. We are cursed with different password rules at every site, different lengths (some even implementing max lengths). People resort to software to manage passwords, or worse, give up on security. This is not good.
Could you elaborate on the replay attack you are considering here? 

1. I was relatively appauled at the summary "generally accepted as a non-compelling enhancement as it does not
protect against simple replay attacks." Passwords are essentially useless now, and I think that is compelling enough. Fixing it at the HTTP level may be the right solution, but there's no reason why it can't be layered. It is also easier to accomplish in HTML on an application basis, rather than making everyone upgrade their servers AND applications.

2. I did not suggest the origin as the salt, I suggested the action domain as the salt. They are not necessarily equal. Furthermore changing the action domain is a very rare occurrence, and there are mitigation strategies if it really is that important. (Location header, DNS alias, proxy etc.)

3. Transition from v4 to v5 would be eased if the scheme was adopted for v5, then applications could back-port via javascript the same functionality. Having a simple, clear mechanism like hashing "domain.com:password" for can be trivially done by a standard javascript routine inlcuded in the page, or a browser plugin, or the browser itself. When a v5 page is detected the plugin/browser becomes a no-op. if the javascript technique is used (application supported), then that is moot as well because the application page will be HTML version specific, which will then simply not include the JavaScript function by matter of design.

4. The digest mechanism is an excellent approach in terms of security, but I fear it will be too much work to properly implement. Salting passwords is trivial and we can't even get that out of the big players. As I understand it, all authentication should be over HTTPS anyway. Implementing hased passwords over SSL seems much easier to achieve than both redesigning protocols and servers and applications.

Thank you for your reply, and I look forward to continuing this conversation with you. 




________________________________
 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 10:16 AM
Subject: Re: Securing Password Inputs
 
On Wed, Aug 29, 2012 at 1:05 AM, Jason H <scorp1us@yahoo.com> wrote:
> I must not have been clear. This in no way changes the way server-side
> authentication happens. This only changes what is sent as a "password" to
> the server. The idea when applied would obsolete the "score" because 36^40
> is a very high score. All scores are the same regardless of "bob" or
> "Sdf3er3dSdse32e3dsfsfvbgs" because they are all moved into the hash's
> hashspace (always 40 chars, base 36).
>
> This is NOT an end-user problem. If that is the case then we are out of luck
> when it comes to security because all passwords will be dictionary attack
> vulnerable.
>
> You could do this today for a site in javascript, yes, but the problem with
> that is you're going to have a million algorithms, some not as secure as the
> others, and you have no idea when it is going to be applied. If it goes into
> the HTML spec, then you know it is compliant.
>

I'm not sure what you are stating this achieves, but the idea for
client-side hashing of passwords has been discussed before and was
generally accepted as a non-compelling enhancement as it does not
protect against simple replay attacks. The most recent discussions
have been on the whatwg:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032109.html

The use of the origin as a salt is also not a good approach as the
password is tied to the origin preventing the site from moving domains
or otherwise restructuring their site, domain use or providing single
sign-on across multiple domains.

There is the additional problem of having a mix of html4 and html5
users - the password would either be a hash or plaintext depending on
what browser the user used to login, how can the site reconcile this?

If there is no salt, encrypting the passwords on the client side would
amount to a dictionary translation and still be susceptible to rainbow
tables.

As an alternative solution for sites wanting greater security, there
is a progressing issue in HTML5 for declarative HTTP authentication
within forms. This allows sites to provide HTML interfaces for
capturing credentials which are then encoded by the browser into
either BASIC or DIGEST headers. These authentication schemes employ
either simple base64 encoding against trivial password sniffing, or
with DIGEST there is proper cryptographic hashing using nonce values.
Sites employing these authentication schemes will exhibit the
enhancement to security you are looking for. Mandating the use of
crypto hashing for all passwords is not possible and, as always with
security, users must apply prudence to the sites they interact with
and credentials they use or give out as a matter of explicit trust and
self defense.

The issue is tracked here:

http://www.w3.org/html/wg/tracker/issues/195

Thanks,
Cameron Jones