Use Yubikey challenge-response secret to decrypt database

[Brocklobsta]

Is it possible to use the Yubikey challenge-response secret (hex string) to decrypt a KeePassXC database using the KeePassXC yubichallenge implementation? I like how you guys implement the Yubichallenge btw, it is much closer to a true 2fa.

Expected Behavior

Have some way to enter the yubikey challenge-response secret when decrypting the database

Current Behavior

No option to input challenge-response secret

Possible Solution

Add a "Recovery" box to the challenge-response area that allows a hex string to be entered and used for the challenge response computation.

Steps to Reproduce (for bugs)

1: Create a database using Yubikey challenge-response (save the secret used the configure the yubikey) 2: try and decrypt the database without the use of the yubikey and only the secret.

Context

Basically since I own a Yubikey 4 and not a NEO variant, I am unable to use the Yubichallenge app to decrypt my database since it is not possible to perform a challenge-response over a USB connection with android at the time of this message. My solution to save my Yubikey secret to an encrypted android file storage and copy and paste when I need to decrypt my database.

Debug Info

KeePassXC - 2.3.1 Revision: REVISION

Libraries:

• LIBS

Operating system: Windows CPU architecture: Intel x64/x86 Kernel: Win10

Enabled extensions:

• EXTENSIONS

[droidmonkey]

This would offer no additional protection over a secure master password. The whole point of the yubikey is to be a second factor. Recommend buying a Neo.

If you must use this method, just append the yubikey hex to your master password. It has the same logical effect.

[Brocklobsta]

Hey droidmonkey,

This would be useful in the situation where a yubikey is lost, but the user saved the secret.

[droidmonkey]

Interesting scenario

[TheZ3ro]

This would be useful in the situation where a yubikey is lost, but the user saved the secret.

Note: If you have another yubikey you can use the saved secret on that as well.

[Brocklobsta]

Yeah, I agree. That is the only solution. That is a $40 and week of shipping solution though.

[CueHD]

This would be useful in the situation where a yubikey is lost, but the user saved the secret.

Try this with your secret key: https://www.freeformatter.com/hmac-generator.html If it works, you have a way back into your database in case of a lost YubiKey.

If anything regarding this were integrated into KeepassXC, I would prefer a Challenge-Response generator that uses the inputted secret key. This keeps the superior method of using the response instead of the secret while providing an integrated method of recovery.

[TheZ3ro]

@CueHD it's exactly what I was thinking. Adding a dummy yubikey that will emulate the challenge-response and use the response like KeePassXC is already doing now

[Brocklobsta]

@CueHD

