# Notes on the Derby security features

TheDerby security model has some basic limitations.

You lock out non full-access users with database properties, which are stored in the database (and in an encrypted database these properties are also encrypted). Note, however, for a distributed/embedded system that a sophisticated user with the database encryption key might be able to physically change those properties in the database files.

In addition, in the Derby system, it is not necessary to have a specific connection (or permission to access a particular database) to shut down the system. Any authenticated user can shut down the system.

Other security holes to think about are:

- JVM subversion, running the application under a home-grown JVM.
- Trolling for objects
- Class substitution, locating a class that has access to sensitive data and replacing it with one that passes on information

Parent topic: Derby and Security
Related concepts
Configuring security for your environment
Working with user authentication
Users and authorization identifiers
User authorizations
Encrypting databases on disk
Signed jar files
User authentication and authorization examples
Running Derby under a security manager