Correct.
They should spend more time to develop better management of passwords.
I would like to have a poem generator that generates unique and easy to remember poems, that can be used as master passwords.
They should spend more time to develop better management of passwords.
I would like to have a poem generator that generates unique and easy to remember poems, that can be used as master passwords.
Yes they are more painful to type. But long alpha numeric passwords with symbols are painful to type too.
Ideally we'd want such pass-phrases to have 128 bits of entropy, although I suspect just getting to 64 bits would be a big improvement on most general password/pass-phrase schemes (Does anyone know of research into how stretching a 64 bit key to 128 bits affect real-world crypto-systems? Assuming a "slow"/"good" stretching/key derivation scheme, and the use of a salt, I suspect it might be "good enough").
Now, some napkin math: The English alphabet consists of 5 vowels and 21 non-vowels; we can generally start words with a combination of the two, and some words (like "two") start with a sequence of two non-vowels. 5 * 21 = 105, with another 23 combinations we can reach 128. That's 7 bits for a single word out of a list of 128, identified by it's first two letters. To reach a minimum of 64 bits, we need 10 such words, or perhaps two sentences of 5 words each (Note that there is little help in captilaization here, that single bit doesn't really move the needle on the number of words we end up needing -- considering the difficulty of remember which of a set of random letters are capitalized).
Creating word lists of 128 words is quite easy - we could have some lists of substantives, verbs, adverbs etc - it might even be possible to find words that rhyme. So we could probably construct pass-phrases like: "[The] small red car drives quickly", "huge scary horse hides sadly" -- which we can input/verify/use in their "short form" encoding 70 bits: "smrecadrquhuschohisa". To get through password "security" tests, we might say that the first letter is capitalized, and a period added on the end (possibly we should throw a number in there as well, but hopefully three letter classes are enough for most "checks"): "Smrecadrquhuschohisa." or "1Smrecadrquhuschohisa."
Note that the point here is that the words can be generated just as we generate symmetric cipher keys - from a random 70 bit number -- and are just as secure (or insecure) as such keys are. The rule-based capitalization and punctuation doesn't add any entropy -- it's just there in case we need to get accepted by legacy systems.
Also note that, even this simple scheme, requires a lot of typing for just 70 bits. At 7 bits per word, we'd need 19 words to go beyond 128 bits - which probably means it would be just as well to go for four five-word sentences.
Now, the point of all this, is that if you want a poem that lets you remember 128 bits of random data, you have some work cut out for you, if you want this system to be based around simple generating rules, that are obviously without any bias (no more bias than what you find in generating symmetric (session) keys).
I've been playing with this idea for a while, but so far it seems ~64 bits is a likely "wall" for easy to implement correctly, in a way that's easy to use.
Other options is to use a graphical input - with emoji or images in a grid, possibly with the added factor of colour (eg: red/white, blue/white, black/white etc) - but 128 bits of information turns out to be a lot to encode!
The better solution when length is capped is hashing and something like base64 encoding.
Regarding KDF:s, they only add as much difficulty as you put work in. If you put in 256x the work, you get log2(256) = effectively 8 extra "bits" of entropy worth of bruteforce resistance. You want 80-100 bits in the long term.
Yes, but can you quantify how much entropy is in those letters and spaces that are chopped off? In an obvious way? I agree that there is (probably) no harm in and of itself of including them in the password, but as mentioned in the sibling comment, the main point is to have it obvious what level of entropy is encoded. As the word tables and system is designed to be public, the don't encode more secret information, except in the case where the attacker isn't attacking you/this system specifically. But an attacker could, so I'd rather avoid the false sense of security that the handful of extra bits full English words would add. And as mentioned, it adds to the difficulty of typing in the password correctly, from memory.
> The better solution when length is capped (...)
While systems might cap length when storing/validating passwords, the capping here is for the human part of the system. How and what to remember, how and what to type. It's a user interface/interaction improvement over other password schemes, not strictly a technical scheme.
Basically the problem it tries to solve, is how can we easily remember n numbers of random data, and communicate it to our various systems, both new, and legacy.
A) I don't think you read the encoding bit correctly: the secret is the first two letters, the extension to words is just a mnemonic device - a crutch for the human brain. Typing a (full) paragraph blindly will be too error prone. While one could argue that it would increase the entropy, the basic idea is to have a trivially obvious lower bound on the entropy a password encodes.
B) let's say we change the method to just generating a random 0 or 1. Would you feel comfortable using this password as a Base to derive a 128 bit aes key, and telling the world about your password scheme?
[ed: I'm not sure if a good work-factor+a decent salt would be a reasonable basis for deriving 128bit keys. You'd want it to be hard to "walk the keyspace" that your 64 bits + salt extend to. In the trivial case of passwords "0" and "1", you'd need a long salt - but you'd also have to do all that work yourself every time you need your key. As I understand it, 64bit is still "quite big" -- I'm just not sure if it's big "enough" in this case. I'm thinking no - but I'm not certain.]
26 letters (that can be caps), 10 digits, roughly 32 symbols[1], and we might want to add space, for roughly 95 characters that might be reasonable to use for a password. I personally think this is a little high - good luck typing in the backtick in your login password in a Japanese locale etc. But if we say 95, that's (a littler more than) log2(95)~6.569 bits per character. So you'd need a 10-character string for 64 bits. And that string would look like: jIg@T>L+b_
While that can be memorized for typing, how long will you be able to remember it? What if you have to change it semi-frequently? And how about the 128 bit version?: %w}Wf#O"]#z@eAwI@\'gK
[1] '!"#$%&'()+,-./:;<=>?@[\]^_`{|}~' + * (on the outside due to hn formatting)