Authentication protocols that DO support hashed passwords

[Alan DeKok]

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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Arran Cudbard-Bell]

This post might be inappropriate. Click to display it.

[k***@rice.edu]

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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Stefan Paetow]

> 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: [phone]
gpg: 0x3FCE5142
xmpp: ***@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.





-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Arran Cudbard-Bell]

> On 10 Nov 2014, at 14:46, 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-deployable-standard.

Did anything come of that?

Arran Cudbard-Bell <***@freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Stefan Paetow]

On 10 Nov 2014, at 19:51, Arran Cudbard-Bell <***@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-deployable-standard.
>
> 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: [phone]
gpg: 0x3FCE5142
xmpp: ***@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.

[Stefan Winter]

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

[Alan DeKok]

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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Phil Mayers]

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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan DeKok]

This post might be inappropriate. Click to display it.

[Alan DeKok]

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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html