Trying to log in to Tomcat manager using hashed password.

I've my tomcat-users.xml defined this way:

<?xml version="1.0" encoding="UTF-8"?> <!--  Licensed to the Apache Software Foundation (ASF) under one or more  contributor license agreements.  See the NOTICE file distributed with  this work for additional information regarding copyright ownership.  The ASF licenses this file to You under the Apache License, Version 2.0  (the "License"); you may not use this file except in compliance with  the License.  You may obtain a copy of the License at      http://www.apache.org/licenses/LICENSE-2.0  Unless required by applicable law or agreed to in writing, software  distributed under the License is distributed on an "AS IS" BASIS,  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  See the License for the specific language governing permissions and  limitations under the License. --> <tomcat-users xmlns="http://tomcat.apache.org/xml"              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"              xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"              version="1.0"> <!--  By default, no user is included in the "manager-gui" role required  to operate the "/manager/html" web application.  If you wish to use this app,  you must define such a user - the username and password are arbitrary.  Built-in Tomcat manager roles:    - manager-gui    - allows access to the HTML GUI and the status pages    - manager-script - allows access to the HTTP API and the status pages    - manager-jmx    - allows access to the JMX proxy and the status pages    - manager-status - allows access to the status pages only  The users below are wrapped in a comment and are therefore ignored. If you  wish to configure one or more of these users for use with the manager web  application, do not forget to remove the <!.. ..> that surrounds them. You  will also need to set the passwords to something appropriate. --> <!--  <user username="admin" password="<must-be-changed>" roles="manager-gui"/>  <user username="robot" password="<must-be-changed>" roles="manager-script"/> --> <!--  The sample user and role entries below are intended for use with the  examples web application. They are wrapped in a comment and thus are ignored  when reading this file. If you wish to configure these users for use with the  examples web application, do not forget to remove the <!.. ..> that surrounds  them. You will also need to set the passwords to something appropriate. --> <!--  <role rolename="tomcat"/>  <role rolename="role1"/>  <user username="tomcat" password="<must-be-changed>" roles="tomcat"/>  <user username="both" password="<must-be-changed>" roles="tomcat,role1"/>  <user username="role1" password="<must-be-changed>" roles="role1"/> --> <role rolename="tomcat"/>  <role rolename="manager-gui"/>  <role rolename="admin-gui"/>  <user username="jack" password="4f60ef32b9f4cf8a30d85167c9575e627d1f03845575a620ff5654b85eb29add$1$15a54860775edfab43b7010aed9ca814c6647f5b1c07253cbcdac7dc80e07833ee9ae5392aac0b7ba96760100a1462dcc51ed91cb8c4768bba1de77193f0ad57" roles="tomcat,manager-gui,admin-gui"/>  <user username="TomcatJackAdmin" password="test" roles="manager-gui"/> </tomcat-users>

And I've generated the hash like this from my bin directory :

bin>.\digest.bat -a SHA-512 -h org.apache.catalina.realm.MessageDigestCredentialHandler password

When I login to Tomcat Manager (tomcat 9.0.78) on Windows using TomcatJackAdmin and test, it works fine. But I'm trying to use the encrypted user, "jack" and the "password" for which hash exists above. It doesn't work. Is there an additiona steps I need to fix above issue?

So when you see the login form, you type "jack" in the userid box and "4f60ef32b9f4cf8a30d85167c9575e627d1f03845575a620ff5654b85eb29add$1$15a54860775edfab43b7010aed9ca814c6647f5b1c07253cbcdac7dc80e07833ee9ae5392aac0b7ba96760100a1462dcc51ed91cb8c4768bba1de77193f0ad57" in the password box?

Because otherwise who's going to handle the crptography? Tomcat won't.

Tim Holloway wrote:So when you see the login form, you type "jack" in the userid box and "4f60ef32b9f4cf8a30d85167c9575e627d1f03845575a620ff5654b85eb29add$1$15a54860775edfab43b7010aed9ca814c6647f5b1c07253cbcdac7dc80e07833ee9ae5392aac0b7ba96760100a1462dcc51ed91cb8c4768bba1de77193f0ad57" in the password box?

Because otherwise who's going to handle the crptography? Tomcat won't.

No, I am typing "password" for password but storing it as a hash in tomcat-users.xml. How to handle this if tomcat won't handle this?

You cannot. Besides, there's more than one encryption algorithm in the world, so even if this particular Realm supported such a feature you'd need to make sure it was configured for it.

