> From: Milanez, Marcus [mailto:[EMAIL PROTECTED]
> On the other hand, is it right to stay behind a
> possible security fault (malicious super user performing
> login) in order to say I'll not correct known security issues
> in my application?
There's a lovely discussion on exactly this topic in Howard and LeBlanc,
"Writing Secure Code". The conclusion is that you don't need to make this
bombproof, but you do need to ensure it's not the weakest link in the security
chain. A relatively simple approach, such as obfuscating the password, would
probably defeat the typical script kiddie who grabs a kit to exploit a
vulnerability on the server and manages to get in as root. It wouldn't defeat
a determined cracker. It probably *would* defeat the disgruntled sysadmin who
decides to leave the company with some secrets and sell them / break the
systems - and remember that "inside jobs" like that are a significant fraction
of all security breaches.
I'd ask broader questions: What is the organisation's security policy? What
threat analysis has been done on the application? Is this the weakest link /
does it not meet policy? If so, how much stronger does it need to be in order
to be "sufficiently good" to meet the organisation's security policy?
- Peter
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
