Letractively / webpasswordsafe

Automatically exported from code.google.com/p/webpasswordsafe
0 stars 0 forks source link

user's authn password value should be stored in own table and pojo #28

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Currently when a User domain model pojo is loaded on the server and sent to 
the client as part of a response, it contains all the fields from the user 
table in the database, including the password column. 
2. Although the password is not clear text (by default it is a salted hash 
encrypted value), and can't be replayed to the server as the original value 
(server will re-encrypt it as though it were plaintext password), there is no 
reason for the client side to know what it is or use it, and there is a very 
small chance that if the digest algorithm and salt/encryption key is known on 
the client side, that an attacker could create rainbow tables to brute force 
get the original plaintext password.

What is the expected output? What do you see instead?
1. So the password field isn't sent to the client with each User object, 
refactor it into a child object, and normalize that column to its own table 
linking to user table.  This will also only select from the password table 
*only* when the password field is needed, not every time any user other 
information is needed, helps reduce noise in database auditing.
2. Now user object which doesn't include password field is sent to client, and 
password field only selected when needed to update or authenticate.  Child 
object is not eagerly loaded.  Client never has salted hash encrypted password 
value of user.

Original issue reported on code.google.com by joshdrum...@gmail.com on 25 Dec 2010 at 6:04

GoogleCodeExporter commented 8 years ago

Original comment by joshdrum...@gmail.com on 25 Dec 2010 at 6:04

GoogleCodeExporter commented 8 years ago

Original comment by joshdrum...@gmail.com on 27 Dec 2010 at 11:55