Tomcat Dangerous Documentation/Tomcat Default Plaintext Password Storage

From: Mike Bommarito (g0thm0gat_private)
Date: Wed Jul 09 2003 - 06:09:44 PDT

  • Next message: ashat_private: "IE Object Type Overflow Exploit"

    
     ('binary' encoding is not supported, stored as-is)
    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?
    



    This archive was generated by hypermail 2b30 : Wed Jul 09 2003 - 11:20:46 PDT