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

Do not store master password #5

Open
alexkingorg opened this issue Jul 29, 2011 · 4 comments
Open

Do not store master password #5

alexkingorg opened this issue Jul 29, 2011 · 4 comments

Comments

@alexkingorg
Copy link

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
Copy link
Owner

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.

@alexkingorg
Copy link
Author

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
Copy link
Owner

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
Copy link

eggyal commented Aug 3, 2016

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants