Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

For the number of engineers they have you'd think they'd have figured out how to build a decent wifi network with some actual security in it. Instead every WeWork has the same password for the wifi (literally a variant on `P@ssw0rd`) and it is super easy to spy on other people's connections. The hilarious thing is they actually built a secure wifi network for their staff, so they clearly recognize the need.

They also use the dumbest access points- they don't support roaming and connect you to the least congested point regardless of speed. It used to be a morning ritual of mine to toggle wifi on and off again until I had a decent connection.



Our WeWork was so close to another WeWork that the WiFi networks interfered with each other, and caused the WiFi to drop out every hour or so. Took them a month to fix.


Wifi is largely insecure anyway. You should largely assume that the network is malicious no matter what and just rely on application layer security.


That's a reasonable position to take for networks in general like coffee shops, but if I'm paying WeWork to provide office infrastructure, I expect the network to not be malicious, just like I expect not to need to boil and chlorine-treat the water I get from their water fountains.


Not everybody knows or appreciates the use of a VPN. I don't think yours is enough justification for WeWork for not having built a proper service.


Application layer security doesn't just mean VPNs. What websites are you connecting to with sensitive information that don't use HTTPS with HSTS preload nowadays?


Here's one from just yesterday: the password reset form for sched.com, which the Linux Foundation uses for schedules, is HTTP. I had to follow this link to upload my slides for a talk I'm giving at a LF conference next week.

Yes, the ideal, which we should all be actively working towards, is HTTPS. That doesn't mean that the world is already there.


Note that Let's Encrypt, which is making universal https possible, is also part of the Linux Foundation.

I was going to complain to sched.com for you, but I can't replicate the problem:

https://ossna19.sched.com/password-reset is the default and http://ossna19.sched.com/password-reset redirects to it.

(I work for the Linux Foundation.)


The email you get in your inbox when you do that is http. It starts with http://a.sched.com/track/click/.


I worked with Sched.com this week based on your feedback and that link is now https. Thanks.


Awesome work


What is a "proper service" in this case? Many company networks routinely allow access using fairly straightforward and rarely rotated passwords. Of course, access to actual company resources like email require 2FA etc.

But as others note, the main purpose of having a password at all is to stop casual passersby from leeching off your network.


> What is a "proper service" in this case?

Something like one of the 802.11 Enterprise modes that don't use a PSK and actually check against a user DB before handing out a session.


So now there’s significant complexity to getting on the network. Seems like a poor choice for a co-working space. And, as I say, plenty of large companies with competent IT departments don’t seem to think that’s necessarily.

And how about when you’re having a meeting with outside people who need to get onto a network?


Most universities and schools have a similar setup. No idea how WeWork works but I assume you have some sort of user account already (how do you pay them otherwise?) that you can use to authenticate yourself. Then your AP just needs to talk to a auth gateway (usually RADIUS) which then talks to your actual auth backend (LDAP, AD, or whatever online login form they use).

For guests you either generate guest account or just have a guest network. We don't care if guests fight over the guest network because there aren't that many of them around at any one time... the problem is that actual WeWork customers shouldn't be fighting over insecure APs.


Every WeWork member has a dedicated account which is tied to their company and badge (which is used for building access). This account is also used for reserving rooms.


Fair enough. Although I'm familiar with quite a few situations where most people just use a single network for wireless (whether employees or guests) and confidential company resources are put behind SSO and/or VPN using 2FA.

Others do have separate networks of course and maybe that makes sense in the case of something like WeWork that probably has more people who aren't employees/paying customers coming in and out and getting on the network than the typical company office does.


I think the problem is that providing internet access is part of WeWork's core product. It doesn't matter if your accountant's office just has one shitty wifi connection for everyone -- you'd still go visit them even if they didn't have wifi. But literally the entire point of WeWork is renting space to work, with internet. They should be held to a higher standard in this regard, IMO.


> So now there’s significant complexity to getting on the network

Not really, every OS (even Network Manager does a good job) has support for the WPA enterprise login flow. You basically get 1 prompt to trust a cert, then enter your username + pass (usually tied to AD) which you can save to your OS keychain. I've never had to fiddle with the one at my corporate network since first signing in months ago.

I don't know about the actual security benefits, but I do know it stops the typical "capture the handshake & game over"

> And how about when you’re having a meeting with outside people who need to get onto a network?

You set up a crappy rinky-dink "FooBarGuest" network with a PSK that has no real access to the rest of the network and pretty much can just be used for web browsing.


It's not hard to automate guest accounts.


What VPNs should one be using? Should I create my own because what's the guarantee of a vpn actually being trustworthy?


https://github.com/trailofbits/algo is pretty good for self hosted


Having the same WPA2-PSK authentication secret does not allow spying over WiFi, unless you are willing to actively spoof the network.


