Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid PIN skimming attacks #189

Closed
alexshalamov opened this issue May 3, 2017 · 21 comments · Fixed by #213

Comments

@alexshalamov
Copy link

commented May 3, 2017

When <input type="password"> is active, UA could stop or heavily round / throttle data that is provided by the sensors, therefore, PIN skimming using ALS or Motion sensors could be mitigated for most of the cases.

Similar solution could be applicable for normal <input> element, so that, no information is leaked when user inputs the data.

@anssiko

This comment has been minimized.

Copy link
Member

commented May 3, 2017

We should definitely add this to https://w3c.github.io/sensors/#mitigation-strategies

@lknik, any comments?

anssiko added a commit that referenced this issue May 3, 2017
Fixes #189.
@tobie

This comment has been minimized.

Copy link
Member

commented May 3, 2017

So thinking about this a bit more, what's the scenario where this makes sense?

Currently, we're limiting sensors reading output to top-level browsing context of visible tabs.

So the only case where I see this could be an issue would be in a top-level browsing context trying to snoop on an embedded cross-origin iframe. For example, a merchant that would embed paypal and try to guess the password during checkout.

Seems like a safer mitigation strategy would be to stop outputting readings when the current browsing context looses focus.

I'm not sure what the precise relation between page visibility and page focus is.

@alexshalamov

This comment has been minimized.

Copy link
Author

commented May 3, 2017

I was thinking about focused / unfocused use-cases, but according to this and this, looks like taking into account 'focused' state is unreliable. Main document is still focused when element in iframe has focus. Also, looks like on some platforms, document can have focus, while system UI is focused, e.g. on Mac, if you use spotlight search, document is still focused (have to try on other platforms).

Anyways, imo this issue could be renamed, since it is applicable to all elements that could be used by user to provide input. We need to have a hint from the platform / browser, that user is providing input, therefore UA could apply some special sensor policy. For input=password, this is a 'must' requirement.

@tobie

This comment has been minimized.

Copy link
Member

commented May 3, 2017

I was thinking about focused / unfocused use-cases, but according to this and this, looks like taking into account 'focused' state is unreliable. Main document is still focused when element in iframe has focus.

So we should be able to figure out what the owner document of the focused element is and whether it's the top-level context or not.

Also, looks like on some platforms, document can have focus, while system UI is focused, e.g. on Mac, if you use spotlight search, document is still focused (have to try on other platforms).

Wow, that's bad. I was hoping for visibility state to have us covered here, but it doesn't. :(

Anyways, imo this issue could be renamed, since it is applicable to all elements that could be used by user to provide input.

Well, that goes well beyond elements, though, to include native applications, browser extensions such as 1Password, etc. Yikes!

We need to have a hint from the platform / browser, that user is providing input, therefore UA could apply some special sensor policy. For input=password, this is a 'must' requirement.

Well, until we want to provide background data, it seems what's important is to avoid providing readings of any sort as soon as the user actively engages with content either outside of this origin or outside of the user agent.

@tobie tobie changed the title Avoid PIN skimming attacks by using input element state Avoid PIN skimming attacks May 3, 2017
@lknik

This comment has been minimized.

Copy link
Contributor

commented May 3, 2017

Should help when are used, provided all PIN-like data is inputed using those. Can we go with whole form elements?

The question is also whether to include any specific rounding/frequency advice.

@tobie

This comment has been minimized.

Copy link
Member

commented May 3, 2017

Should help when are used, provided all PIN-like data is inputed using those.

This only helps for nested x-origin iframes. Not for other native apps, browser extensions, etc.

The question is also whether to include any specific rounding/frequency advice.

Thats coming up in a seperate PR.

@pozdnyakov

This comment has been minimized.

Copy link
Contributor

commented May 4, 2017

Whereas the attacks are targeted to skim the symbols pressed on a virtual keyboard, an alternate mitigation strategy would be throttling sensor readings every time the virtual keyboard turns up.
WDYT?

@kenchris

This comment has been minimized.

Copy link
Collaborator

commented May 4, 2017

That is probably fine as the user wont be looking at the data anyways

@alexshalamov

This comment has been minimized.

Copy link
Author

commented May 4, 2017

@pozdnyakov I think html spec does not distinguish between virtual / hw input methods. Also, there are plenty of devices that have sensors and HW keyboards.

@kenchris

This comment has been minimized.

Copy link
Collaborator

commented May 4, 2017

You can detect first input or so, which is what Chrome now does to show the Not Secure badge on http sites. That should at least help if your PIN is more than one number :-)

@tobie

This comment has been minimized.

Copy link
Member

commented May 4, 2017

So there are the following four scenarios here:

  1. User is typing in an input field that's on the page itself: we don't care about skimming in that case, as the web page can just do input[type=password].value to get the value.
  2. User is typing in a different browsing context altogether: we can to solve this using focus (still todo).
  3. User is typing in an iframe that's from a different origin: we can also to solve this using focus (also still todo).
  4. User is in another app or a browser extension: there's currently nothing we can do rigorously in spec, as in some cases the browsing context does not loose focus and can stay visible. Instead we need to mention the threat in the spec and suggest mitigation strategies "user agent should loose focus when the user navigates to a different app or browser extension" or something like that.
@pozdnyakov

This comment has been minimized.

Copy link
Contributor

commented May 4, 2017

@alexshalamov but UA can be aware that virtual keyboard appears if there is a platform API for it. The vast majority of Sensor API clients are smartphones and tablets, so making them safer is already good :) and btw the both strategies can be combined..

