The following "rules" should be considered regarding authentication configuration:
Secure basis for strong authentication means:
- The registration (or linking to a user) of an authentication token must be at least as secure as the authentication token itself.
- Authenticity cannot be created "out of thin air", i.e. an authentication means is only as good as the basis it is set on. Strong authentication means (e.g. SMS token) may not be based on weak means (e.g. username and password) only.
- Never allow the self-registration of strong authentication tokens based on username/password or email only.
In two-factor authentication, the two factors must be independent of each other.
- The registration (or linking to a user) of the second factor must not be based on the first factor.
- The second factor must not be transported over a channel secured by the first factor only.
Use secure hash functions to store information for password verification.
- Use "scrypt" with default or better security parameters wherever possible.
- Using old hash functions (MD5, SHA1) may result in severe risks once password hash databases are stolen or leaked.
Lock user accounts after a few (3-5) failed attempts to login. Note that there are limitations regarding failure counters when using MSAD as sole persistence layer. See Microsoft Active Directory (MSAD) for Airlock IAM for resulting limitations.
Use sensible password policies in order to make password guessing or brute-forcing harder.
If applicable, use the Stealth-Modefeatures (Main Authenticator in Loginapp (JSP) as well as in various REST services).