You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by Rajneesh kapur <ka...@gmail.com> on 2013/09/25 18:53:17 UTC
username/password - security in Apache Thrift
Hello,
I was just wondering if there is any username/password level security build
in framework level. I see we can use SSL but for us we just need simple
check for username/password.
thanks for help.
-rajneesh
Re: username/password - security in Apache Thrift
Posted by George Chung <ge...@glympse.com>.
>
> > 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.
Re: username/password - security in Apache Thrift
Posted by Ben Craig <be...@apache.org>.
> > 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.
Re: username/password - security in Apache Thrift
Posted by George Chung <ge...@glympse.com>.
Is your concern that you don't want your server side to even handle a
cleartext password? Yes, there are possible attacks against that type of
auth scheme that protocols such as Kerberos, CHAP, etc. mitigate. But
unfortunately, they are not integrated into Thrift.
On Wed, Sep 25, 2013 at 1:12 PM, George Chung <ge...@glympse.com> wrote:
> 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.
>
>
>
>> 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.
>
>
> On Wed, Sep 25, 2013 at 1:01 PM, Craig Artley <ca...@hotmail.com> wrote:
>
>> I guess I am not that clever; I need an example or how-to. I would like
>> to add password authentication to a thrift service, 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. 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.
>>
>> Thanks for the pointers on TLS-SRP. I'll take a look and see if I can
>> figure it out.
>>
>> -craig
>>
>> > Date: Wed, 25 Sep 2013 12:09:00 -0700
>> > Subject: Re: username/password - security in Apache Thrift
>> > From: george@glympse.com
>> > To: user@thrift.apache.org
>> >
>> > And it's worth noting that authentication via client side certs is a
>> > "standard, reliable, vetted mechanism" that is already layered into
>> Thrift
>> > via its support for SSL.
>> >
>> > un/pw authentication is typically considered an application layer
>> concern.
>> > I've not heard of TLS-SRP until now...that's cool!
>> >
>> >
>> > On Wed, Sep 25, 2013 at 11:11 AM, Ben Craig <be...@apache.org>
>> wrote:
>> >
>> > > > Does the thrift user have to build all the user authentication into
>> > > > the protocol? It seems like there should be some standard, reliable,
>> > > > vetted mechanism that could be layered into Thrift.
>> > >
>> > > Sending a username and password over an SSL connection is a very
>> common
>> > > pattern. It is difficult for Thrift to do "everything" here, because
>> > > Thrift doesn't have access to whatever the backing database is that
>> stores
>> > > the usernames and passwords.
>> > >
>> > > If you are looking for something that uses the username and password
>> as
>> > > the only forms of authentication (in lieu of certificates), then you
>> > > should investigate TLS-SRP (http://en.wikipedia.org/wiki/TLS-SRP).
>> You
>> > > would likely need to create a new transport class to wrap TLS-SRP.
>> > >
>>
>>
>
>
Re: Issues with client transport not closing sockets
Posted by Dan Engelbrecht <da...@engelbrecht.com>.
Yeah, I know but I need to make it "behave" so my option is the workaround currently.
A lot of classes has an explicit "close" or "dispose" for just this purpose - open files etc.
I'm just asking if a close method on the client wouldn't be appropriate in java (and maybe other languages for consistency).
Dan
27 sep 2013 kl. 13:36 skrev George Chung <ge...@glympse.com>:
> The type of issue you are describing is sometimes called the "deterministic
> finalization" issue in garbage collected environments...where the objects
> wrap actual OS resources that need to be "closed" deterministically. I
> haven't used Java in a while, but other languages provide support for this
> for exactly this reason.
>
>
> On Fri, Sep 27, 2013 at 3:21 AM, Dan Engelbrecht <da...@engelbrecht.com>wrote:
>
>> Hi all, have been quietly following this mailinglist for a while and doing
>> some thrift programming.
>>
>> I have stumbeled onto a java issue which relates (indirectly) to garbage
>> collection.
>>
>> If I create a client that connects to a server and then let the client
>> fall out of scope the clients socket stays open (probably until gc?) which
>> can be a long while - in my testapp that equated to more or less "forever".
>>
>> This would not be so bad with the exception that my TThreadPool server
>> wont stop.
>>
>> I can get around this by manually closing the transports for the client
>> but that is quite ugly:
>>
>> client.getInputProtocol().getTransport().close();
>> client.getOutputProtocol().getTransport().close();
>>
>> I could keep the client transport instance around but then I need to
>> maintain two variables for one client.
>>
>> Wouldn't a .close() on the client be a better option? Or am I missing
>> something?
>>
>> Best regards
>> Dan Engelbrecht
Re: Issues with client transport not closing sockets
Posted by George Chung <ge...@glympse.com>.
The type of issue you are describing is sometimes called the "deterministic
finalization" issue in garbage collected environments...where the objects
wrap actual OS resources that need to be "closed" deterministically. I
haven't used Java in a while, but other languages provide support for this
for exactly this reason.
On Fri, Sep 27, 2013 at 3:21 AM, Dan Engelbrecht <da...@engelbrecht.com>wrote:
> Hi all, have been quietly following this mailinglist for a while and doing
> some thrift programming.
>
> I have stumbeled onto a java issue which relates (indirectly) to garbage
> collection.
>
> If I create a client that connects to a server and then let the client
> fall out of scope the clients socket stays open (probably until gc?) which
> can be a long while - in my testapp that equated to more or less "forever".
>
> This would not be so bad with the exception that my TThreadPool server
> wont stop.
>
> I can get around this by manually closing the transports for the client
> but that is quite ugly:
>
> client.getInputProtocol().getTransport().close();
> client.getOutputProtocol().getTransport().close();
>
> I could keep the client transport instance around but then I need to
> maintain two variables for one client.
>
> Wouldn't a .close() on the client be a better option? Or am I missing
> something?
>
> Best regards
> Dan Engelbrecht
Issues with client transport not closing sockets
Posted by Dan Engelbrecht <da...@engelbrecht.com>.
Hi all, have been quietly following this mailinglist for a while and doing some thrift programming.
I have stumbeled onto a java issue which relates (indirectly) to garbage collection.
If I create a client that connects to a server and then let the client fall out of scope the clients socket stays open (probably until gc?) which can be a long while - in my testapp that equated to more or less "forever".
This would not be so bad with the exception that my TThreadPool server wont stop.
I can get around this by manually closing the transports for the client but that is quite ugly:
client.getInputProtocol().getTransport().close();
client.getOutputProtocol().getTransport().close();
I could keep the client transport instance around but then I need to maintain two variables for one client.
Wouldn't a .close() on the client be a better option? Or am I missing something?
Best regards
Dan Engelbrecht
Re: username/password - security in Apache Thrift
Posted by George Chung <ge...@glympse.com>.
[...] your server side is going to handle the un
> and cleartext pw and ask some service to validate
>> the combination.
>>
>
> Whoa. How do you manage comparing against a clear text pwd when you have
> salted hashes in your DB? You /do/ have salted hashes, do you?
>
> ;-)
>
>
Well, either your server or your service that you are delegating to has to
perform the one way hash with the salt...if that's the way you (or the
service) is storing them. :)
But I think you already knew that... ;-)
Re: username/password - security in Apache Thrift
Posted by Jens Geyer <je...@hotmail.com>.
> [...] your server side is going to handle the un
> and cleartext pw and ask some service to validate
> the combination.
Whoa. How do you manage comparing against a clear text pwd when you have
salted hashes in your DB? You /do/ have salted hashes, do you?
;-)
-----Ursprüngliche Nachricht-----
From: George Chung
Sent: Wednesday, September 25, 2013 10:12 PM
To: user@thrift.apache.org
Subject: Re: username/password - security in Apache Thrift
>
> 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.
> 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.
On Wed, Sep 25, 2013 at 1:01 PM, Craig Artley <ca...@hotmail.com> wrote:
> I guess I am not that clever; I need an example or how-to. I would like to
> add password authentication to a thrift service, 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. 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.
>
> Thanks for the pointers on TLS-SRP. I'll take a look and see if I can
> figure it out.
>
> -craig
>
> > Date: Wed, 25 Sep 2013 12:09:00 -0700
> > Subject: Re: username/password - security in Apache Thrift
> > From: george@glympse.com
> > To: user@thrift.apache.org
> >
> > And it's worth noting that authentication via client side certs is a
> > "standard, reliable, vetted mechanism" that is already layered into
> Thrift
> > via its support for SSL.
> >
> > un/pw authentication is typically considered an application layer
> concern.
> > I've not heard of TLS-SRP until now...that's cool!
> >
> >
> > On Wed, Sep 25, 2013 at 11:11 AM, Ben Craig <be...@apache.org> wrote:
> >
> > > > Does the thrift user have to build all the user authentication into
> > > > the protocol? It seems like there should be some standard, reliable,
> > > > vetted mechanism that could be layered into Thrift.
> > >
> > > Sending a username and password over an SSL connection is a very
> > > common
> > > pattern. It is difficult for Thrift to do "everything" here, because
> > > Thrift doesn't have access to whatever the backing database is that
> stores
> > > the usernames and passwords.
> > >
> > > If you are looking for something that uses the username and password
> > > as
> > > the only forms of authentication (in lieu of certificates), then you
> > > should investigate TLS-SRP (http://en.wikipedia.org/wiki/TLS-SRP).
> You
> > > would likely need to create a new transport class to wrap TLS-SRP.
> > >
>
>
Re: username/password - security in Apache Thrift
Posted by George Chung <ge...@glympse.com>.
>
> 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.
> 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.
On Wed, Sep 25, 2013 at 1:01 PM, Craig Artley <ca...@hotmail.com> wrote:
> I guess I am not that clever; I need an example or how-to. I would like to
> add password authentication to a thrift service, 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. 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.
>
> Thanks for the pointers on TLS-SRP. I'll take a look and see if I can
> figure it out.
>
> -craig
>
> > Date: Wed, 25 Sep 2013 12:09:00 -0700
> > Subject: Re: username/password - security in Apache Thrift
> > From: george@glympse.com
> > To: user@thrift.apache.org
> >
> > And it's worth noting that authentication via client side certs is a
> > "standard, reliable, vetted mechanism" that is already layered into
> Thrift
> > via its support for SSL.
> >
> > un/pw authentication is typically considered an application layer
> concern.
> > I've not heard of TLS-SRP until now...that's cool!
> >
> >
> > On Wed, Sep 25, 2013 at 11:11 AM, Ben Craig <be...@apache.org> wrote:
> >
> > > > Does the thrift user have to build all the user authentication into
> > > > the protocol? It seems like there should be some standard, reliable,
> > > > vetted mechanism that could be layered into Thrift.
> > >
> > > Sending a username and password over an SSL connection is a very common
> > > pattern. It is difficult for Thrift to do "everything" here, because
> > > Thrift doesn't have access to whatever the backing database is that
> stores
> > > the usernames and passwords.
> > >
> > > If you are looking for something that uses the username and password as
> > > the only forms of authentication (in lieu of certificates), then you
> > > should investigate TLS-SRP (http://en.wikipedia.org/wiki/TLS-SRP).
> You
> > > would likely need to create a new transport class to wrap TLS-SRP.
> > >
>
>
RE: username/password - security in Apache Thrift
Posted by Craig Artley <ca...@hotmail.com>.
I guess I am not that clever; I need an example or how-to. I would like to add password authentication to a thrift service, 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. 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.
Thanks for the pointers on TLS-SRP. I'll take a look and see if I can figure it out.
-craig
> Date: Wed, 25 Sep 2013 12:09:00 -0700
> Subject: Re: username/password - security in Apache Thrift
> From: george@glympse.com
> To: user@thrift.apache.org
>
> And it's worth noting that authentication via client side certs is a
> "standard, reliable, vetted mechanism" that is already layered into Thrift
> via its support for SSL.
>
> un/pw authentication is typically considered an application layer concern.
> I've not heard of TLS-SRP until now...that's cool!
>
>
> On Wed, Sep 25, 2013 at 11:11 AM, Ben Craig <be...@apache.org> wrote:
>
> > > Does the thrift user have to build all the user authentication into
> > > the protocol? It seems like there should be some standard, reliable,
> > > vetted mechanism that could be layered into Thrift.
> >
> > Sending a username and password over an SSL connection is a very common
> > pattern. It is difficult for Thrift to do "everything" here, because
> > Thrift doesn't have access to whatever the backing database is that stores
> > the usernames and passwords.
> >
> > If you are looking for something that uses the username and password as
> > the only forms of authentication (in lieu of certificates), then you
> > should investigate TLS-SRP (http://en.wikipedia.org/wiki/TLS-SRP). You
> > would likely need to create a new transport class to wrap TLS-SRP.
> >
Re: username/password - security in Apache Thrift
Posted by George Chung <ge...@glympse.com>.
And it's worth noting that authentication via client side certs is a
"standard, reliable, vetted mechanism" that is already layered into Thrift
via its support for SSL.
un/pw authentication is typically considered an application layer concern.
I've not heard of TLS-SRP until now...that's cool!
On Wed, Sep 25, 2013 at 11:11 AM, Ben Craig <be...@apache.org> wrote:
> > Does the thrift user have to build all the user authentication into
> > the protocol? It seems like there should be some standard, reliable,
> > vetted mechanism that could be layered into Thrift.
>
> Sending a username and password over an SSL connection is a very common
> pattern. It is difficult for Thrift to do "everything" here, because
> Thrift doesn't have access to whatever the backing database is that stores
> the usernames and passwords.
>
> If you are looking for something that uses the username and password as
> the only forms of authentication (in lieu of certificates), then you
> should investigate TLS-SRP (http://en.wikipedia.org/wiki/TLS-SRP). You
> would likely need to create a new transport class to wrap TLS-SRP.
>
RE: username/password - security in Apache Thrift
Posted by Ben Craig <be...@apache.org>.
> Does the thrift user have to build all the user authentication into
> the protocol? It seems like there should be some standard, reliable,
> vetted mechanism that could be layered into Thrift.
Sending a username and password over an SSL connection is a very common
pattern. It is difficult for Thrift to do "everything" here, because
Thrift doesn't have access to whatever the backing database is that stores
the usernames and passwords.
If you are looking for something that uses the username and password as
the only forms of authentication (in lieu of certificates), then you
should investigate TLS-SRP (http://en.wikipedia.org/wiki/TLS-SRP). You
would likely need to create a new transport class to wrap TLS-SRP.
RE: username/password - security in Apache Thrift
Posted by Craig Artley <ca...@hotmail.com>.
Does the thrift user have to build all the user authentication into the protocol? It seems like there should be some standard, reliable, vetted mechanism that could be layered into Thrift.
-craig
> Date: Wed, 25 Sep 2013 10:18:16 -0700
> Subject: Re: username/password - security in Apache Thrift
> From: george@glympse.com
> To: user@thrift.apache.org
>
> You could use SSL sockets as a secure way to xmit un/pw. Wouldn't that work
> for you?
>
>
> On Wed, Sep 25, 2013 at 9:53 AM, Rajneesh kapur <ka...@gmail.com> wrote:
>
> > Hello,
> >
> > I was just wondering if there is any username/password level security build
> > in framework level. I see we can use SSL but for us we just need simple
> > check for username/password.
> >
> > thanks for help.
> > -rajneesh
> >
Re: username/password - security in Apache Thrift
Posted by George Chung <ge...@glympse.com>.
You could use SSL sockets as a secure way to xmit un/pw. Wouldn't that work
for you?
On Wed, Sep 25, 2013 at 9:53 AM, Rajneesh kapur <ka...@gmail.com> wrote:
> Hello,
>
> I was just wondering if there is any username/password level security build
> in framework level. I see we can use SSL but for us we just need simple
> check for username/password.
>
> thanks for help.
> -rajneesh
>