[security-dev] char argument is weak
darran.lofthouse at jboss.com
Fri Dec 7 09:20:11 EST 2012
Reading this a lot of your justification appears to be that there are
other weak areas that also need to be addressed so lets address them
rather than using them as a justification.
Relying on a session token to identify a remote user is weak security,
no stronger than authenticating using plain text passwords.
Having to have some passwords in memory may be an indication that some
of those also need to be reduced but don't see how it justifies keeping
more in memory.
And regarding users that deserve their own fate we have been there, done
that and moved beyond that now - that really is the pre-Red Hat approach
we used to have.
On 12/07/2012 01:44 PM, Bill Burke wrote:
> Representing passwords as char is a weak argument. Manny of these
> char arrays are going to have to stay in memory in some form usually
> anyways. For example, a browser app may not keep a password in memory,
> but it sure as hell will keep a session cookie in memory which is just
> as big of a security hole. Passwords used to continually access the
> same resources (DB connections, etc.) also have to remain in memory
> unless you want to hit persistent storage each and every time. The
> mechanisms to obtain a password from a user are often already String
> based. Plus, there's no guarantee a memory swap isn't going to happen
> when the password char is in memory anyways. Finally, if you're
> running a secure system on an insecure box then you deserve your fate.
More information about the security-dev