Yes it does. If you capture the authentication handshake, it's as straightforward as putting the passphrase into Wireshark.


I could have sworn there was a DH key negotiation? And I worked in WiFi for a decade, a decade ago... Sorry, obviously I have not had enough coffee yet today.

Looks like this was only added in WPA3!


I think you can also do it with WPA2-Enterprise, so a common trick is to set up enough infrastructure to let your users use EAP-TLS or something, and IIRC EAP sets up a per-client session key in the handshake. The public LinkNYC wifi network, for instance, has both an open network and an EAP-TTLS one that you can download a provisioning profile for.


I thought I knew this stuff, but now I'm not so sure anymore. If I take care to only visit https sites, what's the risk in being on an open network or a network with a stupid password?

They can see what domains I connect to and when, but that's it, correct? No MITM, no further snooping, right?


MITM for HTTP and DNS are the main threats. An attacker can use one of these vectors to inject malicious JS into pages for you.

Otherwise, it depends on what else you use the network for. Maybe you set "SSL optional" in your mail client so your email password gets fired off in plaintext. Maybe your special radio streaming app is vulnerable to RCE. Maybe the latest Windows update accidently started sending your keylogs (ahem, "telemetry") over an unencrypted channel.


A favorite attack vector is various auto-updating software on your computer that downloads updates or update metadata over HTTP. For the longest time Sparkle (an update framework used in Mac apps such as VLC, iTerm, ..) defaulted to HTTP.

Once an attacker is in your network, it's more or less trivial to make that software connect to a malicious update server.


There's a limited amount of room to exploit this, this so long as signing is handled correctly. The Debian Apt system worked this way for a long time.

Of course, a lot of code signing systems are mismanaged, so...


If you run local dev servers and expose them they could be accessed.

Also IP addresses and domain names you visit are visible.


Fortunately for everyone, encrypted SNI is becoming a thing.

DNS queries are probably still visible though, and responses potentially poisoned.


If the network is open, your machine may be open to being sent traffic - or attacked - from other devices on the network.


How is this not true on an encrypted wifi or even an old-school wired office LAN?


Its one checkbox to turn on device isolation. It's not perfect, but suddenly no device can see any other device.


You need some password to have encryption at all. This is just a better alternative to open networks with captive portals.

I think it's perfectly fine to expect some risk connecting to someone else's network. At least they didn't make it an open network. If you're a person that wouldn't connect to the internet in a cafe without a VPN, you shouldn't either at a WeWork.


How do you spy on other people's connections at a WeWork?



Be mindful that if you get caught, it is likely to be a breach of contract with WeWork and may end up involving the authorities.


One could argue it wouldn't...(puts on David Caruso sunglasses)...be WeFi otherwise


I don't see the issue. The password isn't to protect you against other WeWorkers, it's to exclude people on the outside.

Personally, I think any attempt at them to provide serious security on the shared network would be a really bad idea. It'd make people feel comfortable but somebody would find a hole and suddenly have access to a ton of devices.

If security is an issue, just use a VPN/Wireguard.


Your first point is actually part of my point- the fact that they have a single password means excluding people on the outside is basically impossible. If someone has a lease at WeWork but then leaves there's no way to keep them off the network without changing the password for everyone. Since the password is really simple (like, "easy to guess" simple), and since it's possible that people have shared it publicly, their network is not that far away from just being an open wifi network.

And yes, we did setup a VPN for all of our employees to use while we were in the WeWork office. I don't think that changes my point that the WeWork network is not setup well at all.


>their network is not that far away from just being an open wifi network.

It is an open network, they just are limiting bandwidth use of passer byers.


In addition, enterprise WPA (802.1x) doesn't work like that. In WPA-Personal, if you have the password (PSK) and capture the handshake (easy), you have easy decryption of any other clients' traffic. In WPA-Enterprise, all the connections are segregated (because the handshake uses your certs and mutual auth).


As the provider of the overall service/experience, the major issue that their clients should have is that they might not be actively letting renters/users know of the risks and advising on the steps that can/should be taken if their Wireless network is intended for privacy sensitive material (e-mail login, credit card, etc).


The Wi-Fi at the WeWork I'm at is blazing fast, even in an open office with a 4 or 5 dozen laptops + cell phones connected.

I can get 20-40MB/s, not the fastest I've seen, when I was plugged into gigabit at MSFT I could basically saturate my network card, but far faster than my home connection and good enough for any possible need my development laptop has.

TBF to your complaints, I am mostly stationary, and the WeWork labs floor I'm on doesn't have very many walls, but I've roamed video calls before and not had an issue.

(The space I'm in is super new though, it was constructed last November, so that may be part of the difference as well?)


My experience is with the WeWork in Berkeley. If we had a good connection our speed was great, but we would have to toggle wifi on and off to get that connection.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: