Hacker News Reader

Comment by wyager | Hacker News Reader

>This is due to iOS' behavior of automatically joining networks whose name (not MAC address) it recognizes, such as “linksys” or “attwifi”.

Discriminating by MAC addresses would not help at all. MAC addresses are trivial to spoof, even though they are "in hardware".

It would be cool if we had a standardized trust-on-first-use cryptographic authentication model for wireless APs, like we do with SSH right now. You connect to the AP, it sends you its pubkey, your phone says "Do you want to trust AP with key AB:CD:BE:EF...". The discriminating paranoid person can choose to make sure this is the right key hash, and the average person gets at least limited protection from later AP spoofing attacks.

View on HN

Yeah, I've been shocked by how easy it is to get a brand new router and set it up with the same SSID and password and every device I have auto-connects like it's the same thing. If you have the AP password, it's trivial to set up a fake second router in the same vicinity (you don't even have to touch the original one) with a stronger signal and have everyone connect through your gateway.

Of course, once you have the AP password there's a lot you can do to the network traffic anyway, but it'd still be nice if the computer would pop something up and say, "The configuration of this device does not match the known configuration - do you still want to connect?"

OSX and I assume iOS does do detection of this. If you connect to an AP that was WPA2 encrypted in the past, and has the same name but no encryption now, it gives you a big scary warning and bails out.

One could always set-up a Ja-sager with WPA2.

I guess this is to combat password stealing attempts in particular, and not AP spoofing in general?

I guess this is to combat password stealing attempts in particular, and not AP spoofing in general, since you could easily make the new AP WPA2?

If have to look it up, but I don't think the AP would get the plaintext password during the WPA2 key exchange.

That kind of breaks down when you consider the fact that Wifi Networks can span multiple APs, and each AP can be running multiple Wifi Networks. For example a corporate or education campus where you have multiple APs for coverage, and then might have several SSIDs xyz-network, xyz-guest, xyz-lab that are running on every AP.

If we were using an SSH-type model, there's no particular reason why APs which you control which share an SSID can't also share a private key. If you are the administrator of the APs and you want them all to be seen as the same network, you could just move the appropriate keys onto the appropriate routers. Running multiple networks is the same thing - generate one key per SSID and duplicate them across all APs.

According to the other comments, apparently something like this is already a feature in WPA2, so evidently it doesn't break down too much.

This is the case with WPA2/EAP. You have to accept the cert (the first time) before entering your Active Directory/RADIUS credentials.

Reply on news.ycombinator.com