On Wednesday 02 January 2013, Jim Jagielski wrote: > For *real* improvement, wouldn't storing in socache be > the optimal method?
Yes. I fear there may be some knee-jerk reaction like "oh my god, they are keeping all the passwords in plain-text". But if it would be limited to the shmcb socache provider, and if the passwords would be cleared after some time of not being used, I don't see any real security problems. Any other opinions? > On Jan 1, 2013, at 3:16 PM, [email protected] wrote: > > Author: sf > > Date: Tue Jan 1 20:16:30 2013 > > New Revision: 1427548 > > > > URL: http://svn.apache.org/viewvc?rev=1427548&view=rev > > Log: > > Add some caching for password hash validation. > > > > Password hash functions must be expensive in order to be secure. > > But if they have to be re-evaluated for every request, > > performance suffers. > > > > As a minimal remedy, cache the most recent result for every > > connection. This gives a great performance boost if a web browser > > does many requests on the same connection with the same > > user+password. In principle, this may keep the plain text > > password around longer than before. But in practice, there won't > > be much difference since user+password can already remain in > > some unused data bucket for longer than the request duration. > > > > A proper solution still needs to be found for connections from > > proxies which may carry requests for many different users. > > > > While it currently only requires the conn_rec, the new > > ap_password_validate() function takes username and request_rec to > > allow future extensions, like detection of brute-force attempts.
