[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] The problem of visible hashes for protection keys
From a quick read of the Wikipedia entry, and some of the references, it seems that increasing the hash output size actually causes a Rainbow table to become _more_ effective, not less. Seems that collisions play havoc with Rainbow tables, though there are modern techniques that reduce the chance of a collision actually being a problem. And collisions aren't really a big problem for most passwords given a modern hashing algorithm. Most user-chosen passwords would fit into upper and lower case alpha, plus numbers, assume a length of 10 characters. There's only 59 bits of total keyspace there, well below the 160-bit keyspace of sha-1, making the chance of a collision neglible, even if sha-1 deteriorates to something smaller. To even start to see collisions, you need to be dealing with full-keyboard character sets, and password lengths up around 22 characters, _and_ they have to have not reduced entropy by including words. This means that collisions weren't a problem to start with, so going to sha-256 is fixing part of the problem that isn't broken. It is nice to use hashing algorithms that are recommended by NIST, the EU, etc, so there is some value in using sha-256, but it doesn't help protect the password at all. Oddly enough, a really bad hash can be of some benefit if you're attempting to protect the password. If you have a lot of collisions, you may find _a_ password that works, but perhaps not _the_ password that we started with. Another aspect of the hash length problem is to consider this - a sha-256 hash might be around 2-4x slower to compute than a sha-1 hash. A single hash brute-force attack can get up around 100 million cracks/second. This means an 8-character all lower case password would fall in 15 minutes on average, 30 minutes max. If you can drive down the cracks/sec by using an iterated hash, you can remove much of the attacker's ability to run computations in parallel, and get the crack rate down to around 10,000 hashes/second. This would hold up for an average of 120 days. Add in sufficient salt, and you remove the Rainbow table attack as well. My recommendation is to use a real key derivation function to create a password verifier. It can be a bit of a problem to deal with versioning - if you change this, then an older version of the software obviously cannot verify the password. However, due to the severity of disclosing passwords, I'd tend to recommend against implementing a feature that exposes passwords in that manner. Just how widespread is this past usage? I do not recall seeing it in the v1.1 spec, but I may have missed it. If this is something new to this version, I'd strongly recommend doing it right, even if there are existing implementations. ________________________________________ From: David LeBlanc [dleblanc@exchange.microsoft.com] Sent: Saturday, October 30, 2010 2:57 PM To: dennis.hamilton@acm.org; 'ODF TC List' Subject: RE: [office] The problem of visible hashes for protection keys I don't believe increasing the length of the hash significantly helps a rainbow table attack. I'll ask some of the cryptographers and find out. Dennis is quite correct that it isn't what the password protects, but the password itself that is of value. Sent from my phone, but I might be verbose - I have a keyboard... -----Original Message----- From: Dennis E. Hamilton <dennis.hamilton@acm.org> Sent: Saturday, October 30, 2010 1:11 PM To: David LeBlanc <dleblanc@exchange.microsoft.com>; 'ODF TC List' <office@lists.oasis-open.org> Subject: RE: [office] The problem of visible hashes for protection keys Right. We use unsalted SHA1 hashes (but not in the encryption methods) in our password verifiers for sheet protection, write protection, etc. Since folks want to *keep* using their memorable passwords and have been frightened about stories concerning hash collisions, we agreed to recommend SHA256 instead of SHA1. That pandering has it appear that we have accomplished something concerning the confidentiality of those passwords. (Elsewhere, I equate this to security theater.) - Dennis PS: The more-complicated worries about the ODF 1.x encryption method is that, along with its complexity (always a warning sign) is the fact that information about the plaintext is leaked in a way that can reveal high-value documents and also exposes known-plaintext attacks on those document, especially considering that the document is durable and an attacker may have a significant amount of time to carry out an attack. This is a speculative risk, but I assume prudence dictates finding a method that does not have such fragility as a concern. -----Original Message----- From: David LeBlanc [mailto:dleblanc@exchange.microsoft.com] Sent: Saturday, October 30, 2010 12:15 To: dennis.hamilton@acm.org; ODF TC List Subject: RE: [office] The problem of visible hashes for protection keys [ ... ] Any time you want to store a password verifier, for example to be used with sheet protection, write protection, etc, PBKDF2 should be used with a good hash, a large iteration count, and a large, random salt. Not using salt is what leads to the attacks listed in the URL below. ________________________________________ From: Dennis E. Hamilton [dennis.hamilton@acm.org] Sent: Saturday, October 30, 2010 11:48 AM To: ODF TC List Subject: [office] The problem of visible hashes for protection keys We know that, using XML documents, it is easy to subvert a lock on text or spreadsheet documents that involves locking material against changes (but not reading). When the lock is itself locked against removal using a password hash, this exposes the password used for the hash to compromise. The problem is the desire by folks to reuse familiar, memorable passwords for this purpose when the memorable password is also used to protect something that is of serious high value. (That is to say, the password is more valuable than the trivial-to-break lock in the document.) Some bad news: < http://www.ciozone.com/index.php/Security/Cracking-14-Character-Complex-Pass words-in-5-Seconds.html> Note that memorable passwords are not the hard ones to crack, and increasing the strength of the hash will not do much to protect memorable passwords from discovery against this kind of computational power. Note: This attack does not work against the PBKDF2 methods used for ODF 1.2 encryption, because the start password is never revealed. On the other hand, the techniques by which the password-hash attack were accelerated so much is probably a reason for concern that the various vulnerabilities of the ODF 1.2 encryption will be too-soon exploitable as a practical matter. My personal assumption is that no well-informed government body or commercial entity that is concerned about document confidentiality will allow use of the ODF 1.x encryption and would require very strong whole-package encryption techniques, whether defined for ODF documents or not. In that regard, the ETSI draft that we have been asked to comment on has moved ahead of us in the level of confidentiality-by-encryption that it attains for Zip-packaged documents. - Dennis Dennis E. Hamilton ------------------ NuovoDoc: Design for Document System Interoperability mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]