Skip to content

Latest commit

 

History

History
51 lines (37 loc) · 5.06 KB

SECURITY.md

File metadata and controls

51 lines (37 loc) · 5.06 KB
Raw

Overview

Password Alert uses a number of techniques to reinforce its security. This document provides a summary of the main ones, especially aspects that are specific to Chrome Extensions and the Password Alert hashing model. For hardware-based protection against password phishing, please consider using Security Key for 2-Step Verification.

Data is kept locally

One idea an attacker might try is to read your stored password. That’s why passwords are not stored, and password hashes are kept locally and never sent anywhere. In particular, a 37-bit, salted SHA-1 of the password is kept in Chrome’s localStorage.

You might be wondering: but what if an attacker can access Chrome’s localStorage? If an attacker can steal local files, they already have access to your system and you’ve already lost. They could steal cookies or other sensitive information that’s stored locally.

Extension Isolation

One idea an attacker might try is to access your password hash directly. Fortunately, the extension's code and localStorage are isolated from both the pages you visit and any other extensions that you have installed. This means there's no cross-site data access from a malicious website to the content script, or to the background page. In other words, bad actors cannot programmatically access your password hash. More details are available here: https://developer.chrome.com/extensions/content_scripts#execution-environment

Brute-forcing the password from a malicious webpage

One attack idea a malicious page could try is to generate fake keystrokes and then watch for the warning banner to appear. We have three protections in place to deter this:

  1. We discard keyboardEvents that appear to be generated by JavaScript on the page instead of a real user typing. For example, in chrome/content_script.js passwordalert.handleKeypress_() see the check for .isTrusted.

  2. The background page limits password checks to a somewhat human speed. Anything over the limit is silently discarded. For the code, see chrome/background.js passwordalert.background.checkRateLimit_()

  3. Saving only 37 bits of the hash intentionally creates collisions. A straight-forward brute force of the hash would result in 20 million+ collisions for a 10 character password, depending on your character space. An attacker would need to pick out the correct password from this list.

Calculation for Size of Hash Bits

Why 37 bits? We were trying to balance two goals: store enough bits to prevent false positives, but few enough bits so that even if an attacker can brute-force it they won’t be able to easily discern your real password. The false positive rate is such that with a 20,000 person company typing randomly for a year, you'd get one false positive. This assumes a user types 300 characters a minute for 120000 work minutes a year and is typing for 20% of the time. It is calculated with (20000*300*120000*0.2)/(2**37) Random typing isn't what people actually do, so the actual false positive rate is likely significantly lower.

For the calculations, we've assumed that password characters are chosen from a set of 72 likely characters. With only an 8 character password, this would result in an average of 5,255 collisions, calculated with (72**8)/(2**37). With a 10 character password, this would result in an average of 27,240,503 collisions, calculated with (72**10)/(2**37).

If your password has more than 37 bits of entropy, then an attacker looking for another password that hashes to the same 37 bits would get collisions and not know which brute-forced password was correct.

Note that Google for Work administrators can determine password lengths here. Other services like Active Directory also support password policies.

Google's bug bounty program

Password Alert is covered by Google's bug bounty program as described here: https://www.google.com/about/appsecurity/reward-program/

For Password Alert specifically, vulnerabilities that would be in-scope for the bug bounty program would be things such as:

  • unauthenticated access to user data on the server
  • a way for a malicious web page to get the password hash from the Chrome Extension
  • code execution in the context of the Chrome Extension's background page or the isolated content script.

However one thing comes to mind that would likely not be in-scope for the bug bounty program: Ways for phishing sites to evade detection by the Chrome Extension, such as by obfuscating their HTML to avoid the string matching, or sending spurious events to avoid triggering password typing alerts. We expect evasion to be a cat-and-mouse game and we plan on dealing with evasion techniques as they're used by attackers. If attackers actually put the time in to specifically evade the tool, then we'll consider building it into Chrome to make evasion less feasible.