Tomcat doesn't need encrypted passwords. Tomcat goes to great lengths to ensure that when you type in a password, it isn't going to be visible to anything but the Tomcat login service, which is quite secure. Tomcat NEVER fetches a passsword, only submits it to a Realm for the Realm to check. And Realms don't fetch passwords either, if they can help it.

The main case where you'd have an encrypted password in Tomcat is if the userid/password was stored in an external database. In which case, you'd encrypt the password IN THE DATABASE, and the Realm would have to do a query in the form "SELECT COUNT(*) FROM users WHERE user_id=? AND ENCRYPT(password) =?". In which case, the actual encryption and checking would be done entirely within the database server, not in Tomcat. You would typically use an encrypted (SSL-style) channel from Tomcat to the database server to avoid network snoops.

Encrypting the password in the database means that even if someone queried the database outside of Tomcat, they wouldn't be able to retrieve the password in a form that Tomcat would match in its Realm processes.

Again, the tomcat-users.xml file isn't really intended for serious production use, so it is not encrypted. Its protection is managed via the OS file-level protections. Which is to say that only the OS "tomcat" user should have the ability to read or write it.

Tim Holloway wrote:You cannot. Besides, there's more than one encryption algorithm in the world, so even if this particular Realm supported such a feature you'd need to make sure it was configured for it.

Tomcat doesn't need encrypted passwords. Tomcat goes to great lengths to ensure that when you type in a password, it isn't going to be visible to anything but the Tomcat login service, which is quite secure. Tomcat NEVER fetches a passsword, only submits it to a Realm for the Realm to check. And Realms don't fetch passwords either, if they can help it.

The main case where you'd have an encrypted password in Tomcat is if the userid/password was stored in an external database. In which case, you'd encrypt the password IN THE DATABASE, and the Realm would have to do a query in the form "SELECT COUNT(*) FROM users WHERE user_id=? AND ENCRYPT(password) =?". In which case, the actual encryption and checking would be done entirely within the database server, not in Tomcat. You would typically use an encrypted (SSL-style) channel from Tomcat to the database server to avoid network snoops.

Encrypting the password in the database means that even if someone queried the database outside of Tomcat, they wouldn't be able to retrieve the password in a form that Tomcat would match in its Realm processes.

Again, the tomcat-users.xml file isn't really intended for serious production use, so it is not encrypted. Its protection is managed via the OS file-level protections. Which is to say that only the OS "tomcat" user should have the ability to read or write it.

Hmm, one username and password in my production tomcat has this thing working already and I'm having issues in figuring out why adding an additional user and password with SHA512 hash is not logging that user. Not sure from where to start to figure out how existing case works.

As I said. Tomcat doesn't want anything to do with your hashed/encrypted passwords. It wants the tomcat-users.xml file to keep passwords in plain text and that's it.

Also, please don't quote me in entirety. It's redundant and wastes space.

Tim, what about jdbc passwords stored in conf/Catalina/localhost/MyDb.xml?

<Context ...> <Resource name="jdbc.jndiName: auth="Container"...username...password..../> </Context>

Thomas Griffith wrote:Tim, what about jdbc passwords stored in conf/Catalina/localhost/MyDb.xml?

<Context ...> <Resource name="jdbc.jndiName: auth="Container"...username...password..../> </Context>

That file should be describing a webapp accessable from http://localhost:8080/MyDb. The Resource defines something that Tomcat will store in that webapp's JNDI dictionary. Typically it would also specify type="javax.sql.DataSource", which would define a Datasource Connection Pool that the webapp would use. It has no direct connection to Tomcat security.

Tomcat's security is managed by plugins to Tomcat itself and not to the webapp. The security modules are called Realms and there are a specific set of APIs (Interfaces( that define Realms so that Tomcat knows how to talk to them.

The most important method a Realm module presents is the authenticate() method. This is an overloaded method from org.apache.catalina.realm.RealmBase, but the most common invocation is for Tomcat to pass 2 arguments that it obtains from the LoginForm or dialog: juserid and jpassword. These arguments are always cleaf-text strings, never encrypted. Tomcat assumes your client login was done via SSL. it trusts its own internal security, so there's no need for encryption there.

If the Realm talks to an external data repository (most do), it is up the the Realm implementation as to whether or not to use encryption at that point. For the JDBC Realm, you can provide a JDBC query such as "SELECT COUNT(*) FROM my_user WHERE user_id = ? AND password = CRYPT(?)". And/or use an encrypted network connection to the JDBC server.

As I've said before, the tomcat-users.xml file is not intended for production use, so it doesn't make any provision for encryption. Since it's typically stored in the Tomcat directory tree, it's as secure — or not — as the rest of Tomcat.