3 ms·

Any time your password uses a pattern, it by definition has low entropy. I don't know of anyone that has calculated the entropy of code, but I'm guessing it's e

• crpatino 13y ago
  Theoretically, you are of course right. In practice, it is a tradeoff. If you have already decided that the password for this particular computer/application/website does not entail the use of password DB, it is a good option. You are on purpose selecting a low entropy password, just one whose underlying pattern is hard to guess by a would-be attacker. I would not use this kind of approach for any account that makes it obvious that I am a programmer (aajem, HackerNews)... but for the general population, the attacker is not likely to target YOU, but the average user of such and such site.
  • tga_d 13y ago
    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 useless) - as I said in my blog post: ... a passphrase is most useful if you can remember it and use it. While having 100 bits of entropy is something nice to shoot for, one has to look at their threat models and decide if it’s worth it. Is having a passphrase 8 words long really the price you pay to keep hackers out of your lolcats.rus account? Maybe yes, maybe no. The truth is, for most web accounts, 100 bits of entropy is overkill. My point is that there is no advantage of relying on a passphrase you don't know the entropy for, since it's usually lower than what you thought, and there are methods of generating memorable passphrases that you can actually measure the entropy. I guess I just don't understand why one would ever let their security rely on the incompetence of a potential attacker, instead of relying on the math, when they're both basically just as easy.
    • 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.