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
Original issue reported on code.google.com by
joshdrum...@gmail.com
on 25 Dec 2010 at 6:04