Hacker News new | past | comments | ask | show | jobs | submit login

I love it. The practical side of me, however, would recommend increasing the name space a little bit and adding checksums; human memory is not perfect, and having built-in error correction would help immensely.



Great idea. Thanks. I need to find some extra space for fitting in a version number anyway, to preserve backward-compatibility.


I've been thinking about something similar to this for secure passwords. And your haikus neatly demonstrate both the challenge and viability. I was thinking of encoding as a phrase, but keeping the two first letters of each word in a 256-word set unique, so that a phrase could be used for memorization, but you'd "only" have to type the two first letters of every word. But 16 characters for 64 bits of entropy is still pretty long (for password entry) -- and ideally you'd want 96 or even 128 bits. Especially for passwords/pass phrases that are used to derive/protect encryption keys (the goal being to avoid having the entropy of the password as the weakest link. There are still other challenges with passwords, of course. Eg: key loggers).

I'd also thought about having a generic library, that could be used for things like representing hashes/fingerprints etc (think: an alternative to the ssh key ascii art).

While I'd considered poetry (especially using rhyming dictionaries) -- my main idea so far is to just construct grammatically well-formed sentences. With a limited vocabulary, it should be easy enough...

And as touched upon in this post, it might make a nice alternative for verbally communicating 64-128 bits of random data -- say reading out a password while someone across the server room types it into a console.

[edit: eg, using a random haiku:

    Hoarse dunes and slim germs
    gulp pure ripe foul dead bland sole.
    Firm trees bleed short heads.
This would become: "hoduslgegupurifodeblsofitrblshhe" (ignoring the and). If anyone wonders why you'd not just type in the whole thing: it's hard, even for a skilled typist, to get something so long, exactly right, when typing blind. And obviously even the short form here strains typing ability. But then again, how many can say with confidence that their passwords hold 128 bits worth of entropy? With a one-to-one mapping between word-lists (or equivalently sets of two leading characters, and a random N bit integer, assuming the integer is as random as your other secret/session keys -- it's trivial to demonstrate a lower bound for the entropy of such a password]

[edit2: I should add that I considered adding a standard transform to the final password: capitalize the first letter, and terminate with a punctuation mark. It would add nothing to the entropy of the password, but might allow an "insecure" lowercase-only password to pass inane "strength" requirements, by mixing three character classes.]


I made this a while back. :) http://rmmh.github.io/abbrase/

An interesting fork: http://bcaller.github.io/abbrase/

Some comments: https://news.ycombinator.com/item?id=8059210

Letting users pick their passphrases from a list sacrifices a few bits of entropy in theory, and in practice gives much more usable mnemonics.

I'm not sure grammatical models are a definite improvement over Abbrase's naive bigram method -- part-of-speech constraints can make sentences more awkward than freeform associations.

Having 128 bit passwords feels like overkill. I'm not sure on the precise threat model for sites, but the worst case of someone getting your password hash should be ameliorated by not reusing passwords between sites and the password being stretched properly.

If you're actually deriving encryption keys directly from passwords, you'll probably be okay with 60 bits of password entropy and 30 bits of memory-hard stretching.


Interesting.

I should add, that my idea was to publish an RFC-style standard that worked both ways (from the password to number and back again) -- which is why mapping two letters to 256 bits was nice: it makes for short word lists. It might even, with some care, allow for localizing the actual word list to at least some other European languages (we're really only concerned with the two first letters).

> Having 128 bit passwords feels like overkill.

I agree. However, as a user can't be sure sites properly stretch passwords, I'd say 64-bits feels more comfortable.

For use-cases where one are protecting keys, it'd be good if the password wasn't the weakest brute-force target with too large a margin. Obviously, if you can manage to get 64-bits into a password suitable for everyday use, chaining two together for the (presumably rarer case of) master passwords should be viable.

But even 64 bits is a lot of entropy to be typing in, no matter how you encode it :-/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: