Architectural security considerations

exercise No. 52

Q:

In the section called “Gui authentication: The real McCoy” we achieved end user credential protection. How about the overall application security? Provide improvement proposals if appropriate. Hint: Consider the way credentials are being supplied.

A:

Connecting the client to our database server solely depends on credentials ❷ being stored in a properties file database.properties:

PersistenceHandler.jdbcUrl=jdbc:mysql://localhost:3306/hdm?useSSL=false
PersistenceHandler.username=hdmuser ❶
PersistenceHandler.password=XYZ 

This properties file is user accessible and contains the password in clear text. Arbitrary applications connecting to the database server using this account do have all permissions being granted to hdmuser ❶. In order for our application to work correctly the set of granted permissions contains at least inserting datasets. Thus new users e.g. smith including credentials may be inserted. Afterwards the original application can be started by logging in as smith.

Conclusion: The current application architecture is seriously flawed with respect to security.

Rather then using a common database account hdmuser we may configure per-user accounts on the database server having individual user credentials. This way user credentials are no longer stored in our Person table but are being managed by the database server's user management and privilege facilities. This completely avoids storing credentials on the client side.