"Daniel John Debrunner (JIRA)" <[EMAIL PROTECTED]> 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

Reply via email to