Simple solution to the password reuse problem | Hacker News Reader

Simple solution to the password reuse problem

grisha.org

23 pointsgtrubetskoy53 comments

This is a prime example why you should leave crypto to the experts. This method in no way should be used.

Imagine one of your hashes leaks. A cracker can notice your password was a hash of something and just run their normal attacks on it for leaked password + salt hashes. They don't know the salt exactly, but it will likely be part of the leaking site's url.

Now the cracker can generate your password for any account you have. Great.

Please use Keepass or another password safe to generate pseudo-random hashes. These were designed by experts.

But a cracker can't "notice" that your password was a hash of "something" without knowing exactly what that "something" was, because the output of the hash is pseudorandom and isn't distinguishable from a random string.

Sure, they could assume every random-looking cracked password is a hash and try to crack each one, and conceivably discover your master password that way, but depending on your master password's entropy, that can be as unlikely as you need it to be. And the whole point of something like this is that you can use all your memory remembering an extremely high-entropy master password, rather than a large number of medium-entropy single-use passwords.

When we do an analysis on something like this we assume the method of encryption is fully known. Otherwise it's called 'security through obscurity'[1]. If this method got popular at all crackers would automatically start checking all hash-like passwords.

I'm also completely ignoring what would happen if that site were compromised. A little javascript snippet could just forward all passwords to the hacker's server. Even a browser extension could be compromised if it auto-updates. These are implementation details though that could be fixed/worked around.

[1]https://en.wikipedia.org/wiki/Security_through_obscurity

That is why the pass phrase is required to have a lot of entropy. Even if you know the algorithm used, you're going to have to guess the pass phrase to verify that. And the pass phrase is harder to guess than most people's passwords are.

Aside from the implementation details that you've raised, I'm not finding as many flaws as I expected in it.

So put that high entropy pass phrase in Keepass and don't worry about a cracker getting access to all your accounts through a misplaced hash. With all these sites getting attacked you have to assume anything you put in a website is public knowledge.

I mean, using a password safe is no more inconvenient than having to go to a website. When set up, the safe can even be a one click auto-fill deal. I don't see any reason to take the added risk.

I'm not recommending this approach. I'm merely saying that it isn't as trivially broken as one would think.

And SHA wasn't designed by experts? :)

From the comments:

> I do something similar via a shell

> echo "masterpassword gmail" | md5

Please do not do this, md5 is not a cryptographic hash and is relatively trivial to reverse. Ie; is possible for someone to discover your 'masterpassword' given any one of your passwords generated via this method.

If one of your passwords is leaked then it is possible for an attacker to brute-force this to find out a list of possible 'masterpassword foo' combinations (although not knowing the length increases the search space).

If one of those foos is 'gmail' for your gmail password then it is game over.

Even if your foo is not similar to the service, if the attacker is able to get 2 of your passwords then the search-space is much smaller (looking only at the overlap of the reverse of both md5 functions).

This may not be relevant if you only take a 'random' sub-sequence from the generated md5, thus only disclosing part of the hash to the attacker.

People might not share my sentiment but I think doing this is fine. Yes, all your points are true, but they require the attacker to single you out specifically, and try and figure out your process. Frankly, unless you're a very important person to warrant someone singling you out, an attacker is going to go after the countless easier targets that do not require personal attention.

One assumption in security / cryptography is that the process is always known, otherwise it is security by obscurity.

This is still better than password reuse as the plaintext doesn't disclose your other identified without further effort, however the users should be under no illusion of bullet-proof security.

Ahem, md5 is impossible to reverse. The weakness of md5 is related to the ease with which one can find inputs that result in a specific hash, which does not apply in this case.

I should have said 'possible to find the reverse'.

For a given length it is possible to find all the inputs that could generate a possible hash relatively easy (cheap compared to other one-way-hashes).

Considering this requires you to go back to a single source to retrieve your passwords, I fail to see what this offers over tools such as 1password. I am aware that passwords are not actually being stored anywhere, but ultimately you are doing the same thing: copy and pasting. 1password with a sufficiently strong passphrase to protect the keychain (is it even called that?) is just as realistically impossible to crack.

