17

I have got a YubiKey NEO recently (and a bit disappointed that you can only have two activated second factor authentication methods out of all the listed).

In password managers those support YubiKey, Password Safe is open-source and works locally. It can be configured to authenticate using YubiKey HMAC-SHA1 Challenge-Response. I am confused how it is possible to make a secure challenge-response mechanism securely with just two parties: (1) my local PC, and (2) YubiKey. (Related documentation)

In fact, what is the advantage of sending Master Password to YubiKey, get the response and decrypt database using it? Now, YubiKey response is our static password, which is available in the memory and all the places Master Password can be leaked.

They have implemented it for fun? or I am missing some points?

3
  • Did you found the answer? Could you share it? Is the resulting key generated in then YubiKey constant and just a replacement for passphrase?
    – atok
    Nov 18, 2015 at 9:06
  • @atok Unfortunately your statement is correct. Using YubiKey locally is almost a funny thing, and prevents simplest methods of attacks, not something it intended to do.
    – Kousha
    Nov 18, 2015 at 21:44
  • I find it the descriptions of use-cases at yubico.com/applications lacking on this kind of information. They just glance over the fact that some of those are just weak from security standpoint.
    – atok
    Nov 19, 2015 at 9:14

6 Answers 6

6

The source code of Password Safe is open source so you're free to do what I did: check.

A HMAC takes two inputs: the key and the data. What PS does with the YubiKey is take your input as data and send it to the YubiKey. The key is in the YubiKey itself and stays there.

So, the sequence of event is the following:

  1. You enter your passphrase.
  2. The software sends that passphrase to the YubiKey
  3. The YubiKey performs a HMAC using your passphrase as input and the (internally stored) secret key.
  4. The resulting value is sent back to the application and is used for unlocking your database.

So the system is still safe as long as the various crypto elements are safe: the database REAL passphrase is the result of the HMAC operation, the HMAC is made of the secret key, which stays on your 2FA device and your own master password, which you enter through your computer.

3
  • 3
    Thanks for description, however my question is not how Password Safe works. I have described what you have mentioned in my third paragraph if you review. I have also reviewed the source code. The question is about Challenge-Response of a static value (Master Password) that does not make sense. Challenge-response is not made to always use for a non-variable challenge. We have applied a HMAC-SHA1 on master password, and HMAC-SHA1 of our Master Password is now our Master Password! Its not safe by any mean.
    – Kousha
    Jun 12, 2015 at 10:43
  • I believe that this is just the fact that they use the challenge-response system on UbiKey to generate the DB key. The same system I described could be used by a remote server to verify your knowledge of the private key
    – Stephane
    Jun 12, 2015 at 12:13
  • 2
    As its mentioned in my question details in the first place, we all know that they use challenge-response to generate DB key. I am asking about security measures, and their possible security issues. Not what is challenge-response, and we all know that challenge-response should be used when a remote server is available. Please read the question title and my emphasize on LOCALLY
    – Kousha
    Jun 13, 2015 at 12:44
4

You are missing some points.

If someone steals a copy of your Password Safe database file they will not be able to unlock it unless they also have physical possession of your yubikey (Even if they already know what your Pass Phrase is).

Of course, if an attacker has a level of access to your system where they can read memory then you are screwed as soon as you unlock your Password Safe database no matter how many yubikeys you own.

One advantage to linking your yubikey to Password Safe is that you can feel a little better about backing up your Password Safe database file to the cloud.

3
  • Password Managers are password managers, single point of failure! Currently, Password Safe has several methods which make it complicated for a simple keylogger to steal the password. So, the attack concern is related to specially programmed malware to steal Password Safe data. YubiKey+Password Safe can not solve this issue. When attacker software get master password in my pc, they can pass it to YubiKey in realtime and get the response, and thats all (just we consider that access to memory is difficult).
    – Kousha
    Jun 15, 2015 at 12:05
  • 1
    You can and should configure your Yubikey to require a finger touch in order to proceed with a challenge-response request. That way malware will be not be able access the yubikey without your knowledge.
    – Michael
    Jun 16, 2015 at 13:56
  • Seems logical. However, the core problem is still there, it is not safe enough as a real "two-step" authentication method.
    – Kousha
    Nov 18, 2015 at 21:42
3

I do not specifically resolve any of the original questions here concerning the purpose of Yubikey with Password Safe, but I think the experiment I performed can shed some light on the situation.

I have confirmed that @Kousha is correct: the Yubikey response simply becomes the static password.

Verify as described below. (I wanted to provide the following code to help the poster at Password Safe on Source Forge, but I do not have an account to do so.)

Password Safe Yubikey Responses from the Secret Key

A Yubikey response may be generated in a straightforward manner with HMAC-SHA1 and the Yubikey's secret key, but generating the Password Safe Yubikey response is a bit more involved because of null characters and operating system incompatibilities. (Essentially, one has to insert a null byte between every original byte in the challenge.) In addition, Yubikey challenges get parsed. In short, on a Linux computer, if key stores the Secret Key in hexadecimal form with 40 hexits and message stores the challenge, then the following command should return the Password Safe Yubikey response:

printf $message |
  xxd -p | sed 's/../&00/g' |
  sed 's/00$//' | cut -c -63 | xxd -r -p |
  openssl dgst -sha1 -mac HMAC -macopt "hexkey:$key" -binary |
  xxd -p

