• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

encrypt tomcat admin password running on Windows

 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Tomcat Experts,

I'm trying to document steps needed to properly SHA-1 encrypt tomcat admin password, which is used to access tomcat manager application. It seems I need to run a .bat file, which invokes quite a few other bat files to perform the encryption. I'm wondering if anyone has a definitive guide / code repository / for encrypting tomcat password listed in %CATALINA_HOME%\conf\tomcat-users.xml to be encrypted and not use the defaults: <user name="tomcat" password="tomcat" roles="manager-gui" />

So far what I've come up with is digest.bat needs to be run, but I'm unable to find this in any of the %CATALINA_HOME%\bin\ directories I've looked at. Searching the internet, I've found the following code examples, but can these be run on tomcat 7 running on windows and are the following code snippets all the pieces of code I need to properly encrypt tomcat user password?

Thanks in advance for your help. I beleive this would benefit the tomcat community as a whole because I can't imagine I'm the only user trying to properly secure the tomcat-users.xml file on windows.

example code found on internet, which I think is needed to properly encrypt the tomcat password:
(need to be able to run: digest.bat -a SHA-1 <PASSWORD>)


-digest.bat


Tool-wrapper.bat


setclasspath.bat


Am I missing any code? can't find env.bat anywhere but maybe it's somewhere else on the internet or I can set env manually? Or perhaps there's an easier way to do this? -Thanks.
 
Saloon Keeper
Posts: 15488
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why would you want to encrypt the password?
 
Kris Thomson
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:Why would you want to encrypt the password?



to follow security best practices. OWASP
 
Stephan van Hulst
Saloon Keeper
Posts: 15488
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This sounds like a terrible practice to me. Can you point out specifically where it says that you should encrypt the password?
 
Kris Thomson
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:This sounds like a terrible practice to me. Can you point out specifically where it says that you should encrypt the password?



The question isn't about why it should be encrypted, encryption is possible and it's documented (especially on linux), The question is how do I encrypt the password on windows.
None of this functionality would be available on linux if it wasn't covered within CIS benchmark for tomcat on linux for production deployments. I'm sure Google, Amazon, etc. who use tomcat would never have this file with an un-encrypted password on their production system. Heck I encrypt passwords on JBoss all day long on windows for production deployments, why is it so difficult for tomcat out of the box passwords?

Thanks.
 
Stephan van Hulst
Saloon Keeper
Posts: 15488
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Kris Thomson wrote:I'm sure Google, Amazon, etc. who use tomcat would never have this file with an un-encrypted password on their production system.


And there I think you would be mistaken. Do you have any reason at all to believe that this password should be encrypted? Can you point me to any publication that makes a compelling argument for this practice?

Encrypting passwords on systems where only administrators should have access to in the first place is a sure indication of a fundamental misunderstanding of security concepts.
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually, tomcat-users.xml isn't intended for secure or high-performance production use. That file is simply the data file used by the MemoryRealm Tomcat security module and its relatives. You could certainly extend one of those Realms to handle encrypted files, but more often you'd use a database or an LDAP/Active Directory server to hold the user credentials. In such cases, you'd normally store the password in encrypted form. The user ID is generally in clear text, but since Tomcat is supposedly using a secure internal connection, that's not such an issue, especially since the stock security modules don't fetch credentials - they simply ask the credential server to affirm or deny that the credentials match.

e.g.:
SELECT COUNT(*) from USERS WHERE user_id = ? AND CRYPT(password) = ?
[/code]

Which returns 0 if the credentials are invalid and non-zero (hopefully 1!) if they are valid.
 
Kris Thomson
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for all the feedback, but I'm confused. Can someone please point me to a guide / whitepaper on how to properly secure tomcat management console on windows? I've seen strategies to limiting the ip to localhost, encrypting the password and obfuscating the user, to now using third party ldap to authenticate, to removing the tomcat manager app all together. I'm simply looking for the most secure method to secure this web application from a malicious user attempting to remotely manipulate / deploy apps to tomcat deployed in a production environment on windows.  Anymore help here would be greatly appreciated because using tomcat / tomcat as it comes out of the box seems horribly insecure.
 
Kris Thomson
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:

Kris Thomson wrote:I'm sure Google, Amazon, etc. who use tomcat would never have this file with an un-encrypted password on their production system.


And there I think you would be mistaken. Do you have any reason at all to believe that this password should be encrypted? Can you point me to any publication that makes a compelling argument for this practice?

Encrypting passwords on systems where only administrators should have access to in the first place is a sure indication of a fundamental misunderstanding of security concepts.



non-plain text for tomcat users

Encrypting passwords on tomcat

to name a few. thanks.
 
Tim Holloway
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Encrypting passwords on systems where only administrators should have access to in the first place is a sure indication of a fundamental misunderstanding of security concepts.



Not so. Otherwise we'd still be using plaintext /etc/passwd files in Unix and Linux.

However, the Tomcat tomcat-users.xml file is located (by default) under the Tomcat installation directory, and anyone who has direct access to those directories pretty well owns the system already. Not only the Tomcat passwords, but the database passwords configured in the connection pools.
 