It does occur to me though, that it could be turned into a browser plugin. I'd have no idea whether that would be an improvement over anything, though.

Either way, it is an interesting thing.

And just to play devil's advocate, there is the possibility that someone hosting this code theoretically could add an event handler to surreptitiously send them the content of the text fields by ajax, so there is the issue of implicitly trusting the host even if the passwords aren't stored anywhere.

So, host a known-safe copy of the code somewhere in the cloud with https access (e.g., one of your appspot apps). Then you'll know where to find it whenever you need to regenerate a password.

Of course, you'll still need to trust that the machine you are using isn't logging your keystrokes. You face that problem in any case, but it's worse if all your passwords are exposed instead of only one or two.

You probably should have two or three pass-phrases. E.g, one for banking and brokerage, one for other business use, and a third for fora, social networking, etc.

Agreed. And given that my blog is not SSL, I wouldn't trust this particular implementation at all. But the point is that you can have your passwords without ever saving anything on disk. Even if you don't have 'net access, you could regenerate your passwords by having access to any SHA implementation, the code to do this is trivial.

I use a similar scheme, and one definite advantage has been being able to access my passwords anywhere, on any device with a web browser, without worrying about synchronizing something to my phone, work computer, etc.

This is a great, straightforward idea. But the main problem with these kinds of approaches is that the system breaks down if you ever need to change any of your passwords. There's also the problem of sites with password restrictions like alphanum-only, or maximum of 8 chars, which are unfortunately things a practical password scheme would need to deal with. I think KeePass (or one of the alternatives) paired with a browser extension is still the best solution out there right now.

That's easy to work around - use google2, google3, etc as the keyword. A more "industrial" implementation might actually store secure hashes of past/void passwords and increment a nonce until we get a "new" one. The underlying crypto is still sound.

Passwords produced are only ten or eleven characters long - pretty good, but they could be longer.

Edit: A recent Ars Technica article[1] suggests an 11-character minimum. Ending with 0 or ! like this doesn't really add a whole character to the search space.

[1] http://arstechnica.com/security/2013/05/how-crackers-make-mi...

So make it 11? A SHA-512 in Base-64 encoding is 42 characters long, use all of them if you'd like. Chain them, and get infinite length passwords. My post is a just a demonstration of the technique which requires no disk storage or network transfer :)

If we're using master passwords, why not go all the way and use a password file program like KeePass?

I can instantly generate passwords of arbitrary length and complexity and I do so for each new account I create.

I suppose the difference here is that there is no password file, like with KeePass. You are re-generating all your passwords with the knowledge in your head.

So instead of generating the passwords once, I do it over and over? I'm not sure that's a win.

Because realistically, I'm still going to copy and paste the end result.

Just use LastPass (or one of the alternatives, like 1password). Sure it takes a few minutes to set up and learn to use, but once that's done, it will be far easier and less error-prone than something like this. Plugins for all major browsers, as well as a couple of top mobile ones, apps for the major mobile platforms... password reuse is a solved problem.

Sure, it sends data over the internet, but data is 256-bit AES encrypted on your local machine, and then is sent via SSL on top of that. So even if someone could get a hold of the data you're sending, they couldn't do anything with it.

I finally started using LP a few months back after having it on my to-do list for a year, and I only wish I'd made the leap sooner.

So, I built something almost identical for myself[1] but lately I've been switching to 1Password. Why? Essentially, it's difficult/impossible to create passwords for all the weird/stupid requirements people think up (no more than X characters, no symbols, require at least 2 symbols, etc.) without storing information about the passwords themselves somewhere. And once you have infrastructure for storing information about passwords, well, you might as well just encrypt the password itself and store that.

In the end, it was fun to build and a cool proof of concept, but the problem it solves is solved more robustly and just as securely by existing solutions.

[1] http://mawud.com

The requirements could be integrated into the generation scheme. As long as it is reproducible, you are fine. Essentially something like a pipe:

