4 ms·

To start with, never abbreviate passwords. You're making it more ambiguous, creating more possible sentences that could match the same output. The better solut

To start with, never abbreviate passwords. You're making it more ambiguous, creating more possible sentences that could match the same output. 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.

e12e 10y ago
[ed: apologies if the first section come off a bit hostile, that wasn't/isn't my intention - also see my sibling comment. I appreciate all feedback!] 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.]
e12e 10y ago
> You're making it more ambiguous, creating more possible sentences that could match the same output. 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.

e12e 10y ago

[ed: apologies if the first section come off a bit hostile, that wasn't/isn't my intention - also see my sibling comment. I appreciate all feedback!] 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.]

e12e 10y ago

> You're making it more ambiguous, creating more possible sentences that could match the same output. 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.