Stephan van Hulst
Saloon Keeper
Posts: 15488
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Kris Thomson wrote:non-plain text for tomcat users

Encrypting passwords on tomcat

to name a few. thanks.


The first link only says how, not why. The second link references an OWASP page that actually mentions there is no way around storing server/DB passwords in essentially plain text.

Tim Holloway wrote:Not so. Otherwise we'd still be using plaintext /etc/passwd files in Unix and Linux.


That's a completely different case. User passwords need to be hashed, not encrypted. They are verified by hashing the password the user enters. You can't do the same thing with server passwords, because at some point the manager app needs it in plain text. When the password has to be decrypted, you might as well store it in plain text.
 
Stephan van Hulst
Saloon Keeper
Posts: 15488
363
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Cleartext Passwords in CATALINA_HOME/conf/server.xml
When configuring a resource, such as a JDBC pool, it is necessary to include clear text username and password in CATALINA_HOME/conf/server.xml Best practices advice us never to store clear text passwords, but the following paragraphs highlight it is very difficult to avoid.

If one way encryption was used on the password it must be possible for a database connection to be established using a username and encrypted password - so the encrypted password is just as valuable as the clear text one to an attacker.

If two way encryption was used a keyfile is needed which must also live on the filesystem. To make it more secure a passphase is added to the keyfile which then has to be stored in the configuration as clear text - no improvement.

Encoding is security by obscurity and offers no form of protection (algorithms can be reverse engineered). What encoding does do is make huge amounts of overhead work - you need to customise Tomcat and the commons digester it uses to parse the config files. You'd also need a way to create encoded passwords.
In the case of a JDBC pool what you can do is;

  • make sure the database user only has access to the databases and tables they need (also limit rights as necessary).
  • make sure the raw database files are only accessible to the user running the database services (e.g. mysql/postgresql user)
  • make sure the Tomcat configuration files are only accessible to the tomcat user

  • https://www.owasp.org/index.php/Securing_tomcat

    I highlighted the most relevant parts. Just store the passwords in plain text, and make sure only the user running Tomcat has access to those files. The protection then comes down to how strongly the user account is protected. If a hacker can breach that protection, you have bigger problems than them accessing the Tomcat passwords.
     
    Tim Holloway
    Saloon Keeper
    Posts: 27752
    196
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Stephan van Hulst wrote:You can't do the same thing with server passwords, because at some point the manager app needs it in plain text.



    Look at my model SQL statement and tell me that again.

    Any security system that has to retrieve credentials back to the client is inherently much weaker than one that uses an approach like the one I illustrated where the data never escapes the database server (or LDAP server or web service or whatever authenticator you like). This is also the reason why J2EE has the isCallerInRole/isUserInRole methods that don't allow enumeration or retrieval of security roles.

    Hashing is less secure than encryption for passwords, but it's faster, especially when you don't allow reading of the password. Note that the J2EE Realms don't have password maintenance functions - they expect credentials to be maintained externally, so a one-way system is just fine with them, too.

    As I said, and you re-affirmed, if someone can see Tomcat's config files, security is pretty much down the bog at that point anyway. We have had people ask in this forum about encrypting database passwords, and some JDBC drivers have options to encrypt the db server network traffic, but, as you said, knowing the encrypted password is just as good as knowing the plain-text password unless there's some sort of invisible security context unique to that server. And in the case of vanilla Tomcat, there isn't.



    Fun Fact: Java security systems generally avoid putting security credentials in Strings. That's because a java.lang.String is an immutable object and a really determined hacker can find them and harvest them even after the String is up for garbage collection. The preferred container for credentials is an array of Characters or Bytes. You can manually erase each element in the array and ensure it doesn't hang around to be snooped. Of course, it's very likely that in many cases the credentials have been passed through other system layers as Strings, but at least at the security manager level, it's treated more securely. As always, security is only as strong as its weakest link.
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 15488
    363
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Tim Holloway wrote:Hashing is less secure than encryption for passwords, but it's faster, especially when you don't allow reading of the password.


    This goes against everything I know about security. Care to elaborate?
     
    Kris Thomson
    Greenhorn
    Posts: 10
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks for all the feedback, but after reading all of this I think I'm just going to take the simple route and remove tomcat manager app all together. Found another post on this forum here, so I think this might be the most secure approach since we aren't using the manager app for anything and it's just pandora's box sitting out there waiting for some malicious user to try and take advantage of.

    I'm assuming the process is the same for tomcat 7 as it was for the older post, also did some research perhaps the %CATALINA_HOME%\manager directory should be retained, but everything in it deleted. Also will comment out or remove the entry in the %CATALINA_HOME%\conf\tomcat-users.xml where tomcat manager-gui user is referenced.

    Please do let me know if you see any insecurity with taking this approach or if you agree it would be the most secure method.

    Thanks,
    Kris
     
    And when my army is complete, I will rule the world! But, for now, I'm going to be happy with this tiny ad:
    a bit of art, as a gift, that will fit in a stocking
    https://gardener-gift.com
    reply
      Bookmark Topic Watch Topic
    • New Topic