Yubico Forum

I got this question via e-mail, and I think others may have thought about this issue before and would be helped by having this answered in public, so here goes the question:



My answer is:

he HMAC key is shared only between the server and you, and is not tied to a specific yubikey.

We do use yubikey for authentication during HMAC key generation to reduce the number of "bogus" keys in the database. People without an yubikey aren't likely to need the validation service interface right now anyway.

It doesn't matter if the yubikey used for authentication of the HMAC-key generation stops working or is lost, it will not affect the security of the HMAC key (assuming the HMAC key is handled properly).

I hope this answers your question.

/Simon

I think I misunderstand the question here. The outbound HMAC authenticates that the Yubico servers were actually getting a message from a valid user, and that the message was not tampered with in transit. Conversely, the return HMAC verifies the answering server shares your 'secret' API key and is actually not being intercepted and modified in transit.

Given this understanding, if you are using Yubico's public servers for production use, I would thing the hmac would be integral to validating the response is actually coming from them and not being intercepted or modified via a man in the middle attack. You would not want to share your HMAC key. You do want to use it in any code you write.

Simon does say above that the HMAC key is unique per api ID and not tied to any specific key though if that was your actual question.

If I understand correctly, the HMAC is used to secure the query to and from the server. If so, why not just https (ssl) on the server side?

ssl via https only verifies the server (via the server certificate, and how do you manage that in an application reliably), but not the client.

Gorkab's understanding here is correct.

Arguable, we _could_ use https (and we do support https!) instead of this HMAC scheme. However, client-side HTTPS is rarely implemented well, so we needed a simpler solution. For most clients, using https and trusting our server certificate should be good enough -- you don't need to deal with the HMAC key then. However, none of our published clients utilize HTTPS and server certificate verification yet.

/Simon

I was wondering about that, thanks. There's something that irks me a bit. By checking the response's HMAC, you will only learn that the response was originated at the server. Without further client-side storage, you can not be sure, if the server's response is replayed by someone malicious. Am I missing something?

It looks to me if someone can take over my internet connection/DNS, s/he can replay a former "success" response to any authentication requests in plain HTTP, even without a yubikey. The first idea would be to check the time stamp, however, this is what I've just got from the server:

h=...
t=2008-08-08T10:08:44Z0773
status=OK

Where does 10:08:44 UTC come from? It's around 09:32 when I was trying this... It seems this is the servers date (from the Date header), though I could rely only on authenticated data, like the t field. (And what's 0773?)

My first instinct would be to add a challenge to the query which will be sent in the answer, which would be very easy to check, and prevent HTTP replays to be valid, without depending on times, and require nor client, nor server-side extra storage.

How does sending extending a protocol with a c=uniquestring which would come back signed (if present)? Or is there some other protocol feature which prevents the attack I imagined? (Should I be using a separate topic for this question?)

Thanks!

Good ideas! Yes, the response should definitely include the OTP that is being validated, so the client can check this. We will work on changing this, I've filed a bug:

http://code.google.com/p/yubikey-server ... etail?id=8

We recommend that you use https and validate the api.yubico.com server certificate. Then you aren't vulnerable to this attack. You can also verify the timestamp in the response, it should be UTC time.

Thanks,
/Simon

Cool, thank you!

Just to think out loud, I obviously prefer encrypted communications; the trouble in this case, that nowadays what using SSL/TLS ensures is just temporary domain control. So, in the case of domain expiration, or the rare (ehrm..) case of domain poisoning, it might not be prohibitively difficult to acquire a certificate for an arbitrary hostname(*), which is then accepted by many clients. Protection against is not quite convenient, you would either need to make sure the domain signer is not changing (but this is only making the window smaller), or build a separate "trusted" CA list, which is against at least common sense

Checking the timestamp may be an option, if your servers keep better time in the future But also it would need better time synch on the clients as well..

(*) Sidenote: the way things are, I think if we relied on SSL/TLS much more, these attacks may became much more common.