# 4.3 Identity Management Testing ## [Identity Management Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/03-Identity_Management_Testing/README) ## 4.3.1 [Test Role Definitions](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/03-Identity_Management_Testing/01-Test_Role_Definitions) * [ ] Identify and document roles used by the application. * [ ] Review the granularity of the roles and the needs behind the permissions given **Evidence**: ``` ​ ``` ## 4.3.2 [Test User Registration Process](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/03-Identity_Management_Testing/02-Test_User_Registration_Process) Verify that the identity requirements for user registration are aligned with business and security requirements. * [ ] Can anyone register for access? Is it intended? * [ ] Are registrations vetted by a human prior to provisioning, or are they automatically granted if the criteria are met? * [ ] Can the same person or identity register multiple times? * [ ] Can users register for different roles or permissions? * [ ] What proof of identity is required for a registration to be successful? * [ ] Are registered identities verified? * [ ] Can users registered using weak password policies? * [ ] Does the application automatically logs in the new user? Validate the registration process. * [ ] Can identity information be easily forged or faked? * [ ] Can the exchange of identity information be manipulated during registration **Evidence**: ``` ​ ``` ## 4.3.3 [Test Account Provisioning Process](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/03-Identity_Management_Testing/03-Test_Account_Provisioning_Process) Determine which roles are able to provision users and what sort of accounts they can provision. * [ ] Is there any verification, vetting and authorization of provisioning requests? * [ ] Is there any verification, vetting and authorization of de-provisioning requests? * [ ] Can an administrator provision other administrators or just users? * [ ] Can an administrator or other user provision accounts with privileges greater than their own? * [ ] Can an administrator or user de-provision themselves? * [ ] How are the files or resources owned by the de-provisioned user managed? Are they deleted? Is access transferred? **Evidence**: ``` ​ ``` ## 4.3.4 [Testing for Account Enumeration and Guessable User Account](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/03-Identity_Management_Testing/04-Testing_for_Account_Enumeration_and_Guessable_User_Account) Review processes that pertain to user identification looking for ways to enumerate accounts. * [ ] The login **error** or **response time** differs from a valid and invalid username? * [ ] The login **error** or response time differs having a valid username but a wrong password? * [ ] The password recovery function alerts if the username exists or not? Does it take more time? * [ ] During account creation what messages you receive if an account already exists? * [ ] Look for other endpoints that might be used for user enumeration. To obtain a wordlist of existing and not existing emails, you can execute the following command ```bash cat registered_emails.txt | awk -F "@" '{print $1"@"$2"\n"$1"donotexist@"$2}' | xclip -sel clipboard ``` **Evidence**: ``` ​ ``` ## 4.3.5 [Testing for Weak or Unenforced Username Policy](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/03-Identity_Management_Testing/05-Testing_for_Weak_or_Unenforced_Username_Policy) Check if there is any kind of account name structure like “” or “” that could lead to user name enumeration. **Evidence**: ``` ​ ```