5 ms·

They can be transmitted encrypted over https and still readable by the server. It doesn’t make a ton of difference if you encrypt client side, whatever the clie

• unethical_ban 6y ago
  In the best of systems, client-side encryption/hashing occurs. In the mediocre, they are sent to a server-side app and hashed without being analyzed, and stored in their hashed/salted state. No good service analyzes your password server side, much less for the offensive nature of your password. edit: Okay, I suppose there can be some analysis of password strength server-side before hashing at rest. Still, it should not be analyzed for the social acceptance of its content.
  • jakear 6y ago
    > In the best of systems, client-side encryption/hashing occurs What does this protect against?
    • jlokier 6y ago
      - Accidentally recognisable passwords in logfiles, tracefiles, network dumps, HTTP request traces, HTTP proxy coredumps. - The actual password being known to an attacker who can read everything but the client-side state. - The password has a high chance of being used at other sites as well, so preventing attackers from knowing the password on this site, also prevents them from using it to attack other sites. But: - It does not protect against determination to get an authorization token, which is the client-side hashed password that the server sees. - It does not protect against an attacker who can modify the code which the client receives and runs.
      • jakear 6y ago
        So instead of the attackers/admins seeing your password, they see a string of characters that, when delivered to the server along with your account id, grants access to your account. Hm.
        • lixtra 6y ago
          They could send you a challenge salt that you hash together with your hashed password and send back as a response. So that string is valid only once.
          • hunter2_ 6y ago
            "Nonce" is probably the word you're looking for.
          • 0x0 6y ago
            Doesn't mitigate the fact that this type of scheme turns the hashed password into the equivalent of THE cleartext password. It's usually compromised/dumped server databases you want to protect against.
            • jakear 6y ago
              No, the outlined scheme is actually correct. If there’s a call/response aspect, then the hashed nonce+password is not “the cleartext password”, it’s “the cleartext password for that particular challenge”, which makes it useless for other auth attempts, which would have different challenges.
              • 0x0 6y ago
                The reason passwords are hashed is to prevent them from being usable to people who gain access to the backend database. If the hash in the backend is the only thing you need to calculate the salt challenge, then it is the equivalent of a plaintext password. Someone with access to dumps of a compromised backend database can use the hash directly.
                • jakear 6y ago
                  I think we’re making different assumptions about how the challenge/response would be implemented. I agree that if there’s a shared secret and the nonce is simply appended to it and hashed, it’s a poor design.
  • syrgian 6y ago
    I've used systems in the past that analyze them server side for similitude with previous passwords of your own (or perhaps only your last password? if that's the case, requiring current password would be enough, no need to store it in plain text). They might also want to check it against a list of most used passwords.
    • luckylion 6y ago
      I vaguely remember Microsoft doing this, e.g. "You cannot use your old password and just add a number to it", but I might be mistaken and it may have been only blocking setting the password to a previous one.
      • hunter2_ 6y ago
        All they'd have to do to safely achieve that is, when you initially set your password to "foo" they will store 11 hashes (foo, foo0, foo1, foo2...). Then when you change your password, it's hash cannot equal any previous hashes.
        • duskwuff 6y ago
          Or, even simpler: if the plaintext of the new password ends in a number, try stripping (or decrementing!) that number and see if either of those hash to the same as the stored old passwword.
          • hunter2_ 6y ago
            Oops, yes of course! And then it can be any incrementable (or not) character.
• stickfigure 6y ago
  Lots of people in this thread are trying to come up with theoretical ways this could be relatively benign. Look at it from the state's perspective: You have nearly unlimited control over your population, but you still can't read their minds. Given how common password reuse is, why wouldn't you track everyone's passwords in case you want access to data stored on systems that aren't already integrated into your sweeping surveillance system?
• ViViDboarder 6y ago
  For some use cases. For others like, a password manager, it matters because the plain text is used to decrypt the database.