3 ms·

How do you secure your company WLAN in a smaller company? PEAP-MSCHAPv2 seems to be common, but allows rogue access points / evil twins to steal user credentia

How do you secure your company WLAN in a smaller company? PEAP-MSCHAPv2 seems to be common, but allows rogue access points / evil twins to steal user credentials. First it requires running a private CA, which is unproportional effort for the part-time IT guy who might be pretty inexperienced in that area. And worse, how do you make sure that your non-technical or even some sloppy technical users configure their clients to check the CA?

tinus_hn 5y ago
Although interception is not risk free, intercepting MSCHAPv2 does not compromise the credentials. There is no way to fix that problem because SSIDs are not structured in a way that allows certificates. Possible fixes would be to allow FQDNs as SSIDs and match these to a certificate, or to require the usercode to contain a domain (like an email address) and verify that. But it’s not in the protocols so that’s a long way off.
- usr1106 5y ago
  > intercepting MSCHAPv2 does not compromise the credentials. But the cryptography it uses is horrible. A random Web search suggests that Schneier declared it insecure in 1999 and Microsoft in 2004 or so. In the mid 2000s there where commercial services on the Web to recover forgotten Windows NT passwords for $20 or less. (I used it once, worked perfectly). I understand it's the same algorithm. You don't even need to recover the password. You can use the hash you captured to get access later because it is unsalted.
  - tinus_hn 5y ago
    It’s really out of date and the way the system works precludes the use of salts, that’s true. It’s because they want to use the password as a shared secret, but avoid storing the plaintext password on the server and avoid sending the password itself to the server. The protocol is designed for use with file sharing by random untrusted workstations. The unfortunate end result is that the data stored by the server is a plaintext equivalent. It isn’t easy to recover the original password though unless it’s on a precomputed list, and you can’t get either the password or the encrypted form (that is plaintext equivalent) by watching the network or by posing as the server.
    - usr1106 5y ago
      > you can’t get [...] the encrypted form (that is plaintext equivalent) by watching the network or by posing as the server. Not by watching the network. Because the outer protocol is PEAP, which is similar to TLS I understand. So not completely broken. But when you pose as a server? Of course the definition of "easy" might vary. What some world-class experts presented at Defcon 9 years ago, is it considered easy? https://web.archive.org/web/20160316174007/https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/ https://web.archive.org/web/20160316174007/https://www.cloud...
      - tinus_hn 5y ago
        As far as I know there is no difference whether you are just watching the network or are posing as the server.
        usr1106 5y ago
        While I am not the absolute expert and have not really studied the specs I would cautiously claim this is not correct. The outer protocol is PEAP, a variant of TLS. Listening to what is sent inside is impossible in most practical cases. However, if you are the server (or rogue access point) obviously you see all traffic passing through that tunnel in clear text.
        tinus_hn 5y ago
        The idea is that the real server has access to the encrypted/hashed version of the password so it can decrypt the communication (and so does the client as the user is entering the password). But a fake server would not have that and thus be unable to decrypt the communication.
        usr1106 5y ago
        That's not how TLS / PEAP works. It's asymmetric cryptography initially (to agree a symmetric key). That's why it's important the client verifies it does not talk to a rogue server.

tinus_hn 5y ago

Although interception is not risk free, intercepting MSCHAPv2 does not compromise the credentials. There is no way to fix that problem because SSIDs are not structured in a way that allows certificates. Possible fixes would be to allow FQDNs as SSIDs and match these to a certificate, or to require the usercode to contain a domain (like an email address) and verify that. But it’s not in the protocols so that’s a long way off.

usr1106 5y ago
> intercepting MSCHAPv2 does not compromise the credentials. But the cryptography it uses is horrible. A random Web search suggests that Schneier declared it insecure in 1999 and Microsoft in 2004 or so. In the mid 2000s there where commercial services on the Web to recover forgotten Windows NT passwords for $20 or less. (I used it once, worked perfectly). I understand it's the same algorithm. You don't even need to recover the password. You can use the hash you captured to get access later because it is unsalted.
- tinus_hn 5y ago
  It’s really out of date and the way the system works precludes the use of salts, that’s true. It’s because they want to use the password as a shared secret, but avoid storing the plaintext password on the server and avoid sending the password itself to the server. The protocol is designed for use with file sharing by random untrusted workstations. The unfortunate end result is that the data stored by the server is a plaintext equivalent. It isn’t easy to recover the original password though unless it’s on a precomputed list, and you can’t get either the password or the encrypted form (that is plaintext equivalent) by watching the network or by posing as the server.
  - usr1106 5y ago
    > you can’t get [...] the encrypted form (that is plaintext equivalent) by watching the network or by posing as the server. Not by watching the network. Because the outer protocol is PEAP, which is similar to TLS I understand. So not completely broken. But when you pose as a server? Of course the definition of "easy" might vary. What some world-class experts presented at Defcon 9 years ago, is it considered easy? https://web.archive.org/web/20160316174007/https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/ https://web.archive.org/web/20160316174007/https://www.cloud...
    - tinus_hn 5y ago
      As far as I know there is no difference whether you are just watching the network or are posing as the server.
      - usr1106 5y ago
        While I am not the absolute expert and have not really studied the specs I would cautiously claim this is not correct. The outer protocol is PEAP, a variant of TLS. Listening to what is sent inside is impossible in most practical cases. However, if you are the server (or rogue access point) obviously you see all traffic passing through that tunnel in clear text.
        tinus_hn 5y ago
        The idea is that the real server has access to the encrypted/hashed version of the password so it can decrypt the communication (and so does the client as the user is entering the password). But a fake server would not have that and thus be unable to decrypt the communication.
        usr1106 5y ago
        That's not how TLS / PEAP works. It's asymmetric cryptography initially (to agree a symmetric key). That's why it's important the client verifies it does not talk to a rogue server.