in reply to RFC / Audit: Mojo Login Example
Disclaimer: I'm not at all familiar with Mojo, so there's a bit of guesswork while I'm interpreting the code.
- Hashing at the client side is no good idea anyway. You don't want to expose the salt to the client - but without salt hashing doesn't give better security.
- These days I often see attacks where a list of user ids is probed, once for each user id. This seems to be an attack pattern especially in forum or wiki software where a set of valid login names is easily available for unauthenticated readers.
- An exponential rise is double-edged: If you apply it per session, then attackers aren't affected if they create a new session for every attempt. Applying it per login allows another attack: Lock out users by repeatedly attempting an invalid login. Robots are patient, but users aren't.
So what should be included is:
- Inform users about the number of unsuccessful login attempts since his last successful login. For low numbers it will keep them informed about the value of choosing a good password, for high numbers they might want to inform the server guys.
- Logging both failed and successful logins can help admins to detect ongoing attacks. The heuristics to detect attack patterns from logging data is outside the scope of the application, but it should at least be made possible. A decent but constant delay between logins gives admins sufficient time to think about appropriate countermeasures.
In Section
Seekers of Perl Wisdom