treege Posted May 2, 2016 Report Share Posted May 2, 2016 (edited) Just a thought I'd like to share. With the introduction of time-based OTP in Enpass, you are able to use your one-time passwords from within the Enpass client. While this saves time for browsing to another OTP client (such as Google Authenticator), it does decrease the level of security. One-time passwords are usually used as the second factor of two-factor authentication. In most cases, these two factors are 'something you know' (your password) and 'something you have' (your phone with the OTP app on it). With the integration of OTP in Enpass, these two separate factors become one as they are both 'something you know/have/stored in the Enpass database'. Have you considered this decreased level of security? I know using OTP in Enpass is optional and the chance of someone obtaining and cracking the SQL database is low, but still the principle of two-factor authentication is thrown out the window by storing both your password and OTP in one place. Edited May 2, 2016 by treege Link to comment Share on other sites More sharing options...
SadE54 Posted May 10, 2016 Report Share Posted May 10, 2016 They miss the important thing : They must add TOTP with Master password for Enpass itself ... 2 Link to comment Share on other sites More sharing options...
goldpeter81 Posted May 11, 2016 Report Share Posted May 11, 2016 (edited) On 10.5.2016 at 9:48 AM, SadE54 said: They miss the important thing : They must add TOTP with Master password for Enpass itself ... This isn't as easy as you might think. If you implement TOTP you need "somebody" like a server (the Enpass client) who verifies whether the code is correct. So when somebody stole your Enpass database the Enpass client on you PC can't verify the code and the protection is broken. Edited May 11, 2016 by goldpeter81 Link to comment Share on other sites More sharing options...
Vinod Kumar Posted May 12, 2016 Report Share Posted May 12, 2016 Hi @treege All you said is true that keeping the TOTP at the same place with passwords garbles the purpose of second factor authentication. If the master password of Enpass is compromised there is no actual second factor left. For the same reason we did’t add the TOTP support for logins in Enpass for a long time. But there were too many customer requests with references to competitor products showing desperation and a use case. 1 Link to comment Share on other sites More sharing options...
My1 Posted May 23, 2016 Report Share Posted May 23, 2016 (edited) 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. Edited October 14, 2016 by My1 more details on PW weaknesses. 2 Link to comment Share on other sites More sharing options...
Ivarson Posted October 16, 2016 Report Share Posted October 16, 2016 I like the TOTP feature. For my primary email I only store the TOTP in Enpass,not the password (which is unique from other password but not as complex,so I have no trouble memorizing it. If my email provider didn't support TOTP I'd never store its single factor password in any password manager, "forgot your password" feature on all other accounts would sorta break the security completely IMHO. Link to comment Share on other sites More sharing options...
My1 Posted October 18, 2016 Report Share Posted October 18, 2016 On 16.10.2016 at 9:56 AM, Ivarson said: For my primary email I only store the TOTP in Enpass,not the password well in that case it's okay On 16.10.2016 at 9:56 AM, Ivarson said: which is unique from other password but not as complex,so I have no trouble memorizing it. I know that feeling, I am same. Link to comment Share on other sites More sharing options...
Programie Posted February 5, 2017 Report Share Posted February 5, 2017 (edited) I think two factor authentication is primarily useful for preventing brute force attacks. So if an attacker guesses the password for your account, they still have to find out the TOTP token in a short period of time which is pretty impossible. OK you could also find out the TOTP secret... In case of GitHub I just saw this notice after configuring Two factor Authentication for my account: Treat your recovery codes with the same level of attention as you would your password! We recommend saving them with a password manager such as Lastpass, 1Password, or Keeper. So if you are storing the recovery codes in the password manager, storing the TOTP secret in the password manager as well does not change anything in the security. Edited February 5, 2017 by Programie Link to comment Share on other sites More sharing options...
Recommended Posts