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

I开发者_如何转开发s it any safer to create a table holding user information and another one for their passwords than using the same table for everything?

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.

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:

• Stack Overflow: Preferred Method of Storing Passwords In Database

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.

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

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

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.

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.)

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.