376674 - [meta] Improve password security by generating and managing strong passwords

Status: NEW

(Toolkit :: Password Manager, enhancement)

Description

[Justin Dolske [:Dolske]]

For Firefox 3, we'd like to add functionality to Password Manager to help increase the security of passwords being creates/used.

Bug 363372 (and the PRD) mentions one possible class of solutions, based on the idea of hashing a user's (weak) password plus some choice of salt, so that the resulting password is strong and unique.

However, I think a simpler approach is to simply generate (and store) a randomly generated password. Passwords based on a hash of the sitename get complicated to manage if you want to support things like changing your password periodically, using the same identity on multiple hosts (eg labs.mozilla.org and blog.mozilla.org), and recovering your password if the hostname suddenly changes (eg bugzila.site.com --> bugs.site.com).

Bug 363372 also mentions some other concerns, such as a site requiring or prohibiting the use of certain characters. I think these kinds of real-world problems complicate clever schemes (like hashed passwords) enough that they don't offer significant advantages compared to random passwords.

Hashed passwords are a neat idea; they're just hard to apply to a general user base.

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

Not blocking on P2 items.

I tend to agree that while the initial generation could be hashed on the site, as long as the user is using the pwdmgr to track the password, we get mostly the same effect this way.

cc'ing johnathan as this touches his doman as well.

Comment 2

[Justin Dolske [:Dolske]]

This was cut for FF3, unassigning.

Comment 3

[Mike Kaply [:mkaply]]

This reduces the portability of passwords. I would only be able to access sites on my computer that had my stored passwords, because I couldn't remember the passwords that were generated.

We need a way for people to use their "easy" passwords, but some other magic happens that makes it a secure password, but that magic is repeatable elsewhere.

What about having a way in preferences to store a passphrase? Then we would has any password that was entered against this passphrase to create a more secure password.

We could also provide a place on the web to enter a passphrase and a password so that if you were on someone else's computer, you could get your password that way.

This would provide a way to generate secure passwords and a way to make the passwords portable.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

(In reply to comment #3)
> This reduces the portability of passwords. I would only be able to access sites
> on my computer that had my stored passwords, because I couldn't remember the
> passwords that were generated.

This is a significant issue, and IMHO a showstopper.  I have to be able to access my whatever-account from another computer without carrying a USB key with a (recent?) copy of the auto-passwords my computer(s) generated.

> We need a way for people to use their "easy" passwords, but some other magic
> happens that makes it a secure password, but that magic is repeatable
> elsewhere.
> 
> What about having a way in preferences to store a passphrase? Then we would has
> any password that was entered against this passphrase to create a more secure
> password.

Conceptually this is similar to have a "master password" for your file of passwords (or like a password manager on a PDA, which is itself passworded).  The difference is that, if needed, you can reproduce the hash as needed without the physical device, and it guards against dictionary attacks pretty well.  The downside is that unless you somehow include the site name/addr/etc in the hashing process, you're still vulnerable to the cross-site attack (get them to register with your evil site using their password, and you can try that against banks, etc, since the result is deterministic).

> We could also provide a place on the web to enter a passphrase and a password
> so that if you were on someone else's computer, you could get your password
> that way.

I understand why you suggest this, but oh my isn't that a scary idea.  Better would be a simple way to hash with a specific phrase on the fly - but the problem with that would be if you had to use IE, phone browser, etc that don't support this and where you can't download something to do the hash for you.

> This would provide a way to generate secure passwords and a way to make the
> passwords portable.

Per above, the portability means one attack vector is left open, though perhaps the biggest one (weak easily-brute-forced password) is mostly closed.

There's also the problem of "must have a number, must have multiple cases, no more than N characters, no less than N, etc".  Schwab requires 6-8 characters, for example (yes, really - it's annoyed me for a decade).

Comment 5

[Ben Bucksch (:BenB)]

> > This reduces the portability of passwords. I would only be able to access sites
> > on my computer that had my stored passwords, because I couldn't remember the
> > passwords that were generated.

Firefox would need the ability to export (and import) the passwords in a human- and computer-readable file.

> This is a significant issue, and IMHO a showstopper.  I have to be able to
> access my whatever-account from another computer without carrying a USB key
> with a (recent?) copy of the auto-passwords my computer(s) generated.

That's what I do (Notebook, not USB stick). It's cumbersome, but possible.