So what you are saying is for me to hash the database (SHA-1?) and then use that string and my secret to compute the HMAC using the website (https://www.freeformatter.com/hmac-generator.html).

Now with the HMAC string computed, do I prepend or append this string to my password? Is this string case-sensitive?

[droidmonkey]

Appending it to your password "should" work.

[Brocklobsta]

I am unsuccessful in decrypting my database with the following procedure:

1. Perform SHA1 on the database file (used sha1sum command)
2. Generate HMAC-SHA1 response using the Yubikey Personalization Tool's Challenge-Response Tester.
3. Append response to Password in the Password box (Key file and Challenge Response left unchecked).

It looks like the strings are case sensitive, so I have been using all lowercase.

[Brocklobsta]

@droidmonkey, @CueHD , @TheZ3ro

So far I have been unsuccessful in decrypting my database with a manual challenge-response. Could you guys try this test on your end? I think my hex values are being interpreted as base64 so I'm getting different responses based on the case of my A-F values. The Yubikey Personalization tool has a challenge-response tool that should be useful.

[droidmonkey]

As this point you would have had your shiny new yubikey by now. :grin:

I do not have any free time this week (or recently), this is a complex problem.

Quick question, is your database still on kdbx3? If so then appending to the password will not work.

[TheZ3ro]

I think we should add this feature to the cli version, I don't really see much usage for this in the desktop version but maybe can be useful in cli to recover broken database or things like that.

I'm referring to this proposal -> https://github.com/keepassxreboot/keepassxc/issues/1734#issuecomment-376345124

[droidmonkey]

Yeah i agree with this

[Brocklobsta]

Hey @droidmonkey,

I was indeed using a 3.1 database. I switched to .kdbx 4 and am now getting an HMAC mismatch error (sha256sum my database and use that 64char output as the challenge. Appended that response to my password). I agree that a CLI interface will do the trick, but a checkbox and secret field wouldn't hurt. Honestly some documentation on how to manually compute the response and how to use that to unlock the database would suffice as well.

[vronp]

I'm new to KP but have a couple comments. A "recovery" mode would be very nice IMO just like the feature shown in this version of KP: http://www.kahusecurity.com/2014/11/securing-keepass-with-a-second-factor/

Also, for what it's worth, I setup a Neo with KPXC and it works fine. I had 3 Yubikey Standard keys laying around so I tried to turn one of them into a backup. None of the 3 generate the same string. I'm quite sure I'm doing everything right. Scratching my head on this and I opened a ticket with Yubico. I'll let everyone know what they have to say.

A backup Neo apparently is a solution but it shouldn't be required IMO.

[TheZ3ro]

None of the 3 generate the same string.

You don't have to "generate" a new secret, you must set as secret the one you generated in your primary Yubikey you registered in KPXC (the Neo I guess)

[WiLars]

Hi everyone, i found this post, because i was interested in being able to decrypt my database if my yubikey was lost, before i encrypted my real database using challenge response. Because i tried the suggestions above and it didn't work for my testdatabase (aes and argon2), and didn't really make much sense of the source code, i logged the communication of keepassxc and the yubikey with wireshark: what i found out this way is the following:

• the challenge is 32 byte long, so probably sha256.
• it is not sha256 of the db-file
• it is not sha256 of the password
• the challenge is independent of the password that is entered, but depends on the database file

I did not find a way to open the database with the intercepted response:

• prepending or appending the response in hex, base64 or bytes converted to ascii to the password does not work
• the response without password in the formats above does not work either

I don't know if there is still interest in this, but maybe I save some people the time trying this themselves.

Apart from that, thanks for all the work, I am really glad keepassxc exists!

[droidmonkey]

The best (and probably only) way to truly prevent issues when you lose or destroy your yubikey is to create two and store the other in a safe. Other than that, printing the csv output after creating your CR load will allow you to recreate the key with a new one.

[WiLars]

Thank you for the fast response! I'm afraid it is really the only solution, but i was hopeful to save the 50€ :D

[droidmonkey]

Its a hardware key for a reason :wink:

[WiLars]

I have found a way to decrypt the yubikey challenge-response emcrypted database without a yubikey:

1. obtain the challenge: -opening the database file with a hex editor you'll find the challenge from bytes 0xc5 to 0xe4 for a database with argon2 edit: corrected the address -for a keepass 3.1 aes-kdf encrpyted file i found it at 0x2b (but i'm not sure if you can open the database with it, because the internal mechanisms of working with the response seem to be different. didn't try because it's not relevant to me)

2. calculate the response with an online tool (hmac-sha1) -note: you need to know your secret, obviously, so make sure to save it somewhere save, when programming the yubikey. -set everything in the tool to hex, the key must be entered without spaces.

3. using a hex editor enter the bytes you get as the response and save as a file.

4. open keepassxc, enter your password and take the file as the keyfile. -appending the response to your password does noes not work, if i understood correctly, because there is some hashing involved in combining the keys.

5. enjoy your database despite having lost your yubikey.

Of course, I can't guarantee that this always works, but for me it's good enough to not buy a second yubikey as a backup. I think it's more a possibility to access your database while waiting for the shipment of a new yubikey.

[seatedscribe]

Wow, so basically you defiled the very meaning for a piece of hardware! :)

On Sun, 26 Aug 2018, 12:38 WiLars, [email protected] wrote:

I have found a way to decrypt the yubikey challenge-response emcrypted database without a yubikey:

obtain the challenge: -opening the database file with a hex editor you'll find the challenge from bytes 0xc5 to 0x4e for a database with argon2 -for a keepass 3.1 aes-kdf encrpyted file i found it at 0x2b (but i'm not sure if you can open the database with it, because the internal mechanisms of working with the response seem to be different. didn't try because it's not relevant to me) 2.

