Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Feature Request - Quick Unlock

2012-04-06
2013-09-19
  • Conan Edogawa
    Conan Edogawa
    2012-04-06

    It's a feature of the other password manager that's quite intersting.
    Summary of the feature
    Quick Unlock
    Quick unlock - ******* lets you use a strong password yet still allows quick access. When you first open your password vault you are asked for your full password, but after you subsequently lock it you can unlock quickly with a partial password (configurable - by default the first four characters, as indicated in the password field). Quick Unlock is also available when you use an autotype command while the vault is locked; in this case you will be asked for both password and account (see figure on right). Note that only one partial password attempt is allowed - if you enter a wrong partial password, the full password
    -And of course it will be an opt in feature.

     
  • Paul
    Paul
    2012-04-07

    If you want easy access use a key file.

    cheers, Paul

     
  • Conan Edogawa
    Conan Edogawa
    2012-04-07

    Sounds reasonable but wouldn't it be more secure to use both? A password and a keyfile. :D

     
  • Paul
    Paul
    2012-04-07

    Not if the key file is on a USB key that you carry with you and the database is on the PC.

    cheers, Paul

     
  • Volker B.
    Volker B.
    2012-09-03

    i agree. such a feature would be nice, i was about to post on this.

    usecase: DB is opened upon system startup with long password and keyfile, which shall only be supplied short-term for opening the DB. for security reasons / tamper protection keypass should be locked during regular long-term system usage.

    different access to keypass data should be optionally treated differently:
    a) use of auto-type (read-only):
      - option to set password for it
      - option to set confirmation-popup default and setting per-password-entry
    b) unlock workspace / read-write access
      - option to set password for it

    i imagine the option to supply 2 possibly different passwords for case a) and b) which could be saved in the DB. thus not the initial credentials are required for unlocking the workspace! does locking keypass just lock the workspace or entail complete unloading the DB? this might complicate implementation…

    feedback is highly appreciated, thanks for your time and keep up the great work ;)

     
  • Volker B.
    Volker B.
    2012-09-08

    any feedback to my suggestion?

     
  • Paul
    Paul
    2012-09-10

    There have been similar suggestions for a secondary password. These have not been taken up and probably won't be - why remember 2 passwords when one is more than enough?

    cheers, Paul

     
  • Volker B.
    Volker B.
    2012-09-10

    thanks for the answer. i think with the reasonable usecase laid out such a feature would make much sense:

    suppose the DB is encrypted with a 30-digit password + keyfile. AND the keyfile is on a removable medium and usually not connected to the computer. also, the computer will only be restarted every 2-4 weeks. yet you want protection e.g. from other software trying to read passwords from opened keypass DB or while you leave the computer for a minute (and lock windows).

    supplying secure above password+keyfile is very unpractical. yet such encryption might be considered required to protect against offline attacks if the DB should get into malicious hands, e.g. consider a lost backup, the cloud, …

    sure, using a "short password" and/or a different keyfile for quicklock would compromise security, but only on the system itself AND if the user decides to use such a quick unlock feature first place.

     
  • Volker B.
    Volker B.
    2012-09-10

    uhm… can i edit posts?! it should say "and NOT lock windows".

     

  • Anonymous
    2012-09-10

    The more I read these forums, the more I don't understand the general attitude of the development of this project.  I think this request is even more of a reason to support truly 'open-sourcing' (on a public site like GitHub or BitBucket) the code.  There are people with valid ideas that can be implemented by others for the sake of the whole.  Just because the primary dev can't understand why people would want a feature - doesn't mean that he is always right.  I do software development full time, and I completely understand that many feature requests are not exactly 'well thought' even if they are well-intentioned, so I understand the developers' need to be wary of most feature requests.  However, I think some things get rejected due to rote rejection routines, or for some other terse reason (perhaps lack of time).

    I think volkb79's use case is valid - although not exactly common.  As I thought about it, I would really like this feature as well.  I typically leave my home workstation on for days on end - and I have my DB timeout to increase security - but lately I've made the timeout longer (decreasing security) since I'm tired of always typing in my longer password everytime I need a quick password.  Having a quick-unlock feature here would be ideal.

    Again, I'd be interested in helping code this, the password duplicate finder, etc…but need an easier method to assist!  Thanks for hearing me out.  Please re-consider, with an updated perspective, public source control sites.  There really isn't much overhead anymore!

    https://sourceforge.net/projects/keepass/forums/forum/329220/topic/4478457

     
  • Craig
    Craig
    2012-09-13

    I was about to post a request for a feature similar to this as well. I see major value in having a second short/quick password that can be used to unlock the workspace after the database has been opened using the master key. I would use the feature as simply a way to hide the information being presented in the user interface from onlookers.

    For example, say I am demonstrating something on my computer for person x. Since my KeePass database is one of the few things on my computer that is most personal and private, I would prefer not to show person x anything from inside it. I want to know that while KeePass is open(aka when I'm logged in to my computer), I can alt-tab through the windows without worrying about accidently exposing personal KeePass info.

    This is acceptable because I assume that when I get up from my computer, I must close the KeePass database and lock my desktop anyways. So the secondary password will never be challenged by an unknown user.

    It is simply something that forces a deliberate action to unhide the content. To unhide the content, I feel as tho a key-press, say the esc key, or even a big button that says "unhide" would suffice. Or, maybe those two options would be better than a small password, since it wouldn't give any potential threats the idea that the database key is of bruteforce-able length.

    Thoughts?

    My current, not so great, solution with Xfce is to leave KeePass open on it's own Workspace(in terms of the window manager).

    -Craig

     
  • spocko
    spocko
    2012-09-19

    Hello all. New user of KeePass 2.x here. Thanks so much for all to who have contributed to it!

    I was about to post a request for a feature similar to this as well. I see major value in having a second short/quick password that can be used to unlock the workspace after the database has been opened using the master key. I would use the feature as simply a way to hide the information being presented in the user interface from onlookers.

    I came here to post a similar feature request and found this thread. My user need is similar. I want to protect the KeePass GUI from prying eyes while the database is open. Here is more detail.

    Use Case:
    - KeePass is opened and database is unlocked via password at startup.
    - KeePass generally remains open (minimized to tray) and database remains unlocked, to support auto-type and KeeFox features
    - I don't always lock my computer when I step away briefly
    - IT also has the ability to remote desktop into my computer

    Problem:
    - If my computer is not locked, then my KeePass data is fully exposed to anyone who sits down at the keyboard. All they have to do is open the main window.
    - If IT remotes into my computer, then my KeePass data is also fully exposed

    Proposed solution:
    - I would like the option to lock the KeePass GUI (i.e. the main window) without locking the database.
    - Features like auto-type and KeeFox would remain operational while the GUI is locked
    - This could be implemented as an extension of the existing workspace lock mechanism. It does NOT need a separate password. The database password would be used to unlock the GUI or the database.
    - When locking the workspace, the user would have the option of just locking the GUI (new option) or locking both the GUI and database (same as existing lock feature).

    Of course I understand that if a person has physical or remote access to my unlocked computer, and my KeePass db is unlocked, then that person would have the ability to use my stored passwords via auto-type or KeeFox. That is less of a concern than a person being able to peruse and view my full set of KeePass data.

     
  • spocko
    spocko
    2012-09-19

    To elaborate on my previous post, a simple implementation might look like this:

    - In the Options dialog, under the Security tab, add one new checkbox: "Ask for password before restoring main window from tray"
    - If enabled, the existing Enter Master Key dialog is presented before main window is displayed. If the master key is not successfully entered, the main window is not restored.

    That's it. A simple incremental UI addition with no impact on the database.

     
  • Volker B.
    Volker B.
    2012-09-19

    spocko, nice to have another one wanting a quick unlock or similar feature :)
    but if something like this should ever be implemented i still think a more general solution to the problem, e.g. optionally also protecting you from unwanted autotype usage would be nice. 

    i still see a need (and not so hard to implement?) to differentiate between
    a) GUI-access (could still be read-only or read-write)
    b) read-only access using auto-type (GUI still locked)
    c) read/write access (special case of a))
    all optional of course. you just check a box in settings to force a popup before allowing requested access.

    also please consider that although many users apparently don't do it (guess why - currently it is unpractical), having the keyfile not easily available provides additional security, thus needing it for a quick unlock would be highly undesirable.

     
  • Jamesy
    Jamesy
    2012-09-23

    In short, i think this is a really sensible idea. To have a quick unlock that say… times out after an hour before a full unlock is required. Leave it alone for 1 minute and it quick-locks… leave it alone for an hour and it full locks. Or, alternatively, have quicklock as an option only for autotype, i think would be even better.

     
  • Jamesy
    Jamesy
    2012-09-24

    and of course only one or two tries at the quick password before full password is required

     
  • Matthew Pearce
    Matthew Pearce
    2012-10-17

    I am thinking that all that wouold be required would be a trigger action to change the master key.

    Then when you open a database a trigger action is fired which saves the database to a new Tempdata.kdbx.
    By default, this would have the same password as the original database.
    The next trigger action would change the password to a new short password which would be retrieved from a previously saved record in the existing database.
    On closing the database, Tempdata.kdbx needs to be deleted because it is less secure than the original database.

    The only problem with this is what happens to updates while you are using Tempdata.kdbx?

    Any updates to the database would need to trigger an action to save the data back to the original database and also prompt for the longer password (which could also be stored in a separate record in the database).

    After saving the data back to the original database, the datbase would once more be resaved back to Tempdata.kdbx.

    Is this technically possible?

     
  • Paul
    Paul
    2012-10-17

    Possible but what do you do with a temporary, less secure, database? You really need to erase it securely and that may require additional software. It's really the sort of thing that is best handled within KeePass, but as you've probably noticed, Dominik isn't keen.

    cheers, Paul

     
  • Matthew Pearce
    Matthew Pearce
    2012-10-17

    You ask "what do you do with a temporary, less secure, database?" The point is that this database is on your own PC so the risk must be mitigated somewhat.

    Furthermore, the advantage of being able to use a shorter password while Keepass is open is not being forced on anybody: it is an option for those prepared to trade convenience for pretty insignificant risk (in my opinion).  When investigators manage to read information from a previously deleted file, they usually need to gain access to your computer and be able to protect your disk from being overwritten while having time to examine its contents.

    This sort of opportunity is normally only afforded to officers of the law or to someone else once you have discarded your old drive. In which case, you should be responsible for erasing the data in a secure manner before disposal, right?

    Which is the riskier option: having a deleted, encrypted database on your own PC which had been encrypted using a shorter than ideal password, or keeping KeePass unlocked for long periods of time while your PC is in use?

    cheers

    matthew

     

  • Anonymous
    2012-11-13

    I wish pail459/dominik would realize that some feature requests are reasonable - and some may even be appropriate even if they don't completely understand the rationale.  Also, if they just view threads based on the numbers of responses, they will see that some thread are very popular/the community voice is loud, but they are still trying to defend a point the community wants to see implemented.  Since it's not truly 'open source' (in the sense that if I code against the 2.20 codebase, 2.21 may well break my changes…and I have no way of keeping in sync as I go along)…we can't extend this 'open source' software ourselves.  I guess it's a different flavor of OSS - the kind that leaves you wishing they really wanted the support of the community using it :)  I'll get off my soapbox for today - but it's frustrating to not be able to really embrace software I want to love!

    @mwrp - I completely agree with your premise - I work on my computer all day, but don't want the hassle of composing the master key every time I arrive from a brief walk to the printer, bathroom, etc…or even just while I haven't touched it in a while.  The idea of a 'weaker' password/pin being used to 'quick-unlock' is fantastic, and I hope it happens someday.

     
  • Paul
    Paul
    2012-11-14

    Just for the record, I don't have a say in the direction of KeePass development. I am just a contributor of ideas and a little help on the forum, though I do try to support Dominik in his decisions - don't always agree with them.

    cheers, Paul

     
  • I'd like to add my 2 cents here, since I think that the general idea of a quick unlock feature is a good one. This has already been implemented in an android app (Keepass2Android)

    http://keepass2android.codeplex.com/

    The idea is that the keepass database locks itself relatively quickly, 30 seconds to 5 minutes. The QuickUnlock feature uses the last 3 or 4 characters of your master password as a "short" password to unlock the database. Critically, you only get 1 shot to enter the short password, and if it's wrong, you have to enter the whole thing again. You don't have to remember a separate password if it's implemented this way.

    I suppose this could be a security risk, maybe if someone watches your hands, or video records you typing, or uses a keylogger. Maybe it could be coupled with an alert system, so that if the quick password is incorrect, it emails an alert to the owner of the database.

     
    • ursus
      ursus
      2013-09-19

      Exactly. It's awesome feature of Keepass2Android. I use it all the time and would like to have it on desktop.

      Feature request to KeePass for this functionality is here:
      https://sourceforge.net/p/keepass/feature-requests/1606/