1

Looking to create a database table that saves user information (primarily user and password).

  • Is the best way to hash (password) and user?
  • Should I encrypt the name of user too?
  • If i have a table of passwords and another with users data, how i can associate/link them?

The login is not the problem, the question is how to associate the tables (table of passwords and table of data for each user)

Thanks

RDL
  • 7,865
  • 3
  • 29
  • 32
anvd
  • 3,997
  • 19
  • 65
  • 126
  • I would just hash the password. Obviously it would be more secure to do both, but I believe best practices say to hash the password. – The Muffin Man Mar 16 '11 at 17:50
  • You should also use a different salt for each password. – John Mar 16 '11 at 17:53
  • @John, If you used a different salt for each password how would you go about using the correct salt when you need to check if a users password is correct? – The Muffin Man Mar 16 '11 at 17:59
  • @Nick Store the salt in some form alongside the hashed password. The whole (well, most) of the point of salts is to make attacks a per-user effort instead of letting an attacker gain access to all passwords once they crack one. – John Mar 16 '11 at 18:37

6 Answers6

4

You basic User table would look something like this:

User Table
-------
id    username    password
1     mike        @#$90sDfsa

Where the password is a hashed version (with a salt) of my password.

Mike Lewis
  • 63,433
  • 20
  • 141
  • 111
  • yes, i agree, the problem is to associate the data of the other table to the mike – anvd Mar 16 '11 at 17:59
  • 1
    In that case you would use a foreign key... An example might be: Post(id, title, body, user_id) where user_id is a reference to the id in the User's table. – Mike Lewis Mar 16 '11 at 18:00
1

You should of course hash the password before storing it. Ideally with an unique salt.

As a hash function you should not use something like SHA-*, because the cryptographic hash functions are designed to be fast. This makes it easy for someone getting the hash to try a large number of possible passwords very fast.

Use a password hash function like bcrypt which is designed to be arbitrarily slow.

Philipp T.
  • 793
  • 4
  • 13
  • one question please, i have the same doubt that nick in my post, if i have a unique salt for each password - "how would you go about using the correct salt when you need to check if a users password is correct" – anvd Mar 16 '11 at 18:10
  • You just save the salt along the hash. – Philipp T. Mar 16 '11 at 18:17
0

The login is not the problem, the question is associate the tables (table of passwords and table of data for each user)

To associate the tables you can work with relations:

Community
  • 1
  • 1
DADU
  • 6,482
  • 7
  • 42
  • 64
0

I would store the hashed and salted password in the table with the rest of the users data. If you really want to store the passwords in a seperate table store the user id with it to associate passwords with users. In general use a strong hashing algorithim e.g. SHA251 and salt the passwords to prevent rainbow table attacks. I don't think that you should need to hash the username.

Belinda
  • 1,230
  • 2
  • 14
  • 25
  • thanks belinga, i have a unique table to the pass/login, the question is the relations in table: User Mike and the data associated (personal) that is present in another table – anvd Mar 16 '11 at 18:01
  • 1
    Do *not* use a cryptographic hashing algorithm! Use bcrypt (http://bcrypt.sourceforge.net/) – Philipp T. Mar 16 '11 at 18:04
  • @Fel, this has been said a couple of times but we'd all really recommend that you just extend your user table by adding UserId, Username and PasswordHash columns. Your life will be much easier if you do that. Is that an option? – Chris Haas Mar 16 '11 at 18:04
0

As I commented above, I would just hash the password.

Also, why are you storing users and passwords in a separate table? They are related, and should be in the same table. Data such as addresses would belong in a separate table.

The Muffin Man
  • 19,585
  • 30
  • 119
  • 191
  • no, my idea is just a table to pass/login and another to associated data, like birth, location, etc – anvd Mar 16 '11 at 17:57
0

You can use surrogate keys to do the relation between the tables, if you absolutely must have two tables, one with hashed/salted passwords, the other with user information.

You could have a setup like this:

CREATE TABLE users (USER_ID INTEGER, 
                    PASSWORD_ID INTEGER, 
                    USER_ATTRIBUTE VARCHAR(30));
CREATE TABLE passwords (PASSWORD_ID INTEGER, 
                        PASSWORD_HASH VARCHAR(255));

PASSWORD_ID is the surrogate key, you use it in the users table to reference the value in the passwords table. You can join the tables together with a SQL query:

SELECT * 
FROM users INNER JOIN passwords 
     ON users.PASSWORD_ID = passwords.PASSWORD_ID;
N West
  • 6,768
  • 25
  • 40
  • I would not use a table called "passwords" in any system though, since its a ripe object for hacking... – N West Mar 16 '11 at 19:16