I'm hashing the passwors of my users with PDKDF2 right now. A user can gain access to his account with his password. When the user is logged in he can edit his personal information and do other stuff in his account. All this will get safed to the same database. So if an attacker gets access to the database he will get all the information he would like to know without knowing the password. So why should I use PDKDF2, scrypt or bcrypt to hash the passwords?
Add a comment
|
3 Answers
An attacker might not have to gain access to your database to obtain the passwords of your users.
By design, data stored in a database are segregated by tables. Information like usernames and passwords should be in a different table from the user details like name and such. This is basic database schema design.
If an attacker compromises your application using techniques like SQL injections, they might be able to access only the table containing the passwords.
Even assuming the attacker manages to gain access to your entire database, there are other factors to consider. User information is not the only important thing in your application. If the attacker changes the information in the database directly, his actions would most likely be logged. This makes it relatively easy to find and fix any unwanted modifications.
However, if the attacker logs into a user account through the login page of your application, it would be difficult to differentiate what is intended and unintended access. He could cause a lot of potential damage.
In addition, many users use the same username/password combinations across multiple sites. If an attacker compromises the account information on your site, he could potentially access all the other online accounts of the user. This is bad.
Always hash your passwords.
-
I'm using NoSQL so I don't got tables but the rest was quite interesting.– noobCommented Aug 11, 2012 at 2:45
-
@micha Hah, i always think of RDBMS whenever i see the word database.– user10211Commented Aug 11, 2012 at 2:49
-
NoSQL injections still exist. In fact, they're probably more prevelant by percentage than SQL injection holes are, since most people don't know anything about them. Commented Aug 12, 2012 at 8:57
-
Im inserting like this:
db.mycollection.insert({key: userinput}). How can NoSQL injection exist in this case?– noobCommented Aug 12, 2012 at 10:42
People tend to reuse passwords for different sites. They can't remember 20 different secure passwords for 20 different sites! Using a secure password hash is a responsible way to limit the damage in the unfortunate event of a site compromise. Their data on your site will be exposed, but they won't suffer compromise of accounts which are high-value (to both themselves, and attackers) like Facebook (spam), Gmail (full online identity compromise), or Amazon (allows purchases through user's auto-saved credit card details, without requiring CVV).
(No, full names and usernames should not be in separate tables as a matter of "basic database schema design". Each user has one name, and one username, so they should be in the same table. OTOH, more complex data like an address book of friend's email addresses is likely to be split between multiple tables, so I agree using PDKDF2 might help limit the damage of a lone SQL injection).
If your passwords are not hashed, but stored "as is", then an attacker who gets a read-only access to the database immediately learns all the passwords, allowing him to log as any user and do whatever these users can do, which includes, as you say, edit their personal information. This means that the attacker can escalate the read-only access into a read-write access.
Read-only access are not an improbable scenario. This is what the attacker gets when he steals an old backup tape.
See this blog post for more details.
answered Jan 12, 2013 at 23:51
