Pinned toot

I post about technical topics here, especially , , . My other account is for German-language non-technical stuff.

Do you remember the times when "alternative" browsers like had to masquerade as IE6? That's where we are heading again, thanks to the prevalence of Chromium-based browsers.

Welcome to the dark ages of the web, brought to you by . web client won't make calls in Chromium on Linux due to some b0rked user agent sniffing (user agent switcher extensions won't help). "Unsupported" Firefox will work just fine however if user agent is changed to Chrome. Feature detection, anyone?

@kaffeeringe brought this up two weeks ago already but I only realized now how thoroughly messed up this is.

Supposedly, this plugin should be capable of configuring the hardware token automatically. I cannot see this in the source code however, and documentation pretty much doesn't exist. I guess that current version requires copying secret between applications, same as KeeChallenge?

To alleviate this issue, OtpKeyProv encrypts the HMAC secret not merely with the next OTP but with the next 3 to 6 OTPs (configurable). Doesn't change the fact that most users of this plugin probably need to restore the secret from backup every now and then.

Of course, you get issues when the counter on the hardware token and the one expected by the database are out of sync. That might be because you generated an OTP but didn't use it, restored a database from backup or have an outdated version on a particular device.

Otherwise, the main difference is replay protection. The challenge is not random here, it's rather an incremental counter. The hardware token will only give you the current response. So one has to access the encrypted secret and the YubiKey roughly simultaneously.

I think that now I also understand what OtpKeyProv plugin for is doing. The scheme is very similar to what I saw in the KeeChallenge plugin, but it's supposed to work with any hardware token supporting OATH HOTP standard.

Not just that, YubiKey would probably also slow down the attack massively. Even if there is no explicit bruteforce protection, its capability for calculating HMAC-SHA1 hashes should be rather limited. Now if there weren't this backup/data loss issue...

IMHO there would be a way to improve this scheme, by making the hashed master password part of the challenge. So attackers would need the YubiKey when bruteforcing the master password rather than merely "borrowing" it for a minute.

Finally, backing up the HMAC key is essential if you want to avoid data loss. No hints on how one would do this securely and reliably. It's probably more likely for this backup to be compromised than the YubiKey itself. And will people really find it if their YubiKey is lost?

Usability impact is more obvious. The HMAC scheme seems proprietary, not supported in the same way by other vendors. The setup (set up HMAC key in one application, then copy into another) is too scary for the less technical crowd. But I guess they wouldn't buy a YubiKey anyway.

Compared to a thumb drive, there is an advantage: an attacker can access the thumb drive and the password database in arbitrary order, with YubiKey it's password database first, YubiKey later. I still have to figure out how much this helps in practice.

Stealing the file and accessing YubiKey doesn't need to happen simultaneously. Since there is no replay protection in this scheme, the challenge can be arbitrarily old. Adding replay protection is complicated to say the least, due to legitimate outdated copies (e.g. backups).

YubiKey provides them with the signature corresponding to the challenge, so they can decrypt the HMAC key. That's it, the protection provided by the hardware token is permanently compromised. Future versions of this database will still use the same HMAC key, though reencrypted.

From what I can see, the challenge rotation serves little purpose. The main attack scenario appears to be: somebody gains access to the file where the challenge and the encrypted HMAC key are stored. Later they get a chance to use the corresponding YubiKey.

But it wouldn't be a proper challenge-response scheme if the challenges wouldn't rotate. So on every access a new challenge is generated and the HMAC key is reencrypted. HMAC key itself stays unchanged (it's also the encryption key given to KeePass on successful authentication).

YubiKey can store an HMAC key. Presumably, reading out the key is impossible after that, only signing challenge messages with it. The same HMAC key is being entered into KeePass. To protect it, KeeChallenge generates a random challenge and encrypts the HMAC key with the response.

In principle, a challenge-response scheme has advantages over merely using YubiKey to generate a shared secret - accessing YubiKey once doesn't grant you access forever. The issue: you need a shared secret to encrypt the password database. How is it being solved here?

On my thread yesterday, and disagreed with my conclusion. In particular, they pointed me to the KeeChallenge plugin which allows to use via an offline challenge-response scheme.

And if they deny the request, how would you legitimately recover access to your account after losing the hardware token? No simple answers here, e.g. relying on user's cooperation ("print out these recovery codes just in case") isn't a silver bullet.

Show more
Infosec Exchange

A Mastodon instance for info/cyber security-minded people.