5 ms·

And top of that, password should NEVER be stored to database

• junon 3y ago
  Well, not in plaintext.
  • klyrs 3y ago
    That's why you hash the password with an SQL built-in hash function. For security! But the password is still in plaintext inside the query so you can retrieve it from the logs for... security? (I joke, but 20 years younger me, self-teaching php and security etc? Who knows what she'd think of this)
• eddd-ddde 3y ago
  It's normal for them to make it to an executed SQL query.
  • duskwuff 3y ago
    No, it isn't. If a user's password leaves the web application in any form other than a hash, something nonstandard and probably bad is going on.
    • Wingy 3y ago
      Hashing can be done in a stored procedure. Maybe the organization decided that it's better for the DBA to handle hashing. Nonstandard maybe but not necessarily bad.
      • duskwuff 3y ago
        > Hashing can be done in a stored procedure. [...] Nonstandard maybe but not necessarily bad. No, it's unambiguously bad. You're transmitting a cleartext password to a system which doesn't have a business need to know it, and which wasn't designed to process secret data. There's a substantial risk that the database may leak that data in some unexpected way, e.g. by logging it when an error occurs or by showing the parameter in a process list. Worse, a stored procedure can potentially be covertly modified to store or exfiltrate the password while hashing it.
        • junon 3y ago
          To be clear, this only improves security if the user reuses passwords.
        • Wingy 3y ago
          That's true, the hashing should definitely be done as early as possible. "As early as possible" is interesting. It could be done on the client, however you need to actually have the hash to check if a string hashes to the same as it because of the salts embedded in the strings. Using an algorithm without salting would allow you to hash the password on the client then allow arbitrary 32 (or however long your hash digests are) character strings on the server as a password equivalent. This would also protect from a misconfigured or malicious server logging unhashed passwords.
          • duskwuff 3y ago
            > It could be done on the client No, that's actually too early -- if you let the client hash the password, you're vulnerable to a "pass-the-hash" attack where the client submits a hash without knowing the password. There are protocols like SRP and other PAKEs which allow this to be done securely, but it's uncommon for them to be used in web applications.
            • Wingy 3y ago
              My reasoning was that if you can capture the hash, you could have also captured the password but that doesn't account for a situation where the database is compromised.
    • berkes 3y ago
      Hashing is hardly ever done client side. Most often server side, which is fine, because it's not the same as "storing plain text". In fact, if you rely on client side hashing, you are not only making the app a lot less accessible (it will only work with JS enabled), the security is worse, because now you are publishing a salt to the client. Or you are working with unsalted hashes which is hardly better than just plain text. SSL is what protects passwords in transit. Not some JavaScript client side hashing DIY.
      • duskwuff 3y ago
        I think you may have misunderstood me. By "the web application" I mean the application server, not client-side code.