Technical Tip: Admin logins taking longer to complete after upgrading to FortiOS v7.2.11, v7.4.8, v7.6.1 or later
| Description | This article describes a known behavior where logging into FortiGate as an administrator can take longer than expected after upgrading to FortiOS 7.6.1, 7.4.8, and later. This change will also be introduced in FortiOS 7.2.11 (which at the time of this writing has not yet been released). |
| Scope | FortiOS v7.2.11, v7.4.8, and v7.6.1. |
| Solution | Starting with FortiOS 7.6.1, the cryptographic hashing scheme used for administrator passwords on the FortiGate was upgraded to enhance security. Refer to the following New Features page for more information: Enhanced administrator password security 7.6.1.
A side effect of this enhancement (upgrading the password hashing scheme from SHA256 to PBKDF2) is that a greater amount of CPU computing is required when verifying administrator logins (since the FortiGate must hash the provided password and compare to the hash saved in the configuration). Depending on the CPU resources available on the FortiGate, this hashing operation can take noticeably longer than on previous firmware versions.
For example, admins may find that when logging into smaller desktop FortiGate models (such as the FortiGate-40F, 60F, and 100F) the login may take 5-7 seconds before the login action is completed. On larger FortiGates (such as the FortiGate-2601F), the effect is much less noticeable, possibly adding 1-2 seconds of delay before completing the login.
On the GUI, this behavior manifests as the login page pausing for several seconds before taking the administrator to the web GUI, whereas on the CLI, a 'Verifying Password...' message will be presented before the command prompt is displayed.
Note 1: When logging into the FortiGate, CPU usage will increase on the associated process (for example, httpsd for GUI logins, sshd for SSH logins, getty for serial console logins, etc.) as the hashing operation takes place. For example, a FortiGate-60F may see these processes go up to 99% for a brief period as the login is conducted, then the CPU usage will decrease immediately after the login is completed.
Overall, the observed impact is inversely proportional to the amount of CPU resources onboard the FortiGate (i.e. larger more powerful FortiGates will see a much smaller impact compared to smaller FortiGates), and in general, the functional impact should be minimal (i.e. other than slower logins, there should be no effect to actual production traffic).
Be careful for units with extremely high ongoing CPU usage, as the admin login may take even longer than expected or even impact traffic if there is a serious lack of CPU resources. In cases of sustained high CPU usage on FortiGates, consider upgrading to a more capable FortiGate to ensure that these new hashing algorithms do not result in an impact on the network (i.e., size the FortiGate appropriately for the network conditions, assuming the CPU usage is not bug-related).
Note 2: Reminder that the CPU usage occurs per-admin login attempt. While the CPU usage for each individual login attempt is relatively brief, it can add up significantly if there are many consecutive admin logins. Consider disabling admin access for WAN interfaces or any other interfaces that public users can reach, and consider implementing features such as Trusted Hosts and Local-In Policies that tighten the list of source addresses that may attempt authentication to the FortiGate.
Note 3: Remote authentication options such as LDAP, SAML and RADIUS can be utilized for administrator access as a means of avoiding the high CPU usage related to logins (these admin types are not stored locally, and so no password hashing is required).
Related documents: |