I have just configured a test database with the otpKeyProv plugin. Just wanted to ask if it is safe to use daily? I mean are there any bugs/incompatiblies that may arise with future versions of keypass?
Have configured it with 8digit otp key with 3 keys required using google auth.
I know if the Otp keys get out of sync we can use the secret key that's used to generate otp keys.. just wanted to be sure if this plugin is safe.. since I don't want to lose ALL my passwords if there is an issue with plugin. I am going to copy the secret key to multiple places ( as a text file, take a snapshot of the key and keep it in multiple devices and phone). Also of course setting up a daily backup of the database to different devices.
If the keys get out of sync, I just have the secret key as last attempt... i just hope that the plugin has no bugs etc.
If someone has been using the plugin for some time for protecting the passwords, please share your experience.
Thanks in advance,
Regards,
Art79
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If the keys get out of sync, I just have the secret key as last attempt... i just hope that the plugin has no bugs etc.
The secret key can be used multiple times. It always works because it is the actual secret of the key file portion of the database's Master Key.
If someone has been using the plugin for some time for protecting the passwords, please share your experience.
I explored this plugin but don't use it regularly.
In practice, I found the plugin to be more of a demonstration of an encrypted key file technology than a practical method for protecting a database because:
Manually entering three or more OTPs from an OTP generator (e.g. google authenticator) is cumbersome. The minimum number or OTPs can not be reduced (its not allowed) without sacrificing security.
A $25 yubikey can generate and enter the requiste 3 OTPs with 3 button pushes but you must keep track of a single purpose device (the yubikey) and a USB port may not be conveniently located unless you arrange your workspace accordingly.
Setup and maintenance of a distributed database system (e.g. multiple database copies that are synchronized with each other) is complex. It is necessary to either
actively replicate the dbname.otp.xml file everywhere (e.g. via dropbox) so that the otp counter range specified in the file remains synchronized with the OTP generator's counter.
use a large counter LOOKAHEAD value in separate dbname.otp.xml files so that the otp counter range specified in any given dbname.otp.xml file spans the current counter of a single OTP generator.
use independent dbname.otp.xml files for each database paired with its own OTP generator so that the counter of the file and paired OTP generator remain synchronized. This method is not suitable for use with a single OTP generator (e.g. a single yubikey).
Last edit: wellread1 2015-09-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't think it's impratical ( to enter 3 opt keys) from your mobile phone google auth app if that increases the security of the most important database!. I am using it in preference to a key file since you have to keep that key file located somewhere on the same computer as the database. ( whichcan be very easily located by hackers based on last accessed time ). Even if kept on usb flash drive, you have to insert that everytime and locate it.
Your OTP's are generated on seperate device. The secret key used to derive the OTP's can also be kept elsewhere ( scanned, printed ) but not on the same computer.
I am not using the keypass database on multiple devices but backing it up on regular basis in cloud and external drive.
Correct me if I am wrong in my understanding and the belief that OTP's are more secure than a key file.
Thanks once again,
Art79
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OTP provides protection against capture of your master password, but no protection against capture of any credentials used from KeePass. It's convenience versus perceived security.
cheers, Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am in the process of evaluating different methods of securing my KeepAss password store.
OtpKeyProv is looking interesting, but I need to fully understand all dependencies
between keys and different conditions before using it with a real KP database.
My main concerns:
1) To avoid being locked out from my own KP store
2) To be sure it is secure enough,
that at least other people cannot extract secret key from a stolen KP database,
otherwise it is not useful to bother with all this typing these 3 pins everyday.
If I understand correctly verification of OTP is done on both sides (client and server)
by calculating following function:
HMAC(SecretKey,Counter)
So the SecretKey should be present on both client and server to allow client
to generate one time password and to allow server to verify if it is
a correct one time password received from a client.
Please help me to understand where secret key is stored?
After some reading I have found OtpKeyProv is somehow related to key file feature
of the KeepAss application. I guess may be a product of OTP HMAC calculation is used
to generate an analogue of temporary key file to unlock KP database?
But I do not understand where secret key is taken for calculation of HMAC by the plugin, especially taking into account secret shall be entered manually during recovery.
If the secret key is not present withing the KP database, then how HMAC(Key,Count) is calculated by the plugin?
But if the secret key is present in the database or in another place on the computer then it is not secure at all and the only another secure method is challenge-response with asymmetric keys?
Last edit: Alex 2016-03-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am in the process of evaluating different methods of securing my KeepAss password store.
Use a strong master password. Use a specialized method only if you can articulate a specialized need.
If I understand correctly verification of [H]OTP is done on both sides (client and server)
...OTP HMAC calculation is used to generate an analogue of temporary key file to unlock KP database?
If the secret key is not present withing the KP database, then how HMAC(Key,Count) is calculated by the plugin?
But if the secret key is present in the database or in another place on the computer then it is not secure at all and the only another secure method is challenge-response with asymmetric keys?
The KeePass OtpKeyProv HOTP based database unlocking process is superficially similar to client/server HOTP verification process but is fundamentally different. Whereas a typical client-server OTP uses OTPs to verify that both the client and server know the same shared secret (because they can both calculate the same OTP), the OtpKeyProv plugin uses HOTPs to protect (by encryption) a shared secret that is needed to decrypt (open) the database. The OtpKeyProv plugns creates a key file containing the encrypted shared secret named dbname.otp.xml file. The shared secret contained in this file does not change, but the HOTPs needed to decrypt the keyfile change each time the database is successfully unlocked. So, for KeePass the "verification process" is: use the HOTPs to decrypt the shared secret that is part of the Master Key that is used to decrypt the database. This is verification in the sense that only the client can generate the HOTPs needed to decrypt the encrypted shared secret.
The KeePass method is secure because it requires a minimum of three HOTPs (four is better) to encrypt the shared secret. Since the shared secret is an actual component of the database Master Key you can not get locked out of the KeePass database as long as you know the shared secret and all other components of the Master Key (e.g. master password).
To avoid lockouts that are recoverable if you know the shared secret you should set the the lookahead value to allow a reasonable number of failed unlock attempts using the formula
Lookahead value = (allowed failed unlock attemps + 1) x (number of HOTPs per unlock attempt)
If you synchronize your database across multiple devices you may have to adjust (increase) the lookahead value based on your configuration and typical database usage patterns.
Thank you very much for your very good and detailed explanation and the links.
What about TOTP (time based), is it planned to do in the future?
Though may be it is not useful enough because desktop computer time generally can be changed relativelly easy.
Please let me know, does it work well on Linux+Mono? I mean general Windows version of the KeePass and the plugin on the Debian v7 with all latest updates and Microsoft repo of the latest mono.
What about TOTP (time based), is it planned to do in the future?
No, The OtpKeyProv plugin can not be adapted to TOTPs becasue the shared secret would need to be encrypted in advanced with the TOTPs which are valid only for a short period.
Last edit: wellread1 2016-04-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Right,
I missed requirement to have encrypted copy of the secret for each expected OTP
Anyway the idea looks very good
I am not sure how to evaluate a strength of such OTP protection
Say I use 3 OTPs of 8 digits each,
How much time is needed on the most powerful noncluster server say with 4 modern Intel CPUs each with 16 threads = total 64 threads to bruteforce my KP db?
Also please suggest, do any compatible small tokens exist which would be able to work together with OTPKeyProv except Yubikey
Sure small mobile phone can be used, but what about small tokens similar to Yubikey, I saw Nitrokey was mentioned like bugy with KeePass
What about rasbperry based devices? Why not port PIN generator to a Raspberry PI working the same way as Yubikey?
Last edit: Alex 2016-04-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Encrypting the shared secret with a single OTP is not adequate protection.
The requirement is to have L encrypted copies of the shared secret encrypted by N HOTPs where L is the lookahead value and N is the number of HOTPs needed to decrypt the shared secret.
Since the HOTP generation algorithim is deterministic the HOTPs are psuedo random. However as long as Shared Secret Quality>>HOTP Quality then an optimistc quality estimate would treat 3 x 8 digit HOTPs as a 24 digit random number. A 24 digit genuine random number has 80 bits of quality. A cryptographer might take exception to my analysis, but that is the best I can do. See the random password's information entropy equation in the Wikipedia article on Password Strength.
HOTP generatorrs: Yubikey is convenient if you are OK with carrying a usb stick around and inexpensive ($25). Google authentiator is free but awkward. Any generator that can produce HOTPs based on the OATH HOTP standard (RFC 4226), and that you can enter the shared secret into should work.
What about rasbperry based devices? Why not port PIN generator to a Raspberry PI working the same way as Yubikey?
You are getting into territory that you will need explore yourself.
Last edit: wellread1 2016-04-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Did anyone estimate how much calculation power is needed to bruteforce N=3, and usual amount for L, not sure which is the best?
Does increasing of L makes breaking easier if some cryptoanalysis is done which may happen in the future as this plugin gets more popularity?
Last edit: Alex 2016-04-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the clarification, I read that Yubikey models except Neo work with glitches, is it still true for the latest version of the plugin? What about Yubikey v4?
Can you please explain about unchangeable OTP secret in the Youbikey?
If I understood correct during different forum reading, a Yubikey OTP secret is unchangeable, but most likely exportable (at least readable from the screen in personalization/customization GUI).
What happens if Yubikey secret for OTP is leaked? Only throw Yubikey N1 into a recycle bin and then purchase a new Yubikey N2?
In spite of Yubikey often mentioned as partially open solution, I guess its mass production is allowed only provided it has some NSA backdoors. What are the most probable NSA hacks available for Yubikey? I guess nothing for OTP and may be private key extraction for asymmetric cryptography which does not matter for OTPKeyProv?
Do you know any good shop(s) selling Yubikeys worldwide except Amazon, Ebay and original vendor's shop?
Last edit: Alex 2016-04-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Form factor (size) of a very small new Android phone model looks convenient for a PIN generator device for me (at least it is good to carry it in a pocket):
There is a list of HOTP implementations in the Wikipedia Article HMAC-based One-time Password Algorithm. You might want to try findning one that you can run on your current hardware before making an investment. For example a Chrome Browser extension is listed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have just configured a test database with the otpKeyProv plugin. Just wanted to ask if it is safe to use daily? I mean are there any bugs/incompatiblies that may arise with future versions of keypass?
Have configured it with 8digit otp key with 3 keys required using google auth.
I know if the Otp keys get out of sync we can use the secret key that's used to generate otp keys.. just wanted to be sure if this plugin is safe.. since I don't want to lose ALL my passwords if there is an issue with plugin. I am going to copy the secret key to multiple places ( as a text file, take a snapshot of the key and keep it in multiple devices and phone). Also of course setting up a daily backup of the database to different devices.
If the keys get out of sync, I just have the secret key as last attempt... i just hope that the plugin has no bugs etc.
If someone has been using the plugin for some time for protecting the passwords, please share your experience.
Thanks in advance,
Regards,
Art79
The secret key can be used multiple times. It always works because it is the actual secret of the key file portion of the database's Master Key.
I explored this plugin but don't use it regularly.
In practice, I found the plugin to be more of a demonstration of an encrypted key file technology than a practical method for protecting a database because:
counterLOOKAHEAD value in separate dbname.otp.xml files so that the otp counter range specified in any given dbname.otp.xml file spans the current counter of a single OTP generator.Last edit: wellread1 2015-09-19
Thanks for replying, wellread1
I don't think it's impratical ( to enter 3 opt keys) from your mobile phone google auth app if that increases the security of the most important database!. I am using it in preference to a key file since you have to keep that key file located somewhere on the same computer as the database. ( whichcan be very easily located by hackers based on last accessed time ). Even if kept on usb flash drive, you have to insert that everytime and locate it.
Your OTP's are generated on seperate device. The secret key used to derive the OTP's can also be kept elsewhere ( scanned, printed ) but not on the same computer.
I am not using the keypass database on multiple devices but backing it up on regular basis in cloud and external drive.
Correct me if I am wrong in my understanding and the belief that OTP's are more secure than a key file.
Thanks once again,
Art79
The OtpKeyProv plugin is a perfectly good and secure solution. It is just less convenient than I prefer.
OTP provides protection against capture of your master password, but no protection against capture of any credentials used from KeePass. It's convenience versus perceived security.
cheers, Paul
Hello,
I am in the process of evaluating different methods of securing my KeepAss password store.
OtpKeyProv is looking interesting, but I need to fully understand all dependencies
between keys and different conditions before using it with a real KP database.
My main concerns:
1) To avoid being locked out from my own KP store
2) To be sure it is secure enough,
that at least other people cannot extract secret key from a stolen KP database,
otherwise it is not useful to bother with all this typing these 3 pins everyday.
If I understand correctly verification of OTP is done on both sides (client and server)
by calculating following function:
HMAC(SecretKey,Counter)
So the SecretKey should be present on both client and server to allow client
to generate one time password and to allow server to verify if it is
a correct one time password received from a client.
Please help me to understand where secret key is stored?
After some reading I have found OtpKeyProv is somehow related to key file feature
of the KeepAss application. I guess may be a product of OTP HMAC calculation is used
to generate an analogue of temporary key file to unlock KP database?
But I do not understand where secret key is taken for calculation of HMAC by the plugin, especially taking into account secret shall be entered manually during recovery.
If the secret key is not present withing the KP database, then how HMAC(Key,Count) is calculated by the plugin?
But if the secret key is present in the database or in another place on the computer then it is not secure at all and the only another secure method is challenge-response with asymmetric keys?
Last edit: Alex 2016-03-31
Use a strong master password. Use a specialized method only if you can articulate a specialized need.
The KeePass OtpKeyProv HOTP based database unlocking process is superficially similar to client/server HOTP verification process but is fundamentally different. Whereas a typical client-server OTP uses OTPs to verify that both the client and server know the same shared secret (because they can both calculate the same OTP), the OtpKeyProv plugin uses HOTPs to protect (by encryption) a shared secret that is needed to decrypt (open) the database. The OtpKeyProv plugns creates a key file containing the encrypted shared secret named dbname.otp.xml file. The shared secret contained in this file does not change, but the HOTPs needed to decrypt the keyfile change each time the database is successfully unlocked. So, for KeePass the "verification process" is: use the HOTPs to decrypt the shared secret that is part of the Master Key that is used to decrypt the database. This is verification in the sense that only the client can generate the HOTPs needed to decrypt the encrypted shared secret.
The KeePass method is secure because it requires a minimum of three HOTPs (four is better) to encrypt the shared secret. Since the shared secret is an actual component of the database Master Key you can not get locked out of the KeePass database as long as you know the shared secret and all other components of the Master Key (e.g. master password).
To avoid lockouts that are recoverable if you know the shared secret you should set the the lookahead value to allow a reasonable number of failed unlock attempts using the formula
If you synchronize your database across multiple devices you may have to adjust (increase) the lookahead value based on your configuration and typical database usage patterns.
Other useful threads:
https://sourceforge.net/p/keepass/discussion/329220/thread/0800a507/#3d5b
https://sourceforge.net/p/keepass/discussion/329220/thread/be102635/#e37a
If you have addtional questions after reviewing this ask them one at a time.
Last edit: wellread1 2016-03-31
Thank you very much for your very good and detailed explanation and the links.
What about TOTP (time based), is it planned to do in the future?
Though may be it is not useful enough because desktop computer time generally can be changed relativelly easy.
Please let me know, does it work well on Linux+Mono? I mean general Windows version of the KeePass and the plugin on the Debian v7 with all latest updates and Microsoft repo of the latest mono.
Also another less detailed explanation is at the end of the thread (if someone could be interested):
https://security.stackexchange.com/questions/42446/does-adding-two-factor-authentication-by-otp-really-make-keepass-more-secure
Last edit: Alex 2016-04-01
I don't recall anyone complaining about incompatibilities on Linux but you will need to test. Let us know what you find.
No, The OtpKeyProv plugin can not be adapted to TOTPs becasue the shared secret would need to be encrypted in advanced with the TOTPs which are valid only for a short period.
Last edit: wellread1 2016-04-01
Right,
I missed requirement to have encrypted copy of the secret for each expected OTP
Anyway the idea looks very good
I am not sure how to evaluate a strength of such OTP protection
Say I use 3 OTPs of 8 digits each,
How much time is needed on the most powerful noncluster server say with 4 modern Intel CPUs each with 16 threads = total 64 threads to bruteforce my KP db?
Also please suggest, do any compatible small tokens exist which would be able to work together with OTPKeyProv except Yubikey
Sure small mobile phone can be used, but what about small tokens similar to Yubikey, I saw Nitrokey was mentioned like bugy with KeePass
What about rasbperry based devices? Why not port PIN generator to a Raspberry PI working the same way as Yubikey?
Last edit: Alex 2016-04-01
Encrypting the shared secret with a single OTP is not adequate protection.
The requirement is to have L encrypted copies of the shared secret encrypted by N HOTPs where L is the lookahead value and N is the number of HOTPs needed to decrypt the shared secret.
Since the HOTP generation algorithim is deterministic the HOTPs are psuedo random. However as long as Shared Secret Quality>>HOTP Quality then an optimistc quality estimate would treat 3 x 8 digit HOTPs as a 24 digit random number. A 24 digit genuine random number has 80 bits of quality. A cryptographer might take exception to my analysis, but that is the best I can do. See the random password's information entropy equation in the Wikipedia article on Password Strength.
HOTP generatorrs: Yubikey is convenient if you are OK with carrying a usb stick around and inexpensive ($25). Google authentiator is free but awkward. Any generator that can produce HOTPs based on the OATH HOTP standard (RFC 4226), and that you can enter the shared secret into should work.
You are getting into territory that you will need explore yourself.
Last edit: wellread1 2016-04-01
Did anyone estimate how much calculation power is needed to bruteforce N=3, and usual amount for L, not sure which is the best?
Does increasing of L makes breaking easier if some cryptoanalysis is done which may happen in the future as this plugin gets more popularity?
Last edit: Alex 2016-04-01
See my edits above.
Last edit: wellread1 2016-04-01
Thanks for the clarification, I read that Yubikey models except Neo work with glitches, is it still true for the latest version of the plugin? What about Yubikey v4?
Can you please explain about unchangeable OTP secret in the Youbikey?
If I understood correct during different forum reading, a Yubikey OTP secret is unchangeable, but most likely exportable (at least readable from the screen in personalization/customization GUI).
What happens if Yubikey secret for OTP is leaked? Only throw Yubikey N1 into a recycle bin and then purchase a new Yubikey N2?
In spite of Yubikey often mentioned as partially open solution, I guess its mass production is allowed only provided it has some NSA backdoors. What are the most probable NSA hacks available for Yubikey? I guess nothing for OTP and may be private key extraction for asymmetric cryptography which does not matter for OTPKeyProv?
Do you know any good shop(s) selling Yubikeys worldwide except Amazon, Ebay and original vendor's shop?
Last edit: Alex 2016-04-01
The website keepass.info looks unavailable:
https://web.archive.org/web/20160401040602/http://keepass.info/
can you please suggest a mirror for plugins or may be share a copy of your plugins (without your customized settings, just DLLs needed)
Last edit: Alex 2016-04-01
There is no alternate site for http://keepass.info/plugins.html, but it appears to up now.
The website is up from here.
http://keepass.info/plugins.html
cheers, Paul
Can you please suggest a Java ME client supporting RFC 4226 except google?
Last edit: Alex 2016-04-01
I don't have any suggestions.
cheers, Paul
Form factor (size) of a very small new Android phone model looks convenient for a PIN generator device for me (at least it is good to carry it in a pocket):
http://www.1949deal.com/z18-mini-mtk6572-dual-core-android-4-0-smartphone-256mb-ram-256mb-rom-2-45-inch-screen-green.html
But I am not sure if it is enough its 256MB of RAM and other parameters to run the latest google authenticator or at least some available old version
Last edit: Alex 2016-04-01
There is a list of HOTP implementations in the Wikipedia Article HMAC-based One-time Password Algorithm. You might want to try findning one that you can run on your current hardware before making an investment. For example a Chrome Browser extension is listed.
I would prefer something disconnected from Internet for PIN generator
Funny device WITHOUT GSM connectivity and relativelly up to date Android at least in its version branch of v4:
http://www.dx.com/p/kid-s-r430-rk2926-1-0ghz-android-4-3-tablet-pc-w-4-3-screen-wi-fi-4gb-rom-tf-slot-blue-385581
Not sure if it can run the latest Google Authenticator
CPU: RK2926
RAM: 512MB
ROM: 2GB
Is it enough to run required application?
Last edit: Alex 2016-04-02