Hacker News Reader

Comment by biot | Hacker News Reader

However, this IS a master password only with a salted hash added on top. From the FAQ it uses a phrase like "Tubby loves tacos!facebook" runs it through SHA1 and spits out Facebook's password. Someone who shoulder surfs your keyphrase can now use this technique to generate passwords for any site, whereas using something like Password Safe or the various other password storage methods would need to both shoulder surf your master password as well as obtain your encrypted password file.

View on HN

It's not only been done, "master password with a salted hash" is broken. If I can convince you to log in to face.com ("Tubby loves taco's!face"), I can find the hash of "Tubby loves taco's!facebook". This is because SHA1("Tubby loves taco's!facebook") is just SHA1-sub(SHA1("Tubby loves taco's!face"), "book"). See "length extension attack" for more details.

More generally, hash functions are collision-resistant, but the output is not (pseudo)random.

That's easily fixable by using an HMAC, as the author should have done in the first place.

Does this attack actually work, by the way? Don't you need to also be lucky with the padding and have the plaintext be an exact multiple of the bytes in the round?

Yes, HMAC is (one of) the right solution(s) here. On the other hand, do you trust the rest of the program if the author gets this wrong?

The attack does work, see e.g. http://www.vnsecurity.net/t/length-extension-attack/. This example suggests that any padding should not matter; and even if it does, being able to mount this attack on a substantial part of visitors is bad. (Sorry for being vague here - I don't have the time to look at this properly now.)

What you point out here is a very implausible attack to perform. Not only would you need to know that the user is using this scheme to generate a password, you would also have to know how he generates the salt (maybe they use fb, or FACEBOOK or facebook.com). But then you'd have to be able to trick him into signing into some website with a name that's a subset of the aforementioned salt. Hell, even using FQDNs would fix the "problem" in most cases.

For the average user, a scheme like this would be a vast improvement over their "123456 is secure enough, no?"-scheme.

Putting the face/facebook start at the front of the passpphrase string would fix that. So would an HMAC.

Reversing the order is not a good idea: read http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-has... for a readable introduction (summary: it works, but it maximally exposes you to any possible problems.) Just use HMAC, especially if you want to use SHA1 - which is not broken, but no longer above suspicion.

I agree that this scheme is probably fine as long as you're the only one using it and nobody is specifically targeting you; but if you're going to go to use a password manager (which would be an improvement in general - as you point out, "123456 is secure enough, no?" is prevalent), why not use a good password manager?

I'm not sure I follow your argument. The user would provide a plain SHA1 hash (or half of one) as their password (either hex or b64 encoded). How do you plan to get the sentence out of that hash? You have no idea what the underlying sentence is. What am I missing... could you elaborate?

Edit: I think I understand what you are getting at now... what you suggest would require the use of a fully encoded SHA1_Pass generated password (not halves) and the user would have to be using a "sentence + salt" scheme where the sentence always stays the same in order for this to work in real life, right? Also, there are many other ways to use SHA1_Pass where your proposed attack would not work at all. What if they put the salt someplace in the middle? Or used entirely different sentences for different sites? How would you know?

Your edit is basically correct, but note that moving the salt doesn't help all that much (see http://news.ycombinator.com/item?id=2432014).

It's not hard to imagine some practical difficulties for an attacker. But if you're writing this kind of software, you should get it right.

HMAC interferes with my design goal of being simple and easily reproducing SHA1_Pass generated passwords on multiple platforms when needed. SHA1 was a design decision to meet that goal. To carry out your attack, you would have to:

1. Somehow know the user used SHA1_Pass with full encodings and a consistent "sentence followed by salt" scheme.

2. Somehow trick the user to log onto your malicious site using a SHA1_Pass password (or gain access to the password in some other way).

3. Somehow produce a different hash that worked on a different site the user visits.

All of that is possible in theory, but not likely to occur. SHA1_Pass generated passwords are not perfect, but they are not "wrong" either (or improper) as you seem to imply. The source is ISC licensed and available to you and others to edit. Feel free to do so.

BTW: I think I know you from @misc.

> BTW: I think I know you from @misc.

If you're talking about misc@openbsd.org, yes.

Yes, OpenBSD misc.

So for HMAC. I've looked at it more and I think your point is valid (even tho it's not very likely to occur). I may add it as an option. I don't really need to use it in the traditional sense (shared secret, integrity, etc) I only need it to better resist the length-extension attacks you point out.

Can the key and the message be the same? I'd rather not prompt the user for a base sentence and a key/salt. But I can't find anyone using HMAC where the key and the msg are the same. I thought you might have some insight into this.

Edit... here is a traditional HMAC (I think):

echo -n msg | openssl dgst -sha1 -binary -hmac key | openssl enc -base64

Here is how I would need to use it without changing functionality:

echo -n msg | openssl dgst -sha1 -binary -hmac msg | openssl enc -base64

I'm not sure this is proper from a cryptographic perspective.

I got advice from some guys on sci.crypto about how to potentially handle this. Some smart guys on that list. So I'll probably incorporate HMAC as an option for those who wish to use it.

Reply on news.ycombinator.com