|Summary:||storage format of digested realm passwords depends on default charset|
|Product:||Tomcat 5||Reporter:||Hontvari Jozsef <hontvari3>|
|Component:||Catalina||Assignee:||Tomcat Developers Mailing List <dev>|
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.