this post was submitted on 09 Jul 2024
642 points (99.7% liked)
Technology
59534 readers
3195 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
What does this mean, that the use plain HTTP or some other protocol? I can't see details.
Two important points raised:
The answer to the first one may be semi-legit as these are mesh products. As in, the other nodes in the mesh will need this information, and it appears that Linksys has decided to store your security data in AWS for the other mesh nodes to retrieve it when you're setting it up. I'd sure as hell like to know this before the product does this. Further, I'd much prefer to simply attached to each mesh node myself to input the secured credentials instead of sending them outside to the internet.
There's not excuse for Linksys sending the creds unencrypted onto the internet.
I'm just finding no confirmation that they send them unencrypted over the Internet and I've seen "researchers" calling sending passwords over HTTPS "unencrypted."
Mesh coordination is interesting. It's not great. That said I doubt that any off-the-shelf consumer mesh system does go through the work to keep things local-only. It's too easy to setup a cloud API and therefore likely all of them do that since it's the cheapest.
Even if they were sending them with proper E2EE to their server, that would still be a huge fucking problem.
That's because the password is unencrypted.
HTTPS will encrypt the channel and the data in flight, but the data is still unencrypted and anyone with a key that validated (assuming it actually checks for certificate validity) now has access to your unencrypted password. So yes, even over HTTPS it should be considered unencrypted.
Whether or not they're sending it over an encrypted channel, they're still sending out an unencrypted password that they have no need for. Linksys has no reason to need the unencrypted password, and at best would only need a hashed password to accomplish whatever business case they're sending that to solve. We have to assume that they're also saving it in clear text given how they're sending it in the clear as well.
No password should ever leave your network unencrypted, no matter the data channel encryption. Anything less is negligence , and the vendor should not be trusted.
The channel is encrypted, the content is not. It is a password, why would they need it?
Because now they have your login and password - not a hashed version they can only validate against, but the real thing that can be used to log into your network. They shouldn't ever have it, aside from them being able to sell credentials this also means someone else could probably obtain access to all of them
How would they know that the device sends the SSID and password otherwise? If it was encrypted you would not be able to read the content of the packages.
If you get root on the device you can MITM it by extracting session keys
Even then, the other nodes would only need the hash of the password, not the password itself.
That depends entirely on the auth system, but you can use a separate credential to retrieve the password (using something like a PAKE algorithm)
From what I can find, by "These routers send your credentials in plaintext", they actually meant to say, "The mobile app sends credentials in plaintext."
If you use the web interface then your credentials are not sent in plaintext. The routers themselves also don't send credentials in plaintext.
The people who found this out got that wrong, and a lot of people are confused because they didn't expand on "in plaintext." They could be a little more professional / thoughtful.
Edit: I'm also thinking about the "may expose you to a MITM" bit. I think if it was https then a MITM (assuming all they can do is examine your packets) wouldn't work because the data can only be unlocked by the private key. It sounds like it was an http connection?
This is what I'm thinking too. The only likely scenario under which the plaintext and MITM words make sense together is HTTP. I wouldn't put it past Linksys to have used an HTTP API endpoint but these days a lot of things scream if you use HTTP. Thanks for the work!