Ginzametrics Open Sources Odin, A Cookie-Based Single Sign On for Apache (opens in new tab)

Thank you for your remarks, this is really helpful.

It doesn't seem to me that timing attack is feasible here: timing of comparison of a relatively short string vs network latency and everything else that happens during Apache's request handling would require a lot of repeated attempts and statistical analysis of very noisy data if it's at all possible to get meaningful results. Still, it's better to be on the safe side and I'm going to close it up.

Sanity check for idea of resolution: adding a random length sleep, 1 to 3 seconds, if HMAC is invalid. This would fuzz the small timing difference in string comparison, and at the same time tarpit any exploit attempts (invalid HMAC is more likely to be sign of manipulation attempt rather than a honest error). Does that make any sense?

Regarding user-controlled data: the context here is that usernames aren't under user's full control (they need to be entered into Google Apps by someone, and also validated). In general case this is a valid issue - a valid login could break the scheme here.

This is in no way an excuse, but rather explanation of my reasoning: the initial idea was to port GodAuth and be at least "kind of compatible", because some people use GodAuth and it might be meaningful for interoperability. Also, as I'm no specialist in crypto (as you can clearly see), I followed the route of not touching crypto-related code that is already written. The issues you've found are strong enough reasons to diverge from GodAuth - especially that GodAuth interoperability is way more theoretical than an actual security issue even if it may not be exploitable. Thank you for reviewing the code and your remarks.

Also, using sha1_hex(secret+...) and calling it HMAC is a slippery slope (see http://netifera.com/research/flickr_api_signature_forgery.pd...). Although it's seemingly not exploitable due to the structure of the data, look into using a proper HMAC (RFC 2104) to prevent length-extension attacks.

This is really helpful, thanks.

Yup, enterprise-y is what I've been trying to avoid here. A lot of overhead for users that I can count on my fingers without using binary. Also, much of the big SSO systems seem to require the application to be aware of it, which is a showstopper to me: I want to protect with SSO ANY webapp ANYONE has written, even the simplest ones, without having to bother with trying to make it aware of the system. That's the whole point of setting REMOTE_USER: either the app doesn't care about identity (think status panel without any actions), or most likely it is already able to hand off authentication to the frontend http server.

Thanks!

I don't use Windows, so I can't promise anything, but there's nothing there that may prevent it from working on Windows. It's pure Perl, so the code itself is portable. If you have any particular problem, feel free to email me (address should be in the repo); and if you have success running Odin on Windows, I'd be very interested in hearing that too.

Re hybridauth: using different identity providers is somewhere between "it's possible" and "it would be nice to have" priority, unless we actually need it. The idea is to have the SSO for the internal services, and hybridauth seems to be focused on end user and social authentication. Also, Hybridauth itself is PHP; while in principle it should be possible to implement the authorizer app in any language, I'd prefer to keep it in Perl until there's a really, really good reason to switch.

If I work on option on different identity providers, it will still be rather focused on internal services use case than end-user social authentication use case. However, I'd be happy to see and review a pull request implementing social auth if any of Odin's users needs that.

For whatever it's worth, this also uses an unsafe compare (it's also not using HMAC, but it's double-hashing and seems to be more careful about canonicalization).

I don't like this idea as a main authentication system for a couple reasons, besides the logout problem. First, it requires team members to register every single browser they'll be using to access the panels – which may also mean being locked out during emergency due to not having a blessed browser nearby.

As I understand the scheme, distributing and deleting/changing clients' public keys to the web servers is basically the same challenge as syncing htpasswd across servers and trying to let users change their passwords. Syncing itself is not an issue, but making it possible (and EASY - any security that gets in the way of getting the job done will be circumvented by users themselves) to add / update / invalidate user's certs by users themselves is not trivial.

It also adds to the proliferation of credentials: Yet Another Key (or even Set of Keys) is just as bad as Yet Another Login And Password.

This is a good idea for a multi-factor authentication, though: require either token / SMS OTP / other out-of-band verification, or a blessed client certificate – basically, pre-authorize certain browsers. This might fly!