4 ms·

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

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.

StavrosK 16y ago
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?
- JoachimSchipper 16y ago
  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/ 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.)
deleted 16y ago
[deleted]
deleted 16y ago
[deleted]
- deleted 16y ago
  [deleted]
Tharkun 16y ago
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.
- JoachimSchipper 16y ago
  Reversing the order is not a good idea: read http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/ 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?
16s 16y ago
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?
- JoachimSchipper 16y ago
  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 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.
  - 16s 16y ago
    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.
    - JoachimSchipper 16y ago

StavrosK 16y ago

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?

JoachimSchipper 16y ago
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/ 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.)

deleted 16y ago

[deleted]

deleted 16y ago

[deleted]

deleted 16y ago
[deleted]

Tharkun 16y ago

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.

JoachimSchipper 16y ago
Reversing the order is not a good idea: read http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/ 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?

16s 16y ago

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?

JoachimSchipper 16y ago
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 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.
- 16s 16y ago
  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.
  - JoachimSchipper 16y ago