[
https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155433#comment-13155433
]
Rick Hillegas commented on DERBY-866:
-------------------------------------
Here is my next tranche of thoughts about building a more secure out-of-the-box
authentication mechanism for Derby. I address two topics:
1) Setting a reasonable goal.
2) Handling system-wide users.
------------- Setting a Reasonable Goal -------------------
Francois raised the point that if someone can read or write your database
directories, then you may have already lost the security battle. If someone can
read your database directories, then they can copy the database to a workbench
area and crack it at their leisure. If someone can write to the database
directories, then they can alter your database; they might even escape
detection via an exploit like the one described by DERBY-5510.
If the attacker can connect to a Derby engine which reads directories holding
your database, then the attacker can copy the database to a workbench area by
exploiting the vulnerability described by DERBY-2470. By using the RESTORE
functionality, the attacker does not even need valid credentials to do this.
Encryption may help protect you from these attacks. However, as Francois points
out, once the attacker has a physical copy of your database, cracking it may
only be a matter of time. Derby encryption may be particularly vulnerable
because system conglomerates keep their original names and begin with known
sequences of bytes. It is possible that encrypted file systems may give you a
bit more protection.
For these reasons, I do not expect this JIRA to address the following non-goals:
A) We are not trying to protect Derby databases on mobile devices like laptops
and phones.
B) We are not trying to protect Derby databases on removable media like USB
sticks.
However, I still think that we can boost the security of databases which live
in physically secure locations such as servers inside protected machine rooms.
This includes databases embedded inside user-written server applications and
databases running inside Derby's own server framework.
------------- Handling System-wide Users -------------------
This JIRA focuses on the problem of database-specific users. However, we need
to give some thought to the problem of system-wide users. These users appear in
the following situations:
i) The credentials of Derby network administrators. Here there is no
distinguished database to which we can tie the credentials.
ii) The credentials needed to create a database. Since the database doesn't
exist yet, we can't tie credentials to it.
I am tempted to add the following case too:
iii) The credentials needed to restore a database from a backup. We might want
to address this problem by authenticating the user in a read-only connection to
the backup BEFORE restoring from it. On the other hand, previous discussions
related to DERBY-2109 and DERBY-2470 have compared this use-case to database
creation. If we want to treat this case like database creation, then we may
want to treat the credentials like case (ii) above.
Here are some options for managing system-wide credentials:
I) Via system-wide properties, stated either on the JVM boot command or in a
properties file. Maybe we could reuse the existing BUILTIN user/password
properties for this purpose. I do not recommend this solution because it seems
vulnerable to being spied on.
II) Via some encrypted file managed by Derby. This would require building
system-wide machinery for changing credentials and for disaster recovery. One
variation of this approach might be a master database which just holds
system-wide credentials.
III) Via some application-supplied authenticator. This pushes the problem into
the application and seems to defeat the intent of this JIRA.
Maybe you can think of some other approaches. As you can tell, I am not
thrilled by any of the solutions above.
Perhaps we can finesse these problems and not create a concept of system-wide
users:
i') We already have a solution to (i): The server administration credentials
are invented at server boot time. In a properly configured server (forget
NetServlet), the server can only be booted by someone who has passed other,
enterprise-supplied authentication hurdles.
ii') Do not allow arbitrary users to write their own Derby connection URLs. The
trick here is for the embedding application to not provide a means by which
users can specify arbitrary connection URLs. That is, educate users to treat
URL injection like SQL injection.
iii') We could tackle this as a case similar to (ii'). Or we could first
authenticate in a read-only connection to the backup, as noted above.
I would appreciate your additional thoughts about these topics. Thanks.
> Derby User Management Enhancements
> ----------------------------------
>
> Key: DERBY-866
> URL: https://issues.apache.org/jira/browse/DERBY-866
> Project: Derby
> Issue Type: Improvement
> Components: Services
> Affects Versions: 10.2.1.6
> Reporter: Francois Orsini
> Attachments: Derby_User_Enhancement.html,
> Derby_User_Enhancement_v1.1.html
>
>
> Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec
> attached to the JIRA).
> Abstract:
> This feature aims at improving the way BUILT-IN users are managed in Derby by
> providing a more intuitive and familiar DDL interface. Currently (in
> 10.1.2.1), Built-In users can be defined at the system and/or database level.
> Users created at the system level can be defined via JVM or/and Derby system
> properties in the derby.properties file. Built-in users created at the
> database level are defined via a call to a Derby system procedure
> (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property.
> Defining a user at the system level is very convenient and practical during
> the development phase (EOD) of an application - However, the user's password
> is not encrypted and consequently appears in clear in the derby.properties
> file. Hence, for an application going into production, whether it is embedded
> or not, it is preferable to create users at the database level where the
> password is encrypted.
> There is no real ANSI SQL standard for managing users in SQL but by providing
> a more intuitive and known interface, it will ease Built-In User management
> at the database level as well as Derby's adoption.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
