Hacker News Reader

Comment by abadpoli | Hacker News Reader

Is this actually plaintext, or is this plaintext-inside-HTTPS? The article and source material don’t say.

It’s pretty normal for passwords to be “plaintext” inside an HTTPS request. That’s how practically every login to a web app works. If it’s not HTTPS, there’s a whole slew of other issues along with putting a plaintext password in the request.

If it is HTTPS, then the issue really is just that the password gets sent anywhere rather than staying local. This is a lot more debatable as a practice, but unfortunately is also common for a lot of routers to support their cloud/app management functionalities.

View on HN

> is also common for a lot of routers to support their cloud/app management functionalities

Why does the cloud need to know the wifi password to support mgmt functionalities? The only reasons I can think of right now are for more "automatic" setup of a second unit for meshing or if you want a factory reset to have the same password. Both of those cases have better solutions.

If it's for setting a new password I don't see why they need the old one, if it's for remote management access using the wifi password as the access credential then that seems both bad (access to my network should not mean access to manage it) and like it can be done a lot better if actually needed (send just a well salted and hashed password).

This appears to be a cloud password first stetup feature. As in you type your new password into the app, the app sends your password to a cloud API, and then the cloud API instructs the router to change to the new password over a management API.

So the password is sent for a specific feature that legitimately wants it.

You could have the app connect to a special WiFi network and then communicate directly with an API exposed by the router. That's what my router does. But the experience of using a special-purpose WiFi network is janky on many common devices so I understand not taking that choice.

> But the experience of using a speical-purpose WiFi network is janky on many common devices so I understand not taking that choice.

Yea, this is my hunch as well as to why this works this way. Consumers are easily confused, and asking them to disconnect from their currently working internet connect and connect to a router that hasn’t yet been set up (and might not be able to provide an internet connection) can get confusing. I know I’ve been in this situation before where I’ve been connected to a special-purpose network without internet connect, need to look up some instructions online, but then remember I can’t because I’m not connected to the internet…

> and might not be able to provide an internet connection

But this router has to have an internet connection for this flow to work, right? Otherwise how can the router get the password from the cloud service?

What is needed is the device-to-router connection to work securely but by sending the wifi credentials plaintext that is not secure, so not sure what is won here.

The router itself has an internet connection but that doesn’t necessarily mean that all of the other stuff required to actually route traffic or connect other devices is configured (like DHCP).

It’d be possible to have some sane defaults in there to make it work, but I wouldn’t count on them to be 100% out in the field of who-knows-what-crazy-settings-this-consumer-has.

> sending the wifi credentials plaintext that is not secure

If the connection between the app, router, and cloud server are all HTTPS, then it’s probably more secure to do it that way than it would be to send it over an unconfigured, insecure WiFi network (which typically uses HTTP or unsigned certificates for the management interface).

Even if all that is true why would you not use a temporary password to then directly set the real password? It seems to me like they have not treated the password as an actual secret in this transaction.

it occurs to me now that the whole recent stuff that Apple has been pushing, where apps are banned from making HTTP requests (HTTPS only) may have been the impetus for this. Their "setup app" can't connect to http:// 192.168.1.1/ (or if if can, does so only after popping up dire warnings in scare dialogs) -- but it can connect to the "cloud" server so just send it up to the cloud and back down the WAN port. I can see how they arrived here. Still this is why "apps" suck for this purpose, but I bet they moved to apps for because there are probably plenty of households without a working computer, who need wi-fi for their phones and Rokus, and this proved to be the friendliest way to do it.

The velop uses bluetooth for setup... you use an application on your phone, that sets up the router. Yes, it's janky too.

Couldn't they then use a random password for the setup process and switch to the selected one when app and the router have connected? I'm pretty sure both android and iOS have APIs for apps to connect to wifi networks.

I'm just trying to ask: What is the scenario where the best (in both security and user-friendliness) solution is to send the wifi password in plaintext?

That API was introduced in Android 10. That's currently supported by only around 60% of Android devices globally and that number would have been lower when they decided how to implement this project.

My phone did have that API, and I subjectively still found the experience janky. But that's just my opinion.

You could send the password through the cloud server pre-hashed, or even better the cloud server could be used to establish an end-to-end encrypted connection from the app to the router.

If they intercepted it, then one must assume it was truly plaintext. Because if they were able to get access to the private key for Linksys's server certificate, that would be even bigger news.

Reply on news.ycombinator.com