db-derby-dev mailing list archives

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

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

Rick Hillegas commented on DERBY-866:
-------------------------------------

Thanks for the analysis and questions, Dag. Some responses follow:


- q1: the password in the system table is the result of the hash, right? (not the password
itself)
- q2: salting?

Right. The password in the system table should be salted and hashed.

- 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?

- q4: boot-strap: how is the dbo user created? Autmatically when sing the provided connection
password when creating the database and seeing the property for the new scheme set in derby.authentication.provider?

Right.

- 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.


- q6: do you see the scheme requiring SQL authorization enabled? If not, we'd need encryption
to avoid attacks: arbitrary user could backup entire database and stage dictionary attack
against the USER table...Btw, I forget, *is* backup restricted with authorization on? Docs
doesn't say...

I think this is a good idea although it violates the orthogonality of the Derby properties.
I don't understand why anyone would want to run with authentication but not authorization.
The ability to do that is an unfortunate accident of our backward compatibility requirements
combined with the order in which we implemented the two security mechanisms. Thanks.

- comment: creating a new user/role should cross-check each other to avoid collisions in uids.

Good idea.

- comment: the new feature only solves the issue of database level authentication, not system
level, obviously (limitation) 

Yes. This is another, closely related discussion we need to have. 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

        

Mime
View raw message