107402 2003-07-09 20:20 /35 rader/ Mike Bommarito <g0thm0g@attbi.com> Importerad: 2003-07-09 20:20 av Brevbäraren Extern mottagare: bugtraq@securityfocus.com Mottagare: Bugtraq (import) <5487> Ärende: 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? (107402) /Mike Bommarito <g0thm0g@attbi.com>/(Ombruten)