How to enter HMACOTP secret key with non-printable UTF-8 chars

Help
E. Bekker
2014-04-30
2014-05-07
  • E. Bekker
    E. Bekker
    2014-04-30

    I'm surprised this hasn't been asked before, unless I'm just completely misunderstanding the way this is used, butナ

    I'm trying to use the native HOTP feature built-in to KeePass 2.x. I've successfully entered the Counter and Secret fields in the Advanced tab for a test entry based on the example provided in the HMACOTP Placeholder documentation (http://keepass.info/help/base/placeholders.html#hmacotp) and produced the same results as the example.

    Now, the question is how do I enter a secret key that contains non-printable, UTF-8 characters into the field value box? I've tried to copy and paste the raw byte-to-UTF8 converted value and while it generates an OTP, it is not the correct one, so it's clearly mis-interpreting the non-printable character value.

    I've also tried using the UTF-8 escape sequence, e.g. \u000D, but still no luck and quick check of the KeePass code, doesn't indicate any UTF8 escape sequence processing.

     
  • wellread1
    wellread1
    2014-04-30

    Just curious why are you using non-printable characters? It is the randomness of the secret key and the size of the set that the secret key belongs to that is important (i.e. the factors that determine entropy), not the presence of hard-to-enter-by-hand characters.

     
  • E. Bekker
    E. Bekker
    2014-04-30

    I'm trying enter an existing secret that was generated for me, therefore I have no control over the key that is being generated. In most OTP-generating tools, the secret (for both HOTP and TOTP) is entered as a Base32-encoded value, including the OTP plugins for KeePass such as the "Tray TOTP" plugin.

    This is the first time I've seen the secret value entered as a UTF-8-encoded string.

    Non-printable characters are not used to strengthen the key, it's simply a question of how do I enter all the bytes.

     
  • wellread1
    wellread1
    2014-04-30

    Here is a link to a microsoft page describing how to insert special characters using the unicode value http://support.microsoft.com/kb/315684/EN-US. Method 2 produces placeholder characters in the OtpKeyProv secret key input for inputs of unicode values representing non-printable characters. I don't if they are correct.

    Beyond this suggestion you'll have to wait for someone that knows what they are doing.

     
  • E. Bekker
    E. Bekker
    2014-04-30

    Forgot about the ALT+#### feature in windows... unfortunately, it didn't work, and neither did the CharMap app. I tried a few different variations of both -- trying different fonts, converting between HEX to DEC, entering it directly in KP and entering it in another app then copying and pasting, etc.

    Thanks for the suggestion though!

     
  • E. Bekker
    E. Bekker
    2014-05-06

    Ok, so I haven't seen any more comments or ideas from knowledgeable folks or "someone that knows what they are doing" as wellread1 suggested.

    So let me just ask this...

    Let's say I have an HOTP secret whose binary value (i.e. the native bits) is the following sequence of 10 bytes:
    * 25-56-3A-9F-68-C6-DB-C4-D7-6C

    This same value can be written encoded as:
    * Base32: EVLDVH3IY3N4JV3M
    * Base64: JVY6n2jG28TXbA==

    So how would I enter this secret using UTF-8 encoding into KeePass?

     
    Last edit: E. Bekker 2014-05-06
  • AlexVallat
    AlexVallat
    2014-05-06

    Sorry, but it's simply not possible. Property values are stored internally as UTF-8 strings, not byte arrays. UTF-8 cannot encode arbitrary byte arrays. For example, there is no UTF-8 string that, when encoded, produces the byte sequence 25 56 3A 9F, mostly because 9F is greater than 7F and therefore can't be a single-byte character and 3A is less than 7F and therefore can't encode a multi-byte character.

    In order to support byte array secrets, a modification to KeePass would be required. A plugin might also be sufficient, possibly by providing a different AutoType keyword ({HMACOTPBASE64} or something).

     
  • E. Bekker
    E. Bekker
    2014-05-06

    That's what I figured, I wanted to make sure I wasn't missing something obvious, but I agree with your assessment. The current mechanism built-in to KeePass for HOTP isn't really adequate.

    Just to be clear with what you were suggesting, it's not necessary to come up with a new KeePass Placeholder -- the existing {HMACOTP} could work just fine if it supports a way to store and read an alternate encoding of the associated secret for the entry.

    My suggestion would be to leave all the current functionality in place as-is to be backward compatible, but to add support for an additional custom entry string field, such as "HmacOtp-Secret-Base32" which can be inspected for as an alternative to the default "HmacOtp-Secret" field. If the default field is not present, the code would look for the alternative and use that instead to provide the secret value.

    The alternative field can support either Base64 (as you suggested) or Base32 encoding -- I recommend Base32 because that is the most popular format that is in use today for the exchange of the secret value for both HOTP and TOTP token generators (such as Google, Amazon, Duo Security, Authy, and even some of the KeePass plugins for TOTP support like Tray TOTP).

     
  • Dominik Reichl
    Dominik Reichl
    2014-05-06

    I've now added support for the following custom entry strings: HmacOtp-Secret-Hex (to specify the secret as hex string) and HmacOtp-Secret-Base64 (to specify the secret as Base64 string).

    Here's the latest development snapshot for testing:
    http://keepass.info/filepool/KeePass_140506b.zip

    Thanks and best regards,
    Dominik

     
  • E. Bekker
    E. Bekker
    2014-05-06

    Wow, that's fast!

    Thanks for the speedy response -- I was about to see how quick I could suggest a patch that might address this, I guess you don't need my help!

     
  • E. Bekker
    E. Bekker
    2014-05-06

    I tested it out, both forms (HEX & B64) work perfectly, thanks!

    You can consider this issue closed.

     
    Last edit: E. Bekker 2014-05-06
  • Dominik Reichl
    Dominik Reichl
    2014-05-07

    Great, thanks for testing it!

    I've now added support for one more entry string: HmacOtp-Secret-Base32 (secret as Base32 string according to RFC 4648).

    Here's the latest development snapshot for testing:
    http://keepass.info/filepool/KeePass_140507.zip

    Best regards,
    Dominik