6 ms·

This can be protected against by the extension looking at keyboardEvents and verifying the isTrusted attribute. Here are details about how we do this in Passwor

This can be protected against by the extension looking at keyboardEvents and verifying the isTrusted attribute. Here are details about how we do this in Password Alert: https://github.com/google/password-alert/blob/master/SECURITY.md#brute-forcing-the-password-from-a-malicious-webpage https://github.com/google/password-alert/blob/master/SECURIT... Before Chrome implemented isTrusted, it was a bit more tricky and we had to rely on a variety of attributes that did not have as much of a security guarantee.

level3 11y ago
Thanks for the helpful explanation! Those seem like fair mitigations. Reading more on it, though, since isTrusted can apparently be spoofed, it looks like the main obstacles are the (2) rate-limiting and the (3) intentional collisions. For (2), I suspect typical users would have a memorizable master password that's more susceptible to brute forcing, but of course it depends on the actual rate limit and how long you can keep the script running. Alternatively, I suppose a malicious script could overwhelm the rate limit so that the user wouldn't receive a legitimate warning. For (3), I wonder whether LastPass has a similar mitigation? From what I understand, they don't store the actual password, so all you would need is a matching hash. I'd be interested to know more details about LastPass's protections. Edit: I just saw pwman's response above.
- DrewHintz 11y ago
  > isTrusted can apparently be spoofed isTrusted cannot be spoofed in this situation, which is its intended use in Chrome. A Chrome extension in the isolated world is receiving events from the main world and checking isTrusted for those events.
  - level3 11y ago
    Thanks for the clarification. I assume the spoofability applies only to JS in the main world then? And extensions can receive the event before a script has a chance to fiddle with it? Sorry for the questions, just trying to figure out how this all works, and Googling doesn't give me a clear answer.

level3 11y ago

Thanks for the helpful explanation! Those seem like fair mitigations. Reading more on it, though, since isTrusted can apparently be spoofed, it looks like the main obstacles are the (2) rate-limiting and the (3) intentional collisions. For (2), I suspect typical users would have a memorizable master password that's more susceptible to brute forcing, but of course it depends on the actual rate limit and how long you can keep the script running. Alternatively, I suppose a malicious script could overwhelm the rate limit so that the user wouldn't receive a legitimate warning. For (3), I wonder whether LastPass has a similar mitigation? From what I understand, they don't store the actual password, so all you would need is a matching hash. I'd be interested to know more details about LastPass's protections. Edit: I just saw pwman's response above.

DrewHintz 11y ago
> isTrusted can apparently be spoofed isTrusted cannot be spoofed in this situation, which is its intended use in Chrome. A Chrome extension in the isolated world is receiving events from the main world and checking isTrusted for those events.
- level3 11y ago
  Thanks for the clarification. I assume the spoofability applies only to JS in the main world then? And extensions can receive the event before a script has a chance to fiddle with it? Sorry for the questions, just trying to figure out how this all works, and Googling doesn't give me a clear answer.