PassIFox not Working when KeePass Locked -- WHY?!

Help
crosis39
2013-08-09
2013-10-16
  • crosis39

    crosis39 - 2013-08-09

    I'm new to KeePass v2.23 so please forgive my ignorance on its usage. I hope, at the very least, you can appease my concerns.

    For my Firefox browser I've installed PassIFox so that i can effortlessly log in to any online website using the login credentials pulled from KeePass. It works quite well -- i always have to use the context menu's "Fill User & Pass" but it works.

    My concern is the KeePass GUI application not only must be running but it must also be unlocked before PassIFox can actually extract the credentials. If i have KeePass locked (with master key), PassIFox will make a request, discover the locked down KeePass and then is unable to extract the credentials. What is so odd is PassIFox initially had to be granted policy access to KeePass making me think it had the appropriate details to login to KeePass, locked or not, to extract what it needed.

    I would like to use KeePass but i do not want the GUI to be always running and unlocked so that any "friend" using my system could easily see ALL my passwords for later mischief. Yes i can lock KeePass with a master key but then the Firefox PassiFox is locked out. I would have to ALWAYS reinput my master key before it can properly operate. This form of operation by KeePass seems very odd to me. What was the point of granting permission to the plugin in the first place?!

    My question: Is it possible to have KeePass securely locked down when i do not need to manage the minutia of its operation and it can simply be interacted with (read / write to dbase) by verified plugins without me having to jump through hoops? Basically work in the most sensible, painless way -- as one secure, seamless channel.

     
    Last edit: crosis39 2013-08-09
  • mstarke

    mstarke - 2013-08-09

    The credentials are stored inside the database (at least that's how KeepassHTTP does it) and PassIFox does not decrypt the pure file data. Keepass closes the file on locking hence the warning, if you want to lock a modified file to save before locking. In other words, if the database is locked, it's no decrypted. PassIFox just queries Keepass for entries and doesn't do any database encryption/decryption on it's own. That's the reason you have to unlock the database in Keepass first

     
  • crosis39

    crosis39 - 2013-08-09

    So then before PassIFox can be used i must ALWAYS have KeePass up and running with an unlocked database. It just seems so easy for a person at my system to peer into my exposed passwords. To me it seems logical to have a hidden KeePass service listen for requests, dynamically unlock the database for verified plugins, run the request and then close. Kind of like a secure server. The way it is now, to go with the RDBMS analogy it is like having my SQL Server GUI with admin access logged in to the database only because PHP is unable to make calls to the database unless the GUI is logged in.

    Is it not possible for KeePass to be running as some background service that listens for requests and not expose the full gui for all to see my full list of easily readable passwords?

     
  • crosis39

    crosis39 - 2013-08-09

    PERHAPS is there a way to better protect the exposed passwords under the EDIT ENTRY window? I mean having the standard asterisk and making it so inconvenient as requiring a simple ellipsis click <roll eyes=""> isn't what i call secure. Firstly the asterisk entry should not reveal the character count of the password (it should be a fixed # of asterisk regardless) and if the user clicks the ellipsis to reveal the password then ask for the Master Key.

    Is this possible?

     
  • wellread1

    wellread1 - 2013-08-09

    KeePass works with the database in two states:

    1. Closed/Locked (where the database is not in memory) and
    2. Unlocked (where sensitive data is in protected memory).

    It is up to the plugin to deal adequately with the two states.

    PERHAPS is there a way to better protect the exposed passwords under the EDIT ENTRY window?

    Probably not because exposed/usable = vulnerable. One can never assume that an unlocked database is secure if the computer is compromised (by software or people). KeePass can only partially protect against attacks when the database is unlocked.

    Firstly the asterisk entry should not reveal the character count of the password

    Point acknowledged, but if the password's strength is such that knowing its length is a weakness, then a stronger password should be selected. KeePass makes this easy.

    if the user clicks the ellipsis to reveal the password then ask for the Master Key. Is this possible?

    It is not possible. See the earlier comments about the two states of the database. Lock the database to render it completely secure.

     
    Last edit: wellread1 2013-08-09
  • AlexVallat

    AlexVallat - 2013-08-10

    Hmm... could be interesting to add a third state though, of "UI Locked", where the database is loaded (sensitive data in protected memory), but the UI itself is not accessible.

    You could use AutoType, and plugins like PassIFox or KeeFox would still work, but if you tried to restore the main window from minimized or trayed it would re-ask for the master password (like it can do by policy if you want to Export or Print, for example).

    It wouldn't be cryptographically secure, but the passwords would have the in-memory protection, and might be a potentially useful state to be in. The only obvious down-side to it would be user-eduction about the relative security of their data:

    Locked: Secure against anything without the key
    UI-locked: Secure against non-keepass-specific malicious software and malicious local users, except those entries which can be auto-typed or are otherwise exposed by a plugin.
    Unlocked: Secure against non-keepass-specific malicious software

    Makes it more complicated to understand than the simple binary locked/unlocked which it seems can already be difficult enough at times!

    Alex

     
    • wellread1

      wellread1 - 2013-08-10

      Alex, The developer has considered and discounted disabling the UI, presumably for the very reason you point out. I imagine the principal advantage of locking the UI is one of convenience, either to:

      1. Use a weaker "working" password, or
      2. To improve performance by avoiding database decryption.

      A plugin ought to be able to provide an interface to access the built KeePass decryption engine, so the problem really comes down to (1), the convenience of using a weaker password in the memory protected mode.

      The difficulty with encouraging users to keep their database in protected memory using a weaker password is that they will do this for extended periods. Though the contrary argument can also be made, namely that users will keep the database in protected memory for extended periods because the Master Key is difficult to use. My personal view is that it is better that the user understand they are using a weaker form of protection (in protected memory mode) than to obscure it behind a weak password.

      It is already possible to create a KeePass configuration that can be unlocked using a "working" Master Key by using the KeeAutoExec plugin, a dedicated "auto-open" database, and a trigger to select the "auto-open" database whenever the database is locked (KeePass 2.21 or later required). This kind of configuration is suitable when the database is used in a secure environment but the user also wants the ability to move/use the main database in less secure environments.

       
      Last edit: wellread1 2013-08-10
      • AlexVallat

        AlexVallat - 2013-08-10

        Ah well, if it's already been ruled out by Dominik then fair enough.

        I'd still like to answer your post, though, if I may.

        The purpose of locking the UI as proposed here wouldn't be for a weaker password (I proposed the same Master Password be re-entered to unlock) or performance, but rather to provide an intermediate level of security sufficient for a specific category of attack: the human non-keepass-specific attack. Most likely to be encountered on a shared family PC, for example. You probably wouldn't expect your brother to perform some sophisticated attack based on knowledge of KeePass, but if he sees it running minimised might be tempted to browse around to see if there's anything interesting in it.

        I'd say that fits in between the software keepass-specific (requires full lock to protect) and the software non-keepass-specific (generally protected against by in-memory protection even when unlocked), and could usefully be treated differently.

        I appreciate that the issue of user-overconfidence in it, though, if they don't fully understand what's going on it could give the impression of being more secure than it actually is.

        On the other hand, I'd class it as the same sort of functionality as the existing policies for requiring a key re-entry for Export and Print. It's not that it would be impossible to extract all the data from an unlocked database with these policies turned on, but it's reasonable to not want it to be obvious, quick or easy to do so.

        Alex

         
  • wellread1

    wellread1 - 2013-08-10

    The purpose of locking the UI as proposed here wouldn't be for a weaker password (I proposed the same Master Password be re-entered to unlock) or performance, but rather to provide an intermediate level of security sufficient for a specific category of attack: the human non-keepass-specific attack.

    If you want to use the Master Key then I am not sure I understand your difficulty. The exact details of what you want to accomplish are important, but in general, KeePass has already implemented this feature fully with superior security via the Lock/Un-lock procedure. A locked database can initiate an auto-type, and prompts to unlock the database so that it can access the data. If using global hot-key auto-type or clicking on a shortcut is not a satisfactory means of initiating the unlocking procedure, then you can create a global hot-key (and limit KeePass to a single instance) for unlocking. I am not a developer or programmer but it seems likely that a plugin developer could likely incorporate similar capabilities in their plugin.

    On the other hand, I'd class it {locking/unlocking the UI} as the same sort of functionality as the existing policies for requiring a key re-entry for Export and Print.

    These kinds of secondary security features are definitely judgment calls. But the developer cannot avoid but be seen as endorsing any feature that is incorporated into KeePass proper. On the other hand, a plugin by a third party developer is not bound by this consideration.

     
    • AlexVallat

      AlexVallat - 2013-08-11

      I am not sure I understand your difficulty

      The idea would be, that when in this UI-locked state, the master key would not be required to perform AutoType or for plugins to be able to access the database. It's lesser security than locking the database, but greater than leaving it always unlocked (against the specific categories of attack already discussed).

      Doesn't look like it's going to happen, though.

       
      • wellread1

        wellread1 - 2013-08-11

        Doesn't look like it's going to happen, though.

        I can see the value of this feature implemented in a plugin that needs it. Not so much as a general UI feature.

         
  • gaberad

    gaberad - 2013-10-16

    I was looking for something to do exactly what you were wanting too, so I made a plugin that works for my purposes.

    Just a note about my setup: I have one database, and have it set so Keepass minimizes after opening a database. I also have an auto-save trigger that automatically save the db when an entry is added/updated (http://www.mydigitallife.info/how-to-auto-save-the-database-in-keepass-password-safe/).

    What this plugin does is when it detects that Keepass is un-minimized, it:
    1. Closes the active database
    2. Temporarily stores the current 'minimize after opening' option
    3. Sets the 'minimize after opening' option off
    4. Re-opens the database (which then asks for the master password/credentials)
    5. Restores the 'minimize after opening' option

    A couple of things to note:
    1. It closes/re-opens rather than locking/unlocking because I couldn't get the main form to unminimize after unlocking.
    2. It needs to temp store then restore the 'minimize after opening' option, because if the option is on and you don't turn it off prior to opening a database, it immediately minimizes the main form, which effectively creates a opening/minimizing loop.
    3. It doesn't save before closing, because the SaveDatabase method and some methods inside SaveDatabase are private and inaccessible to the plugin api. Since I have the auto-save trigger it's not an issue for me.

    The .plgx and source is in the attached .rar file, feel free to do what ever you want with them.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks