Leaderboard

That sounds like you're sacrificing security for the sake of performance. And you're absolutely right, it really is a trade-off between security and performance. That's why I'd suggest to make it configurable. With KeePass I had set this to 200M iterations and it only took a second to open/save the database on my Desktop. If you fear complicating the user settings dialog, you could add an "expert settings" tab.

Hi all, Interesting discussion. Just to spice up the matter I would like to add few points We do not use delta/diff uploads. If a newer file is detected, sync-engine downloads the whole file from the cloud. After syncing the whole file is uploaded to cloud. Reason being, no cloud other than Dropbox supports delta uploads/downloads. So, a single (all-in-one) monolith database will impact sync performance and data cost. However, one file per attachment will also hamper sync performance/reliability when no. of attachments grow. In my personal opinion, Bigger attachments (images/pdfs) are big no-no for inclusion in main database and must go in separate database. However, there must be an option to allow inclusion of small attachments(<5KB) in main database. BTW, we will start the development for attachments support very soon in the best possible manner. Your suggestions are always welcome.

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. 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.

I think there is an easier way to implement it and cover a wide variety of needs. And I myself would love it! Let us assume everyone has his own master vault (i.e. the one you are using just right now). Imagine you just add a new type of password entry ("enpass-vault") where you define: the name of the embedded vault the file_name of the vault file the master password for this embedded vault define read-only or read-write behavior setup synchronization for (i.e. different dropbox account) Now the enpass app will at its start scan the main vault for these "enpass-vault" entries for available embedded vaults and will make them available/searchable for the user. When the user wants to store a new password, it will be stored into the main vault by default unless the user specifies any of the embedded read-write vaults to store it in. In this way, it is solely on the user's decision what kind of embedded vault he/she wants to have (team vault, external company vault, wife's vault, family vault etc.)...