Bug 31592 - storage format of digested realm passwords depends on default charset
Summary: storage format of digested realm passwords depends on default charset
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 5.0.0
Hardware: Other other
: P3 minor (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-07 22:31 UTC by Hontvari Jozsef
Modified: 2004-11-16 19:05 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hontvari Jozsef 2004-10-07 22:31:38 UTC
The documentation specifies the digest algorithms which can be used to avoid 
storing plain text passwords. Unfortunately passwords are strings and the input of 
digest algorithms are bytes, but the conversion between the two - the charset 
encoding to be used - is not specified. 

Looking at the source of org.apache.tomcat.modules.aaa.RealmBase it turns out that 
it uses the system default charset encoding, which is usually a bad idea for a 
server software. E.g. moving the server to another machine or using a second 
server with different locale renders the user database invalid. 

The best solution would be to explicitly specify an encoding, e.g. UTF-8. But at 
this moment this may break existing configurations. Another solution is to add an 
additional parameter to each realm implementation and the command line utility, in 
which the administrator can specify the encoding. The default of this parameter 
must be "encode using the platform's default charset", in order to not break 
compatiblity.
Comment 1 william.barker 2004-10-08 02:59:47 UTC
Assuming that you meant to file this against Tomcat 3 (which is where 
o.a.t.m.aaa.RealmBase lives :), this is fixed now in the CVS.

The Realm now has a 'digestEncoding' attribute that can be used to specify the 
charset (defaulting to the default charset, for BC).

Leaving the bug open, incase you really did mean Tomcat 5.
Comment 2 Hontvari Jozsef 2004-10-08 06:59:31 UTC
Yes, you are right, I mean Tomcat 5 and read the 5.5 doc but the Tomcat 3 source. 
However, now I also checked the 5.5 source, and the code - so the problem - is the 
same. The same fix could be equally useful for Tomcat 5 too.
Comment 3 Yoav Shapira 2004-10-27 16:01:46 UTC
Done for Tomcat 5.5(.4), doing for 5.0.(30) next.
Comment 4 Yoav Shapira 2004-10-27 16:41:00 UTC
Done -- thanks for submitting this issue.