@ricardo said in Authentication:
1.1. The password, if stored in the system, should be stored in a one-way salted hash.
By default the passwords are stored in Bcrypt format which uses a salt.
1.2. The system shall enforce strong password at least 8 characters long with reasonably complex composition.
The minimum length of passwords as of Mango v3.5 is 8 characters, we intend to make this configurable. "reasonably complex composition" is not a very specific requirement, but again we are intending to add password complexity rules.
1.3. The system shall enforce period change of password of user accounts.
You can setup password expiration in the system settings as of Mango v3.5. It's under "System settings" > "Password settings".
1.4. The system shall prevent brute-force password attack. [Comply by editing rateLimit.* in env.properties?]
Correct there is a rate limiter for authentication attempts which can be configured in env.properties. There are limits per IP and per username. Attempts to exceed the rate limit are logged to ma.log at WARN level (class name com.serotonin.m2m2.web.mvc.spring.security.MangoAuthenticationFailureHandler)
1.5. The system shall provide a secure mechanism for user password reset self-service. [Comply with "Forgot password" in login page?]
Yes, there is password reset available via a one-time JWT token sent via email.
1.6. Security events of user account activities shall be logged and kept for at least 3 months including [Comply with event log?]:
There are Mango events for login and logout. The timestamp, username and IP address is recorded for login. The event is "returned to normal" when the user logs out, there is a timestamp recorded when events return to normal.
Failed logins are only logged to your ma.log file (same class as mentioned above, again WARN level), they are not events. The timestamp, username and IP address are logged.
There is no "lockout", but you can disable users, this is logged in the "Audit trail" in "System status" (tracks all changes to users, including password changes). The audit trail logs the timestamp and the username of the user who made the change but there is no IP address recorded.
I think we can look at improving the logging of security related events to ma.log and provide a log4j2.xml configuration file which sends all the security events to a separate log file.