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

#431 Ability to have multiple master passwords / keys

open
nobody
5
2012-11-19
2005-05-26
Anonymous
No

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.

jeremym@lightpower.net

Discussion

  • Phillip Grove
    Phillip Grove
    2005-06-02

    Logged In: YES
    user_id=1289609

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

     
  • Ifni
    Ifni
    2005-07-11

    Logged In: YES
    user_id=454054

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

    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
    user_id=251974

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

    Ewout