Authentication protocols that DO support hashed passwords
Hi all, I was doing some research into the authentication protocol used by a VPN solution we are trying and cam across this fairly old thread on your list: http://freeradius.1045715.n5.nabble.com/Chap-auhtentication-against-LDAP-td2... Which in turn links to a nice page by Alan DeKok here: http://deployingradius.com/documents/protocols/compatibility.html Which left me asking myself 2 questions: 1. Did anything change in the past 5 years, is there any decently supported protocol that does support hashed passwords (other then PAP)? 2. How can it be that all these protocols were designed with the idea that the auth server should have a cleartext copy of the users' password, haven't we all known for years now that that's a bad idea? Thanks in advance, Eli
E.S. Rosenberg wrote:
Which in turn links to a nice page by Alan DeKok here: http://deployingradius.com/documents/protocols/compatibility.html
Which left me asking myself 2 questions: 1. Did anything change in the past 5 years, is there any decently supported protocol that does support hashed passwords (other then PAP)?
MD5 etc. hasn't changed in the last 5 years. So the table (and conclusions) haven't changed either.
2. How can it be that all these protocols were designed with the idea that the auth server should have a cleartext copy of the users' password, haven't we all known for years now that that's a bad idea?
Because different people have different needs. And most people don't think about RADIUS until it's too late to change their password storage method. Alan DeKok.
On Mon, Nov 10, 2014 at 9:05 PM, Alan DeKok <aland@deployingradius.com> wrote:
E.S. Rosenberg wrote:
Which in turn links to a nice page by Alan DeKok here: http://deployingradius.com/documents/protocols/compatibility.html
Which left me asking myself 2 questions: 1. Did anything change in the past 5 years, is there any decently supported protocol that does support hashed passwords (other then PAP)?
MD5 etc. hasn't changed in the last 5 years. So the table (and conclusions) haven't changed either. No new EAP on the block that handles passwords stored in salted hashes?
2. How can it be that all these protocols were designed with the idea that the auth server should have a cleartext copy of the users' password, haven't we all known for years now that that's a bad idea?
Because different people have different needs. And most people don't think about RADIUS until it's too late to change their password storage method. I understand that, my question is more "How is it that the various RADIUS protocols can only work with cleartext passwords known on the RADIUS server side?" To me (someone who has been doing systemadmin/network admin/(web) development work) it seems like the most obvious thing in the world that I don't want my users passwords to be stored anywhere where me/any of my co-workers can get to them in cleartext and since root can get everywhere that means cleartext passwords belong nowhere.
Now I may be naive or have never tried to develop an AUTH protocol, so I am just very curious what the arguments are to store cleartext? Regards and thanks for the quick reply, Eli
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Mon, Nov 10, 2014 at 09:18:15PM +0200, E.S. Rosenberg wrote:
... To me (someone who has been doing systemadmin/network admin/(web) development work) it seems like the most obvious thing in the world that I don't want my users passwords to be stored anywhere where me/any of my co-workers can get to them in cleartext and since root can get everywhere that means cleartext passwords belong nowhere.
Now I may be naive or have never tried to develop an AUTH protocol, so I am just very curious what the arguments are to store cleartext? Regards and thanks for the quick reply, Eli
Kerberos works well and does not require that cleartext passwords be stored on the server. Regards, Ken
Kerberos works well and does not require that cleartext passwords be stored on the server.
But to be able to use Kerberos with RADIUS, you need the clear-text password. :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
On 10 Nov 2014, at 14:46, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
Kerberos works well and does not require that cleartext passwords be stored on the server.
But to be able to use Kerberos with RADIUS, you need the clear-text password.
There's mention on the janet/eduroam site about EAP-PWD being used with salted hashes: https://community.ja.net/groups/eduroam/document/eap-pwd-moving-towards-depl.... Did anything come of that? Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 10 Nov 2014, at 19:51, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
There's mention on the janet/eduroam site about EAP-PWD being used with salted hashes: https://community.ja.net/groups/eduroam/document/eap-pwd-moving-towards-depl....
Did anything come of that?
It's an RFC... http://tools.ietf.org/html/rfc5931 :-) But yeah... if no supplicant supports it (wpa_supplicant does), it's not going anywhere... :-/ Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
Hi,
There's mention on the janet/eduroam site about EAP-PWD being used with salted hashes: https://community.ja.net/groups/eduroam/document/eap-pwd-moving-towards-depl....
Did anything come of that? It's an RFC... http://tools.ietf.org/html/rfc5931 :-)
But yeah... if no supplicant supports it (wpa_supplicant does), it's not going anywhere... :-/
That's very incorrect. There's a supplicant for Windows, and even Android exposes it in it's UI (by virtue of having wpa_supplicant in the backend). There's a new I-D to allow salted hashes (as opposed to "only" hashes in its first version). It's true that it has not been exposed much, the main and only argument being "the crypto is complex and has not been tested enough by cryptographers". IMHO, cryptopgraphy researchers should GET GOING and evaluate it instead of complaining that their community hasn't evaluated it enough yet. BTW, eduroam CAT and https://802.1x-config.org support EAP-pwd for Windows (we ship the supplicant in the Windows CAT installer). Greetings, Stefan Winter
Stefan Winter wrote:
It's true that it has not been exposed much, the main and only argument being "the crypto is complex and has not been tested enough by cryptographers". IMHO, cryptopgraphy researchers should GET GOING and evaluate it instead of complaining that their community hasn't evaluated it enough yet.
Dan Harkins isn't a well known cryptographic researcher. He's done a lot more work in the space than I have in the space. But the "cabal" of cryptographic researchers don't know him very well. So.. they ignore what he's done. I don't really see that changing, unless people start deploying EAP-PWD. Then, the researchers can get papers published by criticizing his work. Alan DeKok.
E.S. Rosenberg wrote:
No new EAP on the block that handles passwords stored in salted hashes?
Not really, no. The reason is simple. Q: How do you get a new EAP method to 10^9 existing devices? A: You don't.
I understand that, my question is more "How is it that the various RADIUS protocols can only work with cleartext passwords known on the RADIUS server side?"
Because the RADIUS server gets given a hash by the client. If the RADIUS server can find a clear-text password in the database, it can re-create the hash, and compare the two hashes. If the RADIUS server has a hashed password in the database, it can't compare MD5(password) to SHA1(password). The hashing methods are designed to make that kind of comparison *impossible*.
To me (someone who has been doing systemadmin/network admin/(web) development work) it seems like the most obvious thing in the world that I don't want my users passwords to be stored anywhere where me/any of my co-workers can get to them in cleartext and since root can get everywhere that means cleartext passwords belong nowhere.
Your ideas are admirable, but unrealistic.
Now I may be naive or have never tried to develop an AUTH protocol, so I am just very curious what the arguments are to store cleartext?
See above. You *cannot* focus on one piece of the system. "I want the passwords stored in hashed form in the DB, NO MATTER WHAT EFFECT IT HAS ANYWHERE ELSE IN THE NETWORK". You have to take ALL things into consideration. The supplicant (end user PC), database, authentication protocol, etc. Then, choose the least crappy method which satisfies all pieces. And the winner is usually clear-text passwords. Alan DeKok.
On Mon, Nov 10, 2014 at 10:21 PM, Alan DeKok <aland@deployingradius.com> wrote:
E.S. Rosenberg wrote:
No new EAP on the block that handles passwords stored in salted hashes?
Not really, no. The reason is simple.
Q: How do you get a new EAP method to 10^9 existing devices?
A: You don't.
I understand that, my question is more "How is it that the various RADIUS protocols can only work with cleartext passwords known on the RADIUS server side?"
Because the RADIUS server gets given a hash by the client. If the RADIUS server can find a clear-text password in the database, it can re-create the hash, and compare the two hashes.
If the RADIUS server has a hashed password in the database, it can't compare MD5(password) to SHA1(password). The hashing methods are designed to make that kind of comparison *impossible*. Since the hashing functions also exist on the client side what stops the protocols from basing the hash requested from the client on the _hash_ of the users' password? And if it's salted then the server would have to send the salt used in the db to the client so that it ends up with the same hash as the server... When you log into to an average modern *nix system it does exactly that hash(password) compare to stored hash in /etc/shadow or ldap. (And if salted first extract salt from stored hash then hash(salt, password) and compare)
Regards, Eli
To me (someone who has been doing systemadmin/network admin/(web) development work) it seems like the most obvious thing in the world that I don't want my users passwords to be stored anywhere where me/any of my co-workers can get to them in cleartext and since root can get everywhere that means cleartext passwords belong nowhere.
Your ideas are admirable, but unrealistic.
Now I may be naive or have never tried to develop an AUTH protocol, so I am just very curious what the arguments are to store cleartext?
See above.
You *cannot* focus on one piece of the system. "I want the passwords stored in hashed form in the DB, NO MATTER WHAT EFFECT IT HAS ANYWHERE ELSE IN THE NETWORK".
You have to take ALL things into consideration. The supplicant (end user PC), database, authentication protocol, etc. Then, choose the least crappy method which satisfies all pieces.
And the winner is usually clear-text passwords.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 11/11/14 14:41, E.S. Rosenberg wrote:
Since the hashing functions also exist on the client side what stops the protocols from basing the hash requested from the client on the _hash_ of the users' password?
Nothing "stops" the protocols doing that. They just don't, because they weren't very well designed. You need to understand what people are telling you - designing a new, better protocol isn't the problem. EAP-PWD, or older protocols like SRP, have solved this problem. The problem is updating the hundreds of millions of laptops, tablets, and mobile phones. The problem is inertia. It's not a technical problem, and you can't look for technical solutions.
E.S. Rosenberg wrote:
Since the hashing functions also exist on the client side what stops the protocols from basing the hash requested from the client on the _hash_ of the users' password?
They're not designed to do that. This isn't a difficult concept. Protocols are defined to have a certain behavior. You can't just randomly change the behavior, and expect the same results. All of the rest of your speculations are based on inexperience, and a lack of understanding of how these protocols work. We're not the ones who designed the protocols. We're not the ones who implemented the Microsoft, Apple, etc. side of the protocols. We're just explaining to you why your ideas won't work. There's no point in discussing changes on this list. For one, you don't know what changes to make, because you don't know how the protocols work. For two, we don't control the protocol design or their implementations. Alan DeKok.
On Tue, Nov 11, 2014 at 10:03 PM, Alan DeKok <aland@deployingradius.com> wrote:
E.S. Rosenberg wrote:
Since the hashing functions also exist on the client side what stops the protocols from basing the hash requested from the client on the _hash_ of the users' password?
They're not designed to do that.
This isn't a difficult concept. Protocols are defined to have a certain behavior. You can't just randomly change the behavior, and expect the same results.
All of the rest of your speculations are based on inexperience, and a lack of understanding of how these protocols work. We're not the ones who designed the protocols. We're not the ones who implemented the Microsoft, Apple, etc. side of the protocols. We're just explaining to you why your ideas won't work.
There's no point in discussing changes on this list. For one, you don't know what changes to make, because you don't know how the protocols work. For two, we don't control the protocol design or their implementations. Thanks for all the explanations, this discussion has been enlightening. As far as the don't design/control goes in some other OSS projects I am familiar with the contributors to the project also took active rolls in newer standards to be developed since they were also stakeholder/parties of interest. EAP-PWD definitely looks interesting and I'll be keeping an eye on it.
Above "supporting all existing devices" is mentioned, but we do have the luxury with newer services to say "this service is only supported on" (and since we are a *nix outfit that's even easier we don't have to support MS stuff). Regards and thanks for all your time invested in answering my questions, Eli
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
E.S. Rosenberg wrote:
Thanks for all the explanations, this discussion has been enlightening. As far as the don't design/control goes in some other OSS projects I am familiar with the contributors to the project also took active rolls in newer standards to be developed since they were also stakeholder/parties of interest.
If you look... I'm author on a large number of RADIUS RFCs. And have about another 5-6 in the queue for eventual publication.
EAP-PWD definitely looks interesting and I'll be keeping an eye on it.
I won't hold my breath. Microsoft implements TTLS and PEAP on the PC. IAS (or whatever they're calling it these days) only does PEAP.
Above "supporting all existing devices" is mentioned, but we do have the luxury with newer services to say "this service is only supported on" (and since we are a *nix outfit that's even easier we don't have to support MS stuff).
Deploying a new EAP protocol everywhere is *hard*. Alan DeKok.
On 10 Nov 2014, at 14:01, E.S. Rosenberg <esr+freeradius-users@mail.hebrew.edu> wrote:
Hi all, I was doing some research into the authentication protocol used by a VPN solution we are trying and cam across this fairly old thread on your list: http://freeradius.1045715.n5.nabble.com/Chap-auhtentication-against-LDAP-td2...
Which in turn links to a nice page by Alan DeKok here: http://deployingradius.com/documents/protocols/compatibility.html
Which left me asking myself 2 questions: 1. Did anything change in the past 5 years, is there any decently supported protocol that does support hashed passwords (other then PAP)?
Windows 8 now supports EAP-TTLS-PAP.
2. How can it be that all these protocols were designed with the idea that the auth server should have a cleartext copy of the users' password, haven't we all known for years now that that's a bad idea?
Passwords in general are shit security. If you want something secure use EAP-TLS it's supported by every major supplicant. The private key need only be known to one party (the supplicant). If you still want passwords for 2FA, allow the users to set encryption keys for the private cert. Then, if your DB is compromised there's nothing to leak, except user identities. Most of the difficulties around managing PKI are imagined. For OSX and Windows you can easily generate network profiles that bundle personal certs with the settings required to connect to Wired/Wireless Networks and VPNs. If you're concerned about passwords being compromised stop using passwords. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (7)
-
Alan DeKok -
Arran Cudbard-Bell -
E.S. Rosenberg -
ktm＠rice.edu -
Phil Mayers -
Stefan Paetow -
Stefan Winter