On Nov. 16th, ElcomSoft (Vladimir Katalov) posted a notice on Bugtraq with the above title. The document shows how to reduce the effort needed for an attack on the key based on a flaw in the design of the database format.
Arguably the best way to generate a password (passphrase) that's difficult to attack but still easy to use is "diceware words". See <http://world.std.com/~reinhold/diceware.html>.
The main problem I have with Elcomsoft's finding is how to describe it accurately, yet clearly enough, so that its implications are clearly understood. I'll do my best here, followed by a description of what was already done, what's on the roadmap, and how users can effectively protect themselves.
If the description here is clear enough, I'll post it to a wider distribution.
First, what the reported flaw isn't: It is not a weakness in the application/database or underlying cryptography that "breaks" it in the sense that there's an attack that is easier than a "dictionary" attack, that is, trying to see if each word in a dictionary is the user's master passphrase, one word at a time.
PassowrdSafe was designed and implemented with the standard countermeasure against such an attack, which consists of making the validation process deliberately slow, that is, hard to compute. The idea is that the user won't notice the delay when entering the correct password, but the accumulated effect of such a delay slows down such a dictionary attack enough to make it infeasible.
What Elcomsoft have done (kudos to them!) is to find a way to circumvent the slow validation process, so that the attacker's check of whether a given password is the right one or not is much faster than the designers intended (but still not quite trivial).
What has been done: Release 2.14 of PasswordSafe already takes measures to reduce this vulnerability. The first time a database is saved with PasswordSafe 2.14, it will be written to the disk in a way that will make the attack described by Elcomsoft more difficult. The change, however, is backwards-compatible. That is, pre-2.14 versions of PasswordSafe will be able to read a database saved by 2.14.
Since it is not possible to fully fix the flaw without breaking backwards compatability, we are working on a new format of the database. This will take some time, though. Of course, the implementation will also include atomatic conversion from the current format to the new one.
In the meanwhile, the best way to protect yourself against this flaw is to adhere to the standard recommendation regarding passphrases: Choose one that is hard to guess! Here's a link to a good article on how to choose such a passphrase:
I hope this clarifies the issue. Please let me know how this explanation can be improved, so that I can post it to a wider audience.
sorry that I'm so late with my response.
I think it would be a good thing to publish a short notice to the PasswordSafe users explaining the problem and what you are doing to fix it. Most people are probably not interested in cryptographic details so a high-level explanation would probably do. Maybe the explanation should concentrate on the reduction of the work factor to brute force the password. If I read the advisory correctly, it is down to roughly the work factor of cracking an encryption algorithm with a 64-bit key.
New format? Go for it! What matters is that users can have the assurance that any vulnerability has been resolved.
You can happily bear in mind that backwards-compatibility really only matters in situations where it costs the user money to upgrade.
(At least, this is true of backwards compatibility in the sense that the old version of the software can read the new format of the data files. "Backwards compatibility" in the sense that the new program can read the old data files is of course handy, but not absolutely essential if a separate conversion program is available. I know some programmers like to keep the main program lean and uncluttered with historic baggage.)
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.