Schneier's PasswordSafe password validation f

2005-11-25
2012-09-17
  • Ulrich Boche
    Ulrich Boche
    2005-11-25

    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.

    I haven't seen a comment from Bruce Schneier in his blog and there is apparently no discussion of this problem here. It would be interesting to learn what crypto experts think about the viability of this attack. Generally, the people from ElcomSoft are not known to make false claims for publicity's sake.

    Ulrich Boche

     
    • John Navas
      John Navas
      2006-03-31

      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>.

       
    • Rony Shapiro
      Rony Shapiro
      2005-11-25

      Hi Ulrich,

      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:
      http://wolfram.org/writing/howto/password.html

      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.

      Cheers,

        Rony
      
       
    • Ulrich Boche
      Ulrich Boche
      2005-12-04

      Rony,
      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.

      With regard to the compatibility issue when changing the database design: for me, that's a non-issue. I'm using PasswordSafe on two PCs; sometimes I need to open one system's database on the other system for synchronization purposes. I wouldn't mind if I had to run the same version of PasswowrdSafe on both systems. Installing a new version of PasswordSafe is a matter of minutes, that cannot be a problem.

      Ulrich Boche

       
    • Dan McCloy
      Dan McCloy
      2005-12-14

      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.)

      Dan