Let's say real-password = hash (domain-name + user-entered-password).
If by "user-entered password" you mean "master password typed into a bit of browser UI", then yes.
Phisherman sets up a site and does not mark the password field as form element type password. He does however put a question mark (or whatever 'in page' feedback) as well as some javascript to asterisk out the not-really password field. The user will enter their password and the un-hashed password will be caught in the net. Since the algorithm and taget domain-name are know the bad-guy has all he needs.
That's basically saying "if you type your password into a phishing site, the phisher has got it". While true, how is this different from now?
A solution to this is to make real-password = hash (domain-name +
user-entered-password + salt).
I think you have missed the point a bit. This is how I think it should work:
- Password fields acquire a right-click "Fill in password" menu item - When this is clicked for the first time in a session, the UA prompts for the PwdHash master password using a UA dialog. This is a browser feature - it can't be turned off. - Field is then filled in with a hash of the master password and the domain name.
At no time does the master password ever get put into the page. And the auto-generated password will be different for a phishing site, so if a user does this procedure on the phishing site, the phisher gets a bad value - and they still don't know the master password to calculate a good one.
Gerv _______________________________________________ Mozilla-security mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-security
