Password Reuse Visualizer

Features

This add-on adds a small green padlock icon to the add-on bar. Upon clicking, it opens a new page with a graph visualization on it.

The graph visualization is generated with data from nsiLoginManager. It's a force directed graph visualization, as seen below. The green nodes represent each individual password in the Firefox profile. The blue nodes represent individual websites that those passwords (green nodes) are used on. Orange nodes serve as "notifications" that two green nodes (again, passwords) connected are very similar.

Hovering over a blue node with the mouse displays the name of the website in question. Hovering over a green node displays a password's visual hash. Clicking on a green node prompts the user with a confirm dialog. If the user clicks "OK", their password is displayed on screen.

Screenshot

Implementation

The visualization is rendered using a SVG canvas and the d3.js library. It's a force directed graph visualization, which automatically organizes itself. Individual nodes can be dragged, and the entire graph will respond. Password similarity is calculated via edit distance.

Unfortunately, the force directed graph doesn't scale up well to a large number of nodes. The fact that password similarity among n passwords often leads to n^2 edges in the graph further complicates things. Future updates could address this problem by only displaying a certain number of passwords on screen at once, changing the way password similarity is expressed, or (a more extreme approach) use an entirely different graph engine.

This add-on requires data from nsiLoginManager to function. Although the code is fairly modular, Google Chrome does not offer user password data to browser extensions, so this add-on is not portable. [1]

The source code is available on Github. [2]

Security Concerns

This add-on saves nothing to disk, so there is no risk of unencrypted login information leaking out to the user. The password manager will prompt the user for a master password before passing password data onto the add-on, so that security is not compromised.

However, some users seemed unaware of the way the password manager and master passwords work, and expressed concern that this add-on could give someone using their Firefox profile access to their passwords. Of course, that information is already accessible via Preferences, but it is possible that this add-on makes this information more discoverable, as many users were unaware of the Saved passwords pane in Preferences.

Password reuse data, even if unaccompanied by actual passwords or password hashes, can be of use to attackers. This add-on does not yet transmit that data in any form. Future versions may make it possible to publish screenshots of password reuse, however these screenshots contain no sensitive information.

This add-on also makes use of visual hashing, so those same security concerns apply.

Collecting Password Reuse Data for Analysis

NOTE: as of March 2012, no data collection of any kind is currently done, this is only a proposal for how we might do so safely.

It could be extremely useful to collect aggregate information about how users employ passwords on the Web. This would, of course, be opt-in, and we have to make sure that the collected data doesn't cause a risk to the user.

Our major assumption is this: an attacker trying to break into Alice's accounts on the Web is going to assume that Alice reuses passwords at various web sites. Even in the worst-case scenario, we would like a password-reuse-visualizer breach to provide no information that the attacker couldn't figure out on their own. We propose the following data-sanitization strategy to that effect, performed locally, in the Firefox client:

• a list of the user's passwords is created and sorted in random order. each password is assigned a serial number alias, e.g. "p1", "p2", "p3" in the randomized order. This serial number alias bears no relationship of any kind to the user's actual passwords.

• a list o the user's password-protected sites is created, sorted in random order, and assigned serial number aliases in the same way, e.g. "s1", "s2", "s3",... Again the serial number alias bears no relationship to the actual site.

• build PS: the correspondence of passwords and sites is serialized based on the aliases, e.g. "p1 used on s2,s5"

• build PP: password similarity is serialized based on aliases, e.g. "p1 and p5 are similar"

• the sanitized password-reuse dataset is then the combination of PS and PP, just enough data to visually recreate the graph.