It's better than ROT13, at least
June 14, 2010 10:30 AM Subscribe
Why does wifi require a password to provide secure communication?
The thread on Google's collection of unsecured wifi traffic got me revisiting this question, which comes up every time I have a house guest and have to give them my 26 character WPA password.
Public key encryption allows two parties to communicate securely without any shared secrets, so why isn't that used for public wifi? You wouldn't need a password; you'd just send you public key to the hotspot, get the hotspot's own public key, and all your communication is encrypted.
The wiki page notes that "[p]ublic key algorithms known thus far are relatively computationally costly compared with most symmetric key algorithms of apparently equivalent security," so I'm guessing this is the reason it isn't used. But is it really so expensive that it's infeasible?
The thread on Google's collection of unsecured wifi traffic got me revisiting this question, which comes up every time I have a house guest and have to give them my 26 character WPA password.
Public key encryption allows two parties to communicate securely without any shared secrets, so why isn't that used for public wifi? You wouldn't need a password; you'd just send you public key to the hotspot, get the hotspot's own public key, and all your communication is encrypted.
The wiki page notes that "[p]ublic key algorithms known thus far are relatively computationally costly compared with most symmetric key algorithms of apparently equivalent security," so I'm guessing this is the reason it isn't used. But is it really so expensive that it's infeasible?
Well the obvious answer is that it doesn't prevent "Man In The Middle" attacks. How do you know if you're getting back the public key from the access point, or from some nefarious person with their laptop around the corner? This is the problem that SSL tries to fix, by assigning a trusted 3rd party to verify where the public keys come from (Verisign etc).
posted by davr at 10:39 AM on June 14, 2010
posted by davr at 10:39 AM on June 14, 2010
Public Key Encryption, used the way you describe, protects the traffic so that a third party who intercepts it cannot read it.
But it doesn't prevent unauthorized users from connecting and using the hot spot.
posted by Chocolate Pickle at 10:41 AM on June 14, 2010
But it doesn't prevent unauthorized users from connecting and using the hot spot.
posted by Chocolate Pickle at 10:41 AM on June 14, 2010
WPA serves two purposes -
1) it encrypts the in flight communication between a client and the ap
2) it serves to limit who can use the access point
You could use a PKI, and in fact there are several commercial/enterprise/public implementations that do leverage a PKI on the back end and do leverage certificates for client to ap communication.
Generally at home I spin up a guest network and force them through a full proxy they have to authenticate against, but it's sort of overkill for casual home users.
posted by iamabot at 10:42 AM on June 14, 2010
1) it encrypts the in flight communication between a client and the ap
2) it serves to limit who can use the access point
You could use a PKI, and in fact there are several commercial/enterprise/public implementations that do leverage a PKI on the back end and do leverage certificates for client to ap communication.
Generally at home I spin up a guest network and force them through a full proxy they have to authenticate against, but it's sort of overkill for casual home users.
posted by iamabot at 10:42 AM on June 14, 2010
I don't think it's just computational cost. The way you'd do it is for the hotspot to use your public key to encrypt a session key that you can decrypt using your private key. iirc, PGP actually does something similar, your public key is used to encrypt a long key that is then used with a symmetric cipher to encrypt the message text.
posted by atrazine at 10:43 AM on June 14, 2010
posted by atrazine at 10:43 AM on June 14, 2010
Symetric-key encryption makes authentication easy as well - the key not only secures communication, but also ensures that the other party is allowed to use your network. Using public key encryption forces the secured resource to decide which clients are allowed access.
And, as you mention, PKI is much more processor intensive. Your PC has plenty of power (although it still takes a few seconds to generate a 2048-bit key pair on my laptop), but mobile devices may not.
posted by bonecrusher at 10:44 AM on June 14, 2010
And, as you mention, PKI is much more processor intensive. Your PC has plenty of power (although it still takes a few seconds to generate a 2048-bit key pair on my laptop), but mobile devices may not.
posted by bonecrusher at 10:44 AM on June 14, 2010
And to follow up with davr says, with SSL certificates, the process is somewhat onerous for web site owners to go through to get certificates for their sites. That would be a lot of work for the average person who puts up a wireless endpoint. Furthermore, the certificate tied to a hostname for a website is something that is relatively easy for an end user to verify that it is accurate (not that people actually check this kind of thing often)*. For endpoints, this is much harder. How do you know you are talking to the end point in the coffee shop vs. the fake end point in the apartment above the coffee shop. It is certainly an easy way to harvest all sorts of good data about people.
*Even this is not entirely a panacea as there have been some attacks where people can spoof certs to a website that you've never been to.
posted by mmascolino at 10:47 AM on June 14, 2010
*Even this is not entirely a panacea as there have been some attacks where people can spoof certs to a website that you've never been to.
posted by mmascolino at 10:47 AM on June 14, 2010
You're also confused about how public key algorithms are used. They don't get used for the entire communication session. They're only used when setting up the session.
HTTPS uses a public key algorithm to perform an initial transaction between the browser and the host, but what gets sent is known as a "session key", which then gets used with a computationally-efficient symmetric cipher. (And if the session lasts a long time, the public key cipher is used periodically to change the session key.)
All of that is intended to make it so that the "man in the middle" who illicitly intercepts the traffic cannot determine what it says. It has nothing to do with authentication, determining whether the client is a legitimate user of the host.
There are ways in which public key algorithms can be used directly for authentication, but they require someone to maintain a table in the host which lists legitimate users and how they are identified. If you don't want to do that, then the only real way to do it is for legitimate users to send a standard authorization string which illegitimate users don't have.
In other words, to send a password.
posted by Chocolate Pickle at 10:50 AM on June 14, 2010
HTTPS uses a public key algorithm to perform an initial transaction between the browser and the host, but what gets sent is known as a "session key", which then gets used with a computationally-efficient symmetric cipher. (And if the session lasts a long time, the public key cipher is used periodically to change the session key.)
All of that is intended to make it so that the "man in the middle" who illicitly intercepts the traffic cannot determine what it says. It has nothing to do with authentication, determining whether the client is a legitimate user of the host.
There are ways in which public key algorithms can be used directly for authentication, but they require someone to maintain a table in the host which lists legitimate users and how they are identified. If you don't want to do that, then the only real way to do it is for legitimate users to send a standard authorization string which illegitimate users don't have.
In other words, to send a password.
posted by Chocolate Pickle at 10:50 AM on June 14, 2010
Anything "computationally expensive" has a bad effect on battery life.
posted by jeffamaphone at 10:56 AM on June 14, 2010
posted by jeffamaphone at 10:56 AM on June 14, 2010
if your need for security is fairly light, keep in mind that you can generate a WPA key which is more like your typical 8+ character password, something which can be easily memorized by the person you're giving it to so they can type it in. Esp. if you're frequently having to share it, it should be changed often. And as iamabot mentioned, you should really take the time to set up a guest network; many wifi routers, even the cheap ones, support that nowadays.
I don't do Fort-Knox kind of stuff over wireless, especially one with any need for public or semi-public access. I don't think any of these schemes are bulletproof. I'm just trying to keep everyone + their brother from having unfettered access to my bandwidth (and, if they get motivated enough, my home computer).
posted by randomkeystrike at 11:01 AM on June 14, 2010
I don't do Fort-Knox kind of stuff over wireless, especially one with any need for public or semi-public access. I don't think any of these schemes are bulletproof. I'm just trying to keep everyone + their brother from having unfettered access to my bandwidth (and, if they get motivated enough, my home computer).
posted by randomkeystrike at 11:01 AM on June 14, 2010
Note that your consumer wifi access point is just that -- it's made for consumers. If you're going to use public key encryption to secure the wifi while still restricting access to a particular set of users, you have to maintain a list of client public keys on the access point (so, the user has to go generate the key pair, then somehow transfer the public key to the router).
Further, so that the user isn't subject to a man-in-the-middle attack, you have to securely transfer the public key of the access point to each user (so, if you see an SSID of "linksys", you know that it's your "linksys", and not some other (possibly malicious) guy's "linksys").
You can get past some of this by creating a public key infrastructure, where a certificate authority signs everyone's public keys, so everyone inside the PKI can be assured of the identities of everyone else. But then you've just moved the problem over to creating a PKI.
So, back to the notion that you have consumer-grade equipment: most of the people who buy the access point are not going to go through this. At best, they're going to use simple password-based authentication, if they're going to do anything at all. You may see this sort of set up in a corporate environment, but presumably the corporate environment would have the technical skill and resources to handle it. Consumers, not so much.
posted by chengjih at 11:07 AM on June 14, 2010
Further, so that the user isn't subject to a man-in-the-middle attack, you have to securely transfer the public key of the access point to each user (so, if you see an SSID of "linksys", you know that it's your "linksys", and not some other (possibly malicious) guy's "linksys").
You can get past some of this by creating a public key infrastructure, where a certificate authority signs everyone's public keys, so everyone inside the PKI can be assured of the identities of everyone else. But then you've just moved the problem over to creating a PKI.
So, back to the notion that you have consumer-grade equipment: most of the people who buy the access point are not going to go through this. At best, they're going to use simple password-based authentication, if they're going to do anything at all. You may see this sort of set up in a corporate environment, but presumably the corporate environment would have the technical skill and resources to handle it. Consumers, not so much.
posted by chengjih at 11:07 AM on June 14, 2010
which comes up every time I have a house guest and have to give them my 26 character WPA password.
FYI, I just use my phone number as my id. When guests come over I tell them it is my 9 digit phone number and this is infinitely easier than whatever else I can think of.
posted by geoff. at 11:07 AM on June 14, 2010
FYI, I just use my phone number as my id. When guests come over I tell them it is my 9 digit phone number and this is infinitely easier than whatever else I can think of.
posted by geoff. at 11:07 AM on June 14, 2010
Response by poster: Sorry, I should clarify my question: this is for public hotspots -- ie. what you connect to at Starbucks. So:
1. No authentication -- that's kind of the whole point
2. No real protection from someone pretending to be the base station itself. It would be nice to have this, but I'm comparing this scheme against the current public wifi system.
Maybe a side question, but if a place like Starbucks had an encrypted network and gave the password to any customer who asked, would there be any protection from snooping by fellow customers? I'm assuming that the password is the key to the encryption, so anyone who has it can decrypt any of the traffic on the network.
posted by bjrubble at 11:15 AM on June 14, 2010
1. No authentication -- that's kind of the whole point
2. No real protection from someone pretending to be the base station itself. It would be nice to have this, but I'm comparing this scheme against the current public wifi system.
Maybe a side question, but if a place like Starbucks had an encrypted network and gave the password to any customer who asked, would there be any protection from snooping by fellow customers? I'm assuming that the password is the key to the encryption, so anyone who has it can decrypt any of the traffic on the network.
posted by bjrubble at 11:15 AM on June 14, 2010
Each user attached to a WPA access point is given their own session key, and this key changes frequently during the session. So no, knowing the password will not let everyone snoop everyone else's traffic between their laptop and the access point.
posted by kindall at 11:38 AM on June 14, 2010
posted by kindall at 11:38 AM on June 14, 2010
Public key encryption allows two parties to communicate securely without any shared secrets, so why isn't that used for public wifi? You wouldn't need a password; you'd just send you public key to the hotspot, get the hotspot's own public key, and all your communication is encrypted.
In the PKI example, given appropriate software on their devices, instead of giving them a password, they would fetch (from your router) a signed certificate that you would need to manage. That would allow them to establish a trusted, encrypted tunnel terminating at your router even if the rest of the traffic (from other devices, ...) was unencrypted entirely. One could imagine using the similar approach to establish and disseminate WPA keys automatically, for example. This would actually be rather nice ... but ...
Without some shared secret or other mechanism to restrict access to the keys, this would do nothing to prevent _other_ unwanted users from connecting to and using your network, which is the whole point. None of this has anything to do with preventing users from sniffing one another.
Keeping unwanted users off of your connection to the internet is an unfortunately desirable thing (this prevents people from surfing illegal content in your name -- and an unencrypted access point is not a legal defense).
It has _zero_ to do with the cost of PKI. PKI is used to establish, share and update session keys which use symmetric encryption schemes like blowfish, idea, AES, and so on.
posted by rr at 11:56 AM on June 14, 2010
In the PKI example, given appropriate software on their devices, instead of giving them a password, they would fetch (from your router) a signed certificate that you would need to manage. That would allow them to establish a trusted, encrypted tunnel terminating at your router even if the rest of the traffic (from other devices, ...) was unencrypted entirely. One could imagine using the similar approach to establish and disseminate WPA keys automatically, for example. This would actually be rather nice ... but ...
Without some shared secret or other mechanism to restrict access to the keys, this would do nothing to prevent _other_ unwanted users from connecting to and using your network, which is the whole point. None of this has anything to do with preventing users from sniffing one another.
Keeping unwanted users off of your connection to the internet is an unfortunately desirable thing (this prevents people from surfing illegal content in your name -- and an unencrypted access point is not a legal defense).
It has _zero_ to do with the cost of PKI. PKI is used to establish, share and update session keys which use symmetric encryption schemes like blowfish, idea, AES, and so on.
posted by rr at 11:56 AM on June 14, 2010
Oops.
1. No authentication -- that's kind of the whole point
The problem is the users and the software stack not even attempting to encourage users to do the right thing.
Users are NOT going to verify the correct connection -- how often do you verify your SSL certificates?* -- so things like malicious base stations [accidentally automatically associated or chosen via deceptive names] will generally not be observed. Users sophisticated enough to know about this issue will be running a VPN client at all times. Masquerading is a huge problem.
The starbucks that I've seen don't use a WPA or WEP scheme; they are unprotected access points that use a proxy to enforce access to a specific user device to the unprotected network. The proxy may or may not put a time limit on sessions, block access to certain kinds of sites and whatnot.
Networks like this are great fun for people who enjoy tcp injection attacks (for example, oops, you went to the dashboard and your safari-hosted widgets update, and in doing so do an unencrypted HTTP GET and someone responds to more quickly with a hostile javascript payload) and the like.
* there was a great attack a few years ago where a proxy ssl service was used to deceive users about their level end-to-end protection and remote site validation [believe it was akamai] that illustrated this quite nicely. Almost no one noticed.
posted by rr at 12:05 PM on June 14, 2010
1. No authentication -- that's kind of the whole point
The problem is the users and the software stack not even attempting to encourage users to do the right thing.
Users are NOT going to verify the correct connection -- how often do you verify your SSL certificates?* -- so things like malicious base stations [accidentally automatically associated or chosen via deceptive names] will generally not be observed. Users sophisticated enough to know about this issue will be running a VPN client at all times. Masquerading is a huge problem.
The starbucks that I've seen don't use a WPA or WEP scheme; they are unprotected access points that use a proxy to enforce access to a specific user device to the unprotected network. The proxy may or may not put a time limit on sessions, block access to certain kinds of sites and whatnot.
Networks like this are great fun for people who enjoy tcp injection attacks (for example, oops, you went to the dashboard and your safari-hosted widgets update, and in doing so do an unencrypted HTTP GET and someone responds to more quickly with a hostile javascript payload) and the like.
* there was a great attack a few years ago where a proxy ssl service was used to deceive users about their level end-to-end protection and remote site validation [believe it was akamai] that illustrated this quite nicely. Almost no one noticed.
posted by rr at 12:05 PM on June 14, 2010
Best answer: Maybe a side question, but if a place like Starbucks had an encrypted network and gave the password to any customer who asked, would there be any protection from snooping by fellow customers? I'm assuming that the password is the key to the encryption, so anyone who has it can decrypt any of the traffic on the network.
Yeah, they can see everything. Remember when they used to call the old Wifi auth standard something like "wired-equivalent privacy"? Much like on an wired ethernet segment, the standard does not include encrypting traffic. You may additionally decide to encrypt your traffic, but loads of stuff that flies between end points and access points on public wifi networks is in the clear.
This is one of those things that absolutely floors people who know how this shit works: how much unencrypted sensitive material most people are happy to let fly, as well as why this doesn't seem to be a bigger practical problem in real life. Many people's email runs in the clear: GMail used to by default, but I think they may have changed that. Many IM clients, etc. All that stuff is in the clear. To be fair, the same thing is often true on wired networks, but most wired networks are not shared by strangers anymore, and when they are, they are often times heavily switched (you can only see traffic on your segment) so a lot of times you can't see anybody else's stuff (of course, anybody upstream of your switch can, but that's way less likely to be some random jerk/creep).
Getting back to your main question, I think all these people above are making good points, but your point is good as well. The key misunderstanding is that the problem you are thinking PK encryption would solve (encrypting traffic between your computer and some part of the network that's harder to access) is not the problem these technologies are trying to solve. Its a totally worthwhile problem given the way these networks are used today, and one you could certainly do (proxy everything through SSL), but its not what the guys working on these standards were thinking.
They were thinking "this is a wireless extension of ethernet. Hosts on a LAN are generally considered to relatively trusted; at least, their privileges are handled at a different place in the network stack (ACLs and what not). With a wired network, the fact that you need access to the jacks keeps randos from plugging in to them, and the fact that the EM radiation is confined mostly to the physical wires keeps our data from leaking out into the great wide open. How do we basically keep those two things true on the wireless extension networks?" The idea that the big threat comes to you from the guy in the next cube/cafe table was not written on the whiteboard when they were doing this.
What you are talking about though IS the way to ACTUALLY protect yourself from your fellow coffee drinkers: encrypt your IM traffic, make sure any sensitive web traffic is over HTTPS, make sure your email client is setup to encrypt traffic both ways from your servers, not just on session setup.
posted by jeb at 12:27 PM on June 14, 2010 [1 favorite]
Yeah, they can see everything. Remember when they used to call the old Wifi auth standard something like "wired-equivalent privacy"? Much like on an wired ethernet segment, the standard does not include encrypting traffic. You may additionally decide to encrypt your traffic, but loads of stuff that flies between end points and access points on public wifi networks is in the clear.
This is one of those things that absolutely floors people who know how this shit works: how much unencrypted sensitive material most people are happy to let fly, as well as why this doesn't seem to be a bigger practical problem in real life. Many people's email runs in the clear: GMail used to by default, but I think they may have changed that. Many IM clients, etc. All that stuff is in the clear. To be fair, the same thing is often true on wired networks, but most wired networks are not shared by strangers anymore, and when they are, they are often times heavily switched (you can only see traffic on your segment) so a lot of times you can't see anybody else's stuff (of course, anybody upstream of your switch can, but that's way less likely to be some random jerk/creep).
Getting back to your main question, I think all these people above are making good points, but your point is good as well. The key misunderstanding is that the problem you are thinking PK encryption would solve (encrypting traffic between your computer and some part of the network that's harder to access) is not the problem these technologies are trying to solve. Its a totally worthwhile problem given the way these networks are used today, and one you could certainly do (proxy everything through SSL), but its not what the guys working on these standards were thinking.
They were thinking "this is a wireless extension of ethernet. Hosts on a LAN are generally considered to relatively trusted; at least, their privileges are handled at a different place in the network stack (ACLs and what not). With a wired network, the fact that you need access to the jacks keeps randos from plugging in to them, and the fact that the EM radiation is confined mostly to the physical wires keeps our data from leaking out into the great wide open. How do we basically keep those two things true on the wireless extension networks?" The idea that the big threat comes to you from the guy in the next cube/cafe table was not written on the whiteboard when they were doing this.
What you are talking about though IS the way to ACTUALLY protect yourself from your fellow coffee drinkers: encrypt your IM traffic, make sure any sensitive web traffic is over HTTPS, make sure your email client is setup to encrypt traffic both ways from your servers, not just on session setup.
posted by jeb at 12:27 PM on June 14, 2010 [1 favorite]
Each user attached to a WPA access point is given their own session key...
Yes, but I believe this session key is distributed at first in a handshake encrypted with the shared key. Wireshark can decrypt WPA. As it says, "WPA and WPA2 use keys derived from an EAPOL handshake to encrypt traffic. Unless all four handshake packets are present for the session you're trying to decrypt, Wireshark won't be able to decrypt the traffic." But if it sees the handshake, and it knows the shared key, it can decrypt everything.
With only a shared key, something has to be sent via the shared key before any individual keys can be used. So as far as I know, WPA doesn't protect you from sniffing by others on the same network. I consider myself fairly tech-savvy, but I didn't recognize this until recently. Knowing that the link is encrypted in some way gives a false sense of blanket security.
posted by whatnotever at 12:34 PM on June 14, 2010
Yes, but I believe this session key is distributed at first in a handshake encrypted with the shared key. Wireshark can decrypt WPA. As it says, "WPA and WPA2 use keys derived from an EAPOL handshake to encrypt traffic. Unless all four handshake packets are present for the session you're trying to decrypt, Wireshark won't be able to decrypt the traffic." But if it sees the handshake, and it knows the shared key, it can decrypt everything.
With only a shared key, something has to be sent via the shared key before any individual keys can be used. So as far as I know, WPA doesn't protect you from sniffing by others on the same network. I consider myself fairly tech-savvy, but I didn't recognize this until recently. Knowing that the link is encrypted in some way gives a false sense of blanket security.
posted by whatnotever at 12:34 PM on June 14, 2010
If want to have encrypted air traffic but open access, broadcast your SSID and put the WPA password in it. For example, name your access point "The password is OpenAccess".
That should cover it for people that care enough to look.
posted by NortonDC at 1:04 PM on June 14, 2010
That should cover it for people that care enough to look.
posted by NortonDC at 1:04 PM on June 14, 2010
Best answer: my 26 character WPA password
IIRC, your WPA password length is unrelated to the strength of the underlying encryption.
I'm assuming that the password is the key to the encryption, so anyone who has it can decrypt any of the traffic on the network.
To any unencrypted traffic; make an https connection to your bank, and even if I know your WPA key, I still have to crack the SSL encryption as a separate effort.
But is it really so expensive that it's infeasible?
I work testing commercial encryption software; our resident public key encryption expert estimates the computational cost would be an order of magnitude, so a transfer that takes 1 minute now, would take 10 minutes under full public key encryption.
posted by nomisxid at 1:04 PM on June 14, 2010
IIRC, your WPA password length is unrelated to the strength of the underlying encryption.
I'm assuming that the password is the key to the encryption, so anyone who has it can decrypt any of the traffic on the network.
To any unencrypted traffic; make an https connection to your bank, and even if I know your WPA key, I still have to crack the SSL encryption as a separate effort.
But is it really so expensive that it's infeasible?
I work testing commercial encryption software; our resident public key encryption expert estimates the computational cost would be an order of magnitude, so a transfer that takes 1 minute now, would take 10 minutes under full public key encryption.
posted by nomisxid at 1:04 PM on June 14, 2010
Sorry, I misunderstood your question.
One thing that occurs to me is that the first WiFi spec may have been written during the dark days when NSA still tried to impose ridiculous limits on commercial use of encryption (remember the 40-bit DVD encryption?). Perhaps they couldn't use PKI because of that.
I don't know if that's the case, but if it is then all the later versions of WiFi would be stuck with it because of backward compatibility.
posted by Chocolate Pickle at 1:20 PM on June 14, 2010
One thing that occurs to me is that the first WiFi spec may have been written during the dark days when NSA still tried to impose ridiculous limits on commercial use of encryption (remember the 40-bit DVD encryption?). Perhaps they couldn't use PKI because of that.
I don't know if that's the case, but if it is then all the later versions of WiFi would be stuck with it because of backward compatibility.
posted by Chocolate Pickle at 1:20 PM on June 14, 2010
Another possibility: When the WiFi spec was written, the RSA patent was still in force, and maybe those who wrote the spec didn't want to force everyone to pay license fees to RSA.
posted by Chocolate Pickle at 1:21 PM on June 14, 2010
posted by Chocolate Pickle at 1:21 PM on June 14, 2010
They were thinking "this is a wireless extension of ethernet. Hosts on a LAN are generally considered to relatively trusted; at least, their privileges are handled at a different place in the network stack (ACLs and what not).
Bingo. You're still on ethernet once you get past the radio. Why should the spec be written only for coffee-shops in mind? It should, and has, been written to act like ethernet typically does. If you want coffee-shop mode, you can enable it in compatible routers, which is little more than a firewall rule to keep the clients from talking to to each other.
Managing a PKI infrastructure isn't easy. People are still bewildered by WPA passwords. For those who want more complexity or security they can use WPA enterprise, RADIUS, VPN, etc. There's no shortage of technologies here.
posted by damn dirty ape at 2:37 PM on June 14, 2010
Bingo. You're still on ethernet once you get past the radio. Why should the spec be written only for coffee-shops in mind? It should, and has, been written to act like ethernet typically does. If you want coffee-shop mode, you can enable it in compatible routers, which is little more than a firewall rule to keep the clients from talking to to each other.
Managing a PKI infrastructure isn't easy. People are still bewildered by WPA passwords. For those who want more complexity or security they can use WPA enterprise, RADIUS, VPN, etc. There's no shortage of technologies here.
posted by damn dirty ape at 2:37 PM on June 14, 2010
Right. The password is to control access to the network. What happens after that is a whole other story.
I believe it is possible (though I can't prove it) to have a passwordless network that is still encrypted.
posted by gjc at 5:46 PM on June 14, 2010
I believe it is possible (though I can't prove it) to have a passwordless network that is still encrypted.
posted by gjc at 5:46 PM on June 14, 2010
« Older Any organismal atmospheric surveyors? | need storage device compatible with mac 10.3.9 Newer »
This thread is closed to new comments.
posted by aeighty at 10:37 AM on June 14, 2010