7 ms·

1. Clean up old tutorials, forum posts, and blogs. This! I'm still seeing code snippets on StackOverflow that use hashing for password storage and queries with

by pasta 9y ago

1. Clean up old tutorials, forum posts, and blogs. This! I'm still seeing code snippets on StackOverflow that use hashing for password storage and queries without prepared statements. I think at the moment that is still a weak spot of PHP. Edit: my mistake. I was refering to weak hashes like md5 and sha1 or 'home brew' hashing.

stephenr 9y ago
> use hashing for password storage As opposed to...?
- CiPHPerCoder 9y ago
  I assume they meant the use of a cryptographic hash function (which is wrong) instead of a password hash function (which, as the name implies, is suitable for password storage). For example, I see a lot of this construction in proprietary code: $passwordHash = md5(md5($password) . md5($salt)); if ($storedHash == $passwordHash) { // Authenticated successfully } I'm quick to find these offending snippets and migrate our clients to use password_hash() and password_verify().
  - duskwuff 9y ago
    Or, for that matter... SELECT * FROM user WHERE username = '$username' AND password_hash = MD5('$password')
    - chx 9y ago
      Surely not after all these years! Does this easy SQL injection still exist...?
      - zaphar 9y ago
        If you only knew the horrors I've seen. This week no less...
      - bitexploder 9y ago
        Yes. Even in places where people use prepared statement and things like LINQ to build queries, somewhere someone will end up wanting or needing a query that is hard to express so they will start string building a raw SQL query and forget or not know to use prepared statements. We see this /all/ the time on our assessment of our customer's software. It is markedly less common, but still quite common, if not pervasive like it used to be. PHP apps are dramatically more likely to have security vulnerabilities of any sort. It is a running joke we have that one of our recommendations to remediate security issues with PHP is to "rewrite in a different language". For whatever reason PHP has a history of encouraging vulnerable code. Even in good shops. PHP itself isn't really to blame (it is, of course much less likely for an experienced shop to write crappy PHP... but they probably wouldn't pick PHP to begin with).
        duskwuff 9y ago
        What deserves a lot of the blame is the awful mysql_* API, which didn't support query placeholders. (The mysqli and PDO APIs weren't available until much later, and weren't reliably available on many web hosts for even longer.) This forced PHP developers to become comfortable with constructing SQL queries as strings -- a habit which proved hard to break for many of them.
- deleted 9y ago
  [deleted]
- yjftsjthsd-h 9y ago
  Perhaps no salt?
  - owenmarshall 9y ago
    Salts don't save you from an attacker who can calculate millions of hashes per second on a GPU. Using bcrypt/scrypt/Argon2id does.
    - TheRealPomax 9y ago
      Salt is not intended to save you, just to make unhashing the next user's password just as much work as the one you just cracked.
    - wongarsu 9y ago
      Salting is incredibly effective. Without salting, the entire power of the attacker can be used against all password hashes at once. With salting, those millions of hashes per second translates to only being able to crack simple passwords, or only the passwords of a few users.
      - tedunangst 9y ago
        Except in the case of MD5, it's billions, many billions, of hashes per second, which translates to cracking lots of users' passwords.
- aruggirello 9y ago
  PHP has had a dedicated password hashing function since version 5.5: it's password_hash(). But at least, if you want to roll your own password hashing, do it right: use hmac, salting, stretching and a decent hash function - or use bcrypt/scrypt and save yourself a few headaches.
  - stephenr 9y ago
    I'm well aware of that. The original comment suggested that password hashing is bad, I was trying to identify what the poster thought should be used instead.
    - idlewords 9y ago
      Evergreen: https://codahale.com/how-to-safely-store-a-password/ https://codahale.com/how-to-safely-store-a-password/
    - deleted 9y ago
      [deleted]
olegkikin 9y ago
MD5 is not that weak, it's just fast, so you have to use a few rounds of it. The preimage vulnerability reduced the search space from 128 bits to 124 [1], which is still extremely secure. People who claim it's broken are probably thinking about the collision vulnerability, which doesn't help you at all to recover the password from a hash. [1]: https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability If you think I'm wrong, I will gladly admit so, just tell me what the $password is here: if (md5(md5($password)) == 'c9876599e5e54aa12962ae1fe7b0f752') ...
- astrodust 9y ago
  The problem is not that hard passwords are easy to crack, it's that easy passwords are stupid easy to crack. An attacker doesn't care about your password so much as they care about getting 50-80% of the passwords on the system, the majority of which are going to be "password123" or some other garbage you can find in a dictionary attack. If you use something like Bcrypt or Scrypt then running your dictionary cracker becomes a real ordeal, it will take a long time to grind through those entries and find matches. With MD5 it's a joke, you can do most of the common ones in seconds and the trickier variants within hours. Hashcat (https://hashcat.net/hashcat/ https://hashcat.net/hashcat/) can and will make short work of your double MD5 nonsense. Additionally, if I can find a bit of text that hashes the same I don't care what the original password was. I have a key that works.
  - olegkikin 9y ago
    That's why I mentioned "a few rounds of it". Use 1000 if you're paranoid, you can make it as computationally complex as BCrypt. And, of course, you should use salts. Good luck breaking that. You couldn't even break my double MD5. Another thing you should do is not allow common or short passwords. That includes "password123". That alone will immediately elevate your security. > Additionally, if I can find a bit of text that hashes the same I don't care what the original password was. I have a key that works And you clearly don't understand how the collusion vulnerability works. You can't create one with a given hash. You carefully craft two documents that hash to the same hash, which you don't know in advance. Again, you can prove me wrong by doing just that to the hash in the code snippet.

by pasta 9y ago

stephenr 9y ago

> use hashing for password storage As opposed to...?

CiPHPerCoder 9y ago
I assume they meant the use of a cryptographic hash function (which is wrong) instead of a password hash function (which, as the name implies, is suitable for password storage). For example, I see a lot of this construction in proprietary code: $passwordHash = md5(md5($password) . md5($salt)); if ($storedHash == $passwordHash) { // Authenticated successfully } I'm quick to find these offending snippets and migrate our clients to use password_hash() and password_verify().
- duskwuff 9y ago
  Or, for that matter... SELECT * FROM user WHERE username = '$username' AND password_hash = MD5('$password')
  - chx 9y ago
    Surely not after all these years! Does this easy SQL injection still exist...?
    - zaphar 9y ago
      If you only knew the horrors I've seen. This week no less...
    - bitexploder 9y ago
      Yes. Even in places where people use prepared statement and things like LINQ to build queries, somewhere someone will end up wanting or needing a query that is hard to express so they will start string building a raw SQL query and forget or not know to use prepared statements. We see this /all/ the time on our assessment of our customer's software. It is markedly less common, but still quite common, if not pervasive like it used to be. PHP apps are dramatically more likely to have security vulnerabilities of any sort. It is a running joke we have that one of our recommendations to remediate security issues with PHP is to "rewrite in a different language". For whatever reason PHP has a history of encouraging vulnerable code. Even in good shops. PHP itself isn't really to blame (it is, of course much less likely for an experienced shop to write crappy PHP... but they probably wouldn't pick PHP to begin with).
      - duskwuff 9y ago
        What deserves a lot of the blame is the awful mysql_* API, which didn't support query placeholders. (The mysqli and PDO APIs weren't available until much later, and weren't reliably available on many web hosts for even longer.) This forced PHP developers to become comfortable with constructing SQL queries as strings -- a habit which proved hard to break for many of them.
deleted 9y ago
[deleted]
yjftsjthsd-h 9y ago
Perhaps no salt?
- owenmarshall 9y ago
  Salts don't save you from an attacker who can calculate millions of hashes per second on a GPU. Using bcrypt/scrypt/Argon2id does.
  - TheRealPomax 9y ago
    Salt is not intended to save you, just to make unhashing the next user's password just as much work as the one you just cracked.
  - wongarsu 9y ago
    Salting is incredibly effective. Without salting, the entire power of the attacker can be used against all password hashes at once. With salting, those millions of hashes per second translates to only being able to crack simple passwords, or only the passwords of a few users.
    - tedunangst 9y ago
      Except in the case of MD5, it's billions, many billions, of hashes per second, which translates to cracking lots of users' passwords.
aruggirello 9y ago
PHP has had a dedicated password hashing function since version 5.5: it's password_hash(). But at least, if you want to roll your own password hashing, do it right: use hmac, salting, stretching and a decent hash function - or use bcrypt/scrypt and save yourself a few headaches.
- stephenr 9y ago
  I'm well aware of that. The original comment suggested that password hashing is bad, I was trying to identify what the poster thought should be used instead.
  - idlewords 9y ago
    Evergreen: https://codahale.com/how-to-safely-store-a-password/ https://codahale.com/how-to-safely-store-a-password/
  - deleted 9y ago
    [deleted]

olegkikin 9y ago

MD5 is not that weak, it's just fast, so you have to use a few rounds of it. The preimage vulnerability reduced the search space from 128 bits to 124 [1], which is still extremely secure. People who claim it's broken are probably thinking about the collision vulnerability, which doesn't help you at all to recover the password from a hash. [1]: https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability If you think I'm wrong, I will gladly admit so, just tell me what the $password is here: if (md5(md5($password)) == 'c9876599e5e54aa12962ae1fe7b0f752') ...

astrodust 9y ago
The problem is not that hard passwords are easy to crack, it's that easy passwords are stupid easy to crack. An attacker doesn't care about your password so much as they care about getting 50-80% of the passwords on the system, the majority of which are going to be "password123" or some other garbage you can find in a dictionary attack. If you use something like Bcrypt or Scrypt then running your dictionary cracker becomes a real ordeal, it will take a long time to grind through those entries and find matches. With MD5 it's a joke, you can do most of the common ones in seconds and the trickier variants within hours. Hashcat (https://hashcat.net/hashcat/ https://hashcat.net/hashcat/) can and will make short work of your double MD5 nonsense. Additionally, if I can find a bit of text that hashes the same I don't care what the original password was. I have a key that works.
- olegkikin 9y ago
  That's why I mentioned "a few rounds of it". Use 1000 if you're paranoid, you can make it as computationally complex as BCrypt. And, of course, you should use salts. Good luck breaking that. You couldn't even break my double MD5. Another thing you should do is not allow common or short passwords. That includes "password123". That alone will immediately elevate your security. > Additionally, if I can find a bit of text that hashes the same I don't care what the original password was. I have a key that works And you clearly don't understand how the collusion vulnerability works. You can't create one with a given hash. You carefully craft two documents that hash to the same hash, which you don't know in advance. Again, you can prove me wrong by doing just that to the hash in the code snippet.