mpasternacki

I have even linked to it in the article. I am going to comment and suggest this kind of approach - I wanted first to flesh out the idea and validate the proof of concept in this script.

Yes, this is convenient and speeds up Dockerfile development. At the same time, this is an issue when you consider using Docker as a part of your production deployment toolchain. I think both ways should be supported: incremental multi-layered images for development or exploration, and then possibility of creating a single, compact image for lower overhead in deployment. In a perfect world, it would be a switch for `docker build`, but I'm not fluent enough in Go to propose a solution on that side.

Some people have considered another approach: flattening an existing stack of images. Scripts for that are linked from the Docker issue on GitHub. I wasn't able to get any of these working, and the logic behind these seemed quite convoluted.

Still, my script is just a proof of concept - I tried whether it is possible to take the approach I use internally for Docker build scripts, and use it to build Dockerfiles. It seems it's possible, and it delivers good results. Time and actual usage will show whether it's a good idea; if this approach makes sense, it will hopefully make its way to the Docker core, and my hack won't stay relevant for too long.

Doesn't it just remove the containers, but still keep the generated images layered? I'll take a look (running 0.6.1 here), but it seems to solve a different issue.

I've seen both; Docker's main registry provides some base images (the most used is named `ubuntu` and has base system for Precise and Raring), and I've seen many imaged descending from author's own base - it's quite easy to prepare a base image using debuild or other distros' equivalents. Can't talk about not debian-ish distributions, but debuild does verify its downloads.

The place of trust here is the registry - usually, for convenience, tags are used rather than hashes (and I'm still quite not sure whether the long hex IDs are hashes, or just unique random names). The registry returns hex id for a given tag, and is trusted to deliver correct files for an ID.

I believe that the main index/registry runs over https and provides basic security, but it would be a huge issue if it was compromised. It's quite easy to run your own registry, too. What I'd love to see on top of that is some kind of GPG-based verification of downloaded images (Debian got the problem basically solved in Apt).

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.

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.

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!

Thank you! This will be closed up by end of this week. As I wrote in the article and in the presentation, one of main points of open sourcing it is to have people smarter than myself look at the crypto and protocols to find any issues like this. It should be fairly easy to close up.

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.