Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't Store Passwords, Generate Them When Needed

16s.us

Post reply on HN
Print view View original

51–60 of 64 posts

Re: Don't Store Passwords, Generate Them When Needed

#51

Post by tjogin »

swaits wrote: post #25

I've been using HMAC-SHA1 as a basis for my passwords for awhile. I call my algorithm "Passy". It works like this (pseudocode'ish). # generate our HMAC hash = generate HMAC-SHA1 (facebook.com, passphrase) (String) hash += SHA1(hash) # just need the extra length # transform hash into a Passy passy_chars = "ABCDEFGHabcdefgh23456789#$%*+=@?" passy = "" foreach octet in hash (starting with MSB) passy += passy_chars[octet…

I use a mnemonic algorithm to generate site specfic passwords instead, but this is _really_ nice. Do you happen to have the source on github, or would you mind putting it up there?

Re: Don't Store Passwords, Generate Them When Needed

#52

Post by swaits »

tjogin wrote: post #51
swaits wrote: post #25

I've been using HMAC-SHA1 as a basis for my passwords for awhile. I call my algorithm "Passy". It works like this (pseudocode'ish). # generate our HMAC hash = generate HMAC-SHA1 (facebook.com, passphrase) (String) hash += SHA1(hash) # just need the extra length # transform hash into a Passy passy_chars = "ABCDEFGHabcdefgh23456789#$%*+=@?" passy = "" foreach octet in hash (starting with MSB) passy += passy_chars[octet…

I use a mnemonic algorithm to generate site specfic passwords instead, but this is _really_ nice. Do you happen to have the source on github, or would you mind putting it up there?

Sure, it's here: https://bitbucket.org/swaits/passyweb

It's not documented other than with comments, although I think the code is readable. You'll find test vectors in the source.

And, thanks!

Re: Don't Store Passwords, Generate Them When Needed

#53

Post by thirsteh »

thirsteh wrote: post #32

SHA-1 is insecure. Use SHA-256 or SHA-512.

Wonder why people are downvoting this. SHA-1 being insecure is not something that is up for debate -- it is fact:

"SHA-1 is the most widely used of the existing SHA hash functions, and is employed in several widely-used security applications and protocols. In 2005, security flaws were identified in SHA-1, namely that a mathematical weakness might exist, indicating that a stronger hash function would be desirable."

"Earlier this week, three Chinese cryptographers showed that SHA-1 is not collision-free. That is, they developed an algorithm for finding collisions faster than brute force. SHA-1 produces a 160-bit hash. That is, every message hashes down to a 160-bit number. Given that there are an infinite number of messages that hash to each possible value, there are an infinite number of possible collisions. But because the number of possible hashes is so large, the odds of finding one by chance is negligibly small (one in 280, to be exact). If you hashed 280 random messages, you'd find one pair that hashed to the same value. That's the "brute force" way of finding collisions, and it depends solely on the length of the hash value. "Breaking" the hash function means being able to find collisions faster than that. And that's what the Chinese did. They can find collisions in SHA-1 in 269 calculations, about 2,000 times faster than brute force. Right now, that is just on the far edge of feasibility with current technology. Two comparable massive computations illustrate that point."

"It's time for us all to migrate away from SHA-1. Luckily, there are alternatives. The National Institute of Standards and Technology already has standards for longer -- and harder to break -- hash functions: SHA-224, SHA-256, SHA-384, and SHA-512. They're already government standards, and can already be used. This is a good stopgap, but I'd like to see more."

Re: Don't Store Passwords, Generate Them When Needed

#54

Post by 16s »

JoachimSchipper wrote: post #37
biot wrote: post #4

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…

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 t…

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?

Re: Don't Store Passwords, Generate Them When Needed

#55

Post by cpeterso »

eli wrote: post #21

So, basically we've just recreated http://supergenpass.com/ which has been around for at least a decade. And I'm sure the idea is older than that. What happens when the generated password doesn't meet the strength requirements for the site (too long/too short, not enough/too many numbers, not enough "special characters")? Or when I'm required to change my password periodically?

SuperGenPass has a serious DOM vulnerability. The link has a live demo.

http://akibjorklund.com/2009/supergenpass-is-not-that-secure

The SuperGenPass UI is rendered within the DOM of the current page when you click the bookmarklet. The UI is where you enter your master password. And because the UI is part of the current page, any script running in the page can read your master password. Remember that script can be external too, as in advertisements or widgets of some kind.

Re: Don't Store Passwords, Generate Them When Needed

#56

Post by cpeterso »

ch0wn wrote: post #34

Another alternative is PasswordMaker. Works on hashes and provides local applications as well as browser extensions: http://passwordmaker.org

The last time I checked, PasswordMaker generated passwords using sites' top two domain labels ("example" and "com"). But for sites' with country code TLDs, PasswordMaker would generate passwords using "co" and "uk", thus sharing the same generated password for all .co.uk sites!

Re: Don't Store Passwords, Generate Them When Needed

#57

Post by JoachimSchipper »

16s wrote: post #54
JoachimSchipper wrote: post #37

Earlier quoted context omitted.

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 t…

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 genera…

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.

Re: Don't Store Passwords, Generate Them When Needed

#58

Post by 16s »

JoachimSchipper wrote: post #57
16s wrote: post #54

Earlier quoted context omitted.

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 genera…

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.

Re: Don't Store Passwords, Generate Them When Needed

#59

Post by beej71 »

tel wrote: post #29
ars wrote: post #13

Earlier quoted context omitted.

There are about 50,000 commonly used words in English. That means that each word has an entropy of about 15.6 bits. (Probably less since some words are far more common than others.) Using a typical 4 word phrase gets you about 62 bits of entropy. In contrast a password can select from a set of about 72 characters. i.e. 6.1 bits per letter. Using an 10 character password gets you about 61 bits of entropy. So they seem…

So they seem reasonably comparable... It would be nice to redo the calculation while accounting for how common each word is, and also that special characters are used less often in passwords. I know this was a rough estimate, but I think it is way, way off. Passphrases are not usually generated by random choice of English words but are instead a particular, meaningful English sentence. This means not only are you dea…

Bruce Schneier goes with 1.3 bits of entropy per character of general English text in Applied Cryptography.

> Anything with genuinely high entropy is by definition difficult to remember.

This wording bugs me a bit, but I'm not quite sure why. I think it has something to do with the time my friend's bank, which only issued random 4-digit PINs for their ATM cards, assigned my friend the PIN 4444. Theoretically, it was just as tough to guess as any other password, but it was really easy to remember.

Re: Don't Store Passwords, Generate Them When Needed

#60

Post by JoachimSchipper »

16s wrote: post #58
JoachimSchipper wrote: post #57

Earlier quoted context omitted.

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…

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

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

Post reply on HN