NTLM hashed passwords.
Hi all, for a couple of years now we have been using freeradius to support a Wifi network. We are using WPA2-Enterprise. We need to support clients running any and every operating system. Currently we store passwords as plain text in a "radcheck" table in the database. I am experimenting with replacing "User-Password" (yes, I know it should be "Cleartext-Password") with an "NT-Password" generated by smbencrypt. So far it seems mostly okay with Windows, Android, iOS and MacOS. And Linux. Are there any pitfalls or gotchas to watch out for? Any systems that only do MSCHAPv1 (which I believe requires the plain text password). thanks dom
On Jul 15, 2016, at 11:34 AM, Dom Latter <freeradius-users@latter.org> wrote:
for a couple of years now we have been using freeradius to support a Wifi network. We are using WPA2-Enterprise. We need to support clients running any and every operating system.
Currently we store passwords as plain text in a "radcheck" table in the database.
I am experimenting with replacing "User-Password" (yes, I know it should be "Cleartext-Password") with an "NT-Password" generated by smbencrypt.
So far it seems mostly okay with Windows, Android, iOS and MacOS. And Linux.
That's not the real criteria.
Are there any pitfalls or gotchas to watch out for? Any systems that only do MSCHAPv1 (which I believe requires the plain text password).
The definitive answer is here: http://deployingradius.com/documents/protocols/compatibility.html Note there is no mention of OS. Just authentication protocol. See your OS documentation for what authentication protocols it supports, and then look up the protocol in the table. Alan DeKok.
On 15/07/16 16:40, Alan DeKok wrote:
Note there is no mention of OS. Just authentication protocol. See your OS documentation for what authentication protocols it supports, and then look up the protocol in the table.
I do not have the OS documentation for every single possible client. What I *do* have is the hope that somebody here might be able to say either "yes, you'll find NT-Password works for everything apart from Windows 95" or "forget it, a substantial chunk of your users will not be able to connect".
On Jul 15, 2016, at 11:49 AM, freeradius-users@latter.org wrote:
I do not have the OS documentation for every single possible client.
Neither do I.
What I *do* have is the hope that somebody here might be able to say either "yes, you'll find NT-Password works for everything apart from Windows 95" or "forget it, a substantial chunk of your users will not be able to connect".
What I *would* expect is that you have some idea as to which clients are connecting to your network. If you don't know, why would you expect me to know? Alan DeKok.
On Jul 15, 2016, at 11:34 AM, Dom Latter <freeradius-users@latter.org> wrote:
Hi all,
for a couple of years now we have been using freeradius to support a Wifi network. We are using WPA2-Enterprise. We need to support clients running any and every operating system.
Currently we store passwords as plain text in a "radcheck" table in the database.
I am experimenting with replacing "User-Password" (yes, I know it should be "Cleartext-Password") with an "NT-Password" generated by smbencrypt.
So far it seems mostly okay with Windows, Android, iOS and MacOS. And Linux.
Are there any pitfalls or gotchas to watch out for? Any systems that only do MSCHAPv1 (which I believe requires the plain text password).
No. All modern supplicants and authentication clients use MSCHAPv2. The most common applications are PEAPv0 and PPTP. There's not a huge advantage in storing unsalted MD4 hashed passwords. -Arran
On 15/07/16 16:52, Arran Cudbard-Bell wrote:
No. All modern supplicants and authentication clients use MSCHAPv2.
Sounds promising.
The most common applications are PEAPv0 and PPTP.
There's not a huge advantage in storing unsalted MD4 hashed passwords.
In terms of security? It ticks the box marked "did the best we could". And it does protect those who use long passwords. And we might yet enforce stricter password strengths - the original rules were designed to deal with (slow) *on-line* attacks.
On Jul 15, 2016, at 1:20 PM, freeradius-users@latter.org wrote:
On 15/07/16 16:52, Arran Cudbard-Bell wrote:
No. All modern supplicants and authentication clients use MSCHAPv2.
Sounds promising.
The most common applications are PEAPv0 and PPTP.
There's not a huge advantage in storing unsalted MD4 hashed passwords.
In terms of security? It ticks the box marked "did the best we could".
No, the best you could would be to use EAP-TLS, because PEAP and TTLS are horrifically insecure in their current OSX and Windows implementations.
And it does protect those who use long passwords.
Not really, you just need to find a collision, the length of the password doesn't matter for that type of attack. It does stop an attacker using the collided password with another service, that's about it. -Arran
On 15/07/16 18:35, Arran Cudbard-Bell wrote:
On Jul 15, 2016, at 1:20 PM, freeradius-users@latter.org wrote:
On 15/07/16 16:52, Arran Cudbard-Bell wrote:
There's not a huge advantage in storing unsalted MD4 hashed passwords.
In terms of security? It ticks the box marked "did the best we could".
No, the best you could would be to use EAP-TLS, because PEAP and TTLS are horrifically insecure in their current OSX and Windows implementations.
Unfortunately the commercial reality of it is that we must stick to the "convenience" end of the "security-versus-convenience" scale. In a week we will have about 6000 wifi devices authenticating. Most are regular users but a fair number are only using it for the day. We have no control over what people turn up with - could be a PDP-11 or an internet-enabled fridge magnet. The devices tend more towards the MacOS / iOS than you might find in general. Most of the users are non-technical, but there's enough full-time geeks to keep us on our toes.
And it does protect those who use long passwords.
Not really, you just need to find a collision, the length of the password doesn't matter for that type of attack.
It does stop an attacker using the collided password with another service, that's about it.
Which is the point, a lot of the time, IMO.
On Jul 15, 2016, at 1:20 PM, freeradius-users@latter.org wrote:
On 15/07/16 16:52, Arran Cudbard-Bell wro In terms of security? It ticks the box marked "did the best we could". And it does protect those who use long passwords. And we might yet enforce stricter password strengths - the original rules were designed to deal with (slow) *on-line* attacks.
In 2016, NT hashed passwords are not really any more secure than clear-text passwords. And, NT hashed passwords prevent some authentication methods from working. Alan DeKok.
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
Dom Latter -
freeradius-users＠latter.org