Challenge-Response or Yubikey support

[fuhsjr00]

Feature Request/Enhancement

It would be nice if Yubikey ( link below) YOTP or HOTP could be used to decrypt a safe. PWSafe on Windows currently supports HOTP (I believe), and it would be helpful to be able to do the same with Gorilla.

https://www.yubico.com/products/yubikey-hardware/

[rich123]

Actually, neither YOTP nor HOTP mode could be utilized to decrypt a safe. The "OTP" in both acronyms stands for "One Time Pad" which means that both modes generate any individual key only once, ever. In order to decrypt a safe, the safe must first be encrypted, and one must encrypt and decrypt with the same key (meaning the key would need to be generated by the Yubi twice (violating the 'one time' aspect of one time pads).

There is a long technical explanation here on the PasswordSafe forum about this exact topic: http://sourceforge.net/p/passwordsafe/discussion/134800/thread/f1a2e2da. Look for the long posting by user Andrey Kuznetsov on 2014-03-30.

The other issue with a OTP mode, if it could be used, is that it would mean than any backups (made by Gorilla or by your external backup system) of the PasswordSafe file would be inaccessible, because due to the "one time" aspect, you could never obtain the decrypt key a second time for any particular encrypt cycle of the file. Rendering all backups useless, and resulting in the complete loss of your passwords should the hardware storing the active copy fail.

Yubikey does have a mode that would work, the challenge-response mode (only works with the 2.2+ versions of the keys). In that mode, your master password would be passed to the Yubi (possibly with a salt) and the Yubi would combine it in a secure manner with a secret value stored only on the Yubi, returning a key that could be used to encrypt/decrypt a safe. Because this mode will return the same output for the same input, it is useful for generating the master key for the safe. It also would not invalidate any backup copies of the safe (provided you remembered the master password and had access to the salt if a salt was used).

Further hampering things is the fact that I do not at this time own a Yubikey, and as well there is no Tcl interface offered by Yubi directly (meaning that even were I to obtain a Yubi I would first have to get a Tcl interface (across Linux [easy], Windows [very painful], and Mac [somewhere in between]) up and running first. So there would likely be some unknown latency before any of that would settle down.

In any case, the concept is intriguing, thanks for suggesting it, and I'll have to do some more research to see how it could be interfaced to a Tcl program.

[fuhsjr00]

My mistake. I was under the impression that challenge-response and YOTP/HOTP were related, possibly because of descriptions like this one:

https://www.yubico.com/products/services-software/personalization-tools/challenge-response/

I can't help much with Tcl.

[rich123]

From what I gather from the Yubi site, at least some of the keys support two types of challenge/response protocols. A more standard hmac-sha1 version and a Yubi specific one based in some way on their existing YOTP system. So far I've not located much detail on the full inner workings of their YOTP protocol. If their YOTP challenge/response returns the same result for the same input, it would also be useful as a way of having the safe encryption key be dependent upon data in the Yubi key. Their website is unclear whether the YOTP challenge/response returns the same result, or differing results, for the same input. I found one spot implying it does, and another page that implies it does not.

[awailly]

This is a really interesting enhancement, were you able to progress on it?

[rich123]

No, no progress. Not having any hardware (i.e., I don't own a Yubikey) also hampers progress.

However, if you have one, you should be able to use it now in 'static' mode due to its USB keyboard emulation (see pg. 9 of the manual here: https://www.yubico.com/wp-content/uploads/2015/03/YubiKeyManual_v3.4.pdf) to let it 'type' a very long random password as your PWGorilla pass phrase. Set it to 'static' mode, then change your safe pass-phrase to what the Yubi types when you press its button.

What this would do for you is allow you to make use of a random pass-phrase that is not at all memorable, but because the Yubi does the 'remembering', you don't have to memorize it.

[rich123]

Note, you do have to use static mode for the above. The OTP modes will output a different value each time you press the button, which means that while you could change your pass-phrase to a OTP string, the Yubi should never output the same string again so you would be unable to later unlock your safe.

[awailly]

Can you give some advices to get started with the code? The static mode is not really providing 2FA. I think HMAC-SHA1 and a user input can be integrated. For the same password, we should get the same output from the yubikey.

[rich123]

No, static mode is not a 2FA. But static mode allows you to use a master password that is significantly more complicated than anything you'd be willing to memorize/type by hand. Which makes brute force attacks on your password safe (should someone obtain a copy of it) much harder and much more time consuming.

Now, a somewhat 2FA mode could be had by adding a second "yubi" input box to the unlock screen. You'd type your usual unlock phrase/password into the first box as always, and you'd let the yubi 'type' via its keyboard emulation its stored static value into the second box, and Gorilla would mix those two together when generating the encryption key to encrypt/decrypt your safe. This is not quite the challenge response modes, but you'd need both your regular passphrase and the data stored on the yubi to unlock a safe. This 'mode' would not be that difficult to add to Gorilla.

Did you mean OTP? Because the only occurrence of OPT in the Yubi docs. is as parts of words. OTP (generally, and from Yubi's usage) means One Time Password, meaning you should never get the same value out even if you put the same data into the Yubi. Which means the value out can't be used to unlock your safe (at least not directly) because to unlock, you need the same resulting crypto key that was used to lock the safe the first time. The password safe file format uses standard symmetric encryption, which means to decrypt the safe, the code needs to ultimately generate the identical string of bits that was used to encrypt the safe.

But the bigger stumbling block to any of the challenge response modes of the Yubi is that to use them, the application has to be able to submit data to the Yubi, and receive data from the Yubi. That means that there needs to be some way, from Tcl, to communicate to the Yubi. Yubi provides some interface libraries, but none for the Tcl language. Which means the very first step for any of the challenge/response modes is finding a way to communicate to the Yubi from Tcl and receive from the Yubi via Tcl. Receive should be present given the Yubi's keyboard emulation mode, but transmit is not present by default just because the Yubi pretends to be a keyboard.

[awailly]

You are totally right, I edited my previous comment. OPT was OTP in a rush. Anyway, I didn't want to reference OTP, but rather the HMAC-SHA1 Challenge-Response mode only.

Static mode only provides stronger passwords, which seems to be a unique factor for me. I did not tested this mode, but keyboard emulation should mean less entropy as we can only use ASCII characters.

I like the second idea combined with the lock screen. Do you see any benefits over the more classical concat(password|staticyubikey) as user password?

For the Tcl libraries I will dig more, this is not in my comfort zone and my comments will not make the issue progress.

[rich123]

The hmac-sha1 challenge/response mode would be useful, provided a driver were available for Tcl to interface to read from the Yubikey.

The Yubi docs talk about the Yubi using an ascii encoding similar to base64 for transmitting data to the computer, so there would not need to be any entropy loss from use of the keyboard emulation. Gorilla would just have to decode the Yubi's 'almost' base64 encoding to recover the original binary data. I don't know if the Yubi uses this mode for the static password mode, but if it did then there is no entropy loss. In any case, even with just typeable characters, a 64 or 128 character random string of typable characters is stronger than a short 20-30 character phrase in any case.

The concatenation method (as in you type your password into the unlock box, then let the Yubi type it's stored item afterward) would work immediately,, no changes to Gorilla at all. And it would increase the resistance of your pass-phrase against dictionary/brute force attacks as well.

The dual entry box method would require some changes to Gorilla, and a method of mixing the two together inside Gorilla has to be added (unless Gorilla does a concat internally, in which case there is no difference). The biggest difference would be that the concat method would we compatible with other password safe programs. A custom mixing of the two entries would also make the resulting safe incompatible with other password safe programs unless they also offered the identical mixing method.

It is doubtful that there are any Tcl interface libraries for the Yubi yet. Hunting around never hurt, but my gut says that in order to interface to a Yubi we will have to start by creating the Tcl libs first.