Yubico Forum

in API docs I can see:



however when i look at (ie.) code i cannot see any code responsible for certificate validation/verification and thus it makes it vulnerable to SSL MITM attack.

alternatively i cannot see a way to make mutual HMAC authentication in API protocol.

how do we avoid MITM then? should we use stunnel on all clients that connect to API?

Either you provide the https URL and let curl handle X.509 server certification verification, or you use the HMAC approach. The HMAC approach authenticates the client to the server and vice versa, assuming the HMAC key is kept secret.

/Simon

i think that your thoughts/documentation might exceed what is actually existing within a code - in particular:

- i cannot find a way to force HMAC for VAL => KSM communication
- i cannot find a way to enforce HMAC between auth-client and VAL server (if i omit a key in request, VAL is *not* refusing to reply)
- i cannot find a way to make php-curl (used by VAL server) verify certs, thus i'm unable to secure VAL => KSM communication - no visible trace of curl_setopt(..., CURLOPT_CAINFO, ...) definition in project (i've been using this version: yubikey-val-2.1-0.5). actually it's even worse - the whole verification is deliberately turned off with: ykval-synclib.php: curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
- i cannot find a way to make yubico-c-client (used ie. by pam_yubico module) verify certs, again - no trace of CURLOPT_CAINFO in ykclient library (versions used: ykclient-2.3 and pam_yubico-2.1)

should i fork your code?

i think hacking organization's dns is currently sufficient to break whole yubico infrastructure trust.

anyone?

what i'd like to know is if you're willing to address those issues. if yes - please state some time estimate. if no - fair enough, we'll just fork your code and get it working on our own.

i guess that it means "no".

For VAL->KSM communication, I would recommend an encrypted+authenticated virtual network connection (TLS, SSH port forwarding, IPSEC, OpenVPN or similar).



You are right that HMAC keying is optional. If there is a need, this could easily be changed in the server code, so that HMAC is always required.



You could use any of the ideas above (TLS, SSH, etc), or help us improve the code here.



It supports HMAC though. Making it support HTTPS would be a very useful addition.



Please send a patch instead! Most of our code is developed as a google code project, so you can easily find bug reports and even provide patches to implement some missing features.



Hacking DNS will lead to a Denial-of-service, but to really do harm against properly configured clients I believe you need the server certificate private key or HMAC shared secrets.

I hope these answers help a small bit. We are aware that not all projects are in perfect condition (or, rather, I think you can find things to improve on all of our projects), but we hope that you and others will help us get things right in the long run.

/Simon

ok, maybe to clear it up a bit: i am not a coder. what is my role here (in my organization) is to evaluate your infrastructure and decide if - from the security perspective - it's suitable for us to use (ie. leverage our systems and overall security). what i came up with for now is that yubico could be trusted as yubikey token vendor (as algorithm is well documented and hardware attacks are not very feasible) and as a hosting-based provider (as long as non-SLA operation is not an issue) but as a server side solution it does not work so well - to paraphrase your words - it's a mess, and doesn't promise prompt and convincing enough security response if any other security concerns/issues will come up along the road.

what we're going to do now, as a software company, is probably implementing our own framework around yubikeys that we can review internally and ultimately trust (or we go and patch your code if i couldn't get a budget to run another software project). however i guess that this is not the thing that we expected while buying a batch of yubikeys. of course the opensource nature of your infrastructure makes things a lots easier, but i wouldn't ever say that opensource in yubico should be considered synomous of DIY (but if it actually is, it should be fairly and clearly stated). after all - it's security infrastructure, in many ways critical to your customers. and there ARE opensource security products that you can trust, ie. openssl - stable and transparent enough that are able to survive any code/infrastructure audit and generate well feedback if there are issues.

i think that i've found where the stable validation server has gone: http://maymay.net/blog/2008/09/01/yubik ... ent-165583

This is an old issue. Yubico's official response to this can be found at the following link:

viewtopic.php?f=4&t=396