If possible, you might want to write a temporary Secret Key onto the Yubikey and use a challenge other than your real password for the verification—I am not familiar with how computers store variables or other related security issues. (I'd be happy to learn if anyone has knowledge about this.) You could at least hide the typed characters using stty. The following script prompts for the Secret Key and challenge without displaying them, and then outputs the Password Hash Yubikey response.

#!/usr/bin/env bash
stty -echo
printf "shared secret key (40 hexits): "
read HMACSHA1_key
if [ -z "$HMACSHA1_key" ]; then
    stty echo
    printf '\n    Empty input. Exiting.\n'
    exit 1
fi
if [ ${#HMACSHA1_key} -ne 40 ]; then
    stty echo
    printf '\n    Need exactly 40 characters. Exiting.\n'
    exit 1
fi
HMACSHA1_no_space="${HMACSHA1_key/ /}"
if [ ${#HMACSHA1_no_space} -ne 40 ]; then
    stty echo
    printf '\n    No spaces. Exiting.\n'
    exit 1
fi
HMACSHA1_key_mod_hex=$(printf "$HMACSHA1_key" | sed 's/\([0-9]\|[a-f]\|[A-F]\)//g')
if [ -n "${HMACSHA1_key_mod_hex}" ]; then
    stty echo
    printf '\n    Invalid characters: %s\n' "${HMACSHA1_key_mod_hex}"
    printf '\n    Only 0-9, a-f, A-F allowed. Exiting.\n'
    exit 1
fi
printf "\n"
printf "message/challenge: "
read HMACSHA1_value
if [ -z "$HMACSHA1_value" ]; then
    stty echo
    printf '\n    Empty input. Exiting.\n'
    exit 1
fi

printf $HMACSHA1_value |
  xxd -p | sed 's/../&00/g' |
  sed 's/00$//' | cut -c -63 | xxd -r -p |
  openssl dgst -sha1 -mac HMAC -macopt "hexkey:$HMACSHA1_key" -binary |
  xxd -p

I cannot attest to the portability of the above command and the above script. They are pared down versions of things that worked for me, at least.

2

Basically what you added is like an old fashioned, physical "key" to your password storage.

A "key" that no locksmith can duplicate.

In your existing model the "passphrase" was the weak link. If you accidentally disclosed it, or someone shoulder surfed, or recorded your keystrokes, or you reuse it on an iffy website an attacker could get into your password store.

In the new setup the attacker needs to do all that plus have access to your physical key.

1
  • 1
    Its partially correct. It prevents simplest attach threats such as generic keyloggers or a friend's eye. However, they do not have access to your database file. So the threat is direct Password Manager attacks. Moreover, your last sentence is not correct. Challenge-response does not return a different response with a single challenge. It will become a static password if you use single phrase (Master Password) all the time. So, the attacker can store challenge output and that's all. Its your master password. Yubi OTP or real challenge-response implementation works different. Take a look to wiki
    – Kousha
    Jun 15, 2015 at 12:19
2

I think Kousha is asking why use either Static Password or Challenge-Response. This page from KeePassXC may be helpful.

https://ewen.mcneill.gen.nz/blog/entry/2017-07-23-keepassxc-with-yubikey-challenge-response/

KeePassXC YubiKey support is via the YubiKey HMAC-SHA1 Challenge-Response authentication, where the YubiKey mixes a shared secret with a challenge token to create a response token. This method was chosen for the KeePassXC YubiKey support because it provides a determinstic response without, eg, needing to reliably track counters or deal with gaps in monotonically increasing values, such as is needed with U2F -- Universal 2nd Factor. This trades a reduction in security (due to just relying on a shared secret) for robustness (eg, not getting permanently locked out of password database due to the YubiKeys counter having moved on to a newer value than the password database), and ease of use (eg, not having to activate the YubiKey at both open and close of a database; the KeePassXC ticket ticket #127 contains some useful discussion of the tradeoffs with authentiction modes needing counters; pwsafe also uses YubiKey Challenge-Response mode, presumably for similar reasons).

So, basically there are technical reasons why these PW managers don't use OTPs, and these two options are alternatives which are admittedly less secure. I would assume the reason is similar for not using TOTP as it is from HOTP, time has vs a counter hash, although they say TOTP is more robust, especially if needing to enter the key again when exiting.

I came here searching for the difference between Static Passwords and Challenge-Response. It seems as Kousha points out the CR basically turns into a SP that can be stolen with internal access to the computer. I suppose it adds an extra layer of having to enter the challenge password for the Yubikey, but I'm using KeePassXC where I'll have to enter a separate password for it in any case anyway.

1

Enabling the YubiKey feature doesn't help if the attacker is capable of sniffing USB packets or inspecting memory.

It does help with a far more common scenario: Someone somehow obtained a copy of your encrypted password database but they don't have access to your computer or YubiKey. (Maybe someone found your lost thumb drive containing a copy. Or maybe someone stole your phone. Or maybe you keep a backup at a family member's house. Or maybe a Google employee is snooping around the files you keep in Drive.)

If you don't enable the YubiKey feature, the difficulty of opening your password database depends solely on the strength of your password. If your password is strong, you probably don't have much to worry about. Unfortunately, humans are generally terrible at creating strong passwords.

If you do enable the YubiKey feature, your potentially weak password is effectively turned into an amazingly strong password, yet it is just as easy to "type" this amazing password if you have the YubiKey. Without the YubiKey, dictionary attacks on the encrypted password database are ineffective.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.