Discussion between Robert Mennell and linofex

Feeds

19:51

0

Q: Use one single table for users' passwords

I'm writing a small remote password manager. A client can register itself and stores its passwords (it is for university purposes). In practice, I have a table Client_ID | hash(Password) that stores the user's hashed password. From this password, I use a KDF to create a 32B AES PASSWORD that I wi...

Robert Mennell

This is more a question about proper table organization and not so much security. Really what you're asking is how you should allocate your foreign keys on your tables so that you can realistically manage a users password(s). This should be as easy as a user table with identifier(s)[email, username] | password(and however you choose to protect it) | id(your easy to use reference that never changes), and a sites table with user(the id field from the users table as a foreign key) | site | password(two way encryption based on some user secret/other logic)

after that you'll probably want an index to keep things fast on user in the passwords table

linofex

thank you for the reply. So It is better to use only one table for all the users.

Robert Mennell

Depending. You need a table for reference, then after that you can move to model. So yes you should have a single table per entity(if no other entity is required but username, then yes user)

linofex

Sorry, but I'm confused. I have a table for client_ID | hash(psw). With this, I check the login. My question is how to organize the tables where I save the passwords of a user. I have two ideas: 1. one table for each user (so if I have 100 users, than 100 tables) like site | password (for simplicity) or 2. one single table for all the users (100 users, 1 table) like user_ID | site | password (for simplicity) ? Obviously in the second case, I have to link the user_IDs of the 2 tables

Robert Mennell

ah. Either of those two models will work. The problem then becomes which is faster and more maitnainable

linofex

19:51

For security reason are these models the same? This project is for cybersecurity course, so the first thing is security, 'then' the performances

Robert Mennell

Think of how your system would be compromised, that should help drive your development towards a more pointed answer

linofex

hi, and thank you for the time.

Robert Mennell

happy to help learn while I acn

linofex

My project is a client - server application that after a protocol that establishes a session symmetric key, starts to handle client requests to the database, on the server.
So, for the treat point of view, I have to solve authentication and confidentiality of the client and server and possibles SQL injection behaviour. For the database I use MySQL and I connect to that with 'username', 'address', 'password'. Inside the database, on the user table I have the hash (+salt) of the user password and I encrypt the site passwords with AES 256 (+IV). In my opinion either the 2 ideas that I proposed…

Robert Mennell

it depends. The biggest difference between the two is what type of leak happens. If every entry fo a site's password is in a single table then you get subsequent rows leaking encrypted passwords that all require different decryption keys and thus are just mangled strings since they don't really know who is what user unless they also compromised the user table.

The other is that they get subsequent rows of the users sites passwords with each one possibly only requiring the same decryption key.

Of course if each website gets a different encryption key for the password, then it's like both models are the same.

Remember security is more about implementation than anything since it's a design paradigm

linofex

20:17

`The other is that they get subsequent rows of the users sites passwords with each one possibly only requiring the same decryption key. `

I do not understand this phrase

Robert Mennell

okay so imagine someone does actually manage to find a vulenerabilty, but it's a vulnerability related to SQL injection to allow them return only contents of a table(we're ignoring full take over here since that sounds like something you're already wary of and are planning to prevent)

now realistically these will be SQL injection attacks where they malform the where clause

that will return several(if not all) rows

the thing becomes in both models that once that leak has happened they must now try and figure out what user they compromised. So in this aspect BOTH models are equivalent.

the difference is how the information is linked to each other

if they get site | pass it's pretty safe to assume these are all for a single user

if they get user | site | pass then it's safe to assume that they also need to get the user references to get a hint at who is where

the difference is that with the first they know they only have to compromise a single user and with the second they have to compromise a user and then check against their data.

of course then it becomes what authenticated request did they make and how did your security implementation fail

but the base difference between the two models is that one can only compromise a single user at a time, but it's easy to figure out what user depending on attack vector, or expose multiple users and make it harder to figure out which user they are(unless you leaked that somehow too in which case it's just as bad as the first)

now if you keep the encryption data seperate from the user table somewhere else too and use a completely different reference that can ALSO be stored on the user table, then your attack vector become even hard to break(especially if it's on a seperate provider)

linofex

20:36

ook!! Thank you again! I very like this field, but during the lessons, all """seems """ easy, but when you start to develop the entire system you have to check and look for hundreds of things! Now I have clearer ideas!

Robert Mennell

glad I think I helped then XD

it confuses me too with how easy it seems

Transcript for

Discussion between Robert Mennell and…