db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dag.Wan...@Sun.COM (Dag H. Wanvik)
Subject Re: [jira] Commented: (DERBY-1387) Add JMX extensions to Derby
Date Fri, 17 Aug 2007 13:59:02 GMT
"Daniel John Debrunner (JIRA)" <jira@apache.org> writes:

>     [ https://issues.apache.org/jira/browse/DERBY-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520325
] 
>
> Daniel John Debrunner commented on DERBY-1387:
> ----------------------------------------------
>
> Rick> So if the DBA uses system procedures to read the passwords, hashed values come
back. 
>
> I don't think so. I think NULL will be returned for a password
> lookup using the get database property method.

I tried this and it does seem to return the hash value, but maybe I
slipped on something?

With derby.properties:

   derby.user.dag=dagspw
   derby.connection.requireAuthentication=true

I ran this set of commands in ij:

   bash-3.00$ java org.apache.derby.tools.ij
   ij version 10.4
   ij> connect 'jdbc:derby:mydb;create=true;user=dag;password=dagspw';
   ij> call SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.user.rick','rickspw');
   0 rows inserted/updated/deleted
   ij> values SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY('derby.user.rick');
   1 
   --------------------------------------------
   3b60f611755f71c545627b196a5e2b915580f9686527 
   1 row selected
   :
   bash-3.00$ java org.apache.derby.tools.ij
   ij> connect 'jdbc:derby:mydb;user=rick;password=rickspw';
   ij> values SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY('derby.user.rick');
   1 
   --------------------------------------------
   3b60f611755f71c545627b196a5e2b915580f9686527 
   1 row selected
   ij> call SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.user.rick','ricksnewpw');
   0 rows inserted/updated/deleted

   ij> connect 'jdbc:derby:mydb;user=dag;password=dagspw';
   ij(CONNECTION1)> values SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY('derby.user.rick');
   1 
   --------------------------------------------
   3b606c98f1d3d14aa029ccd40dc92c806dc86bba3c42 
   1 row selected

So, without sql authorization enabled it seems:

a) the user can change his own password (Rick in example), and 
b) hash value will be returned, also to dbo, making dictionary attack easy.

With sql authorization enabled, only dbo can set/get properties unless
execute privilege is granted, so the user can not change his own password.

Dag

Mime
View raw message