3 ms·

It's not different for encrypted data that obscures the content but not its size. I've written before about how you can sometimes infer the size of a password i

It's not different for encrypted data that obscures the content but not its size. I've written before about how you can sometimes infer the size of a password in a HTML form submitted over an otherwise fully secure, correctly implemented SSL (HTTPS) connection. I've also shown how you you can guess the general location on the earth encoded in GPS coordinates from the size of the textual representation of those coordinates alone. It's not rocket science to make this deduction, but it is, I think, nonetheless an under-appreciated aspect of consumer-grade encryption. See here if you want to read my findings https://guidovranken.files.wordpress.com/2015/12/https-bicycle-attack.pdf https://guidovranken.files.wordpress.com/2015/12/https-bicyc...

dspillett 9y ago
> I've written before about how you can sometimes infer the size of a password in a HTML form submitted over an otherwise fully secure, correctly implemented SSL (HTTPS) connection. Good catch. Interesting, but obvious once you think about it. Not really a danger for properly chose passwords/passphrases (the search space would still be too large for brute forcing) but it would highlight where a brute force attempt is worth trying. I might have to add an extra (hidden) input to all our authentication pages programatically filled with random characters up to a length of 1024 minute the length of the entered password.
- Terr_ 9y ago
  For extra paranoia, pad to a byte limit so that UTF-8 doesn't leak anything from it's fluctuating length. IMO if you don't need the entropy, it's probably easier to pad with some kind of "clearly not legal" character which is still visible when debugging, such as newlines.
  - dspillett 9y ago
    > IMO if you don't need the entropy You almost certainly don't, but my default for any security related value is "properly random" except where the randomness itself might give clues. That way around is less likely to result in a "kicking oneself" situation in the future!
    - Terr_ 9y ago
      The reason I'm suggesting a detectable padding is for a different "kicking yourself" scenario: What happens if some system ever doesn't strip the junk? Now you've got corrupt data, and its been corrupted in a way that you cannot reliably fix. In the case of hashed passwords, suppose the user entered "foo" but you stored hash("foo42156"). Now the user is locked out, and there's no way for you to fix it on their next login attempt, because you have no way of knowing how much of it was "real" anymore. In contrast, a deterministic system (like "pad with newlines to 256 bytes") allows you to take their next login attempt, validate it under the older method, and "upgrade" the hash to the correct de-junked version. It's not just passwords either: The issue of corruption also applies to all variable-length non-hashed sensitive data you might apply this scheme to. For example, security-questions, e-mail addresses, financial account numbers, etc.
      - dspillett 9y ago
        Valid point. In this case though the extra padding would be in a separate field that only exists to control the length of the POST request body - nothing should be looking at it in a way that would allow it in to corrupt other data.
        Terr_ 9y ago
        Ah, I was interpreting it as randomness/padding on a per-field, basis, ex: password = "foo2556019562042" # Example limit of 16 chars password_real_len = 3

dspillett 9y ago

> I've written before about how you can sometimes infer the size of a password in a HTML form submitted over an otherwise fully secure, correctly implemented SSL (HTTPS) connection. Good catch. Interesting, but obvious once you think about it. Not really a danger for properly chose passwords/passphrases (the search space would still be too large for brute forcing) but it would highlight where a brute force attempt is worth trying. I might have to add an extra (hidden) input to all our authentication pages programatically filled with random characters up to a length of 1024 minute the length of the entered password.

Terr_ 9y ago
For extra paranoia, pad to a byte limit so that UTF-8 doesn't leak anything from it's fluctuating length. IMO if you don't need the entropy, it's probably easier to pad with some kind of "clearly not legal" character which is still visible when debugging, such as newlines.
- dspillett 9y ago
  > IMO if you don't need the entropy You almost certainly don't, but my default for any security related value is "properly random" except where the randomness itself might give clues. That way around is less likely to result in a "kicking oneself" situation in the future!
  - Terr_ 9y ago
    The reason I'm suggesting a detectable padding is for a different "kicking yourself" scenario: What happens if some system ever doesn't strip the junk? Now you've got corrupt data, and its been corrupted in a way that you cannot reliably fix. In the case of hashed passwords, suppose the user entered "foo" but you stored hash("foo42156"). Now the user is locked out, and there's no way for you to fix it on their next login attempt, because you have no way of knowing how much of it was "real" anymore. In contrast, a deterministic system (like "pad with newlines to 256 bytes") allows you to take their next login attempt, validate it under the older method, and "upgrade" the hash to the correct de-junked version. It's not just passwords either: The issue of corruption also applies to all variable-length non-hashed sensitive data you might apply this scheme to. For example, security-questions, e-mail addresses, financial account numbers, etc.
    - dspillett 9y ago
      Valid point. In this case though the extra padding would be in a separate field that only exists to control the length of the POST request body - nothing should be looking at it in a way that would allow it in to corrupt other data.
      - Terr_ 9y ago
        Ah, I was interpreting it as randomness/padding on a per-field, basis, ex: password = "foo2556019562042" # Example limit of 16 chars password_real_len = 3