Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re: RFC / Audit: Mojo Login Example

by haj (Vicar)
on Mar 22, 2020 at 13:50 UTC ( [id://11114545]=note: print w/replies, xml ) Need Help??


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.

Replies are listed 'Best First'.
Re^2: RFC / Audit: Mojo Login Example
by haukex (Archbishop) on Mar 23, 2020 at 07:35 UTC

    Thank you for the thoughtful reply!

    You don't want to expose the salt to the client - but without salt hashing doesn't give better security.

    Yes, I should have been more clear on this - I would take a hash of only the password on the client side, say SHA-512 multiple times, and additionally do the same hashing+salt on the server. That way, the cleartext password is never seen by the server, and provided the hash isn't in a rainbow table somewhere, it adds a tiny bit more security.

    All of your points are excellent, and yes, I see that perhaps a per-IP delay or lockout on too many attempts might even be better than the current implementation (in Mojo: $c->tx->remote_address). Even though I agree logging is very important, did leave it out of this example... but luckily Mojo makes it fairly easy to add: app->log->warn("..."), app->log->error("...") and so on, and it can be redirected into a database as well via the event mechanism built into Mojo::Log.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11114545]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others surveying the Monastery: (6)
As of 2024-04-19 13:07 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found