bugtraq - Tomcat Dangerous Documentation/Tomcat Default Plaintext Password Storage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20030709130944.16406.qmail@www.securityfocus.com>
Date: 9 Jul 2003 13:09:44 -0000
From: Mike Bommarito <g0thm0g@...bi.com>
To: bugtraq@...urityfocus.com
Subject: Tomcat Dangerous Documentation/Tomcat Default Plaintext Password
    Storage

>From the Realm HOW-TO on the Tomcat 4.0/4.1 documentation pages:

"For each of the standard Realm implementations, the user's password (by 
default) is stored in clear text. In many environments, this is 
undesireable because casual observers of the authentication data can 
collect enough information to log on successfully, and impersonate other 
users. To avoid this problem, the standard implementations support the 
concept of digesting user passwords. "

Following, near a paragraph down.

"When a standard realm authenticates by retrieving the stored password and 
comparing it with the value presented by the user, you can select digested 
passwords by specifying the digest attribute on your <Realm> element. The 
value for this attribute must be one of the digest algorithms supported by 
the java.security.MessageDigest class (SHA, MD2, or MD5)."

First of all, if SHA, MD2, and MD5 are all supported (since 4.x, as the 
Realm documentation would lead me to believe), and it's only a matter of 
adding an attribute to the server.xml file, what is stopping them from 
enabling this by default?  The problem is made even worse for the 4.x 
family by the fact that the install documentation seems yet to be mature, 
as this rather simple fix is buried in a rather confusingly titled 
document "Realm HOW-TO," and no reference is to be found in any of 
the "Getting Started" documents.  As far as I can tell, with limited 
experience in both the 3.x and 5.x branches, although it's more an issue 
of user neglegience for the well-documented 5.x branch, the 4.x 
documentation is dangerously ignorant of this issue.  While proper file 
system permissions easily prevent unencrypted authentication storage issue 
from causing real trouble, there are always breaks and loops in any file 
system or permission set, so when that happens, why give this information 
away for free?