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?

  • 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 '15 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 '15 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 '15 at 9:14

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 wirth the ubikey is take your input as data and send it to the UbiKey. The key is in the UbiKey itself ans stays there.

So, the sequence of event is the following:

  • You enter your passphrase.
  • The software sends that passphrase to the ubikey
  • The UbiKey performs a HMAC using your passphrase as input and the (internally stored) secret key.
  • 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.

  • 2
    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 '15 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 '15 at 12:13
  • 1
    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 '15 at 12:44

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.

  • 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 '15 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 '15 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 '15 at 21:42

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
    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 '15 at 12:19

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
if [ ${#HMACSHA1_key} -ne 40 ]; then
    stty echo
    printf '\n    Need exactly 40 characters. Exiting.\n'
    exit 1
HMACSHA1_no_space="${HMACSHA1_key/ /}"
if [ ${#HMACSHA1_no_space} -ne 40 ]; then
    stty echo
    printf '\n    No spaces. Exiting.\n'
    exit 1
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
printf "\n"
printf "message/challenge: "
read HMACSHA1_value
if [ -z "$HMACSHA1_value" ]; then
    stty echo
    printf '\n    Empty input. Exiting.\n'
    exit 1

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.


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


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.

New contributor
alchemy is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

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.