I have reconfigured my Yubikey for OATH-HOTP and am trying to use it with OtpKeyProv.
I've tried many variations with a fixed, fixed zero and a random counter/moving factor using decimal and UTF-8. (I've carefully followed the instructions in the OtpKeyProv readme. The readme says Yubikey has been tested successfully).
Using the OTP doesn't work, although I'm able to use recovery mode and the secret key to open my KeePass DB successfully.
I'm using Keepass 2.17 (to maintain keyfox compatiblity) and OtpKeyProv 1.3
Any pointers or help would be appreciated.
Thanks.
AP
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I haven't used a YubiKey, BUT --- you will want a counter that increments by one on every use, to work with OptKeyProv. Make sure you have the same counter to start with in the plugin and the YubiKey. Also set number of digits to match what YubiKey outputs. It's a little easy to get the counter out of sync, that's why I'm hoping a future version of OptKeyProv will implement an optional look-ahead window.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your reply! I was looking at http://docs.liebsoft.com/Enterprise-Random-Password-Manager-Admin-Guide/5348.htm and I was able to use the test token/secret key successfully. I was also able to get it to fail by generating an OTP outside of Keepass. The counter gets out of sync quite easily. Despite setting the moving counters to the same value, I've had no luck with a random token/secret key.
I, too, hope a future version of OptKeyProv will implement a look ahead window. The page I mentioned above describes the needed behaviors well:
Current Sequence Number - This is the current number of key presses recorded against this event token (HOTP). This number starts at zero with a new token and is updated to reflect the last matched key press sequence number. As an example: a brand new token will start with a sequence number of zero. If a user presses the button four (4) times to play around with the token, if they then log in with the fifth (5th) key press on the token, the program will detect that the fifth token code was detected and to expect and accept only token code number six (6) and later. The Current Sequence Number is required to make sure that a user does not reuse an old or previous token code.
Moving Window - Given that a user may inadvertently press the token code, the software needs to account for this and look forward from the last token code. In the default case, the program will accept up to the next 10 token codes from the last one that it successfully authenticated against. In the case of time based tokens (TOTP), this value is split in half to look for tokens 5 steps back in time and 5 steps forward in time, where time is the current time. Note that the program is smart enough to know to not allow the use of time token code values older than the last one correctly authenticated.
As much as I like it and want to use it, as it stands today though, because there is no way to keep the counter in sync (i.e. to account for use of the yubikey outside of Keepass/OTPKeyProv), the plugin is completely unreliable :(
AP
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had to stop using it too, because of the sync. I guess we are both waiting for the improved version of the plugin. Maybe I should download the source and edit the plugin myself :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-02-25
I would really appreciate a look ahead window, as well.
It doesn't make the OTP less secure with this option. The requirement that you enter at least 3 OTPs should take care of it. Additionally, Keepass could display a list of skipped OTPs counters and an approximate date range of when it was skipped, like banks do with out of sequence checks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the update. And I appreciate your security analysis with static OTP's.
Resynchronization is still an issue for me.
Many users will still encounter it even with the look ahead windows, on mirroring their databases in other locations. This will become especially problematic when different versions of the database have not updated. It will be a nightmare to have multiple databases with different counters + very large look ahead windows.
So, I suspect even with the look ahead solution (which you point out increases database vulnerability), the current OTP implementation will see limited use.
I have the following questions:
What is your security analysis with time-synchronized OTP's?
Any reason why a time-synchronized solution was not considered?
Thanks so much.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In a client-server system, where the server knows the secret key (which the attacker has no access to), time-based OTPs are easy to implement and a good solution.
In a local solution like KeePass, where you have to assume that an attacker has full access to all files on your hard disk, I don't see how a time-based solution could be implemented efficiently. In the client-server system, the server knows the secret key and can hash it together with the current time to generate OTPs. With OtpKeyProv this is impossible, because the plugin doesn't know the secret key in advance; the secret key is reconstructed from the multiple OTPs that the user enters (storing the secret key directly would defeat the plugin's purpose). In order to support time-based OTPs, data would need to be stored for each possible time value. Basically you can think of a look-ahead OTP for each time interval. If you look into the .otp.xml auxiliary file, you'll see that quite some information is required in order to support each look-ahead OTP. A time-based system would require too much look-ahead data.
Best regards
Dominik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thank you for the OtpKeyProv plugin. To use this plugin with multiple persons is not so easy, so we ask again, is there meanwhile a TOTP solution for keepass or is your argumentation still valid?
Thx and kind regards,
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OTP and multiple users is not a compatible solution - as you have discovered.
If you need that much control a paid solution, like Bitwarden, may be better.
cheers, Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Choose a strong master password (and key file if required) and enter it on a Secure Desktop.
Tools > Options, Security tab, Advanced, Enter master key on secure desktop.
cheers, Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-04-15
Dominik,
After my initial messages I looked into implementing it myself. I knew I would have to store multiple copies of the encrypted secret to the XML file, and there would have to be some sort of checksum to verify the secret before sending it onto Keepass.
I'm entirely surprised at how few changes you had to make to implement this. I must say you are a very good programmer.
Where is the security analysis tachycore references? Does it make the plugin less secure to store copies of the same secret key encrypted with different keys? Does storing the hashes of the clear text make this less secure?
Thanks, Matthew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-04-15
Tachycore & sourceforgea-p - - Note that Yubico suggests that you only use the Yubikey for ONE security application. You should not be attempting to use the same yubikey to provide keys to more than one application.
I wouldn't recommend having a lookahead window more than 2.5 times the number of keys you are required to enter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe Tachycore meant the table in the ReadMe file in which the key sizes are listed depending on the length and count of OTPs.
Storing multiple copies of the secret key encrypted with different keys shouldn't be a problem in practice. Of course the more copies are stored, the less protected the secret is (the most simple attack would be a brute-force attack: when there are n copies and you try a key, your chance is n/(2^256)), but in practice I don't see an efficient attack.
Storing hashes of the secret key shouldn't be a problem either. The hash being used is SHA-256, which is a cryptographically secure hash function, so inverting or finding another preimage isn't possible efficiently. As you might have seen already, I've additionally implemented a transformation to make it even harder: instead of just hashing the secret, OtpKeyProv hashes it, encrypts the hash a number of times (currently 10000) using AES with a random key (which is stored in the .otp.xml file) and hashes it again. This on the one hand prevents precomputation of hashes and on the other hand makes trying/testing a secret take a longer time, i.e. guessing and dictionary attacks are harder.
Best regards
Dominik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-04-20
Dominik when you have a chance you should update this page to say that Yubikey and Keepass work very well together.
I'll second mhredmond21's comment - it's not obvious that OtpKeyProv can support a YubiKey. I tried it (successfully) on a whim, but only because I happened to read the detailed description, see "OATH HOTP", and then search Google to see if Yubikeys can do that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm very interessed in using OTP with Yubikey (didn't buy it yet) & Keepass. So after setup my .kdbx with OtpKeyProv with Yubikey everything works... Now my Yubikey is lost/broken/bottom of the sea... And i buy a new one, can i duplicate the settings from my old/lost one? (http://forum.yubico.com/viewtopic.php?t=550)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't use a yubikey but there are some general principles that would apply to any OTP generator (e.g. yubikey, google authentication, etc) used with the OtpKeyProv plugin.
The OtpKeyProv plugin allows you to bypass the one time passwords and access your database by entering the original Generator token secret key directly (Recovery mode tab). This would allow you to reset the KeePass database and synchronize it with a new OTP generator. It is important not to lose the Generator token secret key, or you will be unable to access the KeePass database if the OTP generator is lost or becomes unsynchronized with the database.
Note: The OtpKeyProv plugin can use only counter based OTPs not time based OTPs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am about to implement OtpKeyProv-like functionality in Keepass2Android. While this can be done in exactly the same way as the OtpKeyProv plugin does for people who only have their database on their Android device, things are somewhat more complicated assuming that most people probably want to use OTP on a database which is synchronized across devices. Again, as long as the device is online, I can access the .otp.xml auxiliary file as if it was a local file and everything is fine.
But Android devices are often mobile devices which are not always online (why I have implemented caching and sync/merge in KP2A). Now the question is: How should I handle the case that the user opens the database while he's offline and later goes online?
Possible options are
- deny access when offline. I'm sure not all users will like this
- cache the auxiliary file, update the counter in the cache when user logs in. When user is online again, synchronize the file. If the server file has been modified as well, "merge" by using the file with the higher counter?
- something else??
How are people handling this today (with different PCs or other platforms)? Any suggestions for how to implement this?
Thanks a lot!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Denying access is never an option, users will assume it's broken and not understand what is going on. A can of worms methinks. Caching the auxiliary file has issues if the PC version is used and the Android can't pick up the changes. Storing the otp.xml file online has some merit, but if you need to unlock something local when the internet is down....
If you cache the config file you may have to enforce a longish look ahead with lots of warnings if the file is not available to update.
cheers, Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have reconfigured my Yubikey for OATH-HOTP and am trying to use it with OtpKeyProv.
I've tried many variations with a fixed, fixed zero and a random counter/moving factor using decimal and UTF-8. (I've carefully followed the instructions in the OtpKeyProv readme. The readme says Yubikey has been tested successfully).
Using the OTP doesn't work, although I'm able to use recovery mode and the secret key to open my KeePass DB successfully.
I'm using Keepass 2.17 (to maintain keyfox compatiblity) and OtpKeyProv 1.3
Any pointers or help would be appreciated.
Thanks.
AP
I haven't used a YubiKey, BUT --- you will want a counter that increments by one on every use, to work with OptKeyProv. Make sure you have the same counter to start with in the plugin and the YubiKey. Also set number of digits to match what YubiKey outputs. It's a little easy to get the counter out of sync, that's why I'm hoping a future version of OptKeyProv will implement an optional look-ahead window.
Thanks for your reply! I was looking at http://docs.liebsoft.com/Enterprise-Random-Password-Manager-Admin-Guide/5348.htm and I was able to use the test token/secret key successfully. I was also able to get it to fail by generating an OTP outside of Keepass. The counter gets out of sync quite easily. Despite setting the moving counters to the same value, I've had no luck with a random token/secret key.
I, too, hope a future version of OptKeyProv will implement a look ahead window. The page I mentioned above describes the needed behaviors well:
Moving Window - Given that a user may inadvertently press the token code, the software needs to account for this and look forward from the last token code. In the default case, the program will accept up to the next 10 token codes from the last one that it successfully authenticated against. In the case of time based tokens (TOTP), this value is split in half to look for tokens 5 steps back in time and 5 steps forward in time, where time is the current time. Note that the program is smart enough to know to not allow the use of time token code values older than the last one correctly authenticated.
As much as I like it and want to use it, as it stands today though, because there is no way to keep the counter in sync (i.e. to account for use of the yubikey outside of Keepass/OTPKeyProv), the plugin is completely unreliable :(
AP
I had to stop using it too, because of the sync. I guess we are both waiting for the improved version of the plugin. Maybe I should download the source and edit the plugin myself :)
I would really appreciate a look ahead window, as well.
It doesn't make the OTP less secure with this option. The requirement that you enter at least 3 OTPs should take care of it. Additionally, Keepass could display a list of skipped OTPs counters and an approximate date range of when it was skipped, like banks do with out of sequence checks.
I've released version 2.0 of the OtpKeyProv plugin, which now supports look-ahead windows.
http://keepass.info/plugins.html#otpkeyprov
Best regards
Dominik
Thank you for the update. And I appreciate your security analysis with static OTP's.
Resynchronization is still an issue for me.
Many users will still encounter it even with the look ahead windows, on mirroring their databases in other locations. This will become especially problematic when different versions of the database have not updated. It will be a nightmare to have multiple databases with different counters + very large look ahead windows.
So, I suspect even with the look ahead solution (which you point out increases database vulnerability), the current OTP implementation will see limited use.
I have the following questions:
What is your security analysis with time-synchronized OTP's?
Any reason why a time-synchronized solution was not considered?
Thanks so much.
In a client-server system, where the server knows the secret key (which the attacker has no access to), time-based OTPs are easy to implement and a good solution.
In a local solution like KeePass, where you have to assume that an attacker has full access to all files on your hard disk, I don't see how a time-based solution could be implemented efficiently. In the client-server system, the server knows the secret key and can hash it together with the current time to generate OTPs. With OtpKeyProv this is impossible, because the plugin doesn't know the secret key in advance; the secret key is reconstructed from the multiple OTPs that the user enters (storing the secret key directly would defeat the plugin's purpose). In order to support time-based OTPs, data would need to be stored for each possible time value. Basically you can think of a look-ahead OTP for each time interval. If you look into the .otp.xml auxiliary file, you'll see that quite some information is required in order to support each look-ahead OTP. A time-based system would require too much look-ahead data.
Best regards
Dominik
Hi Dominik,
thank you for the OtpKeyProv plugin. To use this plugin with multiple persons is not so easy, so we ask again, is there meanwhile a TOTP solution for keepass or is your argumentation still valid?
Thx and kind regards,
Frank
OTP and multiple users is not a compatible solution - as you have discovered.
If you need that much control a paid solution, like Bitwarden, may be better.
cheers, Paul
Thx Paul,
TOTP for bitwarden database files seems to be also not available.
TOTP for keepass is still no option?
Regards,
Frank
Last edit: Frank Naumann 1 day ago
As Dominik said, can't do it locally.
Choose a strong master password (and key file if required) and enter it on a Secure Desktop.
Tools > Options, Security tab, Advanced, Enter master key on secure desktop.
cheers, Paul
Dominik,
After my initial messages I looked into implementing it myself. I knew I would have to store multiple copies of the encrypted secret to the XML file, and there would have to be some sort of checksum to verify the secret before sending it onto Keepass.
I'm entirely surprised at how few changes you had to make to implement this. I must say you are a very good programmer.
Where is the security analysis tachycore references? Does it make the plugin less secure to store copies of the same secret key encrypted with different keys? Does storing the hashes of the clear text make this less secure?
Thanks, Matthew
Tachycore & sourceforgea-p - - Note that Yubico suggests that you only use the Yubikey for ONE security application. You should not be attempting to use the same yubikey to provide keys to more than one application.
I wouldn't recommend having a lookahead window more than 2.5 times the number of keys you are required to enter.
I believe Tachycore meant the table in the ReadMe file in which the key sizes are listed depending on the length and count of OTPs.
Storing multiple copies of the secret key encrypted with different keys shouldn't be a problem in practice. Of course the more copies are stored, the less protected the secret is (the most simple attack would be a brute-force attack: when there are n copies and you try a key, your chance is n/(2^256)), but in practice I don't see an efficient attack.
Storing hashes of the secret key shouldn't be a problem either. The hash being used is SHA-256, which is a cryptographically secure hash function, so inverting or finding another preimage isn't possible efficiently. As you might have seen already, I've additionally implemented a transformation to make it even harder: instead of just hashing the secret, OtpKeyProv hashes it, encrypts the hash a number of times (currently 10000) using AES with a random key (which is stored in the .otp.xml file) and hashes it again. This on the one hand prevents precomputation of hashes and on the other hand makes trying/testing a secret take a longer time, i.e. guessing and dictionary attacks are harder.
Best regards
Dominik
Dominik when you have a chance you should update this page to say that Yubikey and Keepass work very well together.
http://keepass.info/help/kb/kb090227_yubikey.html
I had to do a lot of searching on google and your website to even be able to tell that Keepass and Yubikey work together.
I'll second mhredmond21's comment - it's not obvious that OtpKeyProv can support a YubiKey. I tried it (successfully) on a whim, but only because I happened to read the detailed description, see "OATH HOTP", and then search Google to see if Yubikeys can do that.
Thanks for the hint, Matthew! I've updated the help page.
I'm very interessed in using OTP with Yubikey (didn't buy it yet) & Keepass. So after setup my .kdbx with OtpKeyProv with Yubikey everything works... Now my Yubikey is lost/broken/bottom of the sea... And i buy a new one, can i duplicate the settings from my old/lost one? (http://forum.yubico.com/viewtopic.php?t=550)
I don't use a yubikey but there are some general principles that would apply to any OTP generator (e.g. yubikey, google authentication, etc) used with the OtpKeyProv plugin.
The OtpKeyProv plugin allows you to bypass the one time passwords and access your database by entering the original Generator token secret key directly (Recovery mode tab). This would allow you to reset the KeePass database and synchronize it with a new OTP generator. It is important not to lose the Generator token secret key, or you will be unable to access the KeePass database if the OTP generator is lost or becomes unsynchronized with the database.
Note: The OtpKeyProv plugin can use only counter based OTPs not time based OTPs.
I am about to implement OtpKeyProv-like functionality in Keepass2Android. While this can be done in exactly the same way as the OtpKeyProv plugin does for people who only have their database on their Android device, things are somewhat more complicated assuming that most people probably want to use OTP on a database which is synchronized across devices. Again, as long as the device is online, I can access the .otp.xml auxiliary file as if it was a local file and everything is fine.
But Android devices are often mobile devices which are not always online (why I have implemented caching and sync/merge in KP2A). Now the question is: How should I handle the case that the user opens the database while he's offline and later goes online?
Possible options are
- deny access when offline. I'm sure not all users will like this
- cache the auxiliary file, update the counter in the cache when user logs in. When user is online again, synchronize the file. If the server file has been modified as well, "merge" by using the file with the higher counter?
- something else??
How are people handling this today (with different PCs or other platforms)? Any suggestions for how to implement this?
Thanks a lot!
Denying access is never an option, users will assume it's broken and not understand what is going on. A can of worms methinks. Caching the auxiliary file has issues if the PC version is used and the Android can't pick up the changes. Storing the otp.xml file online has some merit, but if you need to unlock something local when the internet is down....
If you cache the config file you may have to enforce a longish look ahead with lots of warnings if the file is not available to update.
cheers, Paul
Thanks for your feedback!
I have implemented the caching approach in https://keepass2android.codeplex.com/releases/view/115251 if someone wants to take a look!
See some guidelines on how to set the "lookahead" to avoid synch problems here