5 ms·

So let me get this straight. We currently consider it poor practice if passwords are stored for authentication purposes in anything but heavily salted PBKDF2, b

by Shank 7y ago

So let me get this straight. We currently consider it poor practice if passwords are stored for authentication purposes in anything but heavily salted PBKDF2, bcrypt, or sometimes scrypt. Yet it's okay to just send SHA256 unsalted hashes to web services for the purposes of verifying that those same SHA256 hashes aren't already stored? It's good that Google is encrypting these hashes, but come on, really? Surely there has to be a better way than just shipping off unsalted password hashes to a centralized location. Edit: Okay, unsalted scrypt for the password. Thanks for the clarification :)

dannyw 7y ago
In the infographic, they use Scrypt, I imagine with an expensive cost.
- aawc 7y ago
  https://cs.chromium.org/chromium/src/components/password_manager/core/browser/leak_detection/encryption_utils.cc?l=60&rcl=67e916763b91bda759b9370a9a89fb3e1c8a4cde https://cs.chromium.org/chromium/src/components/password_man... static constexpr size_t kHashKeyLength = 32; static constexpr uint64_t kScryptCost = 1 << 12; // It must be a power of 2. static constexpr uint64_t kScryptBlockSize = 8; static constexpr uint64_t kScryptParallelization = 1; static constexpr size_t kScryptMaxMemory = 1024 * 1024 * 32;
ReverseCold 7y ago
I'm assuming it's similar to the haveibeenpwned pwned passwords API? https://haveibeenpwned.com/API/v3#PwnedPasswords https://haveibeenpwned.com/API/v3#PwnedPasswords
- Shank 7y ago
  It...appears to be so? The infographic states that they "send a strongly hashed and encrypted copy of your username and password to Google." They explicitly mention that the username, not the password, is sent with a 3-byte hash prefix. They make no mention of prefixing the password in the infographic. In the linked paper where they discuss the tradeoffs and take blinding into consideration. They note that the protocol is that a client calls CreateRequest(u, p) which creates a Req that is then sent explicitly to Google. It appears to me that they consider the merits of sending a hash-prefixed password, but do not make it explicitly clear that the final solution sends a hash-prefixed password. I think that they would want to explicitly say that only a partial hash is sent to Google, if that were the case?
  - geogriffin 7y ago
    > ... do not make it explicitly clear that the final solution sends a hash-prefixed password I'm not sure if you're actually talking about something else, but the paper says: "Post-canonicalization, the server calculates a computationally expensive hash of both the canonical username and credential password... This 2-byte prefix—while leaking some bits of password material—provides the client with k-anonymity over the universe of all username and password pairs." IOW, the 3-byte hash prefix sent is of the username and password concatenated. (Note that Google seems to have added another byte to the prefix versus the paper).
    - Reelin 7y ago
      To add to this, hashed username-password material is leaked only by the first variant described in the paper. The second variant described only leaks hashed username material. They reportedly used the first variant during testing but have now switched to the second variant. They indeed appear to have increased the prefix from 2 to 3 bytes. This makes logistical sense though - with 4 billion items, a 2 byte address yields ~61k items per bucket (and thus sent to the client per request) while a 3 byte address yields only ~240 on average.

by Shank 7y ago

dannyw 7y ago

In the infographic, they use Scrypt, I imagine with an expensive cost.

aawc 7y ago
https://cs.chromium.org/chromium/src/components/password_manager/core/browser/leak_detection/encryption_utils.cc?l=60&rcl=67e916763b91bda759b9370a9a89fb3e1c8a4cde https://cs.chromium.org/chromium/src/components/password_man... static constexpr size_t kHashKeyLength = 32; static constexpr uint64_t kScryptCost = 1 << 12; // It must be a power of 2. static constexpr uint64_t kScryptBlockSize = 8; static constexpr uint64_t kScryptParallelization = 1; static constexpr size_t kScryptMaxMemory = 1024 * 1024 * 32;

ReverseCold 7y ago

I'm assuming it's similar to the haveibeenpwned pwned passwords API? https://haveibeenpwned.com/API/v3#PwnedPasswords https://haveibeenpwned.com/API/v3#PwnedPasswords

Shank 7y ago
It...appears to be so? The infographic states that they "send a strongly hashed and encrypted copy of your username and password to Google." They explicitly mention that the username, not the password, is sent with a 3-byte hash prefix. They make no mention of prefixing the password in the infographic. In the linked paper where they discuss the tradeoffs and take blinding into consideration. They note that the protocol is that a client calls CreateRequest(u, p) which creates a Req that is then sent explicitly to Google. It appears to me that they consider the merits of sending a hash-prefixed password, but do not make it explicitly clear that the final solution sends a hash-prefixed password. I think that they would want to explicitly say that only a partial hash is sent to Google, if that were the case?
- geogriffin 7y ago
  > ... do not make it explicitly clear that the final solution sends a hash-prefixed password I'm not sure if you're actually talking about something else, but the paper says: "Post-canonicalization, the server calculates a computationally expensive hash of both the canonical username and credential password... This 2-byte prefix—while leaking some bits of password material—provides the client with k-anonymity over the universe of all username and password pairs." IOW, the 3-byte hash prefix sent is of the username and password concatenated. (Note that Google seems to have added another byte to the prefix versus the paper).
  - Reelin 7y ago
    To add to this, hashed username-password material is leaked only by the first variant described in the paper. The second variant described only leaks hashed username material. They reportedly used the first variant during testing but have now switched to the second variant. They indeed appear to have increased the prefix from 2 to 3 bytes. This makes logistical sense though - with 4 billion items, a 2 byte address yields ~61k items per bucket (and thus sent to the client per request) while a 3 byte address yields only ~240 on average.