Re: CredentialHandler not working for MD5
Mark, On 11/18/23 07:52, Mark Thomas wrote: On 17/11/2023 19:36, Christopher Schultz wrote: Is there any reason why SHA-256 is the default? MD5 is the historical default / only implementation for HTTP DIGEST. RFC 7616 (2015) Chrome will choose SHA-256 if presented with a choice of SHA-256 and MD5. Yeah, but doesn't it advertise that in the HTTP request headers? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CredentialHandler not working for MD5
On 17/11/2023 19:36, Christopher Schultz wrote: Is there any reason why SHA-256 is the default? MD5 is the historical default / only implementation for HTTP DIGEST. RFC 7616 (2015) Chrome will choose SHA-256 if presented with a choice of SHA-256 and MD5. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CredentialHandler not working for MD5
Mark, On 11/17/23 03:55, Mark Thomas wrote: On 16/11/2023 18:06, Peter Otto wrote: 1. Configure BASIC auth with clear-text passwords in the Realm and get that working. 2. Switch to DIGEST auth with clear-text passwords in the Realm and get that working. 3. Then configure DIGEST auth and digested passwords in the Realm. Hi Chris, Step 1 & 2 work Step 3 will not work with the clear txt password, only the digested password, which means the text password in tomcat-users.xml. In past versions of Tomcat, the clear text password would work. Testing with the manager application. Step 1: Use the following user in tomcat-users.xml Step 2: Edit $CATALINA_BASE/webapps/manager/WEB-INF/web.xml BASIC changed to DIGEST Step 3: Edit $CATALINA_BASE/webapps/manager/META-INF/context.xml to specify MD5 digest (rather than default of SHA-256) ... Modify Realm configuration in server.xml Calculate password value for tomcat-users.xml digest.sh -a MD5 -s 0 \"both:Tomcat Manager Application:tomcat\" both:Tomcat Manager Application:tomcat:802b9260bb5c0837169f99e64aca2fd0 Update tomcat-users.xml roles="manager-gui"/> As expected, this works. I will note it took me a couple of attempts to get right as I had some typos in my configuration. If you use the default digest of SHA-256 then you don't need to configure the DigestAuthenticator in the content.xml file. Is there any reason why SHA-256 is the default? MD5 is the historical default / only implementation for HTTP DIGEST. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CredentialHandler not working for MD5
Ok thanks. Got it is now working. This step was missing. We didn’t have to do this before. No mention of having to edit Digest inside context.xml here https://tomcat.apache.org/tomcat-9.0-doc/realm-howto.html Tried SHA-256, couldn’t get it to work. But MD5 does. Thanks again. This e-mail and any files transmitted with it are the property of Arthrex, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 239-643-5553 and delete this message immediately from your computer. Any other use, retention, dissemination forwarding, printing or copying of this e-mail is strictly prohibited. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, while Arthrex uses virus protection, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
Re: CredentialHandler not working for MD5
Mark, On 11/17/23 03:55, Mark Thomas wrote: On 16/11/2023 18:06, Peter Otto wrote: 1. Configure BASIC auth with clear-text passwords in the Realm and get that working. 2. Switch to DIGEST auth with clear-text passwords in the Realm and get that working. 3. Then configure DIGEST auth and digested passwords in the Realm. Hi Chris, Step 1 & 2 work Step 3 will not work with the clear txt password, only the digested password, which means the text password in tomcat-users.xml. In past versions of Tomcat, the clear text password would work. Testing with the manager application. Step 1: Use the following user in tomcat-users.xml Step 2: Edit $CATALINA_BASE/webapps/manager/WEB-INF/web.xml BASIC changed to DIGEST Step 3: Edit $CATALINA_BASE/webapps/manager/META-INF/context.xml to specify MD5 digest (rather than default of SHA-256) ... Modify Realm configuration in server.xml Calculate password value for tomcat-users.xml digest.sh -a MD5 -s 0 \"both:Tomcat Manager Application:tomcat\" both:Tomcat Manager Application:tomcat:802b9260bb5c0837169f99e64aca2fd0 Update tomcat-users.xml roles="manager-gui"/> As expected, this works. I will note it took me a couple of attempts to get right as I had some typos in my configuration. If you use the default digest of SHA-256 then you don't need to configure the DigestAuthenticator in the content.xml file. If you want to default to SHA-256 but fall back to MD5 for clients that don't support DIGEST auth with SHA-256 then you need to next two realms in the LockOut realm. s/next/nest/ One you configure all you users with MD5 passwords and MD5 credential handler. The other you configure all your users with SHA256 passwords and a SHA256 credential handler. i.e. you have two Realms that duplicate the user names but use different digests to calculate the passwords. Peter, while this is entirely technically possible, it's pointless: the purpose in hashing passwords is to protect the stored credentials from being compromised by either the stewards of those credentials (the system administrators) or by some third-party adversary. If you have both MD5 and SHA-256 hashes available on the server, an adversary will ignore the SHA-256 hashes and use the MD5 hashes instead. So if you can guarantee that all your clients support SHA-256, then that's what you should use. Otherwise, you will be stuck with MD5 forever, anyway, so you may as well have a less needlessly-complicated configuration. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CredentialHandler not working for MD5
On 16/11/2023 18:06, Peter Otto wrote: 1. Configure BASIC auth with clear-text passwords in the Realm and get that working. 2. Switch to DIGEST auth with clear-text passwords in the Realm and get that working. 3. Then configure DIGEST auth and digested passwords in the Realm. Hi Chris, Step 1 & 2 work Step 3 will not work with the clear txt password, only the digested password, which means the text password in tomcat-users.xml. In past versions of Tomcat, the clear text password would work. Testing with the manager application. Step 1: Use the following user in tomcat-users.xml Step 2: Edit $CATALINA_BASE/webapps/manager/WEB-INF/web.xml BASIC changed to DIGEST Step 3: Edit $CATALINA_BASE/webapps/manager/META-INF/context.xml to specify MD5 digest (rather than default of SHA-256) ... Modify Realm configuration in server.xml Calculate password value for tomcat-users.xml digest.sh -a MD5 -s 0 \"both:Tomcat Manager Application:tomcat\" both:Tomcat Manager Application:tomcat:802b9260bb5c0837169f99e64aca2fd0 Update tomcat-users.xml roles="manager-gui"/> As expected, this works. I will note it took me a couple of attempts to get right as I had some typos in my configuration. If you use the default digest of SHA-256 then you don't need to configure the DigestAuthenticator in the content.xml file. If you want to default to SHA-256 but fall back to MD5 for clients that don't support DIGEST auth with SHA-256 then you need to next two realms in the LockOut realm. One you configure all you users with MD5 passwords and MD5 credential handler. The other you configure all your users with SHA256 passwords and a SHA256 credential handler. i.e. you have two Realms that duplicate the user names but use different digests to calculate the passwords. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CredentialHandler not working for MD5
Peter, On 11/16/23 13:06, Peter Otto wrote: 1. Configure BASIC auth with clear-text passwords in the Realm and get that working. 2. Switch to DIGEST auth with clear-text passwords in the Realm and get that working. 3. Then configure DIGEST auth and digested passwords in the Realm. Hi Chris, Step 1 & 2 work Good. Step 3 will not work with the clear txt password, only the digested password, which means the text password in tomcat-users.xml. In past versions of Tomcat, the clear text password would work. What does your Authentication request header look like? On line # 1154 in Realmbase.java we read. String digestValue = username + ":" + realmName + ":" + getPassword(username); The method getPassword(username) is using the digested password, when it should use the clear text password. Here is how I run digest in powershell. .\digest.bat -a MD5 -i 1 -s 0 tomcat:UserDatabase:nobueno RealmBase.java is not using the clear text password, instead it is using the digested password. This will return false for the manager access. When I replace the getPassword(username) and replace it with the clear text password, it will then WORK. How did you configure things for Mark's #3 task above? Including the commands you used to generate the stored-credential? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CredentialHandler not working for MD5
1. Configure BASIC auth with clear-text passwords in the Realm and get that working. 2. Switch to DIGEST auth with clear-text passwords in the Realm and get that working. 3. Then configure DIGEST auth and digested passwords in the Realm. Hi Chris, Step 1 & 2 work Step 3 will not work with the clear txt password, only the digested password, which means the text password in tomcat-users.xml. In past versions of Tomcat, the clear text password would work. On line # 1154 in Realmbase.java we read. String digestValue = username + ":" + realmName + ":" + getPassword(username); The method getPassword(username) is using the digested password, when it should use the clear text password. Here is how I run digest in powershell. .\digest.bat -a MD5 -i 1 -s 0 tomcat:UserDatabase:nobueno RealmBase.java is not using the clear text password, instead it is using the digested password. This will return false for the manager access. When I replace the getPassword(username) and replace it with the clear text password, it will then WORK. This e-mail and any files transmitted with it are the property of Arthrex, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 239-643-5553 and delete this message immediately from your computer. Any other use, retention, dissemination forwarding, printing or copying of this e-mail is strictly prohibited. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, while Arthrex uses virus protection, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
Re: CredentialHandler not working for MD5
You are confusing DIGEST authentication and digested passwords. The two are separate but related processes. If you use both, you do need to ensure that they are using the same digest. There is no need to modify code. This call all be controlled via configuration. https://tomcat.apache.org/tomcat-9.0-doc/realm-howto.html#Digested_Passwords Look for "If using digested passwords with DIGEST authentication" I suggest you do this in stages. 1. Configure BASIC auth with clear-text passwords in the Realm and get that working. 2. Switch to DIGEST auth with clear-text passwords in the Realm and get that working. 3. Then configure DIGEST auth and digested passwords in the Realm. Mark On 14/11/2023 00:04, Peter Otto wrote: More info…. In the Request Header-> Authorization->Response. Response is used as the clientDigest. However this response is generated, it is incorrect. Need to understand where Tomcat generates this Response because it is used for comparison of the serverDigest. And if the server digest equals the clientDigest, then it works. The way I understand it, the clientDigest comes from the client entering in the username/pwd on the popup box. From: Peter Otto Date: Monday, November 13, 2023 at 11:05 AM To: Tomcat Users List Subject: Re: CredentialHandler not working for MD5 Chris, Running the debugger, I found out the DigestAuthenticator wants to use SHA-256. 8 months ago there was a change for RFC 7616. https://urldefense.com/v3/__https://github.com/apache/tomcat/blob/9.0.74/java/org/apache/catalina/authenticator/DigestAuthenticator.java__;!!P192cPdC!gngwaC1JS3mDrQRjm-kpcOFNPuIBaF56P2aVV9vgLqK1CJAqprPgZBsUjm671wxFYUYKD6tJCCzjvQLczAw0$<https://urldefense.com/v3/__https:/github.com/apache/tomcat/blob/9.0.74/java/org/apache/catalina/authenticator/DigestAuthenticator.java__;!!P192cPdC!gngwaC1JS3mDrQRjm-kpcOFNPuIBaF56P2aVV9vgLqK1CJAqprPgZBsUjm671wxFYUYKD6tJCCzjvQLczAw0$> To bypass the array of digest, I commented out some code so it was forced to use MD5 only. But In the RealmBase, I really don’t understand what getDigest is doing. When I create a MD5 digest, I use Username:Realm:Password. In the code it is using Nonce, nc, cnonce, gop….. From: Christopher Schultz Date: Friday, November 10, 2023 at 1:44 PM To: users@tomcat.apache.org Subject: Re: CredentialHandler not working for MD5 Peter, On 11/10/23 16:30, Peter Otto wrote: With 9.0.82, and the latest version 10, I get the same problem. So I assume it stopped working since 9.0.74 all the way up to 9.0.82 Removing the Realm LockOutRealm did not work either. Thanks for double-checking both of those. I don't see anything in the changelog that seems like it would be related. Thing I suspect are related were in an earlier release. Are you able to run under a debugger, and are you comfortable doing that? It's pretty easy to set a breakpoint in the Realm and/or CredentialHandler to see what's being done when you try to authenticate. -chris From: Christopher Schultz Date: Friday, November 10, 2023 at 12:35 PM To: users@tomcat.apache.org Subject: Re: CredentialHandler not working for MD5 Peter, On 11/10/23 13:27, Peter Otto wrote: Logging into manager using MD5 works in 9.0.73 but now fails in 9.0.74->current Steps to reproduce. Step 1. Run C:\tomcat\bin> .\digest.bat -a md5 -s 0 -i 1 tomcat:UserDatabase:nobueno tomcat:UserDatabase:nobueno:bb6c1c32b9b6df4f707c0e58f2c900e0 Step 2. Use the digest # and place it in tomcat-users.xml Step 3. Edit server.xml and add the CredentialHandler to use MD5 Step 4. Edit the web.xml in manager to say DIGEST UserDatabase Step 5 start tomcat and try to access the manager. On WIndows 2019 server/Chrome/OpenJDK11 type tomcat for the user and nobueno for the password. This would work on versions 9.0.73 and earlier This stopped working from 9.0.74 and onwards. The way to access the manager from 9.0.74+ is to use bb6c1c32b9b6df4f707c0e58f2c900e0 as the password. In other words the text in tomcat-user.xml is the password. Anyone have any ideas how to fix this? I have to use 9.0.74+ version of tomcat because of CVEs. If you temporarily remove the LockOutRealm, does the correct password work? If you upgrade to 9.0.82, does the correct password work? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This e-mail and any files transmitted with it are the property of Arthrex, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 239-643-5553 and delete this message immediately from your computer. Any other us
Re: CredentialHandler not working for MD5
More info…. In the Request Header-> Authorization->Response. Response is used as the clientDigest. However this response is generated, it is incorrect. Need to understand where Tomcat generates this Response because it is used for comparison of the serverDigest. And if the server digest equals the clientDigest, then it works. The way I understand it, the clientDigest comes from the client entering in the username/pwd on the popup box. From: Peter Otto Date: Monday, November 13, 2023 at 11:05 AM To: Tomcat Users List Subject: Re: CredentialHandler not working for MD5 Chris, Running the debugger, I found out the DigestAuthenticator wants to use SHA-256. 8 months ago there was a change for RFC 7616. https://urldefense.com/v3/__https://github.com/apache/tomcat/blob/9.0.74/java/org/apache/catalina/authenticator/DigestAuthenticator.java__;!!P192cPdC!gngwaC1JS3mDrQRjm-kpcOFNPuIBaF56P2aVV9vgLqK1CJAqprPgZBsUjm671wxFYUYKD6tJCCzjvQLczAw0$<https://urldefense.com/v3/__https:/github.com/apache/tomcat/blob/9.0.74/java/org/apache/catalina/authenticator/DigestAuthenticator.java__;!!P192cPdC!gngwaC1JS3mDrQRjm-kpcOFNPuIBaF56P2aVV9vgLqK1CJAqprPgZBsUjm671wxFYUYKD6tJCCzjvQLczAw0$> To bypass the array of digest, I commented out some code so it was forced to use MD5 only. But In the RealmBase, I really don’t understand what getDigest is doing. When I create a MD5 digest, I use Username:Realm:Password. In the code it is using Nonce, nc, cnonce, gop….. From: Christopher Schultz Date: Friday, November 10, 2023 at 1:44 PM To: users@tomcat.apache.org Subject: Re: CredentialHandler not working for MD5 Peter, On 11/10/23 16:30, Peter Otto wrote: > With 9.0.82, and the latest version 10, I get the same problem. > So I assume it stopped working since 9.0.74 all the way up to 9.0.82 > > Removing the Realm LockOutRealm did not work either. Thanks for double-checking both of those. I don't see anything in the changelog that seems like it would be related. Thing I suspect are related were in an earlier release. Are you able to run under a debugger, and are you comfortable doing that? It's pretty easy to set a breakpoint in the Realm and/or CredentialHandler to see what's being done when you try to authenticate. -chris > From: Christopher Schultz > Date: Friday, November 10, 2023 at 12:35 PM > To: users@tomcat.apache.org > Subject: Re: CredentialHandler not working for MD5 > Peter, > > On 11/10/23 13:27, Peter Otto wrote: >> Logging into manager using MD5 works in 9.0.73 but now fails in >> 9.0.74->current >> Steps to reproduce. >> >> Step 1. Run C:\tomcat\bin> .\digest.bat -a md5 -s 0 -i 1 >> tomcat:UserDatabase:nobueno >> >> tomcat:UserDatabase:nobueno:bb6c1c32b9b6df4f707c0e58f2c900e0 >> >> >> Step 2. Use the digest # and place it in tomcat-users.xml >> >> >> > roles="manager-gui,manager-script"/> >> >> >> Step 3. Edit server.xml and add the CredentialHandler to use MD5 >> >> >> > resourceName="UserDatabase"> >> > className="org.apache.catalina.realm.MessageDigestCredentialHandler" >> algorithm="MD5" /> >> >> >> >> >> >> Step 4. Edit the web.xml in manager to say >> >> DIGEST >> UserDatabase >> >> >> Step 5 start tomcat and try to access the manager. >> On WIndows 2019 server/Chrome/OpenJDK11 type tomcat for the user >> and nobueno for the password. >> >> This would work on versions 9.0.73 and earlier >> >> This stopped working from 9.0.74 and onwards. >> The way to access the manager from 9.0.74+ is to use >> bb6c1c32b9b6df4f707c0e58f2c900e0 as the password. >> In other words the text in tomcat-user.xml is the password. >> >> Anyone have any ideas how to fix this? I have to use 9.0.74+ version of >> tomcat because of CVEs. > > If you temporarily remove the LockOutRealm, does the correct password work? > > If you upgrade to 9.0.82, does the correct password work? > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > This e-mail and any files transmitted with it are the property of Arthrex, > Inc. and/or its affiliates, are confidential, and are intended solely for the > use of the individual or entity to whom this e-mail is addressed. If you are > not one of the named recipient(s) or otherwise have reason to believe that > you have received this message in error, please notify the sender at > 239-643-5553 and delete this message immediately from your computer. Any > other use, rete
Re: CredentialHandler not working for MD5
Chris, Running the debugger, I found out the DigestAuthenticator wants to use SHA-256. 8 months ago there was a change for RFC 7616. https://github.com/apache/tomcat/blob/9.0.74/java/org/apache/catalina/authenticator/DigestAuthenticator.java To bypass the array of digest, I commented out some code so it was forced to use MD5 only. But In the RealmBase, I really don’t understand what getDigest is doing. When I create a MD5 digest, I use Username:Realm:Password. In the code it is using Nonce, nc, cnonce, gop….. From: Christopher Schultz Date: Friday, November 10, 2023 at 1:44 PM To: users@tomcat.apache.org Subject: Re: CredentialHandler not working for MD5 Peter, On 11/10/23 16:30, Peter Otto wrote: > With 9.0.82, and the latest version 10, I get the same problem. > So I assume it stopped working since 9.0.74 all the way up to 9.0.82 > > Removing the Realm LockOutRealm did not work either. Thanks for double-checking both of those. I don't see anything in the changelog that seems like it would be related. Thing I suspect are related were in an earlier release. Are you able to run under a debugger, and are you comfortable doing that? It's pretty easy to set a breakpoint in the Realm and/or CredentialHandler to see what's being done when you try to authenticate. -chris > From: Christopher Schultz > Date: Friday, November 10, 2023 at 12:35 PM > To: users@tomcat.apache.org > Subject: Re: CredentialHandler not working for MD5 > Peter, > > On 11/10/23 13:27, Peter Otto wrote: >> Logging into manager using MD5 works in 9.0.73 but now fails in >> 9.0.74->current >> Steps to reproduce. >> >> Step 1. Run C:\tomcat\bin> .\digest.bat -a md5 -s 0 -i 1 >> tomcat:UserDatabase:nobueno >> >> tomcat:UserDatabase:nobueno:bb6c1c32b9b6df4f707c0e58f2c900e0 >> >> >> Step 2. Use the digest # and place it in tomcat-users.xml >> >> >> > roles="manager-gui,manager-script"/> >> >> >> Step 3. Edit server.xml and add the CredentialHandler to use MD5 >> >> >> > resourceName="UserDatabase"> >> > className="org.apache.catalina.realm.MessageDigestCredentialHandler" >> algorithm="MD5" /> >> >> >> >> >> >> Step 4. Edit the web.xml in manager to say >> >> DIGEST >> UserDatabase >> >> >> Step 5 start tomcat and try to access the manager. >> On WIndows 2019 server/Chrome/OpenJDK11 type tomcat for the user >> and nobueno for the password. >> >> This would work on versions 9.0.73 and earlier >> >> This stopped working from 9.0.74 and onwards. >> The way to access the manager from 9.0.74+ is to use >> bb6c1c32b9b6df4f707c0e58f2c900e0 as the password. >> In other words the text in tomcat-user.xml is the password. >> >> Anyone have any ideas how to fix this? I have to use 9.0.74+ version of >> tomcat because of CVEs. > > If you temporarily remove the LockOutRealm, does the correct password work? > > If you upgrade to 9.0.82, does the correct password work? > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > This e-mail and any files transmitted with it are the property of Arthrex, > Inc. and/or its affiliates, are confidential, and are intended solely for the > use of the individual or entity to whom this e-mail is addressed. If you are > not one of the named recipient(s) or otherwise have reason to believe that > you have received this message in error, please notify the sender at > 239-643-5553 and delete this message immediately from your computer. Any > other use, retention, dissemination forwarding, printing or copying of this > e-mail is strictly prohibited. Please note that any views or opinions > presented in this email are solely those of the author and do not necessarily > represent those of the company. Finally, while Arthrex uses virus protection, > the recipient should check this email and any attachments for the presence of > viruses. The company accepts no liability for any damage caused by any virus > transmitted by this email. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This e-mail and any files transmitted with it are the property of Arthrex, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) o
Re: CredentialHandler not working for MD5
Peter, On 11/10/23 16:30, Peter Otto wrote: With 9.0.82, and the latest version 10, I get the same problem. So I assume it stopped working since 9.0.74 all the way up to 9.0.82 Removing the Realm LockOutRealm did not work either. Thanks for double-checking both of those. I don't see anything in the changelog that seems like it would be related. Thing I suspect are related were in an earlier release. Are you able to run under a debugger, and are you comfortable doing that? It's pretty easy to set a breakpoint in the Realm and/or CredentialHandler to see what's being done when you try to authenticate. -chris From: Christopher Schultz Date: Friday, November 10, 2023 at 12:35 PM To: users@tomcat.apache.org Subject: Re: CredentialHandler not working for MD5 Peter, On 11/10/23 13:27, Peter Otto wrote: Logging into manager using MD5 works in 9.0.73 but now fails in 9.0.74->current Steps to reproduce. Step 1. Run C:\tomcat\bin> .\digest.bat -a md5 -s 0 -i 1 tomcat:UserDatabase:nobueno tomcat:UserDatabase:nobueno:bb6c1c32b9b6df4f707c0e58f2c900e0 Step 2. Use the digest # and place it in tomcat-users.xml Step 3. Edit server.xml and add the CredentialHandler to use MD5 Step 4. Edit the web.xml in manager to say DIGEST UserDatabase Step 5 start tomcat and try to access the manager. On WIndows 2019 server/Chrome/OpenJDK11 type tomcat for the user and nobueno for the password. This would work on versions 9.0.73 and earlier This stopped working from 9.0.74 and onwards. The way to access the manager from 9.0.74+ is to use bb6c1c32b9b6df4f707c0e58f2c900e0 as the password. In other words the text in tomcat-user.xml is the password. Anyone have any ideas how to fix this? I have to use 9.0.74+ version of tomcat because of CVEs. If you temporarily remove the LockOutRealm, does the correct password work? If you upgrade to 9.0.82, does the correct password work? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This e-mail and any files transmitted with it are the property of Arthrex, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 239-643-5553 and delete this message immediately from your computer. Any other use, retention, dissemination forwarding, printing or copying of this e-mail is strictly prohibited. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, while Arthrex uses virus protection, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CredentialHandler not working for MD5
Chris, With 9.0.82, and the latest version 10, I get the same problem. So I assume it stopped working since 9.0.74 all the way up to 9.0.82 Removing the Realm LockOutRealm did not work either. Thanks From: Christopher Schultz Date: Friday, November 10, 2023 at 12:35 PM To: users@tomcat.apache.org Subject: Re: CredentialHandler not working for MD5 Peter, On 11/10/23 13:27, Peter Otto wrote: > Logging into manager using MD5 works in 9.0.73 but now fails in > 9.0.74->current > Steps to reproduce. > > Step 1. Run C:\tomcat\bin> .\digest.bat -a md5 -s 0 -i 1 > tomcat:UserDatabase:nobueno > > tomcat:UserDatabase:nobueno:bb6c1c32b9b6df4f707c0e58f2c900e0 > > > Step 2. Use the digest # and place it in tomcat-users.xml > > > roles="manager-gui,manager-script"/> > > > Step 3. Edit server.xml and add the CredentialHandler to use MD5 > > > resourceName="UserDatabase"> > className="org.apache.catalina.realm.MessageDigestCredentialHandler" > algorithm="MD5" /> > > > > > > Step 4. Edit the web.xml in manager to say > > DIGEST > UserDatabase > > > Step 5 start tomcat and try to access the manager. > On WIndows 2019 server/Chrome/OpenJDK11 type tomcat for the user > and nobueno for the password. > > This would work on versions 9.0.73 and earlier > > This stopped working from 9.0.74 and onwards. > The way to access the manager from 9.0.74+ is to use > bb6c1c32b9b6df4f707c0e58f2c900e0 as the password. > In other words the text in tomcat-user.xml is the password. > > Anyone have any ideas how to fix this? I have to use 9.0.74+ version of > tomcat because of CVEs. If you temporarily remove the LockOutRealm, does the correct password work? If you upgrade to 9.0.82, does the correct password work? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This e-mail and any files transmitted with it are the property of Arthrex, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 239-643-5553 and delete this message immediately from your computer. Any other use, retention, dissemination forwarding, printing or copying of this e-mail is strictly prohibited. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, while Arthrex uses virus protection, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
Re: CredentialHandler not working for MD5
Peter, On 11/10/23 13:27, Peter Otto wrote: Logging into manager using MD5 works in 9.0.73 but now fails in 9.0.74->current Steps to reproduce. Step 1. Run C:\tomcat\bin> .\digest.bat -a md5 -s 0 -i 1 tomcat:UserDatabase:nobueno tomcat:UserDatabase:nobueno:bb6c1c32b9b6df4f707c0e58f2c900e0 Step 2. Use the digest # and place it in tomcat-users.xml Step 3. Edit server.xml and add the CredentialHandler to use MD5 Step 4. Edit the web.xml in manager to say DIGEST UserDatabase Step 5 start tomcat and try to access the manager. On WIndows 2019 server/Chrome/OpenJDK11 type tomcat for the user and nobueno for the password. This would work on versions 9.0.73 and earlier This stopped working from 9.0.74 and onwards. The way to access the manager from 9.0.74+ is to use bb6c1c32b9b6df4f707c0e58f2c900e0 as the password. In other words the text in tomcat-user.xml is the password. Anyone have any ideas how to fix this? I have to use 9.0.74+ version of tomcat because of CVEs. If you temporarily remove the LockOutRealm, does the correct password work? If you upgrade to 9.0.82, does the correct password work? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
CredentialHandler not working for MD5
Logging into manager using MD5 works in 9.0.73 but now fails in 9.0.74->current Steps to reproduce. Step 1. Run C:\tomcat\bin> .\digest.bat -a md5 -s 0 -i 1 tomcat:UserDatabase:nobueno tomcat:UserDatabase:nobueno:bb6c1c32b9b6df4f707c0e58f2c900e0 Step 2. Use the digest # and place it in tomcat-users.xml Step 3. Edit server.xml and add the CredentialHandler to use MD5 Step 4. Edit the web.xml in manager to say DIGEST UserDatabase Step 5 start tomcat and try to access the manager. On WIndows 2019 server/Chrome/OpenJDK11 type tomcat for the user and nobueno for the password. This would work on versions 9.0.73 and earlier This stopped working from 9.0.74 and onwards. The way to access the manager from 9.0.74+ is to use bb6c1c32b9b6df4f707c0e58f2c900e0 as the password. In other words the text in tomcat-user.xml is the password. Anyone have any ideas how to fix this? I have to use 9.0.74+ version of tomcat because of CVEs. Thank you all This e-mail and any files transmitted with it are the property of Arthrex, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 239-643-5553 and delete this message immediately from your computer. Any other use, retention, dissemination forwarding, printing or copying of this e-mail is strictly prohibited. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, while Arthrex uses virus protection, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
RE: CredentialHandler tomcat 7
Hi Chris! Our app is happily running on Tomcat 9.0.64 on our test server. The problem is that unlike our test server which faces the web directly, our production tomcat is behind nginx server which both acts as DDOS protection mechanism as well as SSO idp server, so our users can use two apps with same login credentials(both apps use same db for user info storage). When I tried to install 9.064 on production server about year ago, I discovered that all the static data from our app (jpg,js,css etc.)doesn't get loaded. The only static data which was available was the data inlined inside the jsp pages themselves. Since that meant that we have pretty much have an unusable app and I didn't have time to investigate the root cause at the time I've reverted back to tomcat 7.0.92. Oddly enough nothing was actually changed on the nginx serverat the time of the switch. I'm hoping that next time I'll attempt the upgrade of our production server, installing latest version of 9.0 branch might fix the issue, although I'm not sure.(unfortunately nginx server is in the different department and not under my control) Thank you for the clarification and for all the help От: Christopher Schultz Отправлено: 23 октября 2023 г. 19:24 Кому: users@tomcat.apache.org Тема: Re: CredentialHandler tomcat 7 Chuck, On 10/22/23 13:55, Chuck Caldarale wrote: >> On Oct 22, 2023, at 10:02, Усманов Азат Анварович wrote: >> >> Hi everyone! I'm trying to use CredentialHandler with tomcat to increase >> security since our db at $work still has pwd stored as md5 hashes. Some of >> our servers still use tomcat 7.092/ I was looking at this presentation by >> Christopher Shultz >> http://people.apache.org/~schultz/ApacheCon%20NA%202017/Seamless%20Upgrades%20for%20Credential%20Security%20in%20Apache%20Tomcat.pdf >> it mentions that Credention handler should be available to a web app in >> Tomcat 7.0.70+ But then I looked up source code for catalina.jar in 7.0.92 >> and 7.0.109-src I cant find class Named CredentialHandler.Am I looking at >> the wrong place or is it just not available in tomcat 7 ? Also tomcat docs >> for 7 doesn't seem to mention CredentialHandler at all.. > > > > Looks like the CredentialHandler mechanism was introduced in 8.0.15 (November > 2014), with no indication that it would ever be retrofitted to any 7.0.x > version. (The footnote on slide 30 of the cited presentation appears to be in > error.) Yeah, I have no idea where I got the 7.0.70 version number from. Maybe I guessed it while drafting and never confirmed it. Sorry, Азат, it looks like I got that one wrong. > Given that Tomcat 7.0 has not been supported for over two years and numerous > issues have been addressed in the intervening time period, it might be time > to upgrade… +1 At this point, 7.0 is essentially 2 versions back form the currently-supported version of Tomcat (8.5.x) which itself is scheduled to be retired at the end of this coming March -- a mere 5 months from now. I don't see any appetite for anybody -- myself included -- working on a back-port for this to Tomcat 7. I would encourage you to upgrade to Tomcat 9. I suspect you'll find that your application runs with very few if any issues if you just upgrade in a development environment and run a test. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CredentialHandler tomcat 7
Chuck, On 10/22/23 13:55, Chuck Caldarale wrote: On Oct 22, 2023, at 10:02, Усманов Азат Анварович wrote: Hi everyone! I'm trying to use CredentialHandler with tomcat to increase security since our db at $work still has pwd stored as md5 hashes. Some of our servers still use tomcat 7.092/ I was looking at this presentation by Christopher Shultz http://people.apache.org/~schultz/ApacheCon%20NA%202017/Seamless%20Upgrades%20for%20Credential%20Security%20in%20Apache%20Tomcat.pdf it mentions that Credention handler should be available to a web app in Tomcat 7.0.70+ But then I looked up source code for catalina.jar in 7.0.92 and 7.0.109-src I cant find class Named CredentialHandler.Am I looking at the wrong place or is it just not available in tomcat 7 ? Also tomcat docs for 7 doesn't seem to mention CredentialHandler at all.. Looks like the CredentialHandler mechanism was introduced in 8.0.15 (November 2014), with no indication that it would ever be retrofitted to any 7.0.x version. (The footnote on slide 30 of the cited presentation appears to be in error.) Yeah, I have no idea where I got the 7.0.70 version number from. Maybe I guessed it while drafting and never confirmed it. Sorry, Азат, it looks like I got that one wrong. Given that Tomcat 7.0 has not been supported for over two years and numerous issues have been addressed in the intervening time period, it might be time to upgrade… +1 At this point, 7.0 is essentially 2 versions back form the currently-supported version of Tomcat (8.5.x) which itself is scheduled to be retired at the end of this coming March -- a mere 5 months from now. I don't see any appetite for anybody -- myself included -- working on a back-port for this to Tomcat 7. I would encourage you to upgrade to Tomcat 9. I suspect you'll find that your application runs with very few if any issues if you just upgrade in a development environment and run a test. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CredentialHandler tomcat 7
> On Oct 22, 2023, at 10:02, Усманов Азат Анварович wrote: > > Hi everyone! I'm trying to use CredentialHandler with tomcat to increase > security since our db at $work still has pwd stored as md5 hashes. Some of > our servers still use tomcat 7.092/ I was looking at this presentation by > Christopher Shultz > http://people.apache.org/~schultz/ApacheCon%20NA%202017/Seamless%20Upgrades%20for%20Credential%20Security%20in%20Apache%20Tomcat.pdf > it mentions that Credention handler should be available to a web app in > Tomcat 7.0.70+ But then I looked up source code for catalina.jar in 7.0.92 > and 7.0.109-src I cant find class Named CredentialHandler.Am I looking at > the wrong place or is it just not available in tomcat 7 ? Also tomcat docs > for 7 doesn't seem to mention CredentialHandler at all.. Looks like the CredentialHandler mechanism was introduced in 8.0.15 (November 2014), with no indication that it would ever be retrofitted to any 7.0.x version. (The footnote on slide 30 of the cited presentation appears to be in error.) Given that Tomcat 7.0 has not been supported for over two years and numerous issues have been addressed in the intervening time period, it might be time to upgrade… - Chuck - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
CredentialHandler tomcat 7
Hi everyone! I'm trying to use CredentialHandler with tomcat to increase security since our db at $work still has pwd stored as md5 hashes. Some of our servers still use tomcat 7.092/ I was looking at this presentation by Christopher Shultz http://people.apache.org/~schultz/ApacheCon%20NA%202017/Seamless%20Upgrades%20for%20Credential%20Security%20in%20Apache%20Tomcat.pdf it mentions that Credention handler should be available to a web app in Tomcat 7.0.70+ But then I looked up source code for catalina.jar in 7.0.92 and 7.0.109-src I cant find class Named CredentialHandler.Am I looking at the wrong place or is it just not available in tomcat 7 ? Also tomcat docs for 7 doesn't seem to mention CredentialHandler at all..
Re: Why does LockOutRealm not support CredentialHandler?
Rémy, On 11/17/22 05:07, Rémy Maucherat wrote: On Wed, Nov 16, 2022 at 6:14 PM Christopher Schultz wrote: Rémy, On 11/16/22 07:53, Rémy Maucherat wrote: On Wed, Nov 16, 2022 at 1:36 PM Christopher Schultz wrote: Thorsten, On 11/16/22 03:20, Thorsten Schöning wrote: Guten Tag Christopher Schultz, am Mittwoch, 16. November 2022 um 04:50 schrieben Sie: That worked right from the start, I had a DIGEST in tomcat-users.xml and was able to login with plain-text password provided to the browser. The use of the word "digest" is overloaded, particularly for this discussion. Please try to use "HTTP DIGEST" when you mean the on-the-wire authentication protocol and "hashed credential" when you mean the stuff you drop into an authentication database. It will make things a lot easier to understand for all parties involved. ... Adding that didn't work, I was only able to login with providing the DIGEST of tomcat-users.xml as password to the browser, which actually made it a plain-text password at the server. The following fit as well to what I recognized: https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm BUT: I gave things an additional try now and especially after the discussion about auth-method BASIC vs. DIGEST and login DOES work now! So both the UserDatabase realm and the LockOutRealm as I suggested above are now working as expected? I most likely not only added LockOutRealm at some point, but switched from BASIC auth to DIGEST as well, because I've read that in the CIS spec I worked with. That combination can't work and at some point I most likely became frustrated and changed DIGEST back to BASIC, while having changed other aspects of the realms already or might have simply forgotten to change passwords vs. digests in tomcat-users.xml or whatever. So, I guess the reason for the warnign about an ignored credential helper in LockOutRealm simply is because it doesn't handle credentials at all? And as LockOutRealm forwards actual login to its children THEIR assigned credential handlers are properly taken into account? Yes, no CombinedRealm ever uses its configured CredentialHandler, which is why the warning is shown. There is a very specific case in which you WANT to configure a CredentialHandler for a CombinedRealm, and that's when your application is using the CredentialHandler directy for certain things. That doesn't seem to be your use-case, so I won't detail that, here. If you re-visit the SO question you posted yesterday, you'll see that I posted an Answer which describes that a little more. So whatever the SO-guy sees, might have a different root cause, as it was the case for me. Thanks for triggering me to try again! Might have been to late already at Monday as well. :-) I'm glad it's working. After reading Rémy's initial response, I was thinking that something needed to be done, but there is no problem IMO. If you need a CredentialHandler in your application, you can still use LockOutRealm (or any other CombinedRealm); you just have to specify a CredentialHandler to use on that outer Realm and all is well. And you have to ignore that warning. Sure, but I plan to try something a little better because why not. I guess we could add a configuration option to CombinedRealm: inheritCredentialHandler="first|last|numeric-position|false/off/no" ? Then you'd only have to declare it once and then you have the flexibility of inheriting it or not. But you'd have to opt-into it instead of getting a surprise. Right now the feature is simply too weird, so I'll simply improve it: - It doesn't work if this is a CombinedRealm, so since they are now used all the time this is rather annoying. - For some reason it only sets the attribute if the Realm is on the Context. For example it will not set anything if the realm is on the Host. So instead, I will make these changes: - CombinedRealm will get its own special credential handler if none is set (it will behave like the nested credential handler, except on nested realm.getCredentialHandler()). So it will just always inherit the CredentialHandler from the first Realm? Make sure it works if there are realms nested N levels deep (e.g. LockOutRealm, SomeCombinedRealm, RealRealm). -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
On Thu, Nov 17, 2022 at 11:22 AM Mark Thomas wrote: > > On 17/11/2022 10:07, Rémy Maucherat wrote: > > On Wed, Nov 16, 2022 at 6:14 PM Christopher Schultz > > > > >> I guess we could add a configuration option to CombinedRealm: > >> > >> inheritCredentialHandler="first|last|numeric-position|false/off/no" > >> > >> ? > >> > >> Then you'd only have to declare it once and then you have the > >> flexibility of inheriting it or not. But you'd have to opt-into it > >> instead of getting a surprise. > > > > Right now the feature is simply too weird, so I'll simply improve it: > > - It doesn't work if this is a CombinedRealm, so since they are now > > used all the time this is rather annoying. > > - For some reason it only sets the attribute if the Realm is on the > > Context. For example it will not set anything if the realm is on the > > Host. > > > > So instead, I will make these changes: > > - CombinedRealm will get its own special credential handler if none is > > set (it will behave like the nested credential handler, except on > > nested realm.getCredentialHandler()). > > - In StandardContext, the attribute will be set based on getRealm() > > instead of getRealmInternal(). > > I don't think we do that as it creates a security concern. An untrusted > application would be able to brute force a Realm it hasn't defined. > > A trusted app can obtain a reference to the Realm via other means. > > I know untrusted apps are rare and becoming rarer but at long as we have > to support the SecurityManager (hopefully not for much longer) then we > have to consider untrusted apps. Ok, I (kind of) understand, and I will remove that part of the change then. Rémy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
On 17/11/2022 10:07, Rémy Maucherat wrote: On Wed, Nov 16, 2022 at 6:14 PM Christopher Schultz I guess we could add a configuration option to CombinedRealm: inheritCredentialHandler="first|last|numeric-position|false/off/no" ? Then you'd only have to declare it once and then you have the flexibility of inheriting it or not. But you'd have to opt-into it instead of getting a surprise. Right now the feature is simply too weird, so I'll simply improve it: - It doesn't work if this is a CombinedRealm, so since they are now used all the time this is rather annoying. - For some reason it only sets the attribute if the Realm is on the Context. For example it will not set anything if the realm is on the Host. So instead, I will make these changes: - CombinedRealm will get its own special credential handler if none is set (it will behave like the nested credential handler, except on nested realm.getCredentialHandler()). - In StandardContext, the attribute will be set based on getRealm() instead of getRealmInternal(). I don't think we do that as it creates a security concern. An untrusted application would be able to brute force a Realm it hasn't defined. A trusted app can obtain a reference to the Realm via other means. I know untrusted apps are rare and becoming rarer but at long as we have to support the SecurityManager (hopefully not for much longer) then we have to consider untrusted apps. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
On Wed, Nov 16, 2022 at 6:14 PM Christopher Schultz wrote: > > Rémy, > > On 11/16/22 07:53, Rémy Maucherat wrote: > > On Wed, Nov 16, 2022 at 1:36 PM Christopher Schultz > > wrote: > >> > >> Thorsten, > >> > >> On 11/16/22 03:20, Thorsten Schöning wrote: > >>> Guten Tag Christopher Schultz, > >>> am Mittwoch, 16. November 2022 um 04:50 schrieben Sie: > >>> > >>>> >>>> resourceName="UserDatabase"> > >>>> >>>> className="org.apache.catalina.realm.SecretKeyCredentialHandler" > >>>>algorithm="PBKDF2WithHmacSHA512" > >>>>iterations="10" > >>>>keyLength="256" > >>>>saltLength="16" > >>>> > >>> > >>> That worked right from the start, I had a DIGEST in tomcat-users.xml > >>> and was able to login with plain-text password provided to the > >>> browser. > >> > >> The use of the word "digest" is overloaded, particularly for this > >> discussion. Please try to use "HTTP DIGEST" when you mean the > >> on-the-wire authentication protocol and "hashed credential" when you > >> mean the stuff you drop into an authentication database. It will make > >> things a lot easier to understand for all parties involved. > >> > >>>> > >>>> ... > >>>> > >>> > >>> Adding that didn't work, I was only able to login with providing the > >>> DIGEST of tomcat-users.xml as password to the browser, which actually > >>> made it a plain-text password at the server. The following fit as well > >>> to what I recognized: > >>> > >>> https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm > >>> > >>> BUT: I gave things an additional try now and especially after the > >>> discussion about auth-method BASIC vs. DIGEST and login DOES work now! > >> > >> So both the UserDatabase realm and the LockOutRealm as I suggested above > >> are now working as expected? > >> > >>> I most likely not only added LockOutRealm at some point, but switched > >>> from BASIC auth to DIGEST as well, because I've read that in the CIS > >>> spec I worked with. That combination can't work and at some point I > >>> most likely became frustrated and changed DIGEST back to BASIC, while > >>> having changed other aspects of the realms already or might have > >>> simply forgotten to change passwords vs. digests in tomcat-users.xml > >>> or whatever. > >>> > >>> So, I guess the reason for the warnign about an ignored credential > >>> helper in LockOutRealm simply is because it doesn't handle credentials > >>> at all? And as LockOutRealm forwards actual login to its children > >>> THEIR assigned credential handlers are properly taken into account? > >> > >> Yes, no CombinedRealm ever uses its configured CredentialHandler, which > >> is why the warning is shown. > >> > >> There is a very specific case in which you WANT to configure a > >> CredentialHandler for a CombinedRealm, and that's when your application > >> is using the CredentialHandler directy for certain things. That doesn't > >> seem to be your use-case, so I won't detail that, here. If you re-visit > >> the SO question you posted yesterday, you'll see that I posted an Answer > >> which describes that a little more. > >> > >>> So whatever the SO-guy sees, might have a different root cause, as it > >>> was the case for me. > >>> > >>> Thanks for triggering me to try again! Might have been to late already > >>> at Monday as well. :-) > >> > >> I'm glad it's working. > >> > >> After reading Rémy's initial response, I was thinking that something > >> needed to be done, but there is no problem IMO. If you need a > >> CredentialHandler in your application, you can still use LockOutRealm > >> (or any other CombinedRealm); you just have to specify a > >> CredentialHandler to use on that outer Realm and all is well. > >> > >> And you have to ignore that warning. > > > > Su
Re: Why does LockOutRealm not support CredentialHandler?
Rémy, On 11/16/22 07:53, Rémy Maucherat wrote: On Wed, Nov 16, 2022 at 1:36 PM Christopher Schultz wrote: Thorsten, On 11/16/22 03:20, Thorsten Schöning wrote: Guten Tag Christopher Schultz, am Mittwoch, 16. November 2022 um 04:50 schrieben Sie: That worked right from the start, I had a DIGEST in tomcat-users.xml and was able to login with plain-text password provided to the browser. The use of the word "digest" is overloaded, particularly for this discussion. Please try to use "HTTP DIGEST" when you mean the on-the-wire authentication protocol and "hashed credential" when you mean the stuff you drop into an authentication database. It will make things a lot easier to understand for all parties involved. ... Adding that didn't work, I was only able to login with providing the DIGEST of tomcat-users.xml as password to the browser, which actually made it a plain-text password at the server. The following fit as well to what I recognized: https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm BUT: I gave things an additional try now and especially after the discussion about auth-method BASIC vs. DIGEST and login DOES work now! So both the UserDatabase realm and the LockOutRealm as I suggested above are now working as expected? I most likely not only added LockOutRealm at some point, but switched from BASIC auth to DIGEST as well, because I've read that in the CIS spec I worked with. That combination can't work and at some point I most likely became frustrated and changed DIGEST back to BASIC, while having changed other aspects of the realms already or might have simply forgotten to change passwords vs. digests in tomcat-users.xml or whatever. So, I guess the reason for the warnign about an ignored credential helper in LockOutRealm simply is because it doesn't handle credentials at all? And as LockOutRealm forwards actual login to its children THEIR assigned credential handlers are properly taken into account? Yes, no CombinedRealm ever uses its configured CredentialHandler, which is why the warning is shown. There is a very specific case in which you WANT to configure a CredentialHandler for a CombinedRealm, and that's when your application is using the CredentialHandler directy for certain things. That doesn't seem to be your use-case, so I won't detail that, here. If you re-visit the SO question you posted yesterday, you'll see that I posted an Answer which describes that a little more. So whatever the SO-guy sees, might have a different root cause, as it was the case for me. Thanks for triggering me to try again! Might have been to late already at Monday as well. :-) I'm glad it's working. After reading Rémy's initial response, I was thinking that something needed to be done, but there is no problem IMO. If you need a CredentialHandler in your application, you can still use LockOutRealm (or any other CombinedRealm); you just have to specify a CredentialHandler to use on that outer Realm and all is well. And you have to ignore that warning. Sure, but I plan to try something a little better because why not. I guess we could add a configuration option to CombinedRealm: inheritCredentialHandler="first|last|numeric-position|false/off/no" ? Then you'd only have to declare it once and then you have the flexibility of inheriting it or not. But you'd have to opt-into it instead of getting a surprise. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
Guten Tag Christopher Schultz, am Mittwoch, 16. November 2022 um 13:35 schrieben Sie: > I really don't know why you are seeing that warning. You aren't > explicitly-setting a CredentialHandler on your LockOutRealm and > that's the only time this warning should be shown.[...] Yes I did during tests when the credential handler didn't work as expected for the user database. I simply moved it up for test purposes, got the warning and thought there was some fundamental underluying problem. Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: +49 5151- 9468- 0 Tel: +49 5151- 9468-55 Mobil: +49 178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. Mit freundlichen Grüßen, Thorsten Schöning Telefon: +49 5151 9468-55 Fax: E-Mail: tschoen...@am-soft.de AM-Soft IT-Service - Bitstore Hameln GmbH Brandenburger Straße 7c 31789 Hameln Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte Information untersagt. This e-mail may contain confidential and/or privileged information and is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Hinweise zum Datenschutz: bitstore.group/datenschutz - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
On Wed, Nov 16, 2022 at 1:36 PM Christopher Schultz wrote: > > Thorsten, > > On 11/16/22 03:20, Thorsten Schöning wrote: > > Guten Tag Christopher Schultz, > > am Mittwoch, 16. November 2022 um 04:50 schrieben Sie: > > > >> >> resourceName="UserDatabase"> > >> >> className="org.apache.catalina.realm.SecretKeyCredentialHandler" > >> algorithm="PBKDF2WithHmacSHA512" > >> iterations="10" > >> keyLength="256" > >> saltLength="16" > >> > > > > That worked right from the start, I had a DIGEST in tomcat-users.xml > > and was able to login with plain-text password provided to the > > browser. > > The use of the word "digest" is overloaded, particularly for this > discussion. Please try to use "HTTP DIGEST" when you mean the > on-the-wire authentication protocol and "hashed credential" when you > mean the stuff you drop into an authentication database. It will make > things a lot easier to understand for all parties involved. > > >> > >> ... > >> > > > > Adding that didn't work, I was only able to login with providing the > > DIGEST of tomcat-users.xml as password to the browser, which actually > > made it a plain-text password at the server. The following fit as well > > to what I recognized: > > > > https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm > > > > BUT: I gave things an additional try now and especially after the > > discussion about auth-method BASIC vs. DIGEST and login DOES work now! > > So both the UserDatabase realm and the LockOutRealm as I suggested above > are now working as expected? > > > I most likely not only added LockOutRealm at some point, but switched > > from BASIC auth to DIGEST as well, because I've read that in the CIS > > spec I worked with. That combination can't work and at some point I > > most likely became frustrated and changed DIGEST back to BASIC, while > > having changed other aspects of the realms already or might have > > simply forgotten to change passwords vs. digests in tomcat-users.xml > > or whatever. > > > > So, I guess the reason for the warnign about an ignored credential > > helper in LockOutRealm simply is because it doesn't handle credentials > > at all? And as LockOutRealm forwards actual login to its children > > THEIR assigned credential handlers are properly taken into account? > > Yes, no CombinedRealm ever uses its configured CredentialHandler, which > is why the warning is shown. > > There is a very specific case in which you WANT to configure a > CredentialHandler for a CombinedRealm, and that's when your application > is using the CredentialHandler directy for certain things. That doesn't > seem to be your use-case, so I won't detail that, here. If you re-visit > the SO question you posted yesterday, you'll see that I posted an Answer > which describes that a little more. > > > So whatever the SO-guy sees, might have a different root cause, as it > > was the case for me. > > > > Thanks for triggering me to try again! Might have been to late already > > at Monday as well. :-) > > I'm glad it's working. > > After reading Rémy's initial response, I was thinking that something > needed to be done, but there is no problem IMO. If you need a > CredentialHandler in your application, you can still use LockOutRealm > (or any other CombinedRealm); you just have to specify a > CredentialHandler to use on that outer Realm and all is well. > > And you have to ignore that warning. Sure, but I plan to try something a little better because why not. Rémy > I really don't know why you are seeing that warning. You aren't > explicitly-setting a CredentialHandler on your LockOutRealm and that's > the only time this warning should be shown. When > CombinedRealm.startInternal runs, it creates a trivial CredentialHandler > (I'm not sure why it does that, actually) but only if the reference is > null and then it sets the class member directly instead of calling > setCredentialHandler. > > So I'm still a little confused as to why you are seeing what you are seeing. > > -chris > > - > 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
Re: Why does LockOutRealm not support CredentialHandler?
Thorsten, On 11/16/22 03:20, Thorsten Schöning wrote: Guten Tag Christopher Schultz, am Mittwoch, 16. November 2022 um 04:50 schrieben Sie: That worked right from the start, I had a DIGEST in tomcat-users.xml and was able to login with plain-text password provided to the browser. The use of the word "digest" is overloaded, particularly for this discussion. Please try to use "HTTP DIGEST" when you mean the on-the-wire authentication protocol and "hashed credential" when you mean the stuff you drop into an authentication database. It will make things a lot easier to understand for all parties involved. ... Adding that didn't work, I was only able to login with providing the DIGEST of tomcat-users.xml as password to the browser, which actually made it a plain-text password at the server. The following fit as well to what I recognized: https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm BUT: I gave things an additional try now and especially after the discussion about auth-method BASIC vs. DIGEST and login DOES work now! So both the UserDatabase realm and the LockOutRealm as I suggested above are now working as expected? I most likely not only added LockOutRealm at some point, but switched from BASIC auth to DIGEST as well, because I've read that in the CIS spec I worked with. That combination can't work and at some point I most likely became frustrated and changed DIGEST back to BASIC, while having changed other aspects of the realms already or might have simply forgotten to change passwords vs. digests in tomcat-users.xml or whatever. So, I guess the reason for the warnign about an ignored credential helper in LockOutRealm simply is because it doesn't handle credentials at all? And as LockOutRealm forwards actual login to its children THEIR assigned credential handlers are properly taken into account? Yes, no CombinedRealm ever uses its configured CredentialHandler, which is why the warning is shown. There is a very specific case in which you WANT to configure a CredentialHandler for a CombinedRealm, and that's when your application is using the CredentialHandler directy for certain things. That doesn't seem to be your use-case, so I won't detail that, here. If you re-visit the SO question you posted yesterday, you'll see that I posted an Answer which describes that a little more. So whatever the SO-guy sees, might have a different root cause, as it was the case for me. Thanks for triggering me to try again! Might have been to late already at Monday as well. :-) I'm glad it's working. After reading Rémy's initial response, I was thinking that something needed to be done, but there is no problem IMO. If you need a CredentialHandler in your application, you can still use LockOutRealm (or any other CombinedRealm); you just have to specify a CredentialHandler to use on that outer Realm and all is well. And you have to ignore that warning. I really don't know why you are seeing that warning. You aren't explicitly-setting a CredentialHandler on your LockOutRealm and that's the only time this warning should be shown. When CombinedRealm.startInternal runs, it creates a trivial CredentialHandler (I'm not sure why it does that, actually) but only if the reference is null and then it sets the class member directly instead of calling setCredentialHandler. So I'm still a little confused as to why you are seeing what you are seeing. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
Thorsten, On 11/16/22 02:28, Thorsten Schöning wrote: Guten Tag Christopher Schultz, am Mittwoch, 16. November 2022 um 04:00 schrieben Sie: Thorsten, what makes you say "it doesn't work" and "LockoutRealm ignores any credential handler"? When you say "it doesn't work"... what DOES it do? IGNORES because it logs a corresponding warning on explicitly configured credential handlers for the LockOutRealm itself and uses a hard-coded default handler, which only allows plain-text passwords in tomcat-users.xml. Does it ignore it? Reading the code suggests that it does not ignore it. Or to be more specific, whatever is input intoc tomcat-users.xml is simply used as plain-text password, so adding a digest based on PBKDF2WithHmacSHA512 won't let you login with the real plain-text provided to the browser by the user. But it allow login when providing the digest as plain-text password. So if you copy/paste the junk that's shown in tomcat-users.xml as the user's "password" (really the PBKDF2 algorithm's output) when challenged by the browser, it lets you in? The code for LockOutRealm and CombinedRealm doesn't look like it works that way. Are you sure you have your Tomcat configured the way you think you do? If credential handlers are configured for child realms, those are simply ignored as well, even without any warning this time. Which makes it additionally difficult to debug this whole setup. I think we might need to see a super-simple setup of this, because your description of experience does not match the way that the code is written, nor the way in which it's intended to work. Can you prepare a configuration for the "examples" web application which demonstrates what you are saying, here, and post it somewhere we can find it? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
Guten Tag Christopher Schultz, am Mittwoch, 16. November 2022 um 04:50 schrieben Sie: > resourceName="UserDatabase"> > className="org.apache.catalina.realm.SecretKeyCredentialHandler" > algorithm="PBKDF2WithHmacSHA512" > iterations="10" > keyLength="256" > saltLength="16" > That worked right from the start, I had a DIGEST in tomcat-users.xml and was able to login with plain-text password provided to the browser. > > ... > Adding that didn't work, I was only able to login with providing the DIGEST of tomcat-users.xml as password to the browser, which actually made it a plain-text password at the server. The following fit as well to what I recognized: https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm BUT: I gave things an additional try now and especially after the discussion about auth-method BASIC vs. DIGEST and login DOES work now! I most likely not only added LockOutRealm at some point, but switched from BASIC auth to DIGEST as well, because I've read that in the CIS spec I worked with. That combination can't work and at some point I most likely became frustrated and changed DIGEST back to BASIC, while having changed other aspects of the realms already or might have simply forgotten to change passwords vs. digests in tomcat-users.xml or whatever. So, I guess the reason for the warnign about an ignored credential helper in LockOutRealm simply is because it doesn't handle credentials at all? And as LockOutRealm forwards actual login to its children THEIR assigned credential handlers are properly taken into account? So whatever the SO-guy sees, might have a different root cause, as it was the case for me. Thanks for triggering me to try again! Might have been to late already at Monday as well. :-) Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: +49 5151- 9468- 0 Tel: +49 5151- 9468-55 Mobil: +49 178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. Mit freundlichen Grüßen, Thorsten Schöning Telefon: +49 5151 9468-55 Fax: E-Mail: tschoen...@am-soft.de AM-Soft IT-Service - Bitstore Hameln GmbH Brandenburger Straße 7c 31789 Hameln Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte Information untersagt. This e-mail may contain confidential and/or privileged information and is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Hinweise zum Datenschutz: bitstore.group/datenschutz - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
Guten Tag Christopher Schultz, am Mittwoch, 16. November 2022 um 04:00 schrieben Sie: > Thorsten, what makes you say "it doesn't work" and "LockoutRealm > ignores any credential handler"? When you say "it doesn't work"... > what DOES it do? IGNORES because it logs a corresponding warning on explicitly configured credential handlers for the LockOutRealm itself and uses a hard-coded default handler, which only allows plain-text passwords in tomcat-users.xml. Or to be more specific, whatever is input intoc tomcat-users.xml is simply used as plain-text password, so adding a digest based on PBKDF2WithHmacSHA512 won't let you login with the real plain-text provided to the browser by the user. But it allow login when providing the digest as plain-text password. If credential handlers are configured for child realms, those are simply ignored as well, even without any warning this time. Which makes it additionally difficult to debug this whole setup. > In Tomcat 10 BTW, the "digest" attribute has been removed in favor > of a properly-configured . Note that you can't > use "digest" and also get acceptable security out of the Realm, anyway. Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: +49 5151- 9468- 0 Tel: +49 5151- 9468-55 Mobil: +49 178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. Mit freundlichen Grüßen, Thorsten Schöning Telefon: +49 5151 9468-55 Fax: E-Mail: tschoen...@am-soft.de AM-Soft IT-Service - Bitstore Hameln GmbH Brandenburger Straße 7c 31789 Hameln Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte Information untersagt. This e-mail may contain confidential and/or privileged information and is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Hinweise zum Datenschutz: bitstore.group/datenschutz - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
Thorsten, On 11/15/22 05:09, Thorsten Schöning wrote: I have some webapp hosted by Tomcat and need to restrict user access to some part of that. One additional requirement is that this app needs to be CIS benchmark compliant and that requires to use LockOutRealm and restricts to store plain-text passwords. Therefore, the ultimate solution in my case would be the following: But that doesn't work, because LockOutRealm ignores any credential handler. Does it? Additionally, with my used Tomcat 10, I'm unable to set any "digest" attribute on the realm itself anymore as well. Forget about "digest". It's dead and for good reason. The only way to fulfill both requirements is to implement a custom realm. That should not be true. Nov 14, 2022 9:03:48 PM org.apache.catalina.realm.CombinedRealm setCredentialHandler WARNUNG: A CredentialHandler was set on an instance of the CombinedRealm (or a sub-class of CombinedRealm). CombinedRealm doesn't use a configured CredentialHandler. Is this a configuration error? https://github.com/apache/tomcat/blob/1e8ed80849f2766d3c5b27e09ef53029e1a1a88e/java/org/apache/catalina/realm/LocalStrings.properties#L23 https://github.com/apache/tomcat/blob/1e8ed80849f2766d3c5b27e09ef53029e1a1a88e/java/org/apache/catalina/realm/CombinedRealm.java#L466 https://tomcat.apache.org/tomcat-9.0-doc/changelog.html https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm So, what's the reason of not supporting credential handlers for LockOutRealm? They are supported. Doesn't make too much sense to me, especially as most docs I came across use LockOutRealm in combination with some other realm and there's no docs that a fundamental concept like credential helpers won't work at all in this setup. Additionally, when researching about that task, some people even claim that the above XML config works, but it simply can't. ? I don't see any code in LockOutRealm to ask other realms about their credential handlers. Nor do you need any such code. I've had a look at the bugtracker already and couldn't find this topic discussed or a reason for the implementation. OTOH, someone did add some code to explicitly log a warning message instead of fixing the underlying problem. I'm not sure there is an "underlying problem" that needs fixing. Is the problem really to decide which of the child realms to choose for its credential handler to use? No. In the easiest case simply use the first credential handler found with a depth-first search, that should work for the majority of use-cases. No. Other aspects of the config like default assumed nesting level of realms and stuff seem hard-coded as well. Really? Like what? Would be glad to read some thoughts, as I need to decide how to deal with this limitation right now. Thanks! What happens if you configure your realm like this: resourceName="UserDatabase"> className="org.apache.catalina.realm.SecretKeyCredentialHandler" algorithm="PBKDF2WithHmacSHA512" iterations="10" keyLength="256" saltLength="16" Are you able to login to your application? If not, get that working first. Once that's working, try wrapping the above in: ... Rebuild, restart, and try logging-in again. Are you able to login? If not, please let us know. If you are able to login, then try logging-in a few times with the wrong password. Are you locked out? (Do you know how to verify that?) All of that should work. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
Rémy and Thorsten, On 11/15/22 06:59, Rémy Maucherat wrote: On Tue, Nov 15, 2022 at 11:11 AM Thorsten Schöning wrote: Hi everyone, I have some webapp hosted by Tomcat and need to restrict user access to some part of that. One additional requirement is that this app needs to be CIS benchmark compliant and that requires to use LockOutRealm and restricts to store plain-text passwords. Therefore, the ultimate solution in my case would be the following: But that doesn't work, because LockOutRealm ignores any credential handler. Additionally, with my used Tomcat 10, I'm unable to set any "digest" attribute on the realm itself anymore as well. The only way to fulfill both requirements is to implement a custom realm. Nov 14, 2022 9:03:48 PM org.apache.catalina.realm.CombinedRealm setCredentialHandler WARNUNG: A CredentialHandler was set on an instance of the CombinedRealm (or a sub-class of CombinedRealm). CombinedRealm doesn't use a configured CredentialHandler. Is this a configuration error? https://github.com/apache/tomcat/blob/1e8ed80849f2766d3c5b27e09ef53029e1a1a88e/java/org/apache/catalina/realm/LocalStrings.properties#L23 https://github.com/apache/tomcat/blob/1e8ed80849f2766d3c5b27e09ef53029e1a1a88e/java/org/apache/catalina/realm/CombinedRealm.java#L466 https://tomcat.apache.org/tomcat-9.0-doc/changelog.html https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm So, what's the reason of not supporting credential handlers for LockOutRealm? Doesn't make too much sense to me, especially as most docs I came across use LockOutRealm in combination with some other realm and there's no docs that a fundamental concept like credential helpers won't work at all in this setup. Additionally, when researching about that task, some people even claim that the above XML config works, but it simply can't. I don't see any code in LockOutRealm to ask other realms about their credential handlers. I've had a look at the bugtracker already and couldn't find this topic discussed or a reason for the implementation. OTOH, someone did add some code to explicitly log a warning message instead of fixing the underlying problem. Is the problem really to decide which of the child realms to choose for its credential handler to use? In the easiest case simply use the first credential handler found with a depth-first search, that should work for the majority of use-cases. Other aspects of the config like default assumed nesting level of realms and stuff seem hard-coded as well. Would be glad to read some thoughts, as I need to decide how to deal with this limitation right now. Thanks! Ok, this is a bit confusing. Everything is configured properly if you nest the CredentialHandler on the right realm (the UserDatabaseRealm). However, the CredentialHandler exposed by getAttribute(Globals.CREDENTIAL_HANDLER) is always the CredentialHandler from the realm attached to the context, here it is LockOutRealm, which isn't very useful. Hmm. You're absolutely right, and it's probably my mistake by doing that. I'll review the code. When you have nested Realms (e.g. CombinedRealm) things can get ... weird if you have multiple credential handlers on each one. It may not always be obvious which one to choose or how to combine them. So interrogating the outer realm for a credential-handler may not really be possible without just explicitly-setting a credential handler that knows what to do on the outermost realm. Maybe NestedCredentialHandler could be used to construct a CredentialHandler that could be useful to the application, but this needs more thought. The CredentialHandler set in the application scope is indeed intended to be used by the application, for example to allow for in-app password changes. The idea is that the application should be able to use the same password-mangling rules used by Tomcat without necessarily having to know what those rules are. Thorsten, what makes you say "it doesn't work" and "LockoutRealm ignores any credential handler"? When you say "it doesn't work"... what DOES it do? In Tomcat 10 BTW, the "digest" attribute has been removed in favor of a properly-configured . Note that you can't use "digest" and also get acceptable security out of the Realm, anyway. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
Guten Tag Rémy Maucherat, am Dienstag, 15. November 2022 um 12:59 schrieben Sie: > Maybe NestedCredentialHandler could be used to construct a > CredentialHandler that could be useful to the application, but this > needs more thought. That wouldn't change anything, as that handler would be ignored and/or warned about again. The problem is the strategy from which realm to get the handler and a depth-first approach seems to make most sense. I've created a bit now, this should at least be documented as widely as possible. In the best case even enhanced of course. https://bz.apache.org/bugzilla/show_bug.cgi?id=66349 Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: +49 5151- 9468- 0 Tel: +49 5151- 9468-55 Mobil: +49 178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. Mit freundlichen Grüßen, Thorsten Schöning Telefon: +49 5151 9468-55 Fax: E-Mail: tschoen...@am-soft.de AM-Soft IT-Service - Bitstore Hameln GmbH Brandenburger Straße 7c 31789 Hameln Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte Information untersagt. This e-mail may contain confidential and/or privileged information and is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Hinweise zum Datenschutz: bitstore.group/datenschutz - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does LockOutRealm not support CredentialHandler?
On Tue, Nov 15, 2022 at 11:11 AM Thorsten Schöning wrote: > > Hi everyone, > > I have some webapp hosted by Tomcat and need to restrict user access > to some part of that. One additional requirement is that this app > needs to be CIS benchmark compliant and that requires to use > LockOutRealm and restricts to store plain-text passwords. Therefore, > the ultimate solution in my case would be the following: > > > > >> resourceName="UserDatabase"> > > > className="org.apache.catalina.realm.SecretKeyCredentialHandler" > > algorithm="PBKDF2WithHmacSHA512" > > iterations="10" > > keyLength="256" > > saltLength="16" > > /> > > > > > > But that doesn't work, because LockOutRealm ignores any credential > handler. Additionally, with my used Tomcat 10, I'm unable to set any > "digest" attribute on the realm itself anymore as well. The only way > to fulfill both requirements is to implement a custom realm. > > > Nov 14, 2022 9:03:48 PM org.apache.catalina.realm.CombinedRealm > > setCredentialHandler > > WARNUNG: A CredentialHandler was set on an instance of the > > CombinedRealm (or a sub-class of CombinedRealm). CombinedRealm > > doesn't use a configured CredentialHandler. Is this a configuration > > error? > > https://github.com/apache/tomcat/blob/1e8ed80849f2766d3c5b27e09ef53029e1a1a88e/java/org/apache/catalina/realm/LocalStrings.properties#L23 > https://github.com/apache/tomcat/blob/1e8ed80849f2766d3c5b27e09ef53029e1a1a88e/java/org/apache/catalina/realm/CombinedRealm.java#L466 > https://tomcat.apache.org/tomcat-9.0-doc/changelog.html > https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm > > So, what's the reason of not supporting credential handlers for > LockOutRealm? > > Doesn't make too much sense to me, especially as most docs I came > across use LockOutRealm in combination with some other realm and > there's no docs that a fundamental concept like credential helpers > won't work at all in this setup. Additionally, when researching about > that task, some people even claim that the above XML config works, but > it simply can't. I don't see any code in LockOutRealm to ask other > realms about their credential handlers. > > I've had a look at the bugtracker already and couldn't find this topic > discussed or a reason for the implementation. OTOH, someone did add > some code to explicitly log a warning message instead of fixing the > underlying problem. > > Is the problem really to decide which of the child realms to choose > for its credential handler to use? In the easiest case simply use the > first credential handler found with a depth-first search, that should > work for the majority of use-cases. Other aspects of the config like > default assumed nesting level of realms and stuff seem hard-coded as > well. > > Would be glad to read some thoughts, as I need to decide how to deal > with this limitation right now. Thanks! Ok, this is a bit confusing. Everything is configured properly if you nest the CredentialHandler on the right realm (the UserDatabaseRealm). However, the CredentialHandler exposed by getAttribute(Globals.CREDENTIAL_HANDLER) is always the CredentialHandler from the realm attached to the context, here it is LockOutRealm, which isn't very useful. Maybe NestedCredentialHandler could be used to construct a CredentialHandler that could be useful to the application, but this needs more thought. Rémy > > Mit freundlichen Grüßen > > Thorsten Schöning > > -- > AM-SoFT IT-Service - Bitstore Hameln GmbH > Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK > > E-Mail: thorsten.schoen...@am-soft.de > Web:http://www.AM-SoFT.de/ > > Tel: +49 5151- 9468- 0 > Tel: +49 5151- 9468-55 > Mobil: +49 178-8 9468-04 > > AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska > > > Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. > > Mit freundlichen Grüßen, > > Thorsten Schöning > > > Telefon: +49 5151 9468-55 > Fax: > E-Mail: tschoen...@am-soft.de > > AM-Soft IT-Service - Bitstore Hameln GmbH > Brandenburger Straße 7c > 31789 Hameln > > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen > und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf > diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie &
Why does LockOutRealm not support CredentialHandler?
Hi everyone, I have some webapp hosted by Tomcat and need to restrict user access to some part of that. One additional requirement is that this app needs to be CIS benchmark compliant and that requires to use LockOutRealm and restricts to store plain-text passwords. Therefore, the ultimate solution in my case would be the following: > >resourceName="UserDatabase"> > className="org.apache.catalina.realm.SecretKeyCredentialHandler" > algorithm="PBKDF2WithHmacSHA512" > iterations="10" > keyLength="256" > saltLength="16" > /> > > But that doesn't work, because LockOutRealm ignores any credential handler. Additionally, with my used Tomcat 10, I'm unable to set any "digest" attribute on the realm itself anymore as well. The only way to fulfill both requirements is to implement a custom realm. > Nov 14, 2022 9:03:48 PM org.apache.catalina.realm.CombinedRealm > setCredentialHandler > WARNUNG: A CredentialHandler was set on an instance of the > CombinedRealm (or a sub-class of CombinedRealm). CombinedRealm > doesn't use a configured CredentialHandler. Is this a configuration > error? https://github.com/apache/tomcat/blob/1e8ed80849f2766d3c5b27e09ef53029e1a1a88e/java/org/apache/catalina/realm/LocalStrings.properties#L23 https://github.com/apache/tomcat/blob/1e8ed80849f2766d3c5b27e09ef53029e1a1a88e/java/org/apache/catalina/realm/CombinedRealm.java#L466 https://tomcat.apache.org/tomcat-9.0-doc/changelog.html https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm So, what's the reason of not supporting credential handlers for LockOutRealm? Doesn't make too much sense to me, especially as most docs I came across use LockOutRealm in combination with some other realm and there's no docs that a fundamental concept like credential helpers won't work at all in this setup. Additionally, when researching about that task, some people even claim that the above XML config works, but it simply can't. I don't see any code in LockOutRealm to ask other realms about their credential handlers. I've had a look at the bugtracker already and couldn't find this topic discussed or a reason for the implementation. OTOH, someone did add some code to explicitly log a warning message instead of fixing the underlying problem. Is the problem really to decide which of the child realms to choose for its credential handler to use? In the easiest case simply use the first credential handler found with a depth-first search, that should work for the majority of use-cases. Other aspects of the config like default assumed nesting level of realms and stuff seem hard-coded as well. Would be glad to read some thoughts, as I need to decide how to deal with this limitation right now. Thanks! Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: +49 5151- 9468- 0 Tel: +49 5151- 9468-55 Mobil: +49 178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. Mit freundlichen Grüßen, Thorsten Schöning Telefon: +49 5151 9468-55 Fax: E-Mail: tschoen...@am-soft.de AM-Soft IT-Service - Bitstore Hameln GmbH Brandenburger Straße 7c 31789 Hameln Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte Information untersagt. This e-mail may contain confidential and/or privileged information and is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Hinweise zum Datenschutz: bitstore.group/datenschutz - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CredentialHandler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stefan,
On 4/27/16 11:16 AM, Stefan Frei wrote:
> Tomcat 8.0.33
>
> i need some help with credentialhandler in datasourceRealm.
>
> I wan t to achieve a encrypted password, if possible with salt.
>
> Encryption SHA-512 or similar.
Technically that's a hash, not an encrypted credential. "Encryption"
generally means that it's reversible, and hashes, etc. are not
reversible (at least not directly).
> is there a example somewhere how to modify the realm, i couldnt
> find anything in the docs.
>
> Realm looks like this atm. Its working, but passwords are stored in
> plain text.
>
> dataSourceName="jdbc/sandbox" localDataSource="true"
> roleNameCol="rolename" userCredCol="password"
> userNameCol="username" userRoleTable="roles" userTable="users">
Realms never write passwords out, so they are stored in whatever form
*you* decided to store them.
https://tomcat.apache.org/tomcat-8.0-doc/config/credentialhandler.html
Since you have declared no element inside your
, you are getting the default CH:
MessageDigestCredentialHandler. The default algorithm for MDCH is
plaintext (i.e. "none").
If you want to change that, you'll have to add your own
element and configure it however you want.
Since you have plaintext passwords in the database now, you might want
to convert them to whatever scheme you decide to use (e.g. salted
SHA-256). You can do that using RealmBase from the command-line:
$ $CATALINA_HOME/bin/digest.sh
Unfortunately, that command doesn't have any "help" you can run to
find out what the parameters mean exactly, but the source does have
that detail (apologies for the lack of formatting... I'm not going to
re-format this manually):
* -a - The algorithm to use to generate the stored
* credential. If not specified a default of
SHA-512 will be
* used.
* -e - The encoding to use for any byte to/from characte
r
* conversion that may be necessary. If not
specified, the
* system encoding ({@link
Charset#defaultCharset()}) will
* be used.
* -i - The number of iterations to use when generating t
he
* stored credential. If not specified, the
default for the
* CredentialHandler will be used.
* -s - The length (in bytes) of salt to generate and
store as
* part of the credential. If not specified, the
default for
* the CredentialHandler will be used.
* -k - The length (in bits) of the key(s), if any,
created while
* generating the credential. If not specified,
the default
* for the CredentialHandler will be used.
* -h - The fully qualified class name of the
CredentialHandler
* to use. If not specified, the built-in handlers
will be
* tested in turn and the first one to accept the
specified
* algorithm will be used.
Run each of your passwords through that to get the encoded form, then
use the same parameters to configure your .
Hope that helps,
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlcg4AYACgkQ9CaO5/Lv0PDkNgCfeCS9e1wHy81qOcvyglbjqW3l
DsoAnAhUo/LNR21DRFkW/RhrcEfpm+Ns
=fZL4
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
CredentialHandler
Hello Tomcat 8.0.33 java 8 debian i need some help with credentialhandler in datasourceRealm. I wan t to achieve a encrypted password, if possible with salt. Encryption SHA-512 or similar. is there a example somewhere how to modify the realm, i couldnt find anything in the docs. Realm looks like this atm. Its working, but passwords are stored in plain text. Regards Stefan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Need help with using CredentialHandler
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sreyan, On 8/23/15 2:36 PM, Sreyan Chakravarty wrote: I need to use Container Managed Security and Authentication in my latest project. And I have a couple of queries regarding how to configure a Credential Handler. What are your requirements? You may not have to manually-configure a CredentiaHandler. 1. Firstly how will a CredentialHandler declaration look like ? Can someone provide a sample declaration of the NestedCredentialHandler with the algorithm attribute declared. I need to know since the Digest attribute in Realms has become deprecated. I didn't find any examples on the web and I am utterly confused. Reviewing the documentation, I can see how it might be confusing. Here's a simple configuration. Realm ... CredentialHandler className=org.apache.catalina.realm.MessageDigestCredentialHandler algorithm=SHA-256 iterations=28764 saltLength=16 / /Realm You only need NestedCredentialHandler if you want to be able to support more than one kind of stored-credential. You only really need to do this when you are trying to switch from one type of stored-credential to another, and need to be able to support either style for a period of time. (e.g. switching from plain-old MD5 to salted, iterated SHA-256, or from hash-based credential-format into something like PBKDF.) 2. Whats the difference between MessageDigestCredentialHandler and SecretKeyCredentialHandler which one is more secure ? As the documentation says, MessageDigest uses MessageDigest to hash passwords. It can also perform iterations and salting of the password as it's hashed. SecretKey uses the the SecretKeyFactory class and therefore supports the types of algorithms supported, there. Which one is more secure is a matter of opinion (at least, IMO). Algorithms such as PBKDF2 are not really much more than salt+hash+iteration, so you can achieve the same effect with the MessageDigestCredentialHandler if you tune the parameters correctly. You may be in an environment where saying that you specifically use PBKDF2 (rather than some home brewed salt+hash+iteration) may be more advantageous. Also, that kind of algorithm (PBKDF2) is formally-specified. 3. SecretKeyCredentialHandler specifies only one algorithm in the documentation which is PBKDF2WithHmacSHA1. What other algorithms are available ? Have a look at your JVM to find out what is currently supported. Call java.security.Provider.keySet() on your crypto provider(s) to find out their properties. You're looking for something like this: SecretKeyFactory.DES=com.sun.crypto.provider.DESKeyFactory SecretKeyFactory.DESede=com.sun.crypto.provider.DESedeKeyFactory SecretKeyFactory.PBEWithHmacSHA1AndAES_128=com.sun.crypto.provider.PBEKe yFactory$PBEWithHmacSHA1AndAES_128 SecretKeyFactory.PBEWithHmacSHA1AndAES_256=com.sun.crypto.provider.PBEKe yFactory$PBEWithHmacSHA1AndAES_256 SecretKeyFactory.PBEWithHmacSHA224AndAES_128=com.sun.crypto.provider.PBE KeyFactory$PBEWithHmacSHA224AndAES_128 SecretKeyFactory.PBEWithHmacSHA224AndAES_256=com.sun.crypto.provider.PBE KeyFactory$PBEWithHmacSHA224AndAES_256 SecretKeyFactory.PBEWithHmacSHA256AndAES_128=com.sun.crypto.provider.PBE KeyFactory$PBEWithHmacSHA256AndAES_128 SecretKeyFactory.PBEWithHmacSHA256AndAES_256=com.sun.crypto.provider.PBE KeyFactory$PBEWithHmacSHA256AndAES_256 SecretKeyFactory.PBEWithHmacSHA384AndAES_128=com.sun.crypto.provider.PBE KeyFactory$PBEWithHmacSHA384AndAES_128 SecretKeyFactory.PBEWithHmacSHA384AndAES_256=com.sun.crypto.provider.PBE KeyFactory$PBEWithHmacSHA384AndAES_256 SecretKeyFactory.PBEWithHmacSHA512AndAES_128=com.sun.crypto.provider.PBE KeyFactory$PBEWithHmacSHA512AndAES_128 SecretKeyFactory.PBEWithHmacSHA512AndAES_256=com.sun.crypto.provider.PBE KeyFactory$PBEWithHmacSHA512AndAES_256 SecretKeyFactory.PBEWithMD5AndDES=com.sun.crypto.provider.PBEKeyFactory$ PBEWithMD5AndDES SecretKeyFactory.PBEWithMD5AndTripleDES=com.sun.crypto.provider.PBEKeyFa ctory$PBEWithMD5AndTripleDES SecretKeyFactory.PBEWithSHA1AndDESede=com.sun.crypto.provider.PBEKeyFact ory$PBEWithSHA1AndDESede SecretKeyFactory.PBEWithSHA1AndRC2_128=com.sun.crypto.provider.PBEKeyFac tory$PBEWithSHA1AndRC2_128 SecretKeyFactory.PBEWithSHA1AndRC2_40=com.sun.crypto.provider.PBEKeyFact ory$PBEWithSHA1AndRC2_40 SecretKeyFactory.PBEWithSHA1AndRC4_128=com.sun.crypto.provider.PBEKeyFac tory$PBEWithSHA1AndRC4_128 SecretKeyFactory.PBEWithSHA1AndRC4_40=com.sun.crypto.provider.PBEKeyFact ory$PBEWithSHA1AndRC4_40 SecretKeyFactory.PBKDF2WithHmacSHA1=com.sun.crypto.provider.PBKDF2Core$H macSHA1 SecretKeyFactory.PBKDF2WithHmacSHA224=com.sun.crypto.provider.PBKDF2Core $HmacSHA224 SecretKeyFactory.PBKDF2WithHmacSHA256=com.sun.crypto.provider.PBKDF2Core $HmacSHA256 SecretKeyFactory.PBKDF2WithHmacSHA384=com.sun.crypto.provider.PBKDF2Core $HmacSHA384 SecretKeyFactory.PBKDF2WithHmacSHA512=com.sun.crypto.provider.PBKDF2Core $HmacSHA512 That's for my Oracle 1.8-level JVM. So it looks like it supports
Need help with using CredentialHandler
I need to use Container Managed Security and Authentication in my latest project. And I have a couple of queries regarding how to configure a Credential Handler. 1. Firstly how will a CredentialHandler declaration look like ? Can someone provide a sample declaration of the NestedCredentialHandler with the algorithm attribute declared. I need to know since the Digest attribute in Realms has become deprecated. I didn't find any examples on the web and I am utterly confused. 2. Whats the difference between MessageDigestCredentialHandler and SecretKeyCredentialHandler which one is more secure ? 3. SecretKeyCredentialHandler specifies only one algorithm in the documentation which is PBKDF2WithHmacSHA1. What other algorithms are available ? I followed https://tomcat.apache.org/tomcat-8.0-doc/config/credentialhandler.html before writing this mail. Regards Sreyan Chakravarty
