-2

I'm developing a school, I just applied all the SQL injection protections that exist and database security, administrative roles, parametrized queries, sanitize input from the client.

But FOOL ME! I never hash user passwords, I just store them. But I don't think any hacker will reach the dabatase.

So should I hash the passwords or not?

Thanks :)

Fleche
  • 4,024
  • 1
  • 17
  • 20
NathanWay
  • 559
  • 7
  • 14
  • 1
    It really is necessary to at least hash the passwords before entering it in the database. See how to hash passwords before inserting into MySQL table here : http://stackoverflow.com/questions/17797211/how-to-encrypt-a-password-that-is-inserting-into-a-mysql-table – Pavin Joseph Mar 22 '15 at 20:19
  • 6
    Aren't there better posts to reference? The top answer in that one doesn't even salt it... – ThiefMaster Mar 22 '15 at 20:41
  • I agree, those answers aren't really ideal. But the first post under the frequent tab is about [hashing passwords](https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords). [For PHP > 5.5](https://stackoverflow.com/questions/4795385/how-do-you-use-bcrypt-for-hashing-passwords-in-php) the interface is quite easy to use as well. – tim Mar 22 '15 at 20:45
  • 1
    Yes, hashing and salting. PBKDF2 FTW!! – Pavin Joseph Mar 22 '15 at 20:51

3 Answers3

7

Yes, you should.

Nobody hashes (passwords are hashed, not encrypted) passwords because they KNOW that they have an SQL injection vulnerability. It's a second layer of defense.

And it's needed because you just can't be sure that you don't have an SQL injection. Or that a library you use doesn't have any. Or that there are no other vulnerabilities, such as XSS (if you have a database export option), LFI (if your database is accessible from remote), code execution, badly written backup script, etc via which an attacker can get access to the database.

I'm not quite sure what "developing a school" means, but if you have actual users, and an attack does take place, it will be very bad publicity if your passwords are unhashed, and there might even be some liability on your part.

That are the reasons for hashing. What are the ones against? I mean, it's easy enough, so just do it.

tim
  • 29,122
  • 7
  • 96
  • 120
  • Thanks for the answer. I'll do it, Im not using PHP im using ASP.NET but still i have to protect that and yeaah save my reputation, thanks a lot ^_^ – NathanWay Mar 22 '15 at 20:59
5

YES!! You absolutely MUST both hash and salt the passwords. How do you know that "no hacker will reach the database"? There are probably hundreds of ways a database could be compromised; SQL injection is just one of them. And even if both your server and web application have zero security vulnerabilities (unlikely), you still have to deal with possibilities such as physical compromise of the server and lazy/careless/rogue admins who have access to the database.

Hashing and salting is very easy to perform, so there is simply no excuse to store passwords plaintext. You do, however, need to make sure you choose secure hashing and salting algorithms. No MD5 or SHA1!

Also just to clarify terminology, hashing is not the same thing as encrypting. Encryption is a reversible process, while hashing is not. When storing passwords in a database, most of the time you should hash, not encrypt.

tlng05
  • 10,324
  • 1
  • 34
  • 36
0

Yes, you must hash user passwords, because you have access to the database. You should never have access to user passwords. Because you have access, anyone who obtains your level of privilege also has access. So does someone who manages to get direct database access by compromising the server. So does anyone who can view your backups. A user's password should never be known to anyone except that user; while your server has to learn it temporarily, it should not store it any longer than absolutely necessary, to minimize the risk of someone getting it.

cpast
  • 7,263
  • 1
  • 30
  • 35