The alternative of generating a password from a "master" password + domain name + hashed is fragile. As pointed out, company names and domains change (France's largest ISP (France Telecom) recently changed name from Wanadoo to Orange just because they felt like it). Also, we may find that we need to change the algorithm (e.g. from hostname to domain name or vice versa, or include other information to disambiguate something, e.g. port, URL path or whatever). If you change the algorithm, and the other computer uses a different version of Firefox than you do at home, the password may be generated differently. Last but not least, you may want to use one of your less security-critical accounts from an internet cafe, and it has only MSIE, no way to install Firefox.

Comment 6

[Alex Limi (:limi) — Firefox UX Team]

I can't see any obvious progress (nor UI design needed) on this one, so removing uiwanted. Feel free to tag me again if there is anything needed here.

Comment 7

[Matthew N. [:MattN]]

If we only generate passwords when password sync is setup then I think this addresses some of the concerns. Also, users won't be forced to use this so if they want to type their own password they are free to do so.

Chromium has the implemented behind a flag (I believe at some point running as an experiment with some users).

Comment 9

[Matthew N. [:MattN]]

http://www.chromium.org/developers/design-documents/password-generation

Comment 10

[Ben Bucksch (:BenB)]

> If we only generate passwords when password sync is setup then I think this addresses some of the concerns.

With Sync, it can surely be nicer, but even without, it should be possible on request: E.g. context menu entry on password field or autofill on click. The generated password should definitely be shown to the end user, so that he can write it down elsewhere. That would be wise even with Firefox Sync enabled.

Comment 12

[Chris Karlof [:ckarlof]]

For better or worse, copied from https://bugzilla.mozilla.org/show_bug.cgi?id=1078534#c7

---------------------------------------------------------------------

This feature appears to be a simple big win, but may not be.

1) If we generate a password for the user, we better make sure we don't screw up remembering it and the associated username. Otherwise, we locked the user out of her account. This means password capture needs to be really good before we push this too hard, and we probably need a manually recovery mechanism for the times we don't capture correctly. 

2) It's not clear to me that typical users want this. It's ironic and saddening, because being able to use unique, randomly generated passwords everywhere is the supposed holy grail endgame of passwords managers. As flawed as the strategy is, people use all sorts of personal and private information in their passwords, which makes them take on a life of their own. Rejecting someone's hand-crafted, personal (yet maybe flawed) password in favor of some dehumanizing gibberish spit out by a machine has the potential to piss people off. 

As an anecdote, I was joking with my (not un-technical) neighbor about how with Google's acquisition of Nest, you'd start getting sweater ads when it's too cold in your house. He laughed, and the followed up with: 

"I was using Safari, and it wanted me to use *its* password for a site I was signing up for. Are my passwords not even my own anymore?"

Heh. "Users".

Comment 13

[Šime Vidas]

As a user I want this:

1. I land on some-website.com and decide to create an account.
2. On the Sign Up page, there is a password field. Firefox detects this and offers me to “generate and manage a password for this site”.
3. I accept Firefox’s password which is from now on autofilled on this site across my devices (via Firefox Sync).
4. I live a happy, passwordless life.

If this functionality can be implemented by a browser (as an optional feature), I say go for it :)

Comment 14

[Matthew N. [:MattN]]

We will implement it eventually once we can get accurate detection for your #2 and for later autofilling (#3). In the meantime you can use one of the various extensions on https://addons.mozilla.org that provides this feature.

Comment 15

[IdmFoundInHim]

This could also be implemented for using passphrases. It would be easiest and safest to use the diceware system (explained at https://en.m.wikipedia.org/wiki/Diceware). On the other hand, there are websites that (unfortunately) have set their requirements in a way that would cause a problem. The user would need to be asked if they want to a generated passphrase or a different type of password.

Comment 16

[Daniel Bodea [:danibodea]]

I don't see how this enhancement could block bug 1119063. Matt, can you confirm that this was intended?

Comment 17

[Matthew N. [:MattN]]

The reason is because we don't want authors to use autocomplete="new-password" just to prevent autofill but if we show password generation UI then there is a disincentive to abuse it like that.

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

Changing the priority to p2 as the bug is tracked by a release manager for the current nightly.
See What Do You Triage for more information

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

Everything except bug 1586304 has landed and we'll likely get that into beta 14; I think the feature is in good shape, and I don't need to track the meta bug anymore. Marking fixed for 70.