thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Chung <>
Subject Re: username/password - security in Apache Thrift
Date Wed, 25 Sep 2013 20:47:30 GMT
> > 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.

Right. I sent out an addendum right after my original reply.

> > 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.

There was an initiative to have a unified cross platform API to do this a
long time ago called DCE (Distributed Computing Environment), but the fact
that DCE no longer exists tells you all you need to know.

> 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.

Agreed. And because there is typically no need for a single organization to
have a cross platform *server* mechanism for authentication, they only need
to pick the API of choice whether it's LDAP or PAM or home grown or
whatever. And getting the un/pw to the server is typically accomplished by
communicating the cleartext password to the server via SSL...which *is*
universally cross platform and good enough for Facebook, Google, et. al.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message