363372 - Implement built in PwdHash

Status: RESOLVED INACTIVE

(Toolkit :: Password Manager, enhancement, P5)

Description

[Biju]

reg: built in PwdHash to avoid people using same password for all sites they register
filed per bug 360493 comment 241 by Brendan Eich

It is a fact that people use only a set of limited number of passwords.
So most time we use same password on multiple sites.
This make multiple sites vulnerable if security at 
one of the site using same uid/pwd got compromised 
or when phishing for one site was successful.
(like incomplete content sanitation at myspace.com bug 360493)

This is long been requested feature but never implemented.

Implementation issues:-
1. some sites will have stupid additional conditions to validate passwords, which may make troubles when we make pwdhash.
2. Login screen may be at multiple sub domain


examples
case 1
a) http://myspace.com/ wont allow first name to be there in password.
ie, if you make an id with first name = "b", and your hashpwd is "X3afb31" myspace wont accept it as a strong password, even though only one letter matching.

b) A site may insist first or last character of pwd should be an alphabet.

c) A site may insist all/combination 
at least there should be 
1 capital letter, 
1 small letter, 
1 numeric character, 
1 character from ~!@#$%^&*()_-+=.:;'"<>,./\| (from MS stupid recommendation)

d) A site may only allow alphabets and numeric characters in pwd

case 2
http://buffy.wikia.com/ and http://familyguy.wikia.com/ have same uid/pwd but two login screen at different sub domain.


The GUI should provide a way to name and store a the restriction sets.
Also just like we provide phishing protection from google. 
Cant we also have service providers for serving just restriction sets.


available extension
https://addons.mozilla.org/firefox/1033/
https://www.pwdhash.com/
http://crypto.stanford.edu/PwdHash/

related bug 362580, 362576

Comment 1

[Robert Chapin]

How would this work if I want to log in to my checking account from an Internet cafe?

Comment 2

[Biju]

(In reply to comment #1)
> How would this work if I want to log in to my checking account 
> from an Internet cafe?
Yes, as long as same hash mechanism is used.

Already people are using web/bookmarklet version 
eg http://www.angel.net/~nic/passwd.html
like if my master password is "biju" then 
a web site http://www.cnn.com/ my hashed pwd is "154ca907"
for http://mozilla.com my pwd is "e9c1bd3d"
see you generate a unique pwd for site, 
from a single master pwd.

Comment 3

[Brendan Eich [:brendan]]

(In reply to comment #2)
> Already people are using web/bookmarklet version 
> eg http://www.angel.net/~nic/passwd.html
> like if my master password is "biju" then 
> a web site http://www.cnn.com/ my hashed pwd is "154ca907"
> for http://mozilla.com my pwd is "e9c1bd3d"
> see you generate a unique pwd for site, 
> from a single master pwd.

See also https://addons.mozilla.org/firefox/1033/ (the Firefox add-on version of pwdhash).

/be

Comment 4

[Brendan Eich [:brendan]]

Mozilla could host a service to help you hash your password for a particular site, if you were roaming to a kiosk. It should be simpler than going to the pwdhash.com site or whatever.

/be

Comment 5

[Alex R.]

(In reply to comment #0)
> Implementation issues:-
> [...]
> 2. Login screen may be at multiple sub domain
PwdHash ignores subdomains in creating the hash.

Comment 6

[Biju]

(In reply to comment #5)
> (In reply to comment #0)
> > Implementation issues:-
> > [...]
> > 2. Login screen may be at multiple sub domain
> PwdHash ignores subdomains in creating the hash.

yes https://www.pwdhash.com/ ignore sub domains 
but http://www.angel.net/~nic/passwd.html checks sub domains also.

I dont think ignoring subdomain is a good idea all the time.
example http://aaa.dynip.com/ and http://bbb.dynip.com/ should not have same pwd.
(ps:- pwdhash.com is taking care of http://google.co.uk/ and http://amazon.co.uk/ 
with separate pwd)

Comment 7

[Brendan Eich [:brendan]]

Rob had some data on weakness to dictionary brute-forcing based on a Google study.

/be

Comment 8

[Robert Sayre]

This idea is vulnerable to offline dictionary attacks and, by extension, a cheap namespace walk for common passwords:

http://lists.osafoundation.org/pipermail/ietf-http-auth/2006-April/000232.html

It doesn't help PwdHash's case that the "Related Work" section of the PwdHash paper contains an inaccurate and incomplete assessment of HTTP Digest (though both suffer from the same offline attacks).

See bug 356855 for details on SRP, a scheme that seems preferable on all metrics discussed in this bug.

The best description of SRP in general is here:

http://srp.stanford.edu/srp6.ps

Keep in mind that it is specified in terms of a connection-oriented protocol in that paper.