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.
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. 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. 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. 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. ________________________________ From: Cameron Jones <[email protected]> To: Jason H <[email protected]> Cc: Seth Call <[email protected]>; Thomas A. Fine <[email protected]>; "[email protected]" <[email protected]> Sent: Friday, August 31, 2012 10:04 AM Subject: Re: Securing Password Inputs On Thu, Aug 30, 2012 at 9:55 PM, Jason H <[email protected]> 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
