开发者

User authentication details in user details table or seperate?

I have a user table which has all the user details like name,email, password hash, gender, city, education, etc... about 45ish columns in total.

The question is: Should i normalize this into two tables one for the user authentication, that is user_id, email, password_hash, password_salt.

And second table to hold user details or is it ok to have both in 1 table? I cant normalize the user details too much because this is a critical system and performance is very important so need to keep joins low.

I am just concerned if user password/email used for login authentication sh开发者_运维问答ould be in a separate table for better security or not?


Two tables wouldn't inherently provide additional security over one table unless those tables are implemented in very different ways. Say, for example, they're partitioned off to different hardware and the password table has native disk encryption or something like that. And even then we're talking about different forms of "security." Both tables are still live and in use, one would just be encrypted at rest. (There may be other examples, but that's all I can think of right now.)

Personally, I tend to use two tables not from a security point of view but rather from a separation of concerns point of view. One is authentication, one is the user profile. In the vast majority of cases they don't need to be separate, but I prefer to keep them separate just in case a logic change is required that needs them to be separate, since they are logically not the same thing.


Symfony's sfGuard uses two tables: one for authentication data, other for user details. That looks rather sensible - as this separates two different sets of data from each other, and the user auth table is narrow, thus it fits better into memory (and various caches) and doesn't need to operate with the (wider) user details whenever authentication is needed.

As for security, I don't really see a difference in one table vs. two tables, except maybe in backup storage requirements.

As always, measure and compare how this stacks up in your specific situation.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