PwdHash | Hacker News Reader

PwdHash

pwdhash.com

46 pointsjamesjyu28 comments

See also SuperGenPass (http://supergenpass.com/) and YPassword (http://ypassword.espozito.com/)

I like this approach. It doesn't require anything to be stored on your machine, thus you don't need to worry about backing up or syncing a password database, and you can login from anywhere.

It constantly amazes me that SuperGenPass hasn't caught on more. I don't use it for critical stuff (finance and email), but it provides a decent level of security for the less important stuff.

And http://passwordmaker.org/ (website down right now?) which I think supports more platforms than either of those. I use the Firefox/Chrome extensions and one of the [not so great] Android apps

I'm definitely an advocate of password generators rather than managers

It worries me that they seem to by implying that, e.g., MD5 and SHA-1 are impossible to reverse, when my understanding is that that isn't the case.

"Do not reveal anything about the input that was used to generate it" seems to be too strong a claim, though I hope someone will tell me differently.

Edit: Never mind, I see that you clarified what technology they use further down.

No hash is impossible to reverse but I think the strength of these systems is that the final password isn't something you need to remember. It can be as long and as complex as the website allows. Even weak hash functions like SHA-1 are unrealistic to reverse when the search space is big enough, i.e. enough characters

Well, the relevant search space when reversing a hash is the space of original passwords, and you do have to remember your master password. The attack to worry about with these systems is a website taking your generated password and maliciously reversing it to reveal your master password, not that someone will steal your hashed password from a database where it'll have been hashed again and stored securely, and then reverse it twice to reveal your original master password.

Their FAQ seems to say that they salt with other data before hashing, so they should at least be safe from precomputed lookup tables. I don't know how feasible it'd be to crack a hashed, salted password, but they'd probably be better off using blowfish or one of the other algorithms from the "Storing Passwords Securely" article which is now on the front page [1].

And I'm not sure why they mention using l33t-speak to protect your password from being reversed. That's just bizarre. The information on their website makes me worry that they may not know what they're doing, though maybe I'm just misinterpreting it.

[1] http://throwingfire.com/storing-passwords-securely/?utm_sour...

Funny how people laugh at LinkedIn for using SHA-1 and then recommend using password generators that use one iteration of MD5 of master password.

Yes, as @tlrobinson suggested me, I should use bcrypt instead of SHA1. At the time I created ypassword there weren't any bcrypt js code. There is one now, and this will be my next update.

In fact, I tried to port scrypt to js once. Reading the article about scrypt it felt not so hard to achieve. But I was afraid to introduce implementation error because some parameter aren't specified as clearly as I would have liked in the article.

How safe is it? If everyone started using this, couldn't password crackers adapt? In the recent LinkedIn leak for example, instead of looking for sha1('password'), they could just look for sha1(PwdHash('password'))? Or am I misinterpreting how it works?

I haven't checked what the hash function and length used in PwdHash is but I use PasswordMaker which is kinda the same thing except you can specify exactly how the hash is generated from your master password. Because you don't have to remember the hash it can be as long as the website allows. If you use say.. 12+ characters of SHA-256 with alpha/numbers/symbols then it's probably going to take hackers at least a few years to find your master password.

That's correct, although with some variants you specify charset and length so there end up being tens of possibilities (lcase? ucase? digits? symbols? length=8,10,12,16...) rather than just one. The idea is that you use a passphrase that's reasonably secure, so that it cannot be brute forced.

I used to use a similar password hasher browser extension, and I think it's fine as long as the seed passphrase is sufficiently secure. However, now I prefer keepass/lastpass/1password with random passwords. Not having to type in the passphase as often makes it easier for the average person to use a more secure passphrase.

I tried using something similar for managing my passwords (basically base64(hmac-sha256(site-mnemonic, masterkey))).

I found it had 2 shortcomings:

- As others mention, if your masterkey gets compromised it's very difficult to reset it (you have to change your password everywhere).

- Many websites have stupid limitations on passwords: must be at most X chars long, must or must not contain this and that character...

So not only do you have to remember the per-service "salt" but you also have to find workarounds for the password limitations and remember them. So I just gave up on that and use KeepassX now.

I started to created ypassword to manage many different password on many different websites. The main principle is mainly the same as yours. The formula is (mostly)

    password = base64(sha(site,masterKey,number))

I added the number once one of my password was compromised and I wanted to update it. Using this number it is not so difficult to update to resolve most stupid limitation on password. Almost all my password are good without using this parameter.

Considering the compromised master key, if it is compromised, shouldn't you in the end replace all your password for any password storage system? Unless you are pretty sure your keychain datas weren't accessed?

Concerning KeepassX I believe this is more secure than the "generate using your master password + website". But for now I continue to use my generated password simply because I find it hard to synchronize all the passwords on all platform. I don't like to use Dropbox or any "cloud" equivalent system to synchronize my keychain encrypted file.

Using the generation method you generally don't need to "remember" anything other than your login. And at most you have to remember login + length of the password + format (b64 or hexadecimal) + number. But this is generally not the case. And these data can be shared publicly with a reasonable risk that your password won't be cracked.

I haven't (as most people) found the best way to manage my password in the most secure way. But actually the generation scheme feels like a good enough system.

So what happens when your master password gets exposed? You get to go to every single site and change your password? How do you even know which sites you have accounts?

I think I'll stick with 1Password and completely random passwords. F.ex. with LinkedIN, I just need to change one password (and I have a database of passwords telling me where I have accounts, comes in handy too).

Speaking of LinkedIN, how would you change your password there? (since password = salt (based on domain name) + hashing function + master password; how do you change it?!)

The inability to change password without a new master password is imho very good point, which renders these kind of systems unusable. I'm not sure how that issue could be fixed without resorting to a (centralized) database.

This is one problem I encountered while using YPassword. My MobileMe password was compromised, then to change it, I simply added a parameter (the number of the password).

The new password is then

  hash ( masterPassword . url . number )

So now you need to remember a) masterPassword and b) the number. Basically, two passwords. That seems backwards to me... or am I missing something?

How does this work if you want to use a different machine?

My per-site hash is only salted with the site's name. Hence, there is no state stored on my machine.

Personally, I use (and prefer) LastPass to this approach.

There is no local machine state, so you can just load pwdhash.com (or supergenpass.com) and compute your password hash from there.

Note that it's based on MD5, which is somewhat unfortunate, if unlikely to be consequential in practice.

I use pwdhash for all my passwords. So technically I don't know any of my passwords.

I use it with the Chrome extension - http://code.google.com/p/chrome-pwdhash/. There's also a FF extension.

I've been using oplop for awhile, which I think is pretty similar. It's great!

https://chrome.google.com/webstore/detail/eifkoemjpnnbdmcoge...

This thread mentions already four other similar systems. There are probably lot more of them too. Has anyone done or seen indepth comparisons of them?

What about sites that use a different URL for logins and signups, like signup.live.com and login.live.com? Does it fail there?

When I tried it the generated password was always 2 characters longer than what you type in. Is this dependably so?

no, this depends on the implementation, and the length of the password you used.

It's worth noting that there's a pwdhash Android app, though not authored by the pwdhash.com creators.

Reply on news.ycombinator.com