New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of debian as base image disallows use of bcrypt for password hashes #29

Closed
stevvooe opened this Issue Jul 2, 2015 · 7 comments

Comments

Projects
None yet
2 participants
@stevvooe
Copy link

stevvooe commented Jul 2, 2015

Please see docker/distribution#655 for details, but the use of bcrypt with htpasswd results in the following errors:

nginx_1    | 2015/06/22 09:00:25 [crit] 5#5: *2 crypt_r() failed (22: Invalid argument)

Hunting this down shows this is dependent on the version of gcc shipped with debian. An inspection of ubuntu's crypt manpage shows it has support, although this is untested.

Either the base image needs to updated to support the modern password hashing scheme or libc needs to be recompiled for the base image.

@thresheek

This comment has been minimized.

Copy link
Member

thresheek commented Jul 2, 2015

nginx supports whatever is supported by libc on the system. Therefore, I suggest convincing Debian/Ubuntu libc maintainers to add bcrypt support (there are good reasons not to, see https://wiki.ubuntu.com/SecurityTeam/FAQ "SHA512-crypt as default").

@thresheek

This comment has been minimized.

Copy link
Member

thresheek commented Jul 2, 2015

And that being said, I do not really see a point of moving nginx docker image to a different base OS, considering two facts:

  • most web stack app images in docker library do use debian as base image (I've just checked haproxy, mysql, postgres, php, java)
  • there is a good enough equivalent to bcrypt, with no known problems, SHA-2
@stevvooe

This comment has been minimized.

Copy link
Author

stevvooe commented Jul 7, 2015

@thresheek Debating whether SHA-2 or bcrypt is better is beside the point. In fact, there isn't enough information to come to a proper decision. We can leave that to cryptographers. The issue is that the decision has already been made for something that is not 100% certain.

If you read SHA512-crypt as default, they have made the decision for the user, rather than providing choices. Users should not have decisions made about their security-level based on the side-effect choice that the base operating system for a docker container chose not to include bcrypt in the libc implementation.

This may be considered an nginx-level bug, since delegating the OS wrecks configuration portability.

@thresheek

This comment has been minimized.

Copy link
Member

thresheek commented Jul 7, 2015

I agree with you on the crypto part, however I do not see how it can be fixed for this docker image.

@thresheek

This comment has been minimized.

Copy link
Member

thresheek commented Mar 10, 2016

bcrypt support is now available with nginx:alpine tag, where nginx is built on top of alpine linux distribution, which has bcrypt in its libc.

@thresheek thresheek closed this Mar 10, 2016

@stevvooe

This comment has been minimized.

Copy link
Author

stevvooe commented Mar 10, 2016

@thresheek Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment