db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francois Orsini (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-866) Derby User Management Enhancements
Date Thu, 29 Sep 2011 20:16:48 GMT

    [ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117582#comment-13117582

Francois Orsini commented on DERBY-866:

- q5: database only properties is not default, but must be enabled. will the new mechanism
work without it? (cf. derby.database.propertiesOnly) If so, the authentication could be overridden
by specifying another value for derby.authentication.provider.

This is a good point. It is goofy that someone can masquerade as the DBO by disabling authentication
on the boot command line and then simply asserting "user=dbo" at connection time--even when
sql authorization is enabled. This is a security hole for all of our authentication schemes.
I'm afraid it's too late to close this hole for the other schemes, but we could close it for
this new scheme. That would be independent of turning on derby.database.propertiesOnly as
part of the master security property. Thanks.

**** derby.database.propertiesOnly property cannot be overridden by a system property, unless
things have changed :) so *no one* should be able to override some authentication provider
set at the database level as long as derby.database.propertiesOnly is set to true in that
database - unless of course, one is able to change it to false at the file level.

- q3: should the system table be encrypted to avoid attacks? currently we encrypt entire database
which may not be what one wants(?)

This sounds like a good idea but I'm not sure how to secure the encryption key so that the
database can be booted by someone other than the dbo. Any ideas? 

**** Most traditional RDBMS do not encrypt their sys.sysusers equivalent as you would protect
access to the DB files typically and passwords are (salted)+hashed - if you want to give the
files away or they get accessed by other means, then all bets are off, meaning that no matter
what and with expensive hardware, it could be possible to decrypt most ciphered streams these
days. Of course if the salt is known, then without encryption, someone could just go and replace
an existing password in sys.sysusers, assuming they have access to it - Database encryption
seems like the way to protect sys.sysusers (to a certain limit as mentioned above) unless
one wants to introduce yet another database access (Sesame) secret key that a user would have
to enter to get access (without encrypting the whole DB, but rather sys.sysusers). There is
probably other ways, that's the quickest I had in mind.

At the end, if you want to hand out a some Derby DB files (non client-server topology) and
you want to restrict access, Authentication and Authorization should be enabled as well as
Database encryption turned ON.

> 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:
>            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, 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


View raw message