calculate the response with an online tool https://www.liavaag.org/English/SHA-Generator/HMAC/ (hmac-sha1) -note: you need to know your secret, obviously, so make sure to save it somewhere save, when programming the yubikey. -set everything in the tool to hex, the key must be entered without spaces. 3.

using a hex editor enter the bytes you get as the response and save as a file. 4.

open keepassxc, enter your password and take the file as the keyfile. -appending the response to your password does noes not work, if i understood correctly, because there is some hashing involved in combining the keys. 5.

enjoy your database despite having lost your yubikey.

Of course, I can't guarantee that this always works, but for me it's good enough to not buy a second yubikey as a backup. I think it's more a possibility to access your database while waiting for the shipment of a new yubikey.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/keepassxreboot/keepassxc/issues/1734#issuecomment-416029033, or mute the thread https://github.com/notifications/unsubscribe-auth/AMqpZKW8Skohp34IuGztORKG_VGiGnL1ks5uUnqhgaJpZM4Sskei .

[phoerious]

Well, it's just a piece if secret binary code. It's more secure to have dedicated hardware deliver it, but you can also do it in software.

[WiLars]

I think if you have your binary secret in a safe and only offline it is nearly as save, as if you had a second yubikey in there. Of course in that case you can not be sure if it has been duplicated, which can't be done with the yubikey afiak. For safety reasons you should always be sure to delete the yubikey config file after programming, because the secret is saved in there.

[CueHD]

Great find WiLars. I think that being able to use the keyfile is a perfect recovery option. The only hassle is that one would need to generate a new one every time the master password is changed.

I also like that it is the response instead of the secret that needs to be in the keyfile. This keeps the secret safe in the YubiKey.

[yeah-mike]

I have found a way to decrypt the yubikey challenge-response emcrypted database without a yubikey:

1. obtain the challenge: -opening the database file with a hex editor you'll find the challenge from bytes 0xc5 to 0x4e for a database with argon2 -for a keepass 3.1 aes-kdf encrpyted file i found it at 0x2b (but i'm not sure if you can open the database with it, because the internal mechanisms of working with the response seem to be different. didn't try because it's not relevant to me)
2. calculate the response with an online tool (hmac-sha1) -note: you need to know your secret, obviously, so make sure to save it somewhere save, when programming the yubikey. -set everything in the tool to hex, the key must be entered without spaces.
3. using a hex editor enter the bytes you get as the response and save as a file.
4. open keepassxc, enter your password and take the file as the keyfile. -appending the response to your password does noes not work, if i understood correctly, because there is some hashing involved in combining the keys.
5. enjoy your database despite having lost your yubikey.

Of course, I can't guarantee that this always works, but for me it's good enough to not buy a second yubikey as a backup. I think it's more a possibility to access your database while waiting for the shipment of a new yubikey.

Hi Wilars,

Just wondering if this is recovery procedure is still working for you?

1. I installed KeepassXC 2.3.4 today and created a new database using argon2 as the KDF.
2. I set the master key as Challenge-Response using my Yubikey (with known secret)
3. I opened the database with a hex editor and copied the bytes 0xc5 to 0xe4 (not sure if your post contained a typo?)
4. After running through the remainder of the steps to generate a key file, I sget the error "Wrong key or database file is corrupt. (HMAC mismatch)" when I try to open the database with my key file.

Any suggestions?

[WiLars]

Hi yeah-mike, I am currently using Keepassxc 2.3.3 and could just verify the above method. You are of course right: The challenge is 0xc5 to 0xe4, so 32 bytes.

Have you used a password or only the Yubikey? Without a password I was not able to open the database. In that case the challenge is from 0x29 to 0x48 (only tried it with one file). I was able to calculate the correct response (as verified by wireshark), however I was not able to open the database by using a keyfile. I think because of the way the masterkey is calculated from the different components, it is not possible to open the database with a keyfile in this case. Even if it was possible to open the Database this way, I strongly advise to use a password, otherwise what is the point of a "second" factor?

[0x696c4f]

I wrote a bash script to automate this. Not beautiful but working :)

[droidmonkey]

Please post as a gist, thank you.