Storing otp xml file in the cloud

Help
volksen
2013-11-19
2013-11-20
  • volksen

    volksen - 2013-11-19

    Hello everyone,

    I have switched from using keepass with a masterpassword and a keyfile to a password+otp login (with yubikey). Nice work from the plugin programmer! If I understood correctly many OTP result in a stronger password and look-ahead decreases the security only a little bit.

    So is it true that if I am using let's say 5 OTP with length of 8 resulting in 133 bits and a look-ahead value of 16 then its 16 times easier to brute-force the secrect? Which means that my key has only 133-2^4 bits? So a look-ahead of 16 is generally okay?

    Second question is: I use my database on multiple PCs and thinking about putting it into the cloud because the secret counter would be sync on all devices. Is it possible to only put the otp.xml file into the cloud? Right now I have not found a way to change the location where the plugin puts the file.

    More important: how much does the security decrease if the service keeps a history of all otp.xml files and an attacker would get all the files (a big list of successive hashed keys because of the big look-ahead). Is the method still secure?

    kind regards
    volksen

     
    Last edit: volksen 2013-11-19
  • wellread1

    wellread1 - 2013-11-19

    So is it true that if I am using let's say 5 OTP with length of 8 resulting in 133 bits...

    The maximum entropy available to the KeePass database is the entropy (expressed as bits) of the secret key used to generate the OTPs, not the OTPs directly. The known function that generates the OTPs can only reduce the entropy. Presumably the function has been carefully chosen to minimize entropy loss.

    ...and a look-ahead value of 16 then its 16 times easier to brute-force the secrect?

    ...how much does the security decrease if the service keeps a history of all otp.xml files and an attacker would get all the files (a big list of successive hashed keys because of the big look-ahead). Is the method still secure?

    I suspect the math describing security of the overall process implemented by the OtpKeyProv plugin as a function of look-ahead, secret key strength, and number of sequential OTPs used is non-trivial. If the particular implementation used by the OtpKeyProv plugin was not specifically envisioned by the developers of the OTP standard, there may not exist a quantitative treatment of all potential issues.

    That said, is probably safe if you use a high entropy secret key, at least 3 OTPs, and a "reasonable" sized look-ahead, but as always there is no warranty so use at your own risk.

    Some further comments:

    The OtpKeyProv plugin pre-computes the look-ahead OTPs and uses them to encrypt the secret key (which is used to decrypt KeePass). With a look-ahead of 16, the OtpKeyProv plugin would need to save 16 encrypted copies of the secret key (or an intermediate value). Breaking the encryption of any one copy would enable access to the KeePass database. Access to a large pool of encrypted copies of a secret key (e.g. a history of all otp.xm files) might facilitate decrypting the secret key.

    An additional problem is that the sequences of OTPs are derived from a specific OTP stream and therefore are not independent of one another. I wouldn't be surprised if the specification limiting individual OTPs to 6 or 8 digit numbers is designed to account for this issue. Stringing a large number of OTPs together might not result in a linear entropy increase (to the maximum possible entropy limited by the secret key entropy).

    That said, assuming that the secret key encryption process is: (a) well executed (e.g. includes separately salting each individually encrypted instance of the secret key), and (b) that the secret key itself contributes sufficient entropy, it seems reasonable that the overall process is secure.

    Additional note: Cryptographic hashing is ideally a one-way function whereas encryption is a two-way function. The most important characteristic of the values stored in the otp.xml is that they are well encrypted because it must be possible to convert the values stored in the otp.xml file back to either the secret key (or an intermediate value) that can subsequently be used as an input to a known function that will output the encryption key needed to decrypt the KeePass database.

     
    Last edit: wellread1 2013-11-19
  • volksen

    volksen - 2013-11-19

    Thank you for your answer.

    From your answer and from my understanding using Keepass and the OtpKeyProv is basically meant to be used with a single database on a single device. When using it on multiple devices you either need to set the look-ahead to high value or keep the database and opt auxillary file in sync on all devices, e.g. in the cloud. Both approaches lowering the security.

    Can someone please comment on on the best practice of using a database on multiple devices? Is it a database + a key file on a pen drive?

     
  • Paul

    Paul - 2013-11-19

    Best practice is up to you and the requirements you have. I use a single master password for all my devices because I consider it secure enough for my requirements.

    cheers, Paul

     
  • wellread1

    wellread1 - 2013-11-19

    I would agree that trying to keep multiple copies of a database in sync with a single OTP generator would be a challenge. One strategy (which I have not tested) might be to setup separate OTP generators (e.g using Google Authenticator) based on the same secret key for each individual copy of the KeePass database. Each OTP generator-database pair could be separately kept in sync. Since the secret key is the same for all copies of the database it would (I believe) still be possible to sync the database copies without disturbing the individual OTP synchronized pairs.

    I use one of several strategies when syncing a KeePass database across public file servers without using OTPs.

    1. Protect the database with a very strong Master Password only (e.g. sufficiently strong that if the database fell into the wrong hands it could not be opened even if a serious effort were made to crack the password).
    2. Augment a good/strong Master Password with a key file that is kept off the file server but is available to the end nodes. In this scenario, if an end node falls into the wrong hands the good/strong Master Password is the sole effective protection because the attacker has access to the key file; but it the database copy located on the file server falls into the wrong hands, the attacker needs both the good/strong Master Password and the key file.
    3. A hybrid solution is to use the KeeAutoExec plugin (at the end nodes that can support KeePass plugins) as follows:
      • Protect the primary database with a very strong Master Password only (preferably one that you can still remember).
      • At the end nodes with KeeAutoExec plugin create a secondary database, kept off the file server, that holds the very strong Master Password and that can itself be open with only a good/strong Master Password (optionally, the secondary database can be linked to the Windows User Account or use a key file).
      • This arrangement has the advantage that as long as you have the very strong Master Password you can open the database anywhere without any dependencies, and you can open the database at a KeeAutoExec enabled end-node using lesser credentials (assuming you have the necessary secondary database). Depending on how you define the Master Key for the secondary database, the database copy at the end-nodes is either equally or less well protected than the database on the file server.
     
    Last edit: wellread1 2013-11-19
  • wellread1

    wellread1 - 2013-11-19

    One requirement of the OTP strategy I mentioned above is that it is necessary to keep the individual otp.xml files separate (e.g. off of the file server). This may not be possible in all situations.

     
    Last edit: wellread1 2013-11-19
  • volksen

    volksen - 2013-11-20

    Thank you again for the explanation. I will stick to the second solution.

     

Log in to post a comment.