> > The last thing I want to do is authenticate the password myself, because > > I'm sure whatever I came up with would not be "secure" by any reasonably > > thorough definition of security. > > > Regardless of whether you roll your own or delegate the responsibility to > some other service (via an api), your server side is going to handle the un > and cleartext pw and ask some service to validate the combination.
This isn't necessarily true. TLS-SRP doesn't send a password at all. It sends information derived from a password, similar to a hash. Kerberos authentication doesn't send usernames and passwords, it sends service tickets. Most HTTPS sites send usernames and passwords in "cleartext" underneath a TLS connection, but this isn't the only way to do authentication. > > and I think there must be a way to layer in something that knows how to > > use the local password file or LDAP or whatever. > > > Certainly those mechanisms must have APIs to validate the un/pw that you > received over the wire. Those APIs would return true or false. And if they > return true, they might return a blob of additional data about the > authenticated user. This is heavily platform and authentication mechanism specific. The low level APIs for Kerberos are very different from one platform to the next. Interacting with a "password file" is going to be very different from one platform to the next. On Linux you would need a PAM module. You would need something entirely different on another platform. It is very difficult, and probably even impossible, to make an authentication mechanism that is both one-size-fits-all, and interoperates with existing IT infrastructure. Unfortunately, you do have to be really IT savvy to make most of these technologies work. "Normal" SSL ends up working well because OS and browser vendors distribute root certificates for you. I'm not aware of anything similar for password based authentication.
