Is it any safer to create a table holding user information and another one for their passwords than using the same table for everything?
+4
A:
No I would just do this:
id, username, password.
Where id is just autoincrement, username is a varchar of 20 (or so, depending on your needs) and password is an MD5 or SHA1 hashed password with a salt.
Using two tables for this just doesn't make sense. Then you need to work with joins to get the data. And that's just an unnecessary burden.
Snake
2010-04-28 07:35:09
Don't forget to add the salt to the table, too.
Michael Burr
2010-04-28 07:37:23
You don't necessarily need to do that. You can use one salt for every password. If the database is hacked they don't have the salt. If you add it to the database they do. The idea of a salt is just that the end user does not have final control over the resulting hash.
Snake
2010-04-28 07:41:21
Thanks to everyone! I'm aware of the salted hash. I was just wondering if having two tables adds any valuable security feature.Cheers!
expora
2010-04-28 07:47:40
Agree with Michael - you need unique salts per password. You should always assume the salt is available to the attacker. With a global salt, the attacker can build a dictionary of passwords *once* and use it against all users in the database. With a unique-per-password salt, the attacker has to build a different dictionary *for each user*, which is difficult. If he only wants the password for one specific user, neither approach is going to help; but when you are speaking about thousands of users, the unique salt will help a lot.
sri
2010-04-28 09:17:42
Agreed with the unique (per user) salt, but rather than storing the salt separately to a new column you could use an existing column (with static data) as the salt - such as the username.
PaulG
2010-04-28 15:39:42
I agree with the idea of a unique salt. Sounds like a fine solution! Cheers!
expora
2010-04-28 16:05:25
A:
No it is not safer. Just make sure your passwords are Salted+Hashed before you stored them in the DB.
UpTheCreek
2010-04-28 07:35:11
+2
A:
No, I cannot see how that can make it safer.
You should actually refrain from storing passwords at all. Just store their salted hash.
Further reading:
Daniel Vassallo
2010-04-28 07:35:37
A:
No. Not unless each table required a different user account to access it - which would make querying it a complete pain - and even then, the hacker has worked out one login, so chances are they can get the other.
Just make sure that you are storing passwords in a hashed form, using a secure hash like SHA-2 and a salt. Do not store them in plain text and (IMHO) don't store them encrypted.
Adam Pope
2010-04-28 07:37:06
Thank you Adam. I was in that wavelength while thinking about this: would the hacker get access to everything? I guess it occured to me while learning a bit about Unix and files such as /etc/passwd and /etc/shadow.After reading the answers to my question it became clear this idea doesn't help in a Web application (not to mention the Unix case has a history).
expora
2010-04-28 16:33:26
A:
I disagree with other people - put the authentication information in a separate table and to the greatest extent possible pull authentication out of your application entirely. You shouldn't care. Think siteminder and the like - your web application doesn't have any information about how the user is authenticated. Password, smart card, etc. (Same thing with Kerberos or Active Directory on desktop applications.)
This approach even works if you use a framework like Spring Security. Just set up your interceptor so it looks at the authentication tables alone. You could even use separate DataSources so your interceptor can't see application data or vice versa.
Obviously your application will still need to manage information about the user's authorizations, something usually handled in a 'roles' table. But there's no need to for it to know how the user was authenticated.
bgiles
2010-04-29 17:06:07