Report Support for U2F in Feature requests Posted September 23, 2016 to anyone who hasnt considered this: when the ressource is already accessible (on your harddrive) there is NOTHING which 2FA with a variable (OTP, U2F) would add. the sole reason is because the data is already there. you cant encrypt with a variable. @Niko_K the Yubi for windows with the HMAC sha1 also does nothing to encrypt data it just just to prove that you have the key. but the problem is that when someone can access the data on your harddrive already then your nice yubikey wont help you. The ONLY possible second factor that can really be taken into consideration are smartcards, HSMs and similar which would do the decryption of the DB by themselves. but a signature/Hash based second factor (u2f, OTP and so on) is pretty much useless for offline stuff since the data is already there. when you have for example your lastpass account with 2FA it's simple why it works. since lastpass is a mostly online-only service lastpass can use the second factor to control the data flow to you means if your second factor doesnt match, LP wont hand you over the database. but since a second factor is made in a way that the thing you enter cannot be used to restore a shared secret or whatever it is not possible to encrypt it. there is only ONE possible scenario for one time passowrds but it is 1) a horrible misuse of the concept and 2) if you get out of sync by even 1 try, you can say goodbye without having to try all the OTPs. that scenario would be as the following: when the user sets OTP for the database forst you get your HOTP (counter based) OTP to the phone and of course verify it to the DB when the DB gets closed it gets encrypted by the password and the HOTP for (current counter+1) when the user opens the db he enters both the password and the otp for the next counter rinse and repeat. the only problem is as I said if you dont keep track of your counter and it gets out of sync (e.g. someone accidentially or maliciously pushing the button) you can say good bye especially if you for example have a hardware token with a non-resettable counter. while online services know the shared secret (the OTP seed) they can adjust for desyncs in a certain range because they can just generate OTPs for validation as needed, but for encryption this wont work. so the scenario above is horribly vulnerable for essentially killing your db and is NOT recommended.