die "Invalid signature\n"
if ( $hmac ne hmac_for($secret, $user, $roles, $ts, $ua) );
Also, I'm not wild about a structured cookie with "-" as the separator that contains any user-controlled data. The user-agent is last in the cookie, which is good, but you worry about usernames with the "-" character. "Canonicalization" is the process of ensuring that every piece of data that hits the hash is in a character set that can reliably be extracted from the cookie. For data that is in any way under user control, if you're going to use "-" as a separator, I'd hex-encode the strings.
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.
Guys, fix this ASAP. SHA1(secret || data) (secret-prefix MAC) is totally insecure. (In practice, every valid forgery to this MAC is going to look like x-y-z-useragent-GIBBERISH-evil-content, but you don't want to be relying on that for your security).
Embarrassing (for me).
Allowing everyone to just authenticate via Google Apps is a sweet idea. Anyone know of any resources to implement something similar with Nginx? #lazyweb
The one problem that I've had with it is many oauth providers only allow you to specify one allowed redirect URL per app. So it makes it difficult to run a single doorman instance for multiple services.
Awesome project looking forward to seeing it progress.
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.
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!