#431 Ability to have multiple master passwords / keys


One feature that would be incredibly helpful for anyone
using KeePass in a corporate environment would be the
ability to have more than one master password that can
open the same database, or the ability to open the
same database either with a password or with a key file.
The reason for this is that we could then create
a "master key" that a sysadmin could use to open an
employee's individual keypass database in the event
that an employee has stored an important corporate
password and has been terminated, is out of town, etc.



  • Phillip Grove

    Phillip Grove - 2005-06-02

    Logged In: YES

    This would also be helpful in a small corporate environment
    so that several people could use this as a shared password

  • Ifni

    Ifni - 2005-07-11

    Logged In: YES

    This could potentially be done with a key chain style
    system, where the database is encrypted with a randomly
    generated password, and then this password is in turn
    encrypted once for each intended user with that user's
    personal password. The logistics of adding multiple users
    (presumeably with passwords known only to them) to the
    database could be tricky.

    Since there is no way to keep the randomly generated
    password safe from any of the users (they can decrypt it and
    keep it) should any user be removed, the DB password would
    have to be regenerated. Each users individual password
    remains uncompromized, eliminating the need for all the
    users to change their password each time the random password

    However, I think that this is of limited usefulness since
    any user could keep a copy of the database prior to their
    account's removal from the "official" version. They would
    not have access to new passwords, true, but the same could
    be said using the single password mechanism if the DB
    password was simply changed and the new password given to
    those still allowed access. The only problem this solves is
    distribution of a new password every time a person is
    removed from the "safe" list.

    Though individual passwords would allow some level of access
    tracking (who changed that password, or accessed it last),
    this would not be reliable as a hacked client could make any
    change it desired to the DB, including submitting bogus
    account credentials to any logging system added.

    This feature would only present the illusion of security,
    increasing the risk of DB compromize due to trust placed in
    this illusion. Every time a user is denied access to the
    DB, you must assume that all data present in the DB when
    they had access to it has been compromized, and take
    appropriate action. I'm not sure about the exact details,
    but I think that this feature might also make obtaining the
    other users private passwords much easier, since you'd have
    the cipher text and the plain text, you could feasably use
    these to obtain the key from each of the other users in the
    system. And if they believe that those keys are private,
    they might be using them elsewhere. This mechanism works
    well for private key encryption, but that would be a whole
    other layer of complexity added to KeePass.

    I suggest just using a single password (the way KP currently
    works) and changing it (and every password storedin the DB)
    each time a user is removed from the list. You could then
    implement logging by using the host OS auditing capabilities
    to monitor access to the DB. Yes, you wouldn't have node
    level auditing (i.e. you would know that person A changed
    the file, but you wouldn't know which password they
    changed), and since KP changes the DB file even on access
    (the last accessed date), this would be of limited use.
    But, since any auditing info stored in the DB itself is
    subject to modification/falsification by any user with
    access to that DB file, that's a small sacrifice. The
    KeePass client MUST be treated as untrusted as it can be
    modified. The only thing that is a reasonably safe
    assumption is that if the DB file was modified without
    disrupting its cryptographic checksum, the modifier had the
    DB password. Any information beyond that is unreliable or
    OS dependant.

  • Ewout Prangsma

    Ewout Prangsma - 2005-09-24

    Logged In: YES

    The combination of a master password OR a keyfile would be
    very helpful.


  • schissern

    schissern - 2015-01-13

    What is about the option for a Master password OR Key File for openiong the database?

  • Thaddeus Letnes

    Thaddeus Letnes - 2017-01-09

    This is becoming more important to me with Keepass clients on mobile platforms. I would prefer to use a keyfile on my PC (for ease of use) but I do not want to store those keefiles on my mobile device since it will be stored adjacent to the db.

  • wellread1

    wellread1 - 2017-01-09

    Due to the nature of encryption, an encrypted file can have only one encryption key. Due to the nature of cryptograhic hashing (the process KeePass uses to derive the encryption key from the Master Key) a given Master Key has a 1:1 relation to its encryption key. Therefore it is impossible for a KeePass database to have multiple Master Keys.

    However, KeePass or KeePass plugins provide various methods to simulate having multiple Master Keys.

    it is possible to encrypt the Master Key using multiple different passphrases, each different than the actual database Master Key. Use the KeeAutoExec plugin to use this technique.

    Also, for the special case where the Master Key consists of a master password but not a key file, it is possible to use the master password in a key file. Simply place the master password in an empty file and open the database. When prompted for the Master Key supply the path to the key file instead of the master password, KeePass will open the database. See this post for an example.

    Last edit: wellread1 2017-01-09

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