CODEWITHSUNDEEP
sqlmysqlsecuritydatabase-design
expora
expora

Reputation: 601

Would you use one or two tables for username and password?

Is it any safer to create a table holding user information and another one for their passwords than using the same table for everything?

Upvotes: 12

Views: 4315

Answers (8)

Billy Watsy
Billy Watsy

Reputation: 74

i think having the username and password in the same table is ok ,

but also l have seen people doing silly stuff especially when working with the ORM , someone might end up exposing password hashes etc

for example entity framework C#

someone can just do

 appcontext.Users.ToList();

no attributes kept ensuring that password is hidden nor DTOs (Data Transfer Object) ,

upon noticing this l just keep another authentication table and the other thing l there are a lot of fields for forgot password, last password change all those fields l will have them in another table with the password

Upvotes: 1

Matthew
Matthew

Reputation: 10444

There is no security benefit, but using multiple tables can be useful for storing credentials to multiple systems tied to a single login.

As mentioned above, security should be provided by salted hash for passwords.

Upvotes: 0

programmer
programmer

Reputation: 3113

Btw, there is already a pretty simple (and powerful) c# salted hash class library (they've also included a small demonstration of how to use the library) out there - Link .

It also provides a verification mechanism (so you can verify the user's input as a valid password) and you can choose the Hash algorithm yourself (Sha1/MD5/etc.)

Upvotes: 0

bgiles
bgiles

Reputation: 1220

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.

Upvotes: 1

Adam Pope
Adam Pope

Reputation: 3274

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.

Upvotes: 0

Daniel Vassallo
Daniel Vassallo

Reputation: 344301

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:

Upvotes: 6

UpTheCreek
UpTheCreek

Reputation: 32391

No it is not safer. Just make sure your passwords are Salted+Hashed before you stored them in the DB.

Upvotes: 0

Anemoia
Anemoia

Reputation: 8116

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.

Upvotes: 10

Related Questions