Yubico Forum

...visit our web-store at store.yubico.com
It is currently Tue Jan 30, 2018 11:57 am

All times are UTC + 1 hour




Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Sat Jul 19, 2008 12:13 pm 
Offline
Site Admin
Site Admin

Joined: Tue May 06, 2008 7:22 pm
Posts: 151
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


Top
 Profile  
Reply with quote  

Share On:

Share on Facebook FacebookShare on Twitter TwitterShare on Tumblr TumblrShare on Google+ Google+

PostPosted: Tue Jul 22, 2008 2:54 am 
Offline

Joined: Sat Jul 05, 2008 9:21 pm
Posts: 10
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.


Top
 Profile  
Reply with quote  
PostPosted: Wed Jul 23, 2008 1:14 pm 
Offline

Joined: Fri Jul 11, 2008 8:30 pm
Posts: 8
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?


Top
 Profile  
Reply with quote  
PostPosted: Thu Jul 24, 2008 2:51 am 
Offline

Joined: Sat Jul 05, 2008 9:21 pm
Posts: 10
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.


Top
 Profile  
Reply with quote  
PostPosted: Thu Jul 24, 2008 12:28 pm 
Offline
Site Admin
Site Admin

Joined: Tue May 06, 2008 7:22 pm
Posts: 151
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


Top
 Profile  
Reply with quote  
PostPosted: Fri Aug 08, 2008 10:43 am 
Offline

Joined: Thu Aug 07, 2008 1:14 pm
Posts: 8
Location: Surrey, UK
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!


Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 19, 2008 2:35 pm 
Offline
Site Admin
Site Admin

Joined: Tue May 06, 2008 7:22 pm
Posts: 151
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


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 20, 2008 3:39 pm 
Offline

Joined: Thu Aug 07, 2008 1:14 pm
Posts: 8
Location: Surrey, UK
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:


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group