5 ms·

When the breach was announced, they revealed that they did not store the passwords themselves in plain text, but had a second store that did, so they could prev

• contravariant 8y ago
  This just goes to show that badly designed security measures can be worse than no security measures at all.
• crazygringo 8y ago
  Huh, that's actually... a decent-sounding intention. Is there any way to do that in a secure manner? Because a hash says nothing about the length of a password (and you certainly don't want to store the length, which would make the attack space much smaller)... so if passwords are anywhere, say, from 8-64 characters, then for each chat message you'd need to hash every possible consecutive string of characters for every possible window size separately, which if the hash is even remotely computationally intensive could possibly turn into too much -- especially if being done on the server instead of the client (in order not to expose the hash and salt). Is this just something it's not possible to protect against?
  • y7 8y ago
    Easiest way is to do it on the client. The client has the plaintext password anyway.
    • crazygringo 8y ago
      Good point. But is storing a plaintext password, even on the client, good practice? E.g. in a browser that uses a cookie with something like a session ID to make sure you're logged-in... is storing a plaintext password in localStorage considered a valid security practice? I would have assumed not, although it's certainly not close to as bad as storing it on the server...
      • xianb 8y ago
        if you store plaintext password on the client, you'd be one XSS attack away from potentially having a lot of passwords stolen - best practice is to have password in plaintext for a little as possible (there's some research on not transmitting the password at all but I don't think there's anything widely accepted like bcrypt is for password hashing https://en.wikipedia.org/wiki/Zero-knowledge_password_proof https://en.wikipedia.org/wiki/Zero-knowledge_password_proof)
        • UncleMeat 8y ago
          You are already one xss attack away from having your session stolen or having your credentials stolen or any number of other bad things. Passwords on the client are fine.
          • anoncake 8y ago
            Unless the user uses the same password for other things, which is extremely common.
  • judge2020 8y ago
    Storing the length is somewhat secure, as GSuite does it so administrators can audit who has strong passwords https://judge.sh/j0mMsLU.png https://judge.sh/j0mMsLU.png
  • xianb 8y ago
    anything that makes computation less intensive for you also makes it less intensive for a potential malefactor - it's just an inherent tradeoff. Rather than scan for password being contained in the message, something more reasonable to try would be to check if the whole message is the password since you can just plug that into the normal password hasher and run just one slower hash op
    • kiriakasis 8y ago
      or forbid password from having white spaces and only check at word boundaries