4 ms·

Maybe I'm missing something, but that doesn't make any sense to me. I'm not critiquing the use of low entropy passphrases (though if very low then they become u

• crpatino 13y ago
  > ... and there are methods of generating memorable passphrases that you can actually measure the entropy. No there are not! The minute you publish your method, the measure of the output's entropy stops being relevant. Your security theoretically relies on the input's entropy, which is likely to be much smaller. But in practice, an actual attacker no longer produces brute force attacks in the blind. He actually has to model the desired target's strategy, and produce an attack suited to that. When you are modelling your attacker, you may consider that he may consider the aforementioned method, along with any other methods his model of his intended target (which may be you, personally, or some abstract model of either you or the average X's user, both based on demographic data) allows for. For this reason, using programming language syntax instead of natural languages might be either a decent idea or a terrible idea, based on how accurate the attacker's model of yourself will predict you are likely to do so. In my personal case, given this conversation, it will be an extremely poor strategy, if I choose to model my threat model as a targeted attack (I am leaving plenty of evidence that I am likely to do something like this, on a public forum)... but if I happened to have this 'my-little-pony' alter ego, not traceable to my professional persona, it would be somewhat solid strategy, (at least in the sense than few bronies are likely to choose such type of strategy). And if the risk model is that of an attack on a compromised password database of thousands of not ipsec-sophisticated users, the strategy will be as good as any other for the same ((alphabet size) * (passphrase length)).
  • tga_d 13y ago
    >The minute you publish your method, the measure of the output's entropy stops being relevant. Your security theoretically relies on the input's entropy, which is likely to be much smaller. What? If we're applying Kerckhoff's principle, then the mechanism literally never generates entropy. The only place it can ever come from is the source, which means the only thing your methods can do is either keep the same amount of entropy or reduce it (anything else would require another source of entropy). This comes straight from the math: self-information can't increase using mappings alone, but it sure as hell can decrease. It's these decreases that are difficult to measure. >He actually has to model the desired target's strategy, and produce an attack suited to that. In theory, yes, but in practice, machine learning does that for you. The point is, a patterned method like using code will require very long passwords compared to just using diceware (or hell, just using /dev/random to pick words from your dictionary file) if you want them to both have the same amount of entropy. The only other argument that can be made to the contrary is that something other than entropy determines password strength, which isn't true if we assume a sufficiently advanced adversary (of which I consider machine learning algorithms + a gpu/asic cluster to be). Since the only things that really go into how "good" a password is is usability and security, and diceware passwords are probably just as or more memorable than code snippets, again, I don't see the advantage of the latter in any case.