How to create a template with multiple password fields?

mxx
2013-09-26
2013-10-01
  • mxx
    mxx
    2013-09-26

    I'm trying to create a template that will be used to store server-relevant info:
    multiple IPs, multiple ssh accounts, ssl keys, mysql accounts, firewall configs, other server-specific info.
    One of the issues I encoutered while poking around with KPEntryTemplate plugin is it seems to allow only 1 set of password+confirm_password fields. I'd like to have multiple sets to make sure entered passwords are accurate.

    Alternatively, if anybody already solved such problem, if possible I'd like to see other people's templates.

     
  • wellread1
    wellread1
    2013-09-26

    While an input interface could require validation for any field, default KeePass only provides this capability for the password field, and I am not aware that any plugins have implemented validation of additional fields in a single entry.

    The way I would approach organizing a group of related entries would be to use a hierarchical set of groups e.g. place each server sub-account entry in a server group. The hierarchy could be a deep as needed. Alternatively you could "link" the sub-account entries to a "master" entry using field references. Likely candidate fields for linking are the Title, URL or Notes. You can also place a field reference (e.g. a Title field ref) in a custom field to use the custom field to "link" to the master entry.

    There are several advantages to these methods:

    • KeePass View would remain fairly compact. It would be easy to display the most descriptive fields without a lot of horizontal scrolling.
    • Search would be straightforward. Advanced search on fields like Title would be more productive.
    • Entry icons can be used effectively to distinguish sub-account types.
     
    Last edit: wellread1 2013-09-26
    • mxx
      mxx
      2013-09-26

      Hmm.. interesting. I was not aware of field references. Seems like this could be an interesting idea/workaround.
      Will this work in KeePass-compatible clients such as android/ios/osx?

       
      Last edit: mxx 2013-09-26
      • wellread1
        wellread1
        2013-09-26

        That is an entirely new and very restrictive requirement. All the cross platform implementations of KeePass, with the exception of running KeePass on mono, are third party applications. The feature set that a third party developer chooses to implement is entirely up to the third party. KeePassDroid for example does not dereference field references.

        Plugins are almost certainly unsupported.

        If you want cross platform, your scheme must use a least common denominator feature set. This probably limits you to the group organization scheme; at best.

         
        Last edit: wellread1 2013-09-26
  • steelej
    steelej
    2013-09-26

    I am not really sure exactly what you are trying to do. This answer might be addressing a different problem.

    I use KeyPass to store logon information for multiple computers. I choose which computer to log into. You can often encode the logon parameters into the URL field and use field references to access the user name and password fields. I think you can access custom fields as well. You don't use Title matching in this case. You can use Autotype however.

    I access the computers using TeamViewer and the URL contains the command line parameters to execute the executable. I have bout 30 of these and have a standard Template that I populate for each new computer.

    TeamViewer is a custom URL override
    cmd://"C:\Program Files (x86)\TeamViewer\Version8\TeamViewer.exe" {URL:RMVSCM}

    My URL entry is therefore
    teamviewer:// -i "{USERNAME}" -P "{PASSWORD}"

    For each entry I keep the type of information you mention. This is for information that is not needed for logging onto the device but is needed for reference.

    I also use this technique for PuTTy for SSH access e.g. to my NAS device.

    I have looked at the technique for RDP access to Windows Servers. I think it works but have not yet needed to use it.

    If you have a common user ID and password you can place this in a standard KeePass entry and reference it from elsewhere.

    By being creative and using cross referencing I have not yet found a case I cannot manage.

    This was the thread which solved my problem
    https://sourceforge.net/p/keepass/discussion/329221/thread/ccea5ba5#04d0

     
    • mxx
      mxx
      2013-09-27

      I'm not looking for a way to lunch putty or teamviewer.
      I'm looking for a way to best organize a lot of related information.

      Let's say I'm a consultant that does web development and hosting.
      Each of my clients have a hosting account, with such account I can have many servers, which contain multiple various usernames, passwords, certificates and keys.

      I feel that nesting clients->server->account type->account will be too clunky to setup and use. For example when I need to get all info for a related server I'll need to jump through multiple groups to collect such info.

       
      Last edit: mxx 2013-09-27
  • wellread1
    wellread1
    2013-09-26

     
    Last edit: wellread1 2013-09-26
  • wellread1
    wellread1
    2013-09-27

    If you analyze your organizational needs in a little more detail you may be able to simplify the hierarchical scheme considerably.

    For example, if you have a lot of clients, each with with a lot of servers, you probably should break each client into its own database. That way you minimize the risk of exposing one client's secrets to another client, or of losing control of all of your client secrets in one event.

    On the other hand if one level of the the organizational hierarchy only contains a few records, e.g. a client only has a few servers, you can collapse two group levels into one by using the entry title, e.g. name each entry by client-servername, servername-accounttype or accounttype-account, for accounts you could use a Title such as: accounttype-{username} You could also make use of entry icons e.g. to distinguish account types, and you can use a field reference linking scheme e.g. to systematize your entry naming (For example the entry title, or a custom field could list the complete hierarchy rendering each entry title unique and searchable based on its position in the hierarchy).

    Hierarchical arrangements of data collection are ubiquitous (think OS file system) and there are very workable ways of using such schemes. Trying to collapse each clients' data into one huge data blob contained in an entry seems cumbersome.

     
    Last edit: wellread1 2013-09-27
    • mxx
      mxx
      2013-09-27

      I think splitting each client into its down database file is an overkill and will be a major hassle to manage.
      Clients themselves don't have access to these files. They are for our internal use only. Furthermore, these files will be backed up in multiple versions.
      Collapsing client-servername will create an extremely long list, I think that also will be cumbersome to work with.

      I agree, I would not want to dump everything into a single client entry. But I would like to group things on per-server basis.

      While trying to figure this out I created a spreadsheet with these server-specific entries:
      (I'm not sure why it indents thing. it's one just regular bullets)

      • Public IP
      • Service IP
      • Private IP
      • Root password
      • Multiple ssh users

      • MySQL Root

      • DB replication user
      • DB replication pass

      • DB name

      • DB Admin user
      • DB Admin password

      • DB App user

      • DB App password

      • Apache Status URL

      • Munin URL
      • Munin login
      • Munin password
       
      Last edit: mxx 2013-09-27
      • wellread1
        wellread1
        2013-09-27

        Based on that info I see 4 main entries (assuming one admin account per service), X user entries in one sub-group, and no need of field references unless there is a more complex organization. Of course the exact details may not match your exact situation.

        Groupname: Clientname; Client's corporate ICON
        Title: servername; username/password; URL (apache status); custom fields: Public IP; Sevice IP; Private IP; ssh private key; server or client's corporate ICON
        Title: SQLname - servername; username/password; SQL ICON
        Title: DBname - servername; username/password; DB ICON
        Title: Munin - servername; username/password; URL; Munin ICON

        SubGroup of Clients: User Accounts; User ICON
        Title: ssh account OR ssh - {Username}; username/password or user's ssh private key; SSH ICON
        Title: SQL account OR SQL - {Username}; username/password; SQL ICON
        Title: DB App account OR DB - {Username}; username/password; DBApp ICON
        Title: DB replication account OR DBR - {Username}; username/password; DBApp ICON
        etc...

        If there are multiple admin accounts for each service, then a second subgroup of the main Client group may be useful: e.g. Admin Accounts; Adminstrator ICON

        If you are concerned that the entries might get scrambled over time, add the client name to the entry titles.

         
        Last edit: wellread1 2013-09-27
  • wellread1
    wellread1
    2013-09-27

    I would use a rigorous entry naming convention, and use groups to organize in whatever way was most convenient.

     
  • Paul
    Paul
    2013-10-01

    I don't see a need to have "repeat" entries for those passwords, they are for internal use only so copy / paste should be fine. Thus you only need one record per server under the client group.

    cheers, Paul