Hacking for Christ

That is a clever idea - though the IDN spoof might not be fixed by it.

This is a really great idea, I think that it solves a lot of problems at once. I hope this gets added to Firefox ASAP.

Jason

Doron, what does this have to do with the IDN spoof? Mozilla fills in password fields based on the site URL and the field names - clearly, Mozilla will not recognise a spoofed IDN domain as the same website, that is only a human problem :).

But, I don’t really see the added value of this... Passwords can be hidden behind a master password already, can’t they? So then what’s all this for?

~Grauw

Looks like someone beat Blake to it.
See: http://passwordmaker.mozdev.org/

I guess you couldn't use the subdomain incase they had secure1.paypal.com and secure2.paypal.com.

Are there any times where multiple domains share the same passwords?

But if the UI is in the content area, can't an attacker fake the UI? Prompt the user for the master password, user enters it, and it goes the the malicious server...

Or would this depend on something like the status bar always being visible in non-chrome content?

Could there be configurable settings?

such as alternative hash algorithms and
alternative output representations.

What about modified S/Key calculator (STD61/RFC2289) ?

This application looks to me as its watered down version.

The 6 words output may be pretty cool as you can the remember password easier when you need to access the site by some other browser.

Sounds cool... however I've found the one password I forget the most is my PIN number for my student loans.

--- OFF TOPIC ---

Infact the login page requires your id (social security number), first two initilis of your last name, your dob (MMDDYYYY) then your pin number. All browser Firefox, Opera, Safari think that your soc number and dob is your user id password... so in that one case it would fail....

BTW a nice case study for a horriable UI for a web login can be found at https://www.dlssonline.com/tools/pin-anyone-new.asp

A similar idea, from 1996:
http://www.math.tau.ac.il/~matias/lpwa.html

A similar idea, as a bookmarklet:
http://www.angel.net/~nic/passwdlet.html

Hey Gerv,

Thanks for the coverage. Not sure I understand why you say it would need a modified UI, though. As it is right now, the user doesn't have to do anything special; they just type in their password and it all happens magically. Why add a context menu item?

-Blake

Jed,

The extension you linked to is terrible. It doesn't take into consideration any of the problems that actually make this solution difficult to implement. For example, with that solution, a phisher can very easily capture the user's real password via Javascript and the whole scheme falls apart.

-Blake

Mook,

There is no UI to spoof. It all happens silently and automatically. The browser (and thus the website) never even gets to hear the keystrokes, since our plugin captures them the moment Windows hears about them.

-Blake

Perhaps it would be worthwhile to look at integrating PwdHash into the OS's built-in keyring features. GNOME and KDE already offer password managers and on those platforms, PwdHash could serve as a middleware layer on top of them.

Could there be configurable settings? such as alternative hash algorithms and alternative output representations.

That's a terrible idea :-). There's no need for the user to be able to configure the hash algorithm, and it would mean it wouldn't work the same in every copy of Firefox.

Thanks for the coverage. Not sure I understand why you say it would need a modified UI, though. As it is right now, the user doesn't have to do anything special; they just type in their password and it all happens magically. Why add a context menu item?

Some reasons off the top of my head (based on my understanding of how it works, which could be wrong.) It's not possible to opt out of using PwdHash for certain sites, or to migrate gradually from a non-PwdHash system to a PwdHash system. If it's turned on in someone's browser and someone else borrows it, they won't be able to access their site, as PwdHash will mangle their password. The current system wouldn't work well on Internet cafe browsers, because you'd have to reconfigure Firefox to turn it on in some way.

The browser (and thus the website) never even gets to hear the keystrokes, since our plugin captures them the moment Windows hears about them.

How would that work in Firefox? You can't construct the hash until the entire password is typed in, so you have to allow the letters of the master password to be placed in the password box, and so an onkeydown listener could be capturing the characters while the user is still typing.

It would be nice if the character in password input fields could change from the asterisk to show that the password had been hashed - perhaps using little padlocks instead or something, or by re-using the 'padlock and yellow box' meme. I think you can opt-out by double-clicking or something,

I dislike the idea of one central website where you can put in your password to retrieve the hash - although it's difficult to conceive of a different method.

There is still another problem beyond that of browsers without support - if you use the same password everywhere, you're fine until you want to come and change it. Of course, that's no worse than now, though.

Alex: good point. I'd be happy to use PwdHash for most sites, but I'd want special, different passwords for my bank and my Paypal account, just to guard against the small possibility that my master password was compromised.

Any auto-fillin version of PwdHash has issues with that, unless you have some sort of personal opt-out list - which isn't easily portable between instances.

@Blake.

Yeah, I never said it was good, as I havn't even tried it, just mentioned the URL as I stumbled upon it the other day.

I can't wait for your firefox version though!!
Cheers

Gerv,

You wrote "How would that work in Firefox? You can't construct the hash until the entire password is typed in, so you have to allow the letters of the master password to be placed in the password box, and so an onkeydown listener could be capturing the characters while the user is still typing."

It would work the same way we do it with IE. We store the keystrokes in a translation table in memory. In other words, as you type "password," we store a mapping in memory:

A -> p
B -> a
C -> s
D -> s

etc.

and then all we send along to the password field is ABCDEFGH. Later, when you submit, we replace ABCDEFGH with "password" in the form data.