5 ms·

The DoS aspect is mitigated via pam and user management controls in the OS (for creating /etc/shadow entries). scrypt and bcrypt are a long ways out for suppor

The DoS aspect is mitigated via pam and user management controls in the OS (for creating /etc/shadow entries). scrypt and bcrypt are a long ways out for supported Linux distros. This depends on glibc to make changes that they have stated they won't make. So for now, sha512 shadow hashes are the best most people will have in their datacenters. Perhaps wrap that rascal with MFA / 2FA to be the first line of defense as a mitigating or compensating control.

jessaustin 8y ago
scrypt and bcrypt are a long ways out for supported Linux distros. Presumably you're referring to some sort of special acceleration for these algorithms? Why is that a prerequisite for using them? Speed isn't more important than security.
- LinuxBender 8y ago
  Not related to speed at all. glibc needs to add the support for them and it doesn't exist, at least not in the older branches that all the commercially supported distros use. There is talk of adding support for external libraries. [0] [0] - https://sourceware.org/bugzilla/show_bug.cgi?id=16814 https://sourceware.org/bugzilla/show_bug.cgi?id=16814
derefr 8y ago
> This depends on glibc to make changes that they have stated they won't make. I'm not sure I understand what part of Linux's account security model relies on glibc to make changes. Can't PAM pull in whatever libraries it likes? If not, then why hasn't (any popular distro of) Linux moved toward the Windows/macOS model of unifying account management + AAA onto a single "directory services only" code-path, where a system that's not "part of a directory" is actually just part of its own "directory of one", with your system running its own little LDAP+Kerberos daemons or what-have-you that your local accounts reside in? In that sort of model (which, again, is what Windows and macOS both use exclusively nowadays), the kernel, C library, etc. aren't involved in deciding AAA policy; they just implement the simple AAA mechanism of "let users with the right ACL token do the things the ACL token says they can do" and then rely on one or more [local or remote] directory-service servers to actually authenticate users and issue those tokens to them. Drastically smaller attack surface.
- LinuxBender 8y ago
  There is talk of extending crypt in glibc to support external libraries [0] and that would do exactly as you suggest. [0] - https://sourceware.org/bugzilla/show_bug.cgi?id=16814 https://sourceware.org/bugzilla/show_bug.cgi?id=16814 And certainly, if you move the authentication to another service, such as I mentioned with MFA, or LDAP+Kerberos as you mentioned, that could address this, assuming that system supports scrypt / bcrypt.
  - derefr 8y ago
    I’m still confused—why is the idea to extend crypt(3), rather than for PAM to just call something besides crypt(3), pulling in a better hashing library at the libpam level rather than at the libc level?
    - LinuxBender 8y ago
      That is a good question. One use case that comes to mind is sshd. The ssh daemon is not required to use pam.
    - mjevans 8y ago
      Lots of services call crypt and it expects a variable length string which describes the stored secret to compare the actual password against. It is //very// possible to update this one place and 'solve' support for MANY dependent programs and libraries. (towards the bottom of the manual page: http://man7.org/linux/man-pages/man3/crypt.3.html http://man7.org/linux/man-pages/man3/crypt.3.html )
- mjevans 8y ago
  Offhand, due to setting up 'active directory' integrations, I'd say that yes, it should be possible to have a third party authentication framework which does not depend on traditional glibc/libc support. I can't seem to find, in an offhand and quick glance at search results, any library that I know of to accomplish this task. Doesn't mean it can't be or hasn't been done though. I know for a fact that plain text passwords are passable to authentication libraries since that's how AD integration works. Though there also seems to be some recent interest in implementing support in crypt() https://sourceware.org/bugzilla/show_bug.cgi?id=21421 https://sourceware.org/bugzilla/show_bug.cgi?id=21421
toast0 8y ago
>scrypt and bcrypt are a long ways out for supported Linux distros. Don't you just install libpam-unix2 / an updated version of libpam-unix that supports bcrypt, and configure that? Source: this is how we use bcrypt password hashes on our one Linux machine.

jessaustin 8y ago

scrypt and bcrypt are a long ways out for supported Linux distros. Presumably you're referring to some sort of special acceleration for these algorithms? Why is that a prerequisite for using them? Speed isn't more important than security.

LinuxBender 8y ago
Not related to speed at all. glibc needs to add the support for them and it doesn't exist, at least not in the older branches that all the commercially supported distros use. There is talk of adding support for external libraries. [0] [0] - https://sourceware.org/bugzilla/show_bug.cgi?id=16814 https://sourceware.org/bugzilla/show_bug.cgi?id=16814

derefr 8y ago

> This depends on glibc to make changes that they have stated they won't make. I'm not sure I understand what part of Linux's account security model relies on glibc to make changes. Can't PAM pull in whatever libraries it likes? If not, then why hasn't (any popular distro of) Linux moved toward the Windows/macOS model of unifying account management + AAA onto a single "directory services only" code-path, where a system that's not "part of a directory" is actually just part of its own "directory of one", with your system running its own little LDAP+Kerberos daemons or what-have-you that your local accounts reside in? In that sort of model (which, again, is what Windows and macOS both use exclusively nowadays), the kernel, C library, etc. aren't involved in deciding AAA policy; they just implement the simple AAA mechanism of "let users with the right ACL token do the things the ACL token says they can do" and then rely on one or more [local or remote] directory-service servers to actually authenticate users and issue those tokens to them. Drastically smaller attack surface.

LinuxBender 8y ago
There is talk of extending crypt in glibc to support external libraries [0] and that would do exactly as you suggest. [0] - https://sourceware.org/bugzilla/show_bug.cgi?id=16814 https://sourceware.org/bugzilla/show_bug.cgi?id=16814 And certainly, if you move the authentication to another service, such as I mentioned with MFA, or LDAP+Kerberos as you mentioned, that could address this, assuming that system supports scrypt / bcrypt.
- derefr 8y ago
  I’m still confused—why is the idea to extend crypt(3), rather than for PAM to just call something besides crypt(3), pulling in a better hashing library at the libpam level rather than at the libc level?
  - LinuxBender 8y ago
    That is a good question. One use case that comes to mind is sshd. The ssh daemon is not required to use pam.
  - mjevans 8y ago
    Lots of services call crypt and it expects a variable length string which describes the stored secret to compare the actual password against. It is //very// possible to update this one place and 'solve' support for MANY dependent programs and libraries. (towards the bottom of the manual page: http://man7.org/linux/man-pages/man3/crypt.3.html http://man7.org/linux/man-pages/man3/crypt.3.html )
mjevans 8y ago
Offhand, due to setting up 'active directory' integrations, I'd say that yes, it should be possible to have a third party authentication framework which does not depend on traditional glibc/libc support. I can't seem to find, in an offhand and quick glance at search results, any library that I know of to accomplish this task. Doesn't mean it can't be or hasn't been done though. I know for a fact that plain text passwords are passable to authentication libraries since that's how AD integration works. Though there also seems to be some recent interest in implementing support in crypt() https://sourceware.org/bugzilla/show_bug.cgi?id=21421 https://sourceware.org/bugzilla/show_bug.cgi?id=21421

toast0 8y ago

>scrypt and bcrypt are a long ways out for supported Linux distros. Don't you just install libpam-unix2 / an updated version of libpam-unix that supports bcrypt, and configure that? Source: this is how we use bcrypt password hashes on our one Linux machine.