Was wondering if there would be a possibility in replacing MD5 in NamingHelper.java with something that would be FIPS compliant?
Having a look at the function itself it doesn’t seem to be using MD5 for anything cryptographic that could be considered as insecure but having said that having it there does prevent us from removing MD5 support from our JDK completely.
Pardon if the question doesn’t make too much sense, not very familiar with hibernate but wanted to see if it would even be feasible to substitute it for something like sha256?
The hashing algorithm is only used to create consistent fk/constraint identifiers that are compatible with all supported databases, and is in no way involved with any security concern. At the moment there’s no way of choosing a different algorithm, and changing the default one would break compatibility with existing schemas so I don’t think it’s something we can do easily.
For your specific case, you could provide a custom org.hibernate.boot.model.naming.ImplicitNamingStrategy that overrides all methods that rely on hashing in the default Hibernate implementation with a custom algorithm:
determineForeignKeyName
determineUniqueKeyName
determineIndexName
You can use the hibernate.implicit_naming_strategy configuration property or directly pass an instance to org.hibernate.boot.MetadataBuilder#applyImplicitNamingStrategy to specify a custom naming strategy.
Thanks for the quick reply. Completely agree that hibernate’s use case isn’t a security risk in itself, but in an ideal world would have like to strip it out from the jdk completely in case other 3rd party libs have less innocent uses for it and to prevent them from being brought in accidentally
For the schema compatibility point I’m not sure I followed. Once the key/constraint identifiers are created by hashing column names (i.e within NamingHelper) is the same method then used to later retrieve those names? If so wouldn’t defining a custom naming strategy result in the same issue for existing schemas?
is the same method then used to later retrieve those names
Yes, imagine a production environment where the fk/constraint names are constant. Hibernate sometimes needs to identify said constraints, so we need to have consistent names.
If so wouldn’t defining a custom naming strategy result in the same issue for existing schemas
Of course, my suggestion was to apply a custom naming strategy in your application, to avoid relying on the MD5 hashing algorithm. The default naming strategy in Hibernate would stay the same for everyone else.
Ah makes sense, appreciate the explanation and your patience. I understand that the suggestion of custom naming strategy was for my application only and would leave the rest of the world safe. I was just trying to figure out if it would break our existing apps that already run in environments where fips compliance isn’t a hard requirement (i.e. already using keys/constraints created through md5).
Sounds like it would so will need to figure out a way to bring this only to the new envs. But that’s a problem for me to figure out
Again thanks for the help and appreciate the pointers!
@mbladel We are using hibernate 5.6 and in the same situation as the original poster. Our stack trace is a bit different:
Caused by: java.security.NoSuchAlgorithmException: MD5 MessageDigest not available
at sun.security.jca.GetInstance.getInstance(GetInstance.java:159) ~[?:?]
at java.security.MessageDigest.getInstance(MessageDigest.java:185) ~[?:?]
at org.hibernate.mapping.Constraint.hashedName(Constraint.java:103) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]
at org.hibernate.mapping.Constraint.generateName(Constraint.java:70) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]
at org.hibernate.mapping.Constraint.generateName(Constraint.java:88) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]
at org.hibernate.mapping.Table.createUniqueKey(Table.java:656) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]
at org.hibernate.cfg.annotations.TableBinder.createUniqueConstraint(TableBinder.java:732) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]
at org.hibernate.cfg.annotations.TableBinder.bindFk(TableBinder.java:704) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]
at org.hibernate.cfg.ToOneFkSecondPass.doSecondPass(ToOneFkSecondPass.java:105) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Final]
at org.hibernate.boot.internal.InFlightMetadataCollectorImpl.processEndOfQueue(InFlightMetadataCollectorImpl.java:1750) ~[hibernate-core-5.6.15.Final.j
at org.hibernate.boot.internal.InFlightMetadataCollectorImpl.processFkSecondPassesInOrder(InFlightMetadataCollectorImpl.java:1694) ~[hibernate-core-5.6
at org.hibernate.boot.internal.InFlightMetadataCollectorImpl.processSecondPasses(InFlightMetadataCollectorImpl.java:1623) ~[hibernate-core-5.6.15.Final
at org.hibernate.boot.model.process.spi.MetadataBuildingProcess.complete(MetadataBuildingProcess.java:295) ~[hibernate-core-5.6.15.Final.jar:5.6.15.Fin
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.metadata(EntityManagerFactoryBuilderImpl.java:1460) ~[hibernate-core-5.6.15.Final.ja
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:1494) ~[hibernate-core-5.6.15.Final.jar:5
at org.hibernate.jpa.HibernatePersistenceProvider.createContainerEntityManagerFactory(HibernatePersistenceProvider.java:141) ~[hibernate-core-5.6.15.Fi
at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:367)
Does your suggestion only apply to the latest code? I don’t know the code well enough to say for sure, but this stack trace to Constraint.java doesn’t seem to include any code that would be overridden by setting hibernate.implicit_naming_strategy.
