AES encrypted passwords
Hi, [tech details at end [1]] some of you may remember me from a couple of months back asking about NTLM hashed passwords. I gave those a brief go but found that some devices just didn't work with them. The requirement - a commercial and marketing requirement, not a technical one - has not gone away and it is that we can say that we do not store the passwords in plain text. I have concocted a scheme whereby we do that - the following goes into dialup.conf and is I hope self-explanatory: authorize_check_query = "SELECT id, username, attribute, value, op \ FROM ${authcheck_table} \ WHERE username = '%{SQL-User-Name}' \ AND attribute != 'AES-Password' \ UNION \ SELECT id, username, 'User-Password', \ AES_DECRYPT(UNHEX(value), 'aeskey'), op \ FROM radcheck \ WHERE username = '%{SQL-User-Name}' \ AND attribute = 'AES-Password' \ ORDER BY id" We replace User-Password with AES-Password, decrypt it in the sql query and pass it back to radius /as/ User-Password. (Or Cleartext-Password is more likely in the final implementation). Yes, the key is now held in /etc/freeradius and if someone gets that as well as the database then it's much the same as storing the passwords in plain text. But we can *say* that they are stored encrypted - and there may be a slight edge in security, as a file in /etc/ *may* be less vulnerable than a mysql database. Any thoughts on this scheme? thanks dom [1] wifi network with aerohive access points; freeradius with mysql data store; WPA2-Enterprise, MSCHAPv2, no control whatsoever over what the users want to connect to the network.
On Sep 29, 2016, at 12:13 PM, Dom Latter <freeradius-users@latter.org> wrote:
some of you may remember me from a couple of months back asking about NTLM hashed passwords. I gave those a brief go but found that some devices just didn't work with them.
What does that mean? There is no "device" compatibility issues with NT hashed passwords. Only incompatibility with password hashing schemes. See http://deployingradius.com/documents/protocols/compatibility.html for more details.
The requirement - a commercial and marketing requirement, not a technical one - has not gone away and it is that we can say that we do not store the passwords in plain text.
See the compatibility page. You don't rally have a choice in some cases. When marketing requirements try to over-ride technical limitations, that doesn't work very well.
I have concocted a scheme whereby we do that - the following goes into dialup.conf and is I hope self-explanatory:
authorize_check_query = "SELECT id, username, attribute, value, op \ FROM ${authcheck_table} \ WHERE username = '%{SQL-User-Name}' \ AND attribute != 'AES-Password' \ UNION \ SELECT id, username, 'User-Password', \ AES_DECRYPT(UNHEX(value), 'aeskey'), op \ FROM radcheck \ WHERE username = '%{SQL-User-Name}' \ AND attribute = 'AES-Password' \ ORDER BY id"
I guess that will work. Tho it's not any more secure than just storing clear-text passwords in SQL. If you want security, store the encrypted passwords in SQL, and then decrypt them on the RADIUS server. That way the SQL database has the passwords but not the decryption key, and the RADIUS server has the decryption key but not the password.
We replace User-Password with AES-Password, decrypt it in the sql query
Which means you're still passing the key to the SQL server.
and pass it back to radius /as/ User-Password. (Or Cleartext-Password is more likely in the final implementation).
It's a hack which adds complexity, and no real security.
Yes, the key is now held in /etc/freeradius and if someone gets that as well as the database then it's much the same as storing the passwords in plain text. But we can *say* that they are stored encrypted - and there may be a slight edge in security, as a file in /etc/ *may* be less vulnerable than a mysql database.
Any thoughts on this scheme?
It "works", just like putting a Ferrari sticker on your car "works". But it doesn't add any real security. And your car still isn't a Ferrari. Alan DeKok.
On 29/09/16 17:25, Alan DeKok wrote:
On Sep 29, 2016, at 12:13 PM, Dom Latter <freeradius-users@latter.org> wrote:
some of you may remember me from a couple of months back asking about NTLM hashed passwords. I gave those a brief go but found that some devices just didn't work with them.
What does that mean?
It means that I replaced 'User-Password' in radcheck with an equivalent 'NT-Password'. And I found that (for example) with one of my guinea pig users, two of his devices continued to connect to the Wifi network just fine, but the third did not.
There is no "device" compatibility issues with NT hashed passwords.
See above. From my customer's point of view, that's a device compatibility issue, whatever it may be at a technical level.
If you want security, store the encrypted passwords in SQL, and then decrypt them on the RADIUS server. That way the SQL database has the passwords but not the decryption key, and the RADIUS server has the decryption key but not the password.
When you say "decrypt them on the radius server" - as far as I could see that would mean writing a new module (or modifying rlm_mschap.c) and re-compiling freeradius - is that what you meant?
It "works", just like putting a Ferrari sticker on your car "works". But it doesn't add any real security. And your car still isn't a Ferrari.
I could not agree more! Thanks for your input.
Hello Dom, Why don't you go with EAP-TTLS+PAP ? Plain-text password transferred over TLS-secured channel let you use any hashing algorithm you want in your database. Sure, you have to pay attention for proper device configuration with your CA certificate. On Thu, Sep 29, 2016 at 7:13 PM, Dom Latter <freeradius-users@latter.org> wrote:
Hi,
[tech details at end [1]]
some of you may remember me from a couple of months back asking about NTLM hashed passwords. I gave those a brief go but found that some devices just didn't work with them.
The requirement - a commercial and marketing requirement, not a technical one - has not gone away and it is that we can say that we do not store the passwords in plain text.
I have concocted a scheme whereby we do that - the following goes into dialup.conf and is I hope self-explanatory:
authorize_check_query = "SELECT id, username, attribute, value, op \ FROM ${authcheck_table} \ WHERE username = '%{SQL-User-Name}' \ AND attribute != 'AES-Password' \ UNION \ SELECT id, username, 'User-Password', \ AES_DECRYPT(UNHEX(value), 'aeskey'), op \ FROM radcheck \ WHERE username = '%{SQL-User-Name}' \ AND attribute = 'AES-Password' \ ORDER BY id"
We replace User-Password with AES-Password, decrypt it in the sql query and pass it back to radius /as/ User-Password. (Or Cleartext-Password is more likely in the final implementation).
Yes, the key is now held in /etc/freeradius and if someone gets that as well as the database then it's much the same as storing the passwords in plain text. But we can *say* that they are stored encrypted - and there may be a slight edge in security, as a file in /etc/ *may* be less vulnerable than a mysql database.
Any thoughts on this scheme?
thanks
dom
[1] wifi network with aerohive access points; freeradius with mysql data store; WPA2-Enterprise, MSCHAPv2, no control whatsoever over what the users want to connect to the network. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list /users.html
-- Bogdan Rudas Head of Minsk IT Support Department Exadel Inc. http://www.exadel.com/ E-mail: brudas@exadel.com Skype ID: bogdan.rudas -- CONFIDENTIALITY NOTICE: This email and files attached to it are confidential. If you are not the intended recipient you are hereby notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
On 29/09/16 17:57, Bogdan Rudas via Freeradius-Users wrote:
Hello Dom,
Why don't you go with EAP-TTLS+PAP ? Plain-text password transferred over TLS-secured channel let you use any hashing algorithm you want in your
As far as I can work out, out-of-the-box support for this protocol only arrived for most things in about 2010. We'll have quite a lot of users still using machines older than that. I suspect that for commercial reasons, it's not an option. I can ask.
database. Sure, you have to pay attention for proper device configuration with your CA certificate.
Do you mean a certificate needs to go on the device? I have had a look at this: http://cloudessa.com/tips-and-tricks/how-to-setup-eap-ttls-with-inner-pap-au... for example and it does not look like a certificate *needs* installing. thanks for your suggestion. (Apologies for my mailer dropping my real name from my previous post: don't know why it did that).
On 30 Sep 2016, at 11:09, Dom Latter <freeradius-users@latter.org> wrote:
I have had a look at this: http://cloudessa.com/tips-and-tricks/how-to-setup-eap-ttls-with-inner-pap-au... for example and it does not look like a certificate *needs* installing.
Well if you're not provisioning the root CA why are you concerned about database encryption? An attacker can just harvest the credentials out of the air as they fly past. Regards, Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 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 Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
On 30/09/16 11:20, Adam Bishop wrote:
On 30 Sep 2016, at 11:09, Dom Latter <freeradius-users@latter.org> wrote:
I have had a look at this: http://cloudessa.com/tips-and-tricks/how-to-setup-eap-ttls-with-inner-pap-au... for example and it does not look like a certificate *needs* installing.
Well if you're not provisioning the root CA
I think that's dealt with by the aerohive kit (access points etc) which is not my bag.
why are you concerned about database encryption?
Marketing. If it's a Mark 2 Ford Escort with a Ferrari sticker on it - well, that's what it is.
On Fri, Sep 30, 2016 at 11:09:34AM +0100, Dom Latter wrote:
On 29/09/16 17:57, Bogdan Rudas via Freeradius-Users wrote:
Hello Dom,
Why don't you go with EAP-TTLS+PAP ? Plain-text password transferred over TLS-secured channel let you use any hashing algorithm you want in your
As far as I can work out, out-of-the-box support for this protocol only arrived for most things in about 2010. We'll have quite a lot of users still using machines older than that. I suspect that for commercial reasons, it's not an option. I can ask.
Most things will do EAP-TTLS/PAP these days. Windows XP/7 are the only real big exceptions I'm aware of. And if XP is a problem then that's the least of your issues.
database. Sure, you have to pay attention for proper device configuration with your CA certificate.
Do you mean a certificate needs to go on the device?
I have had a look at this: http://cloudessa.com/tips-and-tricks/how-to-setup-eap-ttls-with-inner-pap-au... for example and it does not look like a certificate *needs* installing.
It doesn't *technically* need installing. But then you're open to your devices talking to a rogue RADIUS server and giving their cleartext password away. So it's pretty stupid not to. They stopped their instructions before the big certificate warning appears on screen. With wireless, for example, this means little more than someone coming near your site advertising your SSID, and people hit the "trust this wireless network" button and immediately give their credentials away. So yes, it needs installing. But then, you should install a client CA root cert with pretty much whichever EAP method you use, otherwise you risk the same problem, to a greater or lesser degree, depending on the inner method. So this is something you should be doing anyway. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 30/09/16 11:25, Matthew Newton wrote:
Most things will do EAP-TTLS/PAP these days. Windows XP/7 are the only real big exceptions I'm aware of. And if XP is a problem then that's the least of your issues.
I thought Windows 7 *did* support it. (Out of the box, in case that is not crystal clear!) If it does not then it is a definite no-no - definitely lots of users on our network still using W7. I have even found some using XP and Vista in the last few months, although I cannot tell from the Apache logs whether they are wired or wifi.
But then, you should install a client CA root cert with pretty much whichever EAP method you use, otherwise you risk the same problem, to a greater or lesser degree, depending on the inner method. So this is something you should be doing anyway.
As I indicated earlier - this side of things is not really my bag. Mostly, I write code. However I have just looked at the instructions we give to users wishing to connect their Windows 8 machine to the wifi network and have seen this: - Untick “Verify the server’s identity by validating the certificate” So presumably we are at risk of people spoofing the SSID? (although I believe the Aerohive kit has stuff to identify and deal with what they call "rogue" access points).
On Fri, Sep 30, 2016 at 11:53:27AM +0100, freeradius-users@latter.org wrote:
On 30/09/16 11:25, Matthew Newton wrote:
Most things will do EAP-TTLS/PAP these days. Windows XP/7 are the only real big exceptions I'm aware of. And if XP is a problem then that's the least of your issues.
I thought Windows 7 *did* support it. (Out of the box, in case that is not crystal clear!)
It arrived in Windows 8.
But then, you should install a client CA root cert with pretty much whichever EAP method you use, otherwise you risk the same problem, to a greater or lesser degree, depending on the inner method. So this is something you should be doing anyway.
However I have just looked at the instructions we give to users wishing to connect their Windows 8 machine to the wifi network and have seen this:
- Untick “Verify the server’s identity by validating the certificate”
Noooo :(
So presumably we are at risk of people spoofing the SSID?
Yes
(although I believe the Aerohive kit has stuff to identify and deal with what they call "rogue" access points).
And when the rogue Access Point is not within hearing distance of your own APs? It sounds like a good feature, but it will again only provide an illusion of security. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 30/09/16 12:01, Matthew Newton wrote:
On Fri, Sep 30, 2016 at 11:53:27AM +0100, freeradius-users@latter.org wrote:
On 30/09/16 11:25, Matthew Newton wrote:
Most things will do EAP-TTLS/PAP these days. Windows XP/7 are the only real big exceptions I'm aware of. And if XP is a problem then that's the least of your issues.
I thought Windows 7 *did* support it. (Out of the box, in case that is not crystal clear!)
It arrived in Windows 8.
Well - that'll be why we don't do EAP-TTLS/PAP.
- Untick “Verify the server’s identity by validating the certificate”
Noooo :(
Yup.
So presumably we are at risk of people spoofing the SSID?
Yes
(although I believe the Aerohive kit has stuff to identify and deal with what they call "rogue" access points).
And when the rogue Access Point is not within hearing distance of your own APs? It sounds like a good feature, but it will again only provide an illusion of security.
I'll pass this back to the people whose trainset it is. thanks.
On Sep 30, 2016, at 6:53 AM, freeradius-users@latter.org wrote:
However I have just looked at the instructions we give to users wishing to connect their Windows 8 machine to the wifi network and have seen this:
- Untick “Verify the server’s identity by validating the certificate”
Which means that you have no security. This is MUCH worse than storing clear-text passwords in the database. I really wish that amateurs would stop trying to design security systems. They get most things wrong. Alan DeKok.
On 30/09/16 13:57, Alan DeKok wrote:
On Sep 30, 2016, at 6:53 AM, freeradius-users@latter.org wrote:
However I have just looked at the instructions we give to users wishing to connect their Windows 8 machine to the wifi network and have seen this:
- Untick “Verify the server’s identity by validating the certificate”
Which means that you have no security.
...in the event that someone goes to the effort of spoofing the SSID etc.
This is MUCH worse than storing clear-text passwords in the database.
I really wish that amateurs would stop trying to design security systems. They get most things wrong.
I have no idea why they did it that way. I will try and draw their attention to the issue. But if I may be so bold: the problem with security professionals is that they often don't seem to recognise the concept of "Good Enough". They only seem to accept things that are mathematically provably secure. And they can then end up with systems that are so complicated that hardly anybody actually uses them [0]. I live in Cambridge [1]. If you leave a bike unlocked for more than two minutes it *will* get stolen. But if it is locked - even with a lock that could be torn apart with bare hands - it probably will survive until you get back to it. So a really not very good lock is often Good Enough. Is providing Dot11 but not verifying the certificate Good Enough in this instance? I would guess that you do not think so. Other comments would be welcome. I have not yet formed an opinion. I am moving towards Not Good Enough. I do not profess to being a security professional. My main gig is writing code. I am trying to improve things. [0] see: PGP signatures, encrypted mail [1] Cambridge, England. More bicycles than people.
On 30/09/16 14:21, freeradius-users@latter.org wrote:
Is providing Dot11 but not verifying the certificate Good Enough in this instance? I would guess that you do not think so. Other comments would be welcome. I have not yet formed an opinion. I am moving towards Not Good Enough.
I don't think it is good enough. I tested this last year, by configuring a laptop to use its WiFi interface as an AP, broadcasting an SSID and running a local FreeRADIUS instance that was configured only to record the passwords that users sent to it. Our infosec manager was not happy about me harvesting live user authentications (for obvious reasons) so I built my honeypot in a Faraday cage in the engineering dept. Any clients who have configured their 802.1x profile properly would not speak to my fake RADIUS server. The lazy ones with the option unticked just blindly transmitted their password to my honeypot. It took under an hour to research and set up, and I used this as a demonstration with some dummy clients to show management that security is important. This proves that it's easy to do, and all I have to do is sit with my laptop in the foyer of an airport, etc, and I've got a list of usernames and passwords. Cheers, Jonathan -- Jonathan Gazeley Senior Systems Administrator IT Services University of Bristol
On 30/09/16 14:30, Jonathan Gazeley wrote:
On 30/09/16 14:21, freeradius-users@latter.org wrote:
Is providing Dot11 but not verifying the certificate Good Enough in this instance? I would guess that you do not think so. Other comments would be welcome. I have not yet formed an opinion. I am moving towards Not Good Enough.
I don't think it is good enough. I tested this last year, by configuring
<snip> Helpful, thanks.
Hi,
I don't think it is good enough. I tested this last year, by configuring a laptop to use its WiFi interface as an AP, broadcasting an SSID and running a local FreeRADIUS instance that was configured only to record the passwords that users sent to it.
you know thats pretty much in violation of UK law and up for a computer misuse act against you? ;-) just point people to the research already done here eg http://www.eduroam.zm/Maninmiddle.pdf (presentation to educate) https://www.syssec.rub.de/media/infsec/veroeffentlichungen/2015/05/07/eduroa... (paper - that was pretty much a copy of earlier stuff). alan
you know thats pretty much in violation of UK law and up for a computer misuse act against you? ;-)
Only if you do this without prior permission (and people acknowledging that) and not in a Faraday cage (as he had done). :-) But yes... The point is very clear: Don't do this unless you'd like some cozy interaction with the local plod, the Met, and then one (or more) member(s) of the judiciary. ;-) 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.
On Sep 30, 2016, at 9:21 AM, freeradius-users@latter.org wrote:
On 30/09/16 13:57, Alan DeKok wrote:
On Sep 30, 2016, at 6:53 AM, freeradius-users@latter.org wrote:
However I have just looked at the instructions we give to users wishing to connect their Windows 8 machine to the wifi network and have seen this:
- Untick “Verify the server’s identity by validating the certificate”
Which means that you have no security.
...in the event that someone goes to the effort of spoofing the SSID etc.
Which takes all of 10min.
But if I may be so bold: the problem with security professionals is that they often don't seem to recognise the concept of "Good Enough". They only seem to accept things that are mathematically provably secure. And they can then end up with systems that are so complicated that hardly anybody actually uses them [0].
I've explained that putting encrypted passwords into the DB adds zero security, but doesn't really harm anything. I've also explained that disabling the server cert validation is terrible, and actively harms security. Your response complaining about security professionals concentrating on the wrong thing is *entirely* inappropriate. I'll say it again: Amateurs SHOULD NOT be designing security systems. You, and your managers, and the marketing people, are security amateurs. Listen to the experts, or ignore their advice. It's up to you. But do *not* respond by belittling the experts. It's ignorant and anti-social.
Is providing Dot11 but not verifying the certificate Good Enough in this instance? I would guess that you do not think so.
Then you didn't understand my comments. It's *terrible*. It destroys *ALL SECURITY* in your RADIUS configuration. The only worse thing you could do is to print out all of the user names and passwords, and post them in a public place.
Other comments would be welcome. I have not yet formed an opinion.
Learn how to learn from the experts.
I am moving towards Not Good Enough.
I do not profess to being a security professional.
Then don't argue with the experts.
My main gig is writing code. I am trying to improve things.
Then learn from the experts. Honestly, I have no idea what the heck is going through peoples minds when they ask questions, and then argue with the answers. It's completely narcissist. No, you're not the smartest person in the world. You attempts at being humble are just ways to convince yourself that you can ignore the expert advice. Stop it. Alan DeKok.
On 30/09/16 14:47, Alan DeKok wrote:
Your response complaining about security professionals concentrating on the wrong thing is *entirely* inappropriate.
I think my point about sometimes things being Good Enough is valid. Thanks to some helpful replies it is now abundantly clear that not verifying the certificate is not Good Enough.
I'll say it again: Amateurs SHOULD NOT be designing security systems. You, and your managers, and the marketing people, are security amateurs.
I didn't design this.
Listen to the experts, or ignore their advice. It's up to you. But do *not* respond by belittling the experts.
I am sorry if you felt that I was belittling the experts. Or that I was arguing.
Honestly, I have no idea what the heck is going through peoples minds when they ask questions, and thenargue with the answers. It's
/s/argue with the answers/seek further clarification/
Stop it.
I think I'm out of here for now.
Hi,
The only worse thing you could do is to print out all of the user names and passwords, and post them in a public place.
hey thats sounds useful. does FreeRADIUS support that feature and can it print the details out in landscape instead of portrait and on A3 rather than A4?? ;-) alan
Hi,
- Untick “Verify the server’s identity by validating the certificate”
So presumably we are at risk of people spoofing the SSID?
If your company does something valuable, simply assume that it already happened, and the user passwords are up for immediate reset. Better safe than sorry. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Am 30.09.2016 um 12:09 schrieb Dom Latter:
On 29/09/16 17:57, Bogdan Rudas via Freeradius-Users wrote:
Hello Dom,
Why don't you go with EAP-TTLS+PAP ? Plain-text password transferred over TLS-secured channel let you use any hashing algorithm you want in your
As far as I can work out, out-of-the-box support for this protocol only arrived for most things in about 2010. We'll have quite a lot of users still using machines older than that. I suspect that for commercial reasons, it's not an option. I can ask.
database. Sure, you have to pay attention for proper device configuration with your CA certificate.
Do you mean a certificate needs to go on the device?
I have had a look at this: http://cloudessa.com/tips-and-tricks/how-to-setup-eap-ttls-with-inner-pap-au...
for example and it does not look like a certificate *needs* installing.
You didn't read this yet, did you? Section "User Device Configuration": http://freeradius.org/enterprise-wifi.html No CA checks means all your passwords are up for grabbing for everyone with a glimpse on Enterprise Wi-Fi. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On 30/09/16 14:57, Stefan Winter wrote:
You didn't read this yet, did you? Section "User Device Configuration":
Nope. Setting up the network and RADIUS and so on is Not My Job. But thanks for your help - I will have a look now.
On 30/09/2016 14:57, Stefan Winter wrote:
No CA checks means all your passwords are up for grabbing for everyone with a glimpse on Enterprise Wi-Fi. What he said.
It's interesting to note that the "home" version of WPA, with a single pre-shared key (PSK), provides strong mutual authentication as standard. If a rogue access point is set up but has the wrong pre-shared key, the client simply won't be able to connect. Job done. Unfortunately, "enterprise" WPA is a lot murkier. The two most commonly implemented versions are: * EAP-TLS: each side proves its identity to the other with a certificate * PEAPv0 with MSCHAPv2 - the AP [actually RADIUS server] proves its identity with a certificate, and the client with username/password In both cases, if the client doesn't validate the certificate presented by the AP/RADIUS server then they could be connecting to a rogue access point, and all their traffic intercepted. In the PEAP case they will also be giving away their login credentials! Since there's no way to bind an SSID to a certificate directly, you have to manually *configure* every client to know which certificate DN(s) the AP should expect when connecting to that SSID. If you don't do that, then you're vulnerable to trivial attacks from rogue access points. (Maybe it's safer to use a different password for wireless access than for the rest of your enterprise services to mitigate the problem? But if you're going to do that, you could just go the EAP-TLS route anyway. And it doesn't obviate the need for checking the AP certificate to prevent traffic interception) There *is* a protocol which gives strong mutual authentication using a password and without the need for certificates: EPA-EKE (RFC 6124). However it's relatively new and I've not seen it deployed. Also it doesn't seem to be supported by FreeRADIUS at least according to http://freeradius.org/features/eap.html Regards, Brian. P.S. Nice paper here: https://fachschaft-informatik.de/_media/fachschaft:802.1x-security-analysis....
participants (11)
-
A.L.M.Buxey＠lboro.ac.uk -
Adam Bishop -
Alan DeKok -
Bogdan Rudas -
Brian Candler -
Dom Latter -
freeradius-users＠latter.org
-
Jonathan Gazeley -
Matthew Newton -
Stefan Paetow -
Stefan Winter