Just include the information that if the log levels of your software will debug aut passwords if the log level is set to debug in you documentation. I have worked with many security aware linux daemons and many of them are debugging out the passwords they retrieve(Thank god they do this). Take freeradius as an example (options log_auth_badpass and the log_auth_goodpass). And they also include some words about this feature in their documentation: "Include the password in the radius.log file even for successful logins. This is very insecure!" I remember a wise sentence of a member of this list: "I don't want to get in the business of trying to stop folks from failing. It is way too much work and never pays off :D" In this spirit, Richard
On Wed, Apr 15, 2009 at 3:14 PM, Thomas Schlosser <[email protected]> wrote: > Hello Richard, > I agree with you. But the problem is that some applications have to be > delivered to other organizations to run productive. And it is impossible > to be sure that the log level is set to INFO and not to DEBUG on this > system. > > Cheers, > Thomas > > Richard Hauswald schrieb: >> Hello Tomas, >> I don't share your thoughts. Logging the password is only an issue in >> production environments. I don't use DEBUG in production so this is >> not a problem for me. If you do so, just set the log level to INFO for >> the corresponding class. >> >> If I want to debug my application, I want to see the password I >> entered in the logs. This is what I expect if I set the log level of >> an API to DEBUG. >> >> Have a nice day, >> Richard >> >> On Tue, Apr 14, 2009 at 9:54 PM, Thomas Schlosser >> <[email protected]> wrote: >>> Hi, >>> thanks for the advice, but the safety of the Post isn't the problem. >>> Rather the safety of the customers data in the logfiles. >>> >>> Cheers, >>> Thomas >>> >>> >>> Newman, John W schrieb: >>>> Yeah, it probably shouldn't log stripes:password values, but really that >>>> post has to be under SSL or you're still open to much larger problems. >>>> >>>> Unencrypted Login Form/Password Sent in the Clear >>>> An unencrypted login form has been discovered. Any area of a web >>>> application that possibly contains sensitive information or access to >>>> privileged functionality such as remote site administration functionality >>>> should utilize SSL or another form of encryption to prevent login >>>> information from being sniffed or otherwise intercepted or stolen. A page >>>> containing a login form should be SSL as well as the Action of the form. >>>> This will prevent Man-in-the-Middle attacks on the login form. >>>> Recommendations include ensuring that sensitive areas of your web >>>> application have proper encryption protocols in place to prevent login >>>> information and other data that could be helpful to an attacker from being >>>> intercepted. >>>> >>>> SOLUTION >>>> For Security Operations: >>>> Ensure that sensitive areas of your web application have proper encryption >>>> protocols in place to prevent login information and other data that could >>>> be helpful to an attacker from being intercepted. >>>> >>>> For Development: >>>> Ensure that sensitive areas of your web application have proper encryption >>>> protocols in place to prevent login information and other data that could >>>> be helpful to an attacker from being intercepted. >>>> >>>> For QA: >>>> Test the application not only from the perspective of a normal user, but >>>> also from the perspective of a malicious one. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Thomas Schlosser [mailto:[email protected]] >>>> Sent: Tuesday, April 14, 2009 3:17 PM >>>> To: [email protected] >>>> Subject: [Stripes-users] Password Logging as plain text >>>> >>>> Hi, >>>> I have found out that stripes logs the values(also values from >>>> stipes-password-tag) as plain text, when the Validation-annotation is >>>> used with the required-param. >>>> 2009-04-14 17:13:08,246 DEBUG [http-8080-Processor25] (Log.java:183) - >>>> Checking required field: password, with values: [secret] >>>> >>>> I think this is a security hole, therefore I wrote my own >>>> ActionBeanPropertyBinder and removed the logging of the value. >>>> But isn't it a generally problem, which should be fixed in the >>>> DefaultActionBeanPropertyBinder? >>>> >>>> Cheers, >>>> Thomas >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.net email is sponsored by: >>>> High Quality Requirements in a Collaborative Environment. >>>> Download a free trial of Rational Requirements Composer Now! >>>> http://p.sf.net/sfu/www-ibm-com >>>> _______________________________________________ >>>> Stripes-users mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/stripes-users >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.net email is sponsored by: >>>> High Quality Requirements in a Collaborative Environment. >>>> Download a free trial of Rational Requirements Composer Now! >>>> http://p.sf.net/sfu/www-ibm-com >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by: >>> High Quality Requirements in a Collaborative Environment. >>> Download a free trial of Rational Requirements Composer Now! >>> http://p.sf.net/sfu/www-ibm-com >>> _______________________________________________ >>> Stripes-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/stripes-users >>> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> High Quality Requirements in a Collaborative Environment. >> Download a free trial of Rational Requirements Composer Now! >> http://p.sf.net/sfu/www-ibm-com > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > Stripes-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/stripes-users > ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Stripes-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-users
