My1

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.

so essentially this would be a smartcard support, I fully approve this.

okay at least now we have some info.

thanks for that. please keep us updates about any news regarding this.

I am wondering the same as @AMiiMA.

@Vinod Kumar can you say anything about this?

I think I push this.

I want to go a bit more seirous with enpass and I must say that no FF import is really sad.

@Vinod Kumar

just asking because of curiosity, is there any Idea when this will come?

well I think people should criticize the 2nd factor in password manager especially because even if you could say that the database is "something you have" I would be very careful with that assertion especially if sync is on and the db lies on some random cloud server.

they should either NOT use 2FA AT ALL or use it right instead of faking security.

one way of implementing 2FA in enpass would be Inherited or delegated trust plus local device encryption.

meaning that

1) the 2FA isnt stored in the cloud BUT
2) you need to approve transfer of 2FA tokens on a device that already has them
3) the on-device 2FA data get enrypted using an on device secret (in windows you could use their acc encryption and even lock it down to the user so that that db cannot be copied.
4) for authenticating a new device that device would put its public key, encrypted with the master password into the cloud and another device which has 2FA and the user can compare the has of the public key on both devices (e.g. making it a bit more readable using wordlist or similar stuff) and only approve the transmission if both match (the user clicks "yes")
5) everytime a new device gets added, ALL devices no matter whether they have 2FA or not get a notification.

On 12.5.2016 at 9:04 AM, Vinod Kumar said:

But there were too many customer requests with references to competitor products showing desperation and a use case.

seriously what valid use case is there for this? this is just irresponsible from any perspective.

as long as your password is truly needed you still have the db file BUT especially post-quantum you can slice the effective security of your crypto in half so for example if somebody uses 128bit AES which isnt bad, and pretty fast, after quantum there are a lot less operations needed and the effective security is comparable with 64-bits pre-quantum, not nice stuff.

256 reduces to effective 128 which should stay secure for a bit but nobody knows what Moore's law will offer then because it may not just be less operations but they may also be lot quicker as well which may make it even worse.

also storing your password makes it possible to use the existing attack vectors worse for you and easier for the attacker:

1) your knowledge (e.g. they could force your pw out of you e.g. by torture) the most obvious thing since that's supposed to be the only attack vector, since it's something YOU KNOW.
also includes others watching you type your password, which gets a lot more dangerous if there's one password that protects all others.
obviously this also gets possible by good-old phishing (I dont think I need to explain but just for the sake of it: an attacker leads you to a malicious site usually over email or some weird pop-ups with either similar but different domains or a mis-issued TLS cert, or in the dumbest case without TLS at all and tries to get a naive user to enter their password there, so they can get the password)

2) temporary storage (in most cases the password is either typed from the pw manager or the more comfortable version is just plain old copypasting and I certainly know that both javascript and flash can read the clipboard (for js I even have something working in IE) and most obviously if the PW is shown, take a screencap and you also have it. also obviously viruses are a thing.

3) malware or similar "fun" on the PC. (obviously keyloggers, although, for non-admin keyloggers, the secure desktop of WinVista and above certainly helps. with software that can read the RAM of other software you dont even need a key logger if you can just look into the target application) Actually This point gets even worse with password-DBs because any good software kicks your passwords into oblivion after it has been typed and used, which means after you pressed enter and the browser sent the password (or the application evaluated it) it should be gone if the software cares about security. but with password DBs your passwords are in the open for way longer depending on how long the DB stays open, and that's not all that's getting worse. if they capture your master password and you dont notice it and they can get on your DB, e.g. if your cloud pass is in the DB, then they can even have a nice look on future passwords, even if you find and clean your malware, best Idea to get safety against that is getting a cloud that notifies you of any new accesses, but obviosuly doesnt help as long as you have the malware since it can just directly read the passwords from the wide-open DB.)

4) good old traditional bruteforcing (inother words, just trying everything. easily thwarted for online auth with limiters, timers, captchas and so on for offline auth the only serious way to at least slow it down is making it expensive to compute. While the legitimate user may have no problem of waiting 5 secs for the pw scrambling and checks because he isnt trying to type it false all the time, and even 100 msec wait (10 tries per second for the machine) is better than e.g. several billion tries per second even if the attacker can accelerate the calculation with stronger PCs and stuff, that's literally the meaning of expensive,it's a money vs time balance .but with enough time and money, e.g. a state level attacker well screw that part again. and it obviously gets worse when you have a password DB because that means that offline auth is possible in the first place which with only your head there is only either online auth [well we can almost ignore that part for any decent website] or trying to hack the server and offline-attack the passwords on their DB, and obviously with a password-DB you have one password which protects all your other password, meaning you only need a large-scale offline attack on the DB to get all the passwords.)

5) your possession (if they have your password db they could try to decrypt it, especially post-quantum, more details above, which also details the existing attack scenarios for password-DBs)

guess what, I aint finished yet. when you use passwords responsibly (use different passwords and stuff) it's way harder because each password only is for one account and you dont have "the one password that rules all".

There is ONE thing that the pw manager can actually protect against.

Phishing with similar domains because if the manager acually checks the domain before entering anything then you can say good bye to at least that part.

Technically there would be only one way to securely enter your password although I never seen anything like that yet, sadly:
a Secure input Device which can keep the password for itself and just zero-knowledges the password with the server, obviously doesnt work with encryption stuff (see my post at the U2F topic for more info on that, but it may certainly be possible for example that the input device runs the password scrambling and only passes the scrambled password over, just for example.

the whole point of 2FA is that you have something you remember and something you possess. even weak passwords or re-use (so you can ACTUALLY remember your pws) would be a fairly small problem if having 2FA because an attacker needs to get your 2FA keys AND the PW.

I think this feature should be either removed or get a huge warning because it could turn into a responsibility mess when an acc DOES get hacked.