In my case, I'm using a database every day at work, but it's too painful to full unlock it every few minutes (maximum value of inactivity being 9999s, so 2.5 hours, far from the 9 hours day of work).Ībout implementation, ideas here seem correct to me, also I'm using the two references given here (KeePassQuickUnlock and Keepass2Android) so I probably won't be of any help on this subject.īut about the quick unlock workflow, here is something that should reduce the attack possibilities:ġ - Quick unlock is not available if the database is closedĢ - On full unlock, some stuff is done and stored (from what I read, the latest option is encrypting master password with the PIN. Which is even far less secure in the end. I'm coming here, because the quick unlock is definitely one of the two missing features versus keepass (+plugins) that could make me change software.Ībout the security, indeed quick unlock is less secure than full unlock.įull unlock can be so painful (with long passwords, just to input passwords that are less long) that probably a lot of peopledisable auto-lock of database. I'm testing KeePassXC, since I'm starting to see a lot of references to it (I'm a long run user of KeePass, and KeePass2Android). I will look into KeePass2Android code to see their implementation. Sincerely, I don't really like adding another way to unlock my databases so I think we should get this right if users want this feature. The only problem in this setup is that what we call "masterpassword" can be: 1 password, 1 keyfile and/or 1 yubikey. If the PIN is wrong, delete from memory the QuickSecret so an attacker has only 1 attempt. Whenever the DB is locked again KeePassXC will ask for the PIN, decrypt the QuickSecret to get the masterpassword and the unlock the DB. Then once the DB is unlocked for the first time the QuickSecret is loaded in memory. This will be stored in the DB encrypted with the masterpassword itself. Store a new entry called KeePassXC QuickUnlock PIN as the masterpassword encrypted with the user-selected PIN (I will call this QuickSecret). We can store it like KeePassHTTP Settings but then you will need the masterpassword to access it/read it. I am not an expert on how this should be done correctly from a crypto perspective, but I am available and open to collaborations so to have this feature implemented we don't have such a filter, all entry in the DB are displayed. If this sounds still too much for you, choose 4 or more characters in the settings._ When using 3 characters and assuming 70 characters in the set of possible characters, the attacker has a 0.0003% chance of opening the file. Second: If you loose your phone someone seize your laptop and tries to open your password database, the attacker has exactly one chance to make use of QuickUnlock. _Is this safe? First: it allows you to use a really strong password, this increases safety in case someone gets your database file.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |