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

Already on GitHub? Sign in to your account

Do not store master password #5

alexkingorg opened this Issue Jul 29, 2011 · 4 comments


None yet
3 participants

The purpose of the PwdHash scheme is to enable easy entry of a master password that then generates complex passwords. The reason this is so valuable is so that you do not need to ever save your master password somewhere (where the data could be compromised).

By designing Hashed to save the master password, I believe this is defeating the very purpose and benefit that a PwdHash extension can provide.

I strongly believe the default behavior should be to never store any master password, but instead enable easy entry of that password and adjust it for transmittal using the PwdHash algorithm.


nnutter commented Jul 29, 2011

I agree with this in theory and appreciate both you trying the extension out and reporting this issue. However, I have read of (unvalidated) flaws in the Firefox extension where a malicious site can capture your master password as you type it in by watching for the '@@' and/or the F2 keypress. Until I understand this attack completely and can protect against it in Safari I feel it is a better choice to store the password in OS X's Keychain. As far as I know the master password can only be retrieved via the 'Keychain Access' app and requires the user to enter their password in order to view it.

In some ways I think the best solution may be an actual Mac app (possibly also a plugin to Alfred, Quicksilver, etc.).

I'm not going to close this issue at this point but it is definitely contingent upon the master password entry not being capturable from a malicious site.

One of the most important benefits to a system like PwdHash is there is no password honeypot. If you store the master password at all, you lose that benefit.

The way your app is currently designed, I don't see a significant difference between it and 1Password or any other password storage system that uses the Keychain for storage.

In order for a malicious site to get my master password, I would have to enter it on a site that was maliciously created or a site that was compromised with an XSS vulnerability or similar. I understand this could happen, but I believe that a site like this looking explicitly for PwdHash passwords is much lower risk than someone getting to my computer.

I hope this helps frame the issue the "right way" - which, of course, means "how I see it". :)


nnutter commented Aug 3, 2011

I definitely understand your point. My counter to this point is that you would (hopefully) know if someone stole your computer and was able to crack your login password and then get your Hashed password from Keychain. But if a malicious site were able to intercept and steal your master password you may never even know. That's absolutely terrifying to me.

I imagine I'll add support for this with some sort of warning to at least educate users about the risk. I'll let you know when that happens; possibly this weekend.

eggyal commented Aug 3, 2016 edited

In addition to @alexkingorg's concern, it should also be noted that one may need/want to use different master passwords on different sites: e.g. to satisfy conflicting password policies; or to use a master password that is some function of the site's "security value"—manually entering the master password at each site is one solution to this (though storing multiple master passwords in the keychain, from which the user is able to select their choice, is another).

However, I have read of (unvalidated) flaws in the Firefox extension where a malicious site can capture your master password as you type it in by watching for the '@@' and/or the F2 keypress.

Given that JavaScript attacks of this sort were very much at the forefront of the minds of PwdHash's authors when they developed their original extension (indeed, their paper discusses both it and their defences thereto at length), I'm surprised that "unvalidated" claims such as those of which you have read have caused quite so much concern.

That said, the defences they used in their Firefox extension may not be effective in Safari without careful thought and testing (if indeed, at all).

Nevertheless, their paper (§4.6) and original extension did (in a slightly different context) provide a solution that could put both your minds at ease:

Another defense against dictionary attacks,
which we have implemented, is an optional feature
we call the global password. The user can specify a
global password that is incorporated into the salt of
all hashes that the extension yields. Thus, in order
to mount a dictionary attack, a phisher has to guess
both the user’s web password and her global extension
password. This will likely make a dictionary attack
infeasible. The difficulty in using this feature is
that the user needs to set the same global extension
password on any PwdHash computer she uses.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment