Security

[kimwong99956]

I've often wondered what is best when it come to login id's. Should one put the login and password on the same table as the customer data (i.e. they are customer user id's) or should one put them in a completely seperate table,

thoughts anyone

Kim

 

[Gouri]

I've often wondered what is best when it come to login id's. Should one put the login and password on the same table as the customer data (i.e. they are customer user id's) or should one put them in a completely seperate table,

thoughts anyone

Kim

It is better to keep the login IDs table seperate.

 

[descalzo]

You should not store passwords.

You should store a hash (md5 [not the best], sha256, etc) of the password. Then when a user tries to log in, you hash his submitted password and compare that with the stored value.

You can add a random salt value, stored either in a column the password table or prepended to the final hash value.

If a user forgets his password, you cannot give him his old one. You never stored it. So you issue him a new one.

 

[callumacrae]

md5 [not the best]

Easier to brute force, but in no way less secure if your database is secure. http://webdevrefinery.com/forums/topic/4850-hashing-myths/

$finalHash = md5(md5($salt) . md5($password))

Have a unique salt for every user - changed automatically whenever the user changes their password, too - and as long as your database isn't stolen, the passwords are safe. And lets face it, if someone has access to your database, you're in trouble anyway.

~Callum

 

[kimwong99956]

so why is it better to have login Id's in a seperate table

 

[callumacrae]

so why is it better to have login Id's in a seperate table

I would recommend putting them on the same table as their data, it's no less secure and easier for you.

 

[essellar]

so why is it better to have login Id's in a seperate table

That really depends on what you mean by "customer data" (and, to an extent, on what you mean by "database", since SQL-addressed relational databases aren't the only tool in the shed). If you are using a relational database, the object of the game is to normalize your data, at least to an extent. For the most part, in the applications I write the login table will have the user's login name (often, that's an email address rather than a screen handle), the "nonce" or "salt" for the hashed password, the hash value of the salt-plus-password (as often as not I'll use SHA 512 and encourage pass phrases) and a user ID. The rest of the data goes into other tables, since there may be several simultaneous values (multiple addresses, phone numbers, different names for different purposes, etc.).

In general, any time you look at a category (column) of data and say to yourself "ooh, there could be two of those", it's time to break it out into a different table. There are some things I have seen multiples of often enough that I'll use separate tables right from the get-go rather than waiting for the other shoe to drop -- it's less work to build a battleship than to convert an outboard runabout into one later.