"pretty long passphrase I use for everything" + "bank" | bcrypt | only numbers | length 4

Nice!

This is pretty cool. One improvement that would be nice to see is strength checking on weak "spatial" passwords: I was able to eventually get it to say my password was strong just by walking down the keyboard (e.g., "qwertyioup..." or "qazxswedc...").

You can see exactly how it is calculating the strength (and it includes spatial patterns; enough length and you do get some entropy out of it) here: https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.ht...

Same here. I typed in a word and kept typing without numbers until it registered from very weak to strong. But a simple brute force would make short work of such a "source" password.

'I like to eat boogers' is strong. Not against a dictionary attack, I don't think.

It may actually be pretty strong - you have 5 words out of, let's say 2000 "frequently used English words" (totally picked the 2K number out of the air, and "boogers" is probably not as common) - you have 31,840,279,800,048,000 possibilities (according to wolfram-alpha "2000 choose permutations of 5").

This wasn't about password strength calculation - this is really a question to the maintainers of https://github.com/lowe/zxcvbn.

I've been using http://passwordmaker.org/ for years to do the same thing.

I was too. The only reason I stopped using it is because I stared needing to enter my password in things other than Firefox. Not to mention I got tired of having to remember which websites needed which character limitations. I never could get it setup to do this automatically.

http://crypto.stanford.edu/PwdHash/

https://www.pwdhash.com/

This! Also http://wijjo.com/passhash/

There are (Cross) Browser Extensions running the algo on your computer so can log in directly with your passphrase. You can have the JS code offline or in a Dropbox. There are apps using the algorithm on iPhone and Android. No need to rely on a single website. No need to type/copy'n'paste cryptic passwords. No need to rely on the Browser's password storage. So much better.

This is what I use (although I am partially transitioning to Dashlane to try them out). It's fairly ingenious to use your passphrase and the domain to generate the hash, and the browser extensions work very elegantly.

I made something similar for myself that I've been using:

https://c-cr.it/new/

(The "new" version is a few in-browser algorithms instead of my original PHP backend) It's a pretty decent scheme, I think, for most people who are unlikely to be the specific, individual target of some crafty password thief. The technical details of my implementation are described on the about page:

https://c-cr.it/new/what.html

I think it would be simpler and easier to remember one password to your non-cloud based password program such as Keepass. That way, you can create not only random passwords, but random usernames (since usernames are one key to unlocking your account).

The disadvantage of this approach is that your more restricted on where you can login to services (since you'll need your password manager there, and a trusted computer to run it on).

Unfortunately, usernames are very often reused, especially when a site simplifies matters and asks for your email address. This is an especially attractive bit of info because an email address and an easy-to-remember password can net you their email account (so you can delay discovery of your escapades) as well as every ecommerce site where they have an account. Gift cards for everyone.

SuperGenPass does something similar as a bookmarklet (http://supergenpass.com/) There is a convenience vs security trade-off (an attacker could find the master password with javascript), which the author discusses in the FAQ.

Wouldn't this problem be solved by making an extension that runs in a sandbox instead of a bookmarklet that runs on the same page?

This is actually pretty clever, simple, and seems pretty secure. I'm not sure about attack vectors if someone has many of your passwords, but this seems good enough for most people.

I don't think we should consider the "good enough" case when security is involved. (some) password vaults are secure and yet have a straightforward interface.

Having seen the first implementation of this idea years (5+) ago, I never understood why not simply use a password manager? Now you can have them synced with your mobile.

I introduced something to HN a while ago, but received almost no feed back. okay.jpeg: http://www.longpw.com

This is exactly what SuperGenPass is, only the latter is much more convenient.

eh.. zxcvbn-async.js is returning content-type text/plain instead of application/javascript (chrome gives me an error about this, firefox doesn't) and sha.js is returning a 404.

oops... not sure what to do about the chrome error, but sha.js thing should be fixed, thanks!

both fixed now. i was hoping to not have to host those locally, oh well...

It works fine for me now.

Condolences to your server though...

Reply on news.ycombinator.com