Discussion:
Authentication protocols that DO support hashed passwords
(too old to reply)
Alan DeKok
2014-11-10 19:05:49 UTC
Permalink
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
2014-11-10 19:23:41 UTC
Permalink
> On 10 Nov 2014, at 14:01, E.S. Rosenberg <esr+freeradius-***@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-td2781170.html
>
> 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 <***@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
k***@rice.edu
2014-11-10 19:27:30 UTC
Permalink
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
2014-11-10 19:46:36 UTC
Permalink
> 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: ***@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
2014-11-10 19:51:22 UTC
Permalink
> 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
2014-11-11 10:33:43 UTC
Permalink
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: +44 (0)1235 822 125
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
2014-11-13 16:20:19 UTC
Permalink
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
2014-11-13 16:31:13 UTC
Permalink
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
2014-11-10 20:21:04 UTC
Permalink
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
2014-11-11 14:58:43 UTC
Permalink
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
2014-11-11 20:03:46 UTC
Permalink
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan DeKok
2014-11-12 13:39:33 UTC
Permalink
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
Loading...