Lloyd,
On 12/13/24 2:41 PM, DIGLLOYD wrote:
Agreed, it is probably pointless to support SHA-256, given the hard
requirement of supporting MD5 in older browsers for many years to
come.
OTOH, running any kind of DIGEST over TLS and storing zero sensitive
info on server is completely acceptable for my own use case.
You can use HTTP Basic Authentication over TLS and store zero sensitive
information on the server as well.
I have never seen any benefit to using HTTP Digest over HTTP Basic when
TLS in in place.
-chris
On Dec 13, 2024, at 11:37:27, Christopher Schultz
<ch...@christopherschultz.net> wrote:
Lloyd,
On 12/13/24 2:32 PM, DIGLLOYD wrote:
Yes, it is returning the digest without modification. That’s not the issue.
There are three options:
(1) require MD5 only
(2) require SHA-256 only
(3) allow either MD5 or SHA-256
#2 is not an option since some browsers (eg Safari) do not yet support SHA-256.
And SHA-256 will never be supported on millions of computers because they will
never get upgraded to the latest OS/browser.
issue: getPassword(username) has no parameter specifying algorithm MD5 or
SHA-256. Therefore, it cannot be used.
My solution is to override getDigest(String username, String realmName, String
algorithm), and return the digest for the actual algorithm.
If I am missing something, I’d like to hear it but I don’t see an alternative.
<Valve
className="org.apache.catalina.authenticator.DigestAuthenticator" ...
algorithms="SHA-256,MD5" />
It's almost as if HTTP DIGEST authentication cannot be made both secure
and backward-compatible.
-chris
On Dec 13, 2024, at 11:16:50, Christopher Schultz
<ch...@christopherschultz.net> wrote:
Lloyd,
On 12/13/24 11:47 AM, DIGLLOYD wrote:
BTW, I was able to support *both* MD5 and SHA-256 in my subclass of
org.apache.catalina.realm.RealmBase
ISSUE: org.apache.catalina.realm.RealmBas.getPassword(final String username)
affords no means to know *which* algorithm ie which digest to return.
I dealt with this by subclassing org.apache.catalina.realm.RealmBase:
1. Overriding getDigest(String username, String realmName, String algorithm)
for the algorithm, returning the appropriate digest based on the actual
algorithm.
2. getPassword(String username) never gets used because of #1.
3. Storing both MD5 and SHA-256 digests
In this way, I can support both MD5 and SHA-256. I don’t know if this was a
good idea or not, but it is working as desired.
Should org.apache.catalina.realm.RealmBase should be improved to be
getPassword(String username, String algorithm) instead of getPassword(String
username)?
No, getPassword should be returning the stored credential without modification.
It's odd that you have multiple credentials stored.
-chris
On Dec 13, 2024, at 02:23:38, Mark Thomas <ma...@apache.org> wrote:
On 13/12/2024 00:39, DIGLLOYD wrote:
ISSUE: users cannot login to my site.
CAUSE: Firefox and Chrome are sending SHA-256 DIGEST auth, which is MD5 (Safari
uses MD5 which is working fine)
Details:
- Tomcat 9.0.98
- DIGEST auth using MD5
- has been working for 15+ years just fine.
- have read all available Tomcat docs, searched web for answers, etc.
Debugging so far:
Custom Realm in use purpose of managing auth info, but it otherwise defers to
org.apache.catalina.realm.RealmBase.
CredentialHandler: eg <CredentialHandler
className="org.apache.catalina.realm.MessageDigestCredentialHandler" algorithm="MD5"
/>
So you have DIGEST authentication with digested credentials.
That will work as long as DIGEST authentication uses the same digest as
the credentials. In this case: MD5.
By default, Tomcat advertises support for both SHA-256 and MD5 with
DIGEST authentication. Browsers should choose SHA-256 given those
options. To change that, you need to set the algorithms attribute for
the DIGEST authentication Valve to "MD5" so the Valve only advertises MD5.
https://tomcat.apache.org/tomcat-11.0-doc/config/valve.html#Digest_Authenticator_Valve
Note the comment in the introduction to that section.
Mark
By instrumenting this realm, I have determined the following:
- Firefox and Chrome are sending SHA-256 DIGEST to my server, which is using
MD5. Guaranteed failure since wrong digest.
- Safari is sending MD5, which works fine
- Realm uses standard
Thoughts:
I would have thought that Tomcat would be replying to a client by advertising
the correct algorithm.
Possibilities:
1. Tomcat is not properly advising the client that MD5 is required.
2. The spec is somehow deficient so that client and server do not know what is
required.
3. The clients (Firefox and Chrome) are doing it wrong.
4. Something needs to be configured that I have not configured.
Lloyd Chambers
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
