From: Ian Boston (DuraSpace JIRA) <no-reply@du...> - 2012-11-19 04:16:40
Ian Boston created DS-1393:
Summary: internal_id collisions in Util.generateKey() ?
Issue Type: Bug
Components: DSpace API
Affects Versions: 3.0
Reporter: Ian Boston
In generating BitStream IDs the BitstreamStorageManager performs an MD5 on a non secure random string generated from a JVM ID, a simple second precision time stamp and a counter. Since the method is synchronised it will probably be unique on that server, although there remains a chance of collisions with other servers. ie close to a weak Type3 UUID implementation.
more problematic is that the MD5 is known to collide, and since there appears to be no protection within the database for a collision it might be possible for a colliding upload to overwrite an existing bitstream, effectively deleting data.
I haven't done a comprehensive analysis of all the code in this area but if there protection, its not obvious. I also could not find any mention of this issue in this jira instance or on the mailing lists.
Some things that could be done:
Type4 UUID from a recognised UUID library to ensure that the UUID is unique. JDK5 and later has a UUID class with Type 4 http://docs.oracle.com/javase/1.5.0/docs/api/java/util/UUID.html
If that doesn't provide the byte required, use a SHA1 or SHA256 as recommended by Dobertin et all in 1996 http://en.wikipedia.org/wiki/MD5
Make the internal_id have a unique key in the database so that collisions in the same database dont happen, assuming duplicate internal_id's are not allowed.
Apologies if there is protection that I missed. If so just close this with a pointer and wont fix.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira