Yubico Forum
https://forum.yubico.com/

Is the HMAC key related to the Yubikey secret?
https://forum.yubico.com/viewtopic.php?f=3&t=138		 Page 1 of 1
Author:  Simon [ Sat Jul 19, 2008 12:13 pm ]
Post subject:  Is the HMAC key related to the Yubikey secret?
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:

Code:
The API/ID used for HMAC verification, is that to be considered a personal thing tied to a key ? Or just something You got one of per installation/service that uses the Yubico auth server ?


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
Author:  gorkab [ Tue Jul 22, 2008 2:54 am ]
Post subject:  Re: Is the HMAC key related to the Yubikey secret?
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.
Author:  gmik [ Wed Jul 23, 2008 1:14 pm ]
Post subject:  Re: Is the HMAC key related to the Yubikey secret?
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?
Author:  gorkab [ Thu Jul 24, 2008 2:51 am ]
Post subject:  Re: Is the HMAC key related to the Yubikey secret?
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.
Author:  Simon [ Thu Jul 24, 2008 12:28 pm ]
Post subject:  Re: Is the HMAC key related to the Yubikey secret?
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
Author:  chexum [ Fri Aug 08, 2008 10:43 am ]
Post subject:  Re: Is the HMAC key related to the Yubikey secret?
Simon wrote:
Arguable, we _could_ use https (and we do support https!) instead of this HMAC scheme.

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!
Author:  Simon [ Tue Aug 19, 2008 2:35 pm ]
Post subject:  Re: Is the HMAC key related to the Yubikey secret?
chexum wrote:
Simon wrote:
Arguable, we _could_ use https (and we do support https!) instead of this HMAC scheme.

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
Author:  chexum [ Wed Aug 20, 2008 3:39 pm ]
Post subject:  Re: Is the HMAC key related to the Yubikey secret?
Simon wrote:
Good ideas! Yes, the response should definitely include the OTP that is being validated, so the client can check this.

Simon wrote:
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.
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. :shock:
Page 1 of 1 All times are UTC + 1 hour
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/