## 3 Proposed Framework for Cloud Multi-Factor Multi-Layer Authentication
### Cloud MFA Algorithm for Intrusion Detection
As presented in [89], a 3 FA protocol is applied to provide secure, efficient, and practical for mobile lightweight devices. The extended chaotic maps component of the protocol is used to generate random numbers. The fuzzy verifier's component of the protocol is used to verify the users' identity. Algorithm 1 explores the main security layers that are embedded together to create multi-factor methods for authenticating, verifying, securing, and maintaining the privacy of cloud users who are connected to the cloud platform services. As explained, the algorithm initiates the user factor \(UFP\) of \(user_{x}\) that contains the authentications and privileges of the user on the cloud. Furthermore, both the validity and value for each user factor \(UFP\) are defined as Boolean variables with false values at the beginning of the verification method. After passing the first two layers of authentication that include access control and AMS that manipulates user access using email, SMS, and biometric authentication, the MFA is initiated, wherein a request from \(user_{x}\) is sent to the cloud server to login into the cloud platform. Once the user factor \(UFP_{i}\) is sent to the user, the first layer of MFA is to check the length of the factor. If the factor length is not correct, the factor \(UFP_{i}\) is stored in the audit table, and the second layer of authentication is initiated, wherein the cloud server verifies the validity of the factor. If the factor \(UFP_{i}\) is not valid, an alarm will be raised to prevent the user access, and the factor \(UFP_{i}\) will be stored in the suspected table. A new authentication factor \(UFP_{j}\) is generated and stored in the cloud server to be sent to \(user_{x}\). If the validity of the factor \(UFP_{i}\) is true, the factor is stored in the audit table; otherwise, the \(user_{x}\) is classified as suspicious, and the factor \(UFP_{i}\) is stored in the suspected table, and an alarm will be raised. The next authentication parameter is initiated by verifying the value of each privilege in the factor \(UFP_{i}\). Each value in the factor \(UFP_{i}\) represents a specified authorization on the cloud platform services. If the factor value is true and matched, the suspected table is checked first before giving the user permission to login into the cloud services. If the factor has existed in the suspected table, the factor \(UFP_{i}\) will be stored in the audit table, and an alarm will be raised. If the factor \(UFP_{i}\) does not exist in the suspected table, this means that the \(user_{x}\) is mostly viewed as a normal user. In order to reduce the false positive (FP) percentage of normal users, the location and browser name of \(user_{x}\) are verified. Both the location and browser name are stored during user registration to the cloud service provider, then the user location is checked against the stored location in the cloud server. If the location does not match the stored one, the \(user_{x}\) will be stored in the suspected table, and an alarm will be raised. If the location is correct, the browser name will be checked as a final countermeasure. An OTP is applied for verification in this step, as the user can use another browser during registration to the cloud. Therefore, an OTP is raised to ensure the validity of the user. If the verification is not correct, the \(user_{x}\) will be stored in the suspected table and an alarm will be raised. Otherwise, the user will login to the cloud platform to manipulate its services. ```
1 Initialize User Factor Privilege \(UFP\)
2 Initialize Boolean Value for \(UFP\) validity \(=false\)
3 Initialize Boolean Value for \(UFP\) value \(=false\)
4 Request\(UFP_{i}\) from Cloud DB Server
5 GET\(UFP_{i}\)
6 IF\(UFP_{i}\).