4 ms·
a) The part you quoted stipulated "...in the absence of any sort of opsec failures this implies...". You might be surprised to learn that some folks _can_ run r
by simoncion 4y ago
a) The part you quoted stipulated "...in the absence of any sort of opsec failures this implies...". You might be surprised to learn that some folks _can_ run really, really tight opsec.
b) The first two sentences of the next paragraph read:
> Or does it? Let's go into what LUKS is doing in the first place
Someone who doesn't know in detail the math of how this stuff works but _does_ know how to run tight opsec could very reasonably assume that now fairly long passwords can be brute-forced. That's like, the entire point of the article, innit? Describing how this almost certainly _wasn't_ an attack on the password, but almost certainly an attack on the mechanisms that use that password as an input to crypto.
- mjg59 4y agoI don't want to overstate this - it's absolutely possible that the password was obtained through some other mechanism. But a weak password (even if it's 20 characters long!) as the input to PBKDF2 is something that can plausibly be broken in a reasonable timeframe using realistic hardware, and there's a really easy way to fix that, and people who care about this should protect themselves.
- simoncion 4y ago> ...it's absolutely possible that the password was obtained through some other mechanism. +1 To be clear, the person I was replying to was all like "You _idiot_. Obviously the plaintext of the guy's password was in the possession of the attacker!", when the primary (if not the entire) _point_ of the article was to set up and answer the question "Well, what if it _wasn't_? Is it possible using default settings to brute-force a password?".