Documentation: Missing HMAC in Feature list
Thanks wellread1, that clarifies it for me! IMHO the OTP secret should be re-encrypted once it could be successfully decrypted and not only when the database was successfully opened, but that's a minor detail
Ok, found some useful information at https://sourceforge.net/p/keepass/discussion/329220/thread/8b1d33f7/#af0d but it still lacks some details. My guess is that the secret key is encrypted using the next three (if OTP count is 3 and lookahead is 0) unused OTPs. Once the secret key is sucessfuly decrypted, the next OTPs (which are the ones that the user will enter the next time) are calculated and the key is encrypted again. If lookehead is >0, then multiple versions of the encrypted key are prepared....
Hi! Entering the OTPs allows the plug-in to generate the secret. No offence, but this is like saying "some magic happens". The OTPs are derived from some secret S using an unidirectional function. It is impossible to reconstruct S mathematically from any number of OTPs. That's the purpose of the whole algorithm described in the RFC. All that a program can do is to check entered OTPs against the secret S which has to be known beforehand (together with the current state of the counter). Without S,...
PS: I tried to understand the source code but had to give up...
Hi, I have just recently learned about OtpKeyProv as a way to add 2FA to the KeePass database based on RFC4226 HOTP. Reading the RFC it is clear to me how in a client-server infrastructure with a shared secret (known to both sides) HOTP can add an additional layer of security: Using SHA-1 as non-reversible function, both sides can calculate the OTP and verify that the other party is in posession of the secret key. In my understanding, the idea behind an additional key provider Plugin is to derive...
I can confirm this behavior. I added two more discs to my NAS4Free setup as a new...