Open SasiMayo opened 1 year ago
Thanks for bringing this to our attention. I believe ensuring that all of the MSAL's use SHA-256 has been a backlog task for a while but has slipped through the cracks.
Assuming there aren't any unexpected issues, we should be able to get it into our next release. I don't have an ETA for it yet, but it should be within the next couple of weeks, and we'll update this thread once it's done.
@SasiMayo @Avery-Dunn - this is currently a limitation of AAD (the service), as they do not support SHA#256 option. It is on their backlog. We will be addressing this with high priority, but I do not have an ETA.
Note that we are not aware of security implications of using an usafe hash algorithm in the assertion. But I agree it creates noise.
Have you thought about not using a certificate - and using Managed Identity instead? It is currently not available in MSAL 4J, but we are building support for it now. It is available in Azure Identity.
https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview
Tracking working item for AAD (sorry, it's internal tracking system) https://identitydivision.visualstudio.com/Engineering/_workitems/edit/2655345
The tool we used to scan our microservices for vulnerabilities detected a vulnerability in the hashing algorithm used by com.microsoft.aad.msal4j.ClientCertificate.java.
The insecure code is the #getHash function:
private static byte[] getHash(final byte[] inputBytes) throws NoSuchAlgorithmException { final MessageDigest md = MessageDigest.getInstance("SHA-1"); md.update(inputBytes); return md.digest(); }
The tool considers not secure the hashing method 'SHA-1' and suggests to replace it with the stronger algorithm 'SHA-256'.
You can refer to:
CWE https://cwe.mitre.org/data/definitions/328.html OWASP https://owasp.org/Top10/A02_2021-Cryptographic_Failures/