20 comments

[ 3.6 ms ] story [ 65.7 ms ] thread
I just saw a .deb in the new packages that installs the pwdhash plugin for Firefox and thought it was a pretty neat idea. Perhaps only a tiny additional line of defense, but if site A is careless with my password, it's nice to know that someone can't easily login to my account on site B. Does this make sense or do you think it's just too much trouble for what it gains you?
That's a cool extension, but I can't see it gain massive popularity. There is a class of problems with it that wfor a site ould be solved if you make it a bookmarklet (with a companion site): does it support your browser, what if you need to log in from a computer that doesn't have this browser extension?

The real problem is that if you are security-conscious enough to understand how this works and why you need it, you are not using the same password over and over again. E.g. I have a "weak" password that I use on HN and many other sites, but my mail and sites that involve (even remotely) money get an individual password each.

Personally, I'd like to see this become a feature of the HTML 5 standard. I'd also make it opt-out if you specify your doctype as HTML 5. That would certainly help drive adoption.

Who do I send that suggestion to? :-)

I love PwdHash because it is a relatively simple solution to a relatively complicated problem. This is just further proof that "secure by design" is the only real way to do security.

I understand the attractiveness of the convenience, but (perhaps it's just my paranoia) should one approach to security and how users handle it be codified into a standard at this point: shouldn't we be concerned about what currently unknown weaknesses may fall to cracking approaches that develop within a few short years?
I use SuperGenPass, which has a bookmarklet which does exactly this; for FF and Safari, the entire Javascript code can be stored in the bookmarklet, and does the hashing process without having to go to another site. For IE, it loads the script from supergenpass.com.

There's an offline version as well.

I do use a weak password for throwaway sites, but I use hashing (supergenpass) to make sure the (weak) password is unique for each site.

This is a bad idea which has been implemented a half dozen times. It's vulnerable to using a dictionary attack to recover the master password from a stolen hash.

It's also a particularly bad implementation that uses a single round of HMAC-MD5, which is a kind of bizarre primitive to use for hashing a password in the first place.

You know that old saw about your friend putting running shoes on as an angry bear approaches--he doesn't have to outrun the bear, he just has to outrun you? This password hashing is kind of like that. Sure it's easy to break. But if you're running a phishing site, are you really going to go through the trouble to cryptographically attack this weird password that doesn't work on other sites, when you've already got a bunch of other people's passwords that do work?

For that matter, this solution is probably even more complicated than it needs to be. Just tack on the domain name wholesale to the end of the password, and you'll foil any automated phishing password script well enough.

Aren't you really arguing for a variety of "security by obscurity"? Yes, it may work for the immediate present, but it's hardly planning for the future, is it?
> are you really going to go through the trouble to cryptographically attack this weird password that doesn't work on other sites

Of course you are, because this password does work on other sites. All other sites.

With a single high end CUDA capable graphics device you can blow through 500 million MD5 operations in one second. How many words are in an English dictionary? Less than that.

That's how weak this is. If you steal the password database from bigforum.com, you can attack all the passwords in parallel. If you crack a password, you can then log into their facebook, gmail, paypal, whatever. This scheme pretty much guarantees you can do that.

That assumes you know people are hashing (or more specifically, which few passwords are hashed out of this enormous database you've stolen). How do you tell a random password from a hashed one as an attacker?
What you say seems to be completely valid. However, I'm curious why 5 Stanford security experts seem to have not realized this? Honest question, not trying to use it as a way to disprove what you're saying (since I agree with you).
What if instead of this:

  hash(password + domainName);
it did this?

  salts.put(domainName, randomString());
  hash(password + salts.get(domainName));
This solution also misses the motivation behind using the same password on multiple sites: extreme laziness. Any solution that is even infinitesimally more difficult than just typing in something on the tip of your tongue is not going to solve the problem.
I like this idea, but (IMO) we really need widespread deployment of OpenID. If we had that, we wouldn't need PwdHash.
So that way, one password IS complete access to everything.
Yes, but at least that one password is not stored across a multitude of sites with varying security.
Aside from whatever security weaknesses the specific implementation has, it would be very inconvenient to use this unless it became standardized, as you wouldn't be able to use any browser that didn't have the plugin (like on your mobile device) for secure sites.
From the pwdhash page: "Occasionally, users want to login to their web accounts on machines where they cannot install browser extensions (e.g. at Internet cafes). In this case users can connect to our web site https://www.pwdhash.com where they are presented with one of the following forms, depending on whether their browser supports clipboard operations via script."

(Of course, copy and paste is not exactly convenient in mobile browsers, but it's at least possible on most newer ones.)

I wish I could install it on Firefox 3.5. Or should I turn off the extension compatibility check and try it out?