@tobie

This comment has been minimized.

Copy link
Member

commented May 4, 2017

@pozdnyakov can you explain how/where this fits in the 4 steps I outlined above?

@pozdnyakov

This comment has been minimized.

Copy link
Contributor

commented May 4, 2017

Well, wherever user is typing (mainframe, iframe, another app) sensor readings propagation will be suspended, so IMO all 4 steps are fixed (assuming a virtual keyboard is used)

@tobie

This comment has been minimized.

Copy link
Member

commented May 4, 2017

@pozdnyakov so (2) and (3) will already be fixed by virtue of stopping when focus is lost. (1) we don't have to solve.

So the only one that could really help with is (4). In which there are actually two sub cases: (a) which is when the user is doing something in the app but outside of the browsing context (i.e. browser extension or own controls such as bookmarking, password manager, etc.), and (b) another application altogether.

For (4a) I assume you have control over this and that the browsing context looses focus when this happens.

For (4b) I assume platform APIs don't warn you when the virtual keyboard is pulled in a different application. Correct?

@alexshalamov

This comment has been minimized.

Copy link
Author

commented May 4, 2017

@pozdnyakov http://www.gsmarena.com/results.php3?idQwerty=1 . Common denominator is 'user input' so, we have to protect it regardless of input type (hw / sw) :-)

@tobie (1) Agree, no need to protect anything. (2) Should be 'fixable'. (3) Do you know someone from html spec who can help with it?

Maybe text like, if a focused element does not belong to top level browsing context, ... apply some sensor policy.

@tobie

This comment has been minimized.

Copy link
Member

commented May 4, 2017

Maybe text like, if a focused element does not belong to top level browsing context, ... apply some sensor policy.

Yeah, you can focus on x-origins too. I'll try to give it a shot.

@pozdnyakov

This comment has been minimized.

Copy link
Contributor

commented May 4, 2017

@pozdnyakov http://www.gsmarena.com/results.php3?idQwerty=1 . Common denominator is 'user input' so, we have to protect it regardless of input type (hw / sw) :-)

Less than one third from this list has at least one motion sensor
http://www.gsmarena.com/results.php3?chkAccelerometer=selected&idQwerty=1
http://www.gsmarena.com/results.php3?chkGyro=selected&idQwerty=1

I'm not arguing that we should take care about all the input methods, and I'm not challenging the <input type="password"> protection proposal :)

But I'd like to point out that reacting on virtual keyboard appearance is quite a "low-hanging fruit" in terms of implementation and at the same time it is efficient for most of the clients.

@pozdnyakov

This comment has been minimized.

Copy link
Contributor

commented May 4, 2017

For (4b) I assume platform APIs don't warn you when the virtual keyboard is pulled in a different application. Correct?

I'm figuring out the available API on different platforms, but I guess it's most likely the case : /

@alexshalamov

This comment has been minimized.

Copy link
Author

commented May 4, 2017

@pozdnyakov

I'm not arguing that we should take care about all the input methods, and I'm not challenging the <input type="password"> protection proposal :)

<input type="password"> Is a special case, however, all elements that capture user input can be protected. Button is one example, it is focuseable in an iframe, captures input, does not need input from hw / sw keyboard.

But I'd like to point out that reacting on virtual keyboard appearance is quite a "low-hanging fruit" in terms of implementation and at the same time it is efficient for most of the clients.

I've done few projects in the past, where devices had only VKB, HW or combination of both. Usually IME hides this information (VKB open / hidden), therefore, applications don't know when VKB is open.

@tobie tobie closed this May 4, 2017
@tobie tobie reopened this May 4, 2017
@tobie

This comment has been minimized.

Copy link
Member

commented May 4, 2017

Sorry, fat-fingered this and also sent a draft of a previous comment which I hadn't sent as it was out of date. Now deleted.

@tobie tobie modified the milestone: Level 1 May 4, 2017
anssiko added a commit that referenced this issue May 15, 2017
Fixes #189.
anssiko added a commit that referenced this issue May 15, 2017
Fixes #189.
anssiko added a commit that referenced this issue May 15, 2017
Fixes #189.
anssiko added a commit that referenced this issue May 15, 2017
Fixes #189.
anssiko added a commit that referenced this issue May 15, 2017
Fixes #189.
alexshalamov pushed a commit to alexshalamov/sensors that referenced this issue May 19, 2017
alexshalamov pushed a commit to alexshalamov/sensors that referenced this issue May 19, 2017
alexshalamov pushed a commit to alexshalamov/sensors that referenced this issue May 19, 2017
tobie added a commit to tobie/sensors that referenced this issue May 23, 2017
This mitigates both nested browsing context and
other top-level browsing contexts gaining focus
while a top-level browsing context from a different origin
is collecting sensor readings by preventing the latter
to do so.

Fixes w3c#189.
Closes w3c#206.
tobie added a commit to tobie/sensors that referenced this issue May 30, 2017
This mitigates both nested browsing context and
other top-level browsing contexts gaining focus
while a top-level browsing context from a different origin
is collecting sensor readings by preventing the latter
to do so.

Fixes w3c#189.
Closes w3c#206.
@tobie tobie closed this in #213 May 30, 2017
tobie added a commit that referenced this issue May 30, 2017
Refactor existing task source-based security mechanism into
security check algorithm.

Fixes #189.
Closes #206.
Closes #222.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.