Knop Demo Login - Implement standard security practices

[stevepiercy]

The Knop Demo's Login does not implement the features that Knop provides, and additional basic security features beyond the scope of Knop are left off.

• forced HTTPS/SSL on login form
• obliteration of session and cookie data when reaching login form
• redirect to another page after successful login
• encrypted, hashed, salted passwords
• failed login management configuration flags (amtacrick)
  • exponential increase in delay in milliseconds for each subsequent failed login attempt, implemented as sleep(x^n), where x ≥ 0.0 and n > 0.0 and x^n is cast as an integer
  • lock out users after N failed login attempts within an optional duration
  • add explicit lockout timestamp, defined as the instant at which the lockout becomes effective (amtacrick). Duration or clearing of the lockout are left to the developer to implement in their solutions. Lasso 9 may soon have an event_schedule implementation, and we'll investigate that as a possibility to clear a lockout.
  • add fingerprint for non-authenticated users (amtacrick). knop_user supports a fingerprint for authenticated users, but not for anonymous users, so this code could be reused. See: https://github.com/knop-project/knop/blob/master/knop8/source/_ctype/user.inc#L27
• other? please add your thoughts

HTTPS/SSL probably will not be implemented for the Demo because it makes it hard for newbs to get started. Instead we might offer a flag in the global config to enable SSL with a redirect to a secure login page.

[amtacrick]

Suggest multiple failed logins be able to be managed by a site flag to chose what action to take - delay (minutes) / block (require reset) / redirect during "security action period"

Suggest having site setting for time in which failed attempts are detected

Consider delay use of / blocking IP after nominated number of failed login attempts from one IP within defined time period (any invalid login / password combination)

[stevepiercy]

I've incorporated what I understood, but I need a little more clarification.

I'm not sure I understand this: redirect during "security action period". Is this where the system has identified and locked out a user from logging in after repeated failed attempts, and then redirects the user to a page where they can no longer attempt a login? If so, then the redirect itself is beyond the scope of Knop, however the lockout could be part of Knop. It would be up to the developer to decide what to do during the lockout period. I have implemented the non-redirecting lockout to clear the lockout after a period of time in some systems, but it relies on the Lasso 8 [event_schedule] tag which is not supported in Lasso 9.

Can you also elaborate on "time in which failed attempts are detected"? Do you mean, for example, specific times (9a - 5p) or a duration (15 minutes)?

Please let me know if I've missed anything in the revision of the issue description above. Thank you!

[amtacrick]

"security action period" is the period during which the ability to log in is inhibited (until expiry of set time or reset, dependent upon implementation). Agreed that the actions to take should reset with the solution and not Knop - just tossing out there things we do at te moment. Agree that "Duration" is a better word than "time" to describe the period within which attempts are evaluated - typically shorter for straight failed logins (e.g. 3 failed attempts within 2 mins)

[stevepiercy]

Added:

• add explicit lockout timestamp, defined as the instant at which the lockout becomes effective (amtacrick). Duration or clearing of the lockout are left to the developer to implement in their solutions. Lasso 9 may soon have an event_schedule implementation, and we'll investigate that as a possibility to clear a lockout.

Updated:

• lock out users after N failed login attempts within an optional duration

Thank you!