PCI DSS 3.2 two-factor authentication

The login flows for RADIUS authentication, SAML IdP, guest portals, and GUI login all meet PCI DSS 3.2 standards regarding multi-factor authentication.

In the case where the Bypass FortiToken authentication when user is from a trusted subnet option is enabled (under Authentication > SAML IdP > Service Providers), and the user is logging in from a trusted subnet, the login flow reverts to password-only regardless of the PCI mode.

The GUI login page is hard-coded to Apply two-factor authentication if available (authenticate any user), so it behaves the same as the guest portal.

All failed authentications will return the same generic message, so as not to reveal any clue to an attacker about which piece of information was valid or invalid:

"Please enter correct credentials. Note that the password is case-sensitive."

Remote login to the CLI (i.e. Telnet, SSH) also complies with the new PCI requirements.

Guest portal exception

There is one exception for guest portals. When a user has exceeded their time and/or data usage limit, the FortiAuthenticator shows the "Usage exceeded" replacement message. The best behavior would be to only show the replacement message if the credentials are valid. However, this would require a major change in the internal flow of the current authentication implementation. Instead, the FortiAuthenticator only requires that the account name be valid (not the credentials). The downside is that it opens the door for leaking valid account names. Nonetheless, it is deemed acceptable because:

1. Account name leakage prevention is not a PCI requirement (just a best practice).
2. Leaked account names are not usable because they are disabled (due to exceeded usage).
3. Disabled accounts can't be leveraged to brute-force credentials (in the hope of using them if an account gets re-enabled/usage extended).