Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1896 {PASSWORD:literal}

KeePass_2.x
open
nobody
None
5
2014-07-07
2014-07-03
sambowry
No

Please extend the syntax of the {PASSWORD} placeholder to allow literal password embedding into the middle of string fields.

For example an URL field like: "ilo://myUser:{PASSWORD:myPassword}@address" would nice to show on the screen as "ilo://myUser:*@address" (if password hiding is active).

Discussion

  • Paul
    Paul
    2014-07-03

    Where is the password displayed on screen that this is a requirement?

    cheers, Paul

     
  • As sambowry says, a password will be displayed on screen in the URL field - if you use the URL format that includes the raw username and password as part of the address (which - BTW to sambowry - is not a secure way of sending that info, let alone storing it). What really should be done here (assuming that one can't send the credentials in any other way) is to use a placeholder referring to the contents of the password field in the URL field, not by typing the password itself in the URL field.

    That is, instead of:
    ilo://myUser:myPassword@address
    it should be:
    ilo://{USERNAME}:{PASSWORD}@address
    (assuming the USERNAME field for this record contains myUser and the PASSWORD field contains myPassword).

     
    Last edit: T. Bug Reporter 2014-07-03
  • sambowry
    sambowry
    2014-07-03

    I use the developer version of KeePass, it allows many URL fields, not just one. See {BASE:...}.

    I store iLO passwords in ilo:// URLs, because i like compactness. No need to create separate iLO entries.

    The missing feature is the handling of the passwords inside URLs similarly to the {PASSWORD} and {REF:P@...} cases.

     
  • (I'm not familiar with the developer version of KeePass - I can't even find such a thing on the site - and I'm also unfamiliar with this "iLO" system you're referring to, so I apologize in advance if what I'm suggesting seems ignorant or stupid.)

    I agree that for the sake of completeness, URLs containing cleartext passwords should have those passwords hidden from view, but one way to work around this limitation with the current (non-developer) version of KeePass until it gets addressed would be to store the sensitive parts of the URL in other (hidden) fields and to use references to those fields in the URL field.

    Or perhaps your use case already includes many custom fields and adding more would make things too unwieldy?

     
  • sambowry
    sambowry
    2014-07-04

    I think the latest version is: http://keepass.info/filepool/KeePass_140628b.zip found here: http://sourceforge.net/p/keepass/bugs/1254/

    Fortunately Dominik does not publish the source code of the development version. It allows me to just request something, no need to spend hours with making a good patch :-)

    Another workaround is to make a plugin which overrides KeePass placeholder compilation. I made it as an experiment. KPEnchancedEntryView now shows "+++++" instead of {PASSWORD:qwert} for me. It is not a solution because the handling of this new placeholder differs from the handling of the other placeholders: {PASSWORD} and {REF:P@...}.

    I use many custom fields, because i don't like creating many entries related to one server. If i would have too many fields, i would change to "side by side" view instead.

     
  • Paul
    Paul
    2014-07-04

    As this is an unusual use I think the plug-in route is the correct one. Maybe use a different placeholder, {HIDEPASSWORD}? The downside is you can't then use the entries without the plug-in.

    cheers, Paul

     
  • sambowry
    sambowry
    2014-07-04

    Thank You for the idea, here is my {HIDEPASSWORD} hack:

    ilo://myUsername:{PASSWORD:myPassword}@iloAddress{C:{PASSWORD}

    This format force KPEnchancedEntryView to show the hide/unhide button at the end of the field :-)

     
    Last edit: sambowry 2014-07-04
  • Paul
    Paul
    2014-07-05

    Does this use your plug-in?
    This still seems to change the behaviour of the PASSWORD place holder, was that the idea?
    I assume the lack of a final right brace is a typo?

    cheers, Paul

     
  • sambowry
    sambowry
    2014-07-06

    {PASSWORD:myPassword} is handled by my plugin
    {C:{PASSWORD} is handled by KPEnchancedEntryView, no typo, it works this way

     
  • Paul
    Paul
    2014-07-07

    Testing this in KeePass 2.27 without the KPEnchancedEntryView plug-in displays the following - note the second version of the URL:
    URL: ilo://myUsername:{PASSWORD:myPassword}@iloAddress{C:** - ilo://myUsername:{PASSWORD:myPassword}@iloAddress{C:{PASSWORD}

    With the plug-in the same view is shown in the standard KeePass column view and the KPEnchancedEntryView "All Text" pane, but not the "Fields" pane.

    cheers, Paul