Haddock: Built because I want web apps to make passwords fun | Hacker News Reader

Haddock: Built because I want web apps to make passwords fun

stephencelis.com

30 pointsstephencelis23 comments

The name is unfortunate. Haddock is Haskell's documentation generator, which may be familiar to the same techie crowd.

Also - something I learned from working at a big company: For secure memorable passwords, it's better to take a phrase and abbreviate it than to take a couple words and concatenate them together with numbers and symbols. So from "Haddock: Built because I want web apps to make passwords fun", you might get "H:Bb1wwa2mpf", which looks like random noise to any password cracker yet is still reasonably memorable to anyone who remembers the original phrase.

You can get a lot of use out of song lyrics for this, say "Bbmap,dmc2tlbtlwd" from American Pie or "Yccatyl,bycnl" from Hotel California or "Mhfjl2b" from Comfortably Numb. Long, line noise, completely unrecognizable - yet you'll never forget the underlying lyric.

It's unfortunate that Haskell's Haddock wasn't Haddoc or Hadoc. "Haddock" made the most sense to me as a name for a blathering password generator (with those nods to the Marx Bros. and Hergé). I've named the command-line utility "ha-gen", though, to avoid collisions.

And "H:Bb1wwa2mpf" may be more secure than a similar-length haddock password, but its pseudo-acrostic nature is much less digestible to your average user. Meanwhile, with a few potential modifications I outlined, haddock would still be more memorable _and_ just as secure:

http://news.ycombinator.com/item?id=537562

The point's to remember the phrase, not the password. :-) The password is trivially reconstructible from the phrase.

Actually - since any good programmer won't put a maximum length on their passwords, I wonder if it'd be better to get users into the habit of picking really long phrases as passwords. Type in "Haddock: Built because I want webapps to make passwords fun" in the password prompt. Maybe that'll just take too long to input though, each time you want to login.

I have vague memories of acrostics I formed for study in college...and not-so-trivially muddling them ;)

I still agree with you that this kind of phrasal munging is a good method, but I also think haddock has the slight, memorable edge :)

Haddock seems like a brilliant way to generate passwords with a great memorability to length ratio, but it's not clear to me that they have a great memorability to security ratio.

Haddock uses the UNIX wordlist with a known algorithm for password generation: words = %W(#{random_word} #{random_symbol}#{random_word}) if I'm reading the source right. It seems like it's reducing the search space drastically for a gain in memorability that is difficult to quantify. Might be a win, but might be a loss.

But I don't really know this stuff so well-- any real crypto folks care to comment?

It is reducing the search space drastically: Word (about 30% of the total length, and might be capitalized) + number (15%) + symbol (1 character) + word (50%).

The search space for a length n is: 2 x 26^(n/3) x 10^(n/6) x 30 x 26^(n/2) = 60 x 26^(5/6 x n) x 10^(n/6) = 60 x 10^(5/6 x n x log10(26)) x 10^(n/6) =~ 6 x 10^(1.17914n) x 10^(0.16666n) = 6 x 10^(1.34581n)

So that's about a 6 followed by 1.5n zeroes of search space for length n, approximately. Using only 100 characters of the ASCII code tables, you have a search space of 10^(2n) possible passwords, which is about n/2 orders of magnitude larger than Haddock's search space.

Disclaimer: I'm a HS student, no crypto folk, so the above might be wrong, but it's basic combinatorial stuff. And that's just theory, in practice, with just "password1", "letmein" and "123456" for a dictionary attack, you can hack into like 3% of the accounts of a site that doesn't use Haddock.

Edit: Oh, I didn't even think of this: THE WORDS ARE ALL VALID ENGLISH WORDS! That makes hacking in a lot easier.

This first version is really just a quick emulation of Apple's version. There are a few simple security improvements that could be made without reducing memorability too much (dropping vowels, toggling case, swapping vowels for numbers that resemble them, randomizing where the symbol comes in, and perhaps making the number of symbols variable, as well), all of which I may put into the next version.

In the end, though, these passwords should be "secure enough" for most purposes, and should be generally more secure than the password of your average user. Using haddock to generate temporary passwords will hopefully just encourage users to be better about passwords in general.

Yeah, a good point. For a lot of web services, the security doesn't need to be all that good.

Also, it may be that giving users memorable passwords beats letting them make their own, whereupon many of them choose weak ones.

I'm no security guru but with a little sensibility on the website itself could lessen the security risk from dictionary attacks. If you allow 3 login attempts before requiring a captcha, or set a maximum number of attempts per hour, giving your users more memorable passwords shouldn't be too much of a risk.

A very good point, though I would encourage something closer to 25 or 100 login attempts. Don't punish clumsy users for having a secure password, but prevent brute-forces by all means.

25 or 100?

First attempt: quick typing, conscious mistake.

Second attempt: quick typing, wrong password again.

Third attempt: okay, I'll type it in carefully now. Wrong password.

Fourth attempt: oh, yes, that was my Yahoo! password. Remembers password and enters it cautiously, because he/she knows that he has a maximum of 5 login attempts.

Five are enough for me. Or at most 10. 100 seem ridiculous. How often does it happen that you mistype your password 99 times and get it right on the one-hundredth, before you're tired of being shown the "wrong password" message and click the "forgot password" link?

I'm only suggesting an implementation that is transparent for the user. 10 would probably be just fine, but 25 would be closer to an impossible situation without significantly increasing the odds of a successful attack.

Yes, that's the best way to prevent account hijacking, in my opinion. Or block the IP for 30 minutes after 5 failed logins, that renders any dictionary attack terribly inefficient.

Better to switch to a captcha. Banning might provoke DoS attacks.

Hmmm... Using the UNIX word list for password resets may lead to passwords like "oversexed#asshole". May not be the best password to send to your users.

I would suggest trimming the wordlist before use, if you plan to use it for handing out passwords.

Yeah. I addressed that in the post. The odds are low, though, and come on, most users would have a good laugh ;)

Nope. There is no such thing as an average sense of humor. At a company I worked for we got a lot of crap for sending out passwords like "invisible*negro" and "murdered#pakistani". The odds are not as low as you think.

Hell, we got crap for adding the tags "Russian" and "Jew" to people who were, in fact, from Russia and Jewish.

Agh! Good point! Some kind of regex should definitely be included.

The odds are low, though, and come on, most users would have a good laugh ;)

Not very reassuing to anyone with a business. It wouldn't be hard to filter potentially offensive passwords, especially given that false positives don't matter.

I suppose I should provide more warning in the documentation itself. It is an easily resolvable issue, though, as you point out.

I use song lyrics as passwords. I pick a song, then take the first letter from either each word, or each line (depends what works best).

gotta start stopping my own password generating algorithm based on temperature, first name of the first person pops in my head, and crazy md5/sha hash of whatever something like

45john5hit

completely solid.

Reply on news.ycombinator.com