101–110 of 124 posts
Earlier quoted context omitted.
Having to check my e-mail for each login is a major annoyance. Perhaps something like SQRL[0] may help. [0]: https://sqrl.grc.com/pages/what_is_sqrl/
More annoying than passwords?
Earlier quoted context omitted.
Entropy and min-entropy are properties of distributions , not of individual samples from those distributions. So there's no meaning to "the entropy of each chosen password".
A single password represents a distribution of possible bit values for each byte within it. The password itself is a distribution of characters used within the password. In fact, the author's article makes this very point, which is why I pointed out the logical flaw in the thinking. I'll reduce N to 6 for simplifying the author's absurd example but it can expand to any N. If we take the argument to hold that you roll…
In principle, you could estimate a password's strength by the order in which a cracker would be expected to guess it. But that's a pain, depends on the password cracker being used, and can change at any time. Also, it's not "entropy", which is a well-defined mathematical concept and is what the linked article is about.
Entropy is supposed to be a bound that even if the attacker knows your generation method, they won't be able to do better than brute-force search. For this, the author is correct that min-entropy or a similarly conservative measure is the right one; though for the most common (uniform) generation methods this is the same as Shannon entropy.
Entropy of the set of characters used in your password (well, sets don't have entropy, but let's say of the uniform distribution on that set) isn't the same as entropy of password generation mechanism, because the attacker might have more information. For example, if he knows (or correctly guesses) that your password is a dictionary word, then this is super helpful information that isn't captured in the entropy of the bytes.
Earlier quoted context omitted.
Entropy and min-entropy are properties of distributions , not of individual samples from those distributions. So there's no meaning to "the entropy of each chosen password".
Despite that slight misuse of terminology, the point stands: the article talks about estimating the entropy of a distribution used for generating a password, but the important thing is the “distribution” an attacker is using for guessing the password. A single password should instead be treated as a sample from a (plausible) attacker’s distribution, and the complexity of that password can be used to estimate the size…
Of these two approaches, a high-entropy generation method gives more confidence. It gives a mathematical strength "guarantee": if you design and follow the method correctly, then an attacker, whether or not they know the generation method, is mathematically unlikely to guess your password quickly no matter what order they guess in. "Guarantee" is in quotes because of course the attacker could get very lucky or the user could get unlucky (eg generate a uniformly random 8-character string and it happens to be "password"), and also if there's eg an implementation flaw then your guarantee isn't worth the pixels it's printed on.
By contrast, zxcvbn has no guarantee, because it doesn't use a huge curated dictionary and generation mechanism that the attacker is likely to use. So in addition to missing well-known passwords like "correct horse battery staple", it will miss bad passwords related to current events.
Earlier quoted context omitted.
I find this way less convienent because my password manager automatically fills in my username and password. So I can log in with 1 click. With "magic links" I need to enter my email (which may be autocompleted, but it is much less reliable) and then wait for the email to show up. (Assuming I have my email available.) Also email is never going to be reliably "instant" spam techniques include bouncing an email and wai…
My experience with password managers is that it works that well on about 10% of websites/apps, and I have to resort to copy and paste from the password manager everywhere else. It's not that great
Earlier quoted context omitted.
I find this way less convienent because my password manager automatically fills in my username and password. So I can log in with 1 click. With "magic links" I need to enter my email (which may be autocompleted, but it is much less reliable) and then wait for the email to show up. (Assuming I have my email available.) Also email is never going to be reliably "instant" spam techniques include bouncing an email and wai…
My experience with password managers is that it works that well on about 10% of websites/apps, and I have to resort to copy and paste from the password manager everywhere else. It's not that great
But even copy-paste isn't too difficult. Roughly as much clicking as the magic-link solution in my experience.
Earlier quoted context omitted.
A single password represents a distribution of possible bit values for each byte within it. The password itself is a distribution of characters used within the password. In fact, the author's article makes this very point, which is why I pointed out the logical flaw in the thinking. I'll reduce N to 6 for simplifying the author's absurd example but it can expand to any N. If we take the argument to hold that you roll…
I don't understand your argument at all. Why does an attacker need to try a full set of characters? Real attackers try from dictionaries or password generation methods (eg dictionary + numbers, dictionary + dictionary + number + symbol, etc), and "password" is one of the first passwords they'll try. They do this because they don't know exactly how you generated the password, but due to password leaks, they do have a…
I'm well aware. How does this help the attacker attacking the higher-entropy string I outlined?
How difficult is it for an attacker to attack a password consisting of four lower case english dictionary words?
If you run some of these permutations through John, you'll see how long it takes just to generate even quick broken hashes like MD5 versus using something that is a long string of essentially type-able byte data.
> Entropy is supposed to be a bound that even if the attacker knows your generation method, they won't be able to do better than brute-force search. For this, the author is correct that min-entropy or a similarly conservative measure is the right one; though for the most common (uniform) generation methods this is the same as Shannon entropy.
I'm not sure who has dictated that this is supposed to be how entropy is used for password management. Do you have any references here? Because otherwise it looks like it's still the author and yourself assigning a set of rules to something that doesn't actually apply in the real world and doesn't represent how things are used in practice.
My entire point is that the author has taken an incredibly narrow definition of what entropy must be applied to (only to the distribution of the overall set of characters used in the example) and how it must be used in this circumstance, and argued against that.
Where it falls down is this: The entire purpose of using entropy as a measure of difficulty of cracking a password is precisely the character set approach. If you were to type "password" into any system employing a Shannon entropy analysis on the set of characters required to generate that password, you would at worst have to generate 26^8 combinations. Dictionary attacks are good because they reduce that from around 208 billion to about half a million. 208 billion is not a high enough number, and these systems will tell you it's weak. Smarter ones will probably alert you that it's a dictionary word as well.
If the issue is that people are "misusing" the term entropy for passwords here, that's fine but that's a different article (and I'd still disagree).
Earlier quoted context omitted.
More annoying than passwords?
Of course. I can type a password from memory, or it can be auto-filled by the browser/password-mgr. No interruptions before signing in. Having to open email inbox means switching tabs/context.
When will we stop using passwords?! They are an elementary school kid “secret club” game taken way, way too far. They are totally broken. Nobody can come up with and remember good passwords. Nobody can store passwords securely. 100% busted. Instead of continuing to debate what makes a good password, we need to put our energy into better techniques altogether! No more shared secrets! Let’s talk about one-time codes, a…
> Nobody can store passwords securely. 100% busted. [...] Let’s talk about > one-time codes One-time codes rely on a password: either it is stored in your 2FA App, or they rely on your email password, or they rely you storing a password somewhere else. OTP rely on stored secrets. You can make these secrets be much larger than the humble password and call them "private keys" : > asymmetric key cryptography, hardware t…
In other words, something you have (until you forget it). But also something you have to give to someone else after which all security bets are off.
A private key is also something you have (until you lose it). It is not something you ever have to give to anyone else. If you protect it with a password you don’t have to give that password to anyone else.
Big difference!
Earlier quoted context omitted.
The point of public key cryptography is that there isn't a shared secret.
While technically correct, a private key will usually need to be encrypted to provide adequate security. From the user point of view, they will still need to remember the password to unlock this private key.
Earlier quoted context omitted.
While technically correct, a private key will usually need to be encrypted to provide adequate security. From the user point of view, they will still need to remember the password to unlock this private key.
Further to this point, the shared item is moved to a public key and the infrastructure to facilitate communication. Such that it is not a panacea. Getting away from trust in the system is... Likely you will envision a system to register your key. And then you have to have a bootstrap to authenticate to this system. Probably a password.