- From: Cameron Jones <cmhjones@gmail.com>
- Date: Fri, 31 Aug 2012 18:13:21 +0100
- 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>
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