3 ms·

Does this affect the security of password-protected Office documents as well? I think there's lots of valuable information locked up with simple Excel or Word p

Does this affect the security of password-protected Office documents as well? I think there's lots of valuable information locked up with simple Excel or Word passwords.

tialaramex 3y ago
I expect not, Office last century previously had a very simple password scheme (broken essentially instantly with modern tools) and then a poor one (take a couple seconds to break typical passwords) before I think settling on a more modern design where brute force isn't practical for a decent password. It's possible they threw that away to use this approach but seems unlikely
- jabroni_salad 3y ago
  They are still using AES256 with 16 bytes of salt as far as I know. It's good security but it's not like you can rate limit attempts or anything and password bruteforcing has gotten pretty good lately. You also have to wonder if there isn't a skeleton key of some kind hanging around, too.
  - meepmorp 3y ago
    Aren't 256 bit AES keys computationally infeasible to crack? Assuming the rng and implementation aren't broken somehow, the best known attack is 2^254.3 operations to brute force a 256 bit key.
    - mplewis9z 3y ago
      You’re assuming the key is 256 random bits, which is almost certainly untrue for a human-rememberable password. The 16 bytes of salt are public, and AES is designed to be _fast_, so this scheme is horribly insecure for password-based security.
      - tialaramex 3y ago
        It doesn't need to be 256 random bits. The chosen design smears the key, so if your password has 10 bits of randomness, my best attack is to try those 10 bits worth of passwords. That is practical to try, but if I have enough bits you might as well just guess keys, which you can't do, so, game over. It does need to be actual randomness, so "NameOfCorp" won't work to protect Corp's documents, but people need to get over it, we just can't make that work, a fancy stretching algorithm won't make terrible passwords good. "Correct Horse Battery Staple" type passwords maybe are improved with stretching, you can imagine 44 bits of randomness might be feasible for a serious attacker, while maybe if it was 1000 times harder they'd give up. But in most cases humans don't need to memorize these passwords at all, so we can use a 32 hex digit password for example which is more than enough even though it's not 256 bits.
        mplewis9z 3y ago
        > 44 bits of randomness might be feasible for a serious attacker, while maybe if it was 1000 times harder they'd give up My back-of-the-napkin math[^1] says that, on an AMD Ryzen 7 1800X (released in 2017), brute-forcing 54 bits of entropy in AES-256-GCM takes an average of about 2.6 months. That’s on (pretty outdated) consumer hardware, not GPUs, specialized ASICs, or parallelizing across different machines. That’s considered outrageously insecure in the infosec world - anyone with a few thousand dollars to spare on cloud computing can crack. > a fancy stretching algorithm won't make terrible passwords good A properly tuned password-hashing algorithm like Argon2 should take about 1 second per hash, and can be configured to eat as many cores and memory as you expect the attacker to have/you feel like dedicating to hashing. Let’s assume you dedicate 2 cores to each hash (a relatively conservative value) - that same 54 bits of entropy now takes an average of 71 million years to crack[^2]. You’d literally be better off trying to brute-force the full AES-256 key space, after the key derivation step (which is the whole point of Argon2 and similar algorithms). Dangerous advice like you’ve just spouted is against every single password hashing guideline out there - please trust the cryptographic community, they do in fact know what they’re doing when designing algorithms (or at least they know better than you). [^1]: 2642 MBps per core (https://calomel.org/aesni_ssl_performance.html https://calomel.org/aesni_ssl_performance.html) = 165 million 128-bit blocks per second per core = 1.32 billion 128-bit blocks per second -> 6.82 million seconds to try 2^53 combinations (50% chance of success) = roughly 2.6 months [^2]: 1 hash per second per 2 cores = 4 hashes per second -> 2.25e15 seconds to try 2^53 combinations = 71 million years
    - jabroni_salad 3y ago
      That math challenge assumes that the attacker will want to try all keys. In reality, they are going to run rockyou.txt against it and just move on if that isn't sufficient.

Does this affect the security of password-protected Office documents as well? I think there's lots of valuable information locked up with simple Excel or Word passwords.

tialaramex 3y ago

I expect not, Office last century previously had a very simple password scheme (broken essentially instantly with modern tools) and then a poor one (take a couple seconds to break typical passwords) before I think settling on a more modern design where brute force isn't practical for a decent password. It's possible they threw that away to use this approach but seems unlikely

jabroni_salad 3y ago
They are still using AES256 with 16 bytes of salt as far as I know. It's good security but it's not like you can rate limit attempts or anything and password bruteforcing has gotten pretty good lately. You also have to wonder if there isn't a skeleton key of some kind hanging around, too.
- meepmorp 3y ago
  Aren't 256 bit AES keys computationally infeasible to crack? Assuming the rng and implementation aren't broken somehow, the best known attack is 2^254.3 operations to brute force a 256 bit key.
  - mplewis9z 3y ago
    You’re assuming the key is 256 random bits, which is almost certainly untrue for a human-rememberable password. The 16 bytes of salt are public, and AES is designed to be _fast_, so this scheme is horribly insecure for password-based security.
    - tialaramex 3y ago
      It doesn't need to be 256 random bits. The chosen design smears the key, so if your password has 10 bits of randomness, my best attack is to try those 10 bits worth of passwords. That is practical to try, but if I have enough bits you might as well just guess keys, which you can't do, so, game over. It does need to be actual randomness, so "NameOfCorp" won't work to protect Corp's documents, but people need to get over it, we just can't make that work, a fancy stretching algorithm won't make terrible passwords good. "Correct Horse Battery Staple" type passwords maybe are improved with stretching, you can imagine 44 bits of randomness might be feasible for a serious attacker, while maybe if it was 1000 times harder they'd give up. But in most cases humans don't need to memorize these passwords at all, so we can use a 32 hex digit password for example which is more than enough even though it's not 256 bits.
      - mplewis9z 3y ago
        > 44 bits of randomness might be feasible for a serious attacker, while maybe if it was 1000 times harder they'd give up My back-of-the-napkin math[^1] says that, on an AMD Ryzen 7 1800X (released in 2017), brute-forcing 54 bits of entropy in AES-256-GCM takes an average of about 2.6 months. That’s on (pretty outdated) consumer hardware, not GPUs, specialized ASICs, or parallelizing across different machines. That’s considered outrageously insecure in the infosec world - anyone with a few thousand dollars to spare on cloud computing can crack. > a fancy stretching algorithm won't make terrible passwords good A properly tuned password-hashing algorithm like Argon2 should take about 1 second per hash, and can be configured to eat as many cores and memory as you expect the attacker to have/you feel like dedicating to hashing. Let’s assume you dedicate 2 cores to each hash (a relatively conservative value) - that same 54 bits of entropy now takes an average of 71 million years to crack[^2]. You’d literally be better off trying to brute-force the full AES-256 key space, after the key derivation step (which is the whole point of Argon2 and similar algorithms). Dangerous advice like you’ve just spouted is against every single password hashing guideline out there - please trust the cryptographic community, they do in fact know what they’re doing when designing algorithms (or at least they know better than you). [^1]: 2642 MBps per core (https://calomel.org/aesni_ssl_performance.html https://calomel.org/aesni_ssl_performance.html) = 165 million 128-bit blocks per second per core = 1.32 billion 128-bit blocks per second -> 6.82 million seconds to try 2^53 combinations (50% chance of success) = roughly 2.6 months [^2]: 1 hash per second per 2 cores = 4 hashes per second -> 2.25e15 seconds to try 2^53 combinations = 71 million years
  - jabroni_salad 3y ago
    That math challenge assumes that the attacker will want to try all keys. In reality, they are going to run rockyou.txt against it and just move on if that isn't sufficient.