830630 - [Settings] Internet Sharing allows me to set a password for my hotspot *without any indication that I need to also turn on WPA*

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Settings, defect)

Description

[Daniel Holbert [:dholbert]]

Mindset: Pretend you're a somewhat-computer-illiterate user.  (In particular, pretend you have no idea what "open" or "WPA" or "TKIP" or "AES" mean).  This probably describes a lot of our users.  Or, maybe you're just in a hurry.

Now, let's say you want to use the hotspot feature of your phone.

STR:
 1. Go to Settings | Internet Sharing.
 2. Notice that the default password is "1234567890" -- that looks bad, so you decide to pick something better.
 3. Hit "Hotspot settings", and set the password to something else.
 4. OK -- now you've set a password on your WiFi, just like your tech-savvy friend told you you should!!  Hit the slider to enable your hotspot.

ACTUAL RESULTS:
Despite the fact that you've just **explicitly set a WiFi password**, you've just turned on a public WiFi hotspot from your phone. So, unbeknownst to you (depending on your tech knowledge), now anybody nearby can do Evil Things.[1]

EXPECTED RESULTS:
It should've been clearer that you have to take an extra step -- *enabling WPA* -- in order to *actually* get password security.
e.g. perhaps the password fields should be disabled until you've turned WPA on, or we could pop up a warning dialog if the user edits the password without enabling encryption, or something like that. (I'm not a user interface designer, so I'm not sure what's exactly right, but I do know that the existing interface is deceptive and a potential security footgun.)

[1] Evil Things = use your data (increasing your phone bill), sniff the traffic from any machines that you connect to your network, exploit yet-to-be-discovered B2G bugs, ...

Comment 1

[Daniel Holbert [:dholbert]]

(Speculatively marking as blocking the B2G Tethering security review bug, since (per end of comment 0) I think this is a security issue w/ our tethering settings UI.)

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #0)
> EXPECTED RESULTS:
> It should've been clearer that you have to take an extra step -- *enabling
> WPA* -- in order to *actually* get password security.

Alternately: We could just change the defaults such that WPA security (either TKIP or AES) is on by default, and the user has to explicitly pick "open" if they want an open hotspot. That'd be simpler than adding logic to hide/show the password field depending on whether security is enabled.

(My main concern is just that the straightforward path of "turn on wifi hotspot -- but ooh, I should pick a good password first -- OK, I'm safe, _now_ turn it on" ends up leaving the user in an insecure state, by default. If we can steer that path such that the user will end up in a secure state, that would be great.)

Comment 3

[Daniel Holbert [:dholbert]]

Also: just to emphasize that this isn't a contrived scenario -- I actually performed the exact STR from comment 0 myself today.  I only realized that something was off when I connected a client machine and realized that I hadn't been prompted for a password.  That was enough to get me to realize that I'd missed a step, but I bet a lot of users wouldn't notice.

Comment 4

[Paul Theriault [:pauljt] (no longer reading bugmail)]

I actually did the same thing as the STR today. Bug 831948 landing will mitigate this somewhat - the use will actually have to choose open, but it would better if somehow indicated to the user that no password will be used.

Comment 5

[Stephanie Ouillon [:arroway] (needinfo me)]

Now in the UI you can't set a password without having set first WPA or WPA2 (the password field doesn't display if it's "open"). So I think this bug should be closed.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Stéphanie Ouillon [:arroway] from comment #5)
> Now in the UI you can't set a password without having set first WPA or WPA2
> (the password field doesn't display if it's "open").

I've confirmed that this is true, using a local B2G 1.3 build from a day or so ago. Nice.

> So I think this bug should be closed.

Agreed. Resolving as WORKSFORME. (If you know what bug was responsible for hiding the password field, feel free to tweak resolution to FIXED & add dependency on that bug, to indicate "fixed by bug ___")