King Solomon and Authentication Security

King Solomon said, “A cord of 3 strands is not easily broken.” In cybersecurity, authentication using an unpredictable username convention, strong password policy, and securely configured MFA cannot easily be compromised.

Usernames:

• Should always be different from the name & email address and not easy to correlate.  Example: John Doe with an email address of JDoe@domain.com and internal username of TW2342.
• For high-security web applications: Do not allow a user to use an email address for their username.

Password Policy:

• Passwords/passphrase >=14 characters. Even all lower case is better than a short password with arbitrary complexity requirements.
• Eliminate arbitrary forced password rotation to prevent predictable and incremented passwords.
• Restrict the use of compromised passwords, your organization name, or other commonly used and expected words (ex. Spring, Summer, Password, Secret, etc.).
• Rate-limiting mechanism that does not cause DoS: captcha, MFA, or exponential rate limiting – increase timeout for each attempt for ANY source.
• Examples: Auth0, Enzoic, Lithnet, Okta, SecureAuth, Specops, etc.

MFA:

• Verify the MFA token before the password, in the back-end.  This has a dual benefit of protecting against brute-force attacks and other forms of password attacks (ex. password spraying), as well as preventing a DoS attack against known accounts.
• Do not use most push notification solutions. In practice, we have found it to be easier to bypass than even SMS-based. A growing number of threat actors are exploiting this same “muscle memory” user weakness.
• Verify the SMS OTP or push before the user is given a pass/fail. To do so, collect all three pieces of information (username+password+mfa) before providing a pass/fail result to the user or creating even so much as a noticeable timing difference. To prevent a user from receiving a flood of SMS messages or notifications (ex. during a brute force attack), verify the username+password – on the back-end only – before sending out the SMS/push. A token-based MFA solution simplifies this greatly as the initial page would include a field for all three pieces of information (username+password+mfa) and not even check the password unless the MFA token is verified first.
• Require additional information for MFA sign-up – username and password alone is not sufficient.
• Ensure email and text messages are sent to the user after MFA sign-up, to increase the chances they will detect a malicious takeover of their MFA.

_{^{Featured image is a derivative work from the following images: https://pixabay.com/photos/rope-knot-string-strength-cordage-3052477/}}