This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Test User Registration Process (OTG-IDENT-002)"

From OWASP
Jump to: navigation, search
Line 1: Line 1:
 
== Summary ==
 
== Summary ==
  
Some websites offer a user registration process that provisions a person with access. The identity requirements for access vary from positive identification to none at all.  
+
Some websites offer a user registration process that automates (or semi-automates) the provisioning of people with system access. The identity requirements for access vary from positive identification to none at all, depending on the security requirements of the system. Many public applications completely automate the registration and provisioning process because the size of their userbase makes it impossible to manage manually. However, many corporate applications will provision users manually, so this test case may not apply.  
  
 
== Test objectives ==
 
== Test objectives ==
Line 15: Line 15:
 
## Are registrations vetted by a human prior to provisioning, or are they automatically granted if the criteria are met?
 
## Are registrations vetted by a human prior to provisioning, or are they automatically granted if the criteria are met?
 
## Can the same person/identity register multiple times?
 
## Can the same person/identity register multiple times?
 +
## Can users register for different roles/permissions?
 
## What proof of identity is required for a registration to be successful?
 
## What proof of identity is required for a registration to be successful?
 
## Are registered identities verified?
 
## Are registered identities verified?
  
 
# Validate the registration process
 
# Validate the registration process
 +
## Can identity information be easily forged or faked?
 +
## Can the exchange of identity information be manipulated during registration?
  
 
=== Example ===
 
=== Example ===
  
 
In the Wordpress example below, the only identification requirement is an email address that is accessible to the registrant.  
 
In the Wordpress example below, the only identification requirement is an email address that is accessible to the registrant.  
[[File:Wordpress_registration_page.jpg|800px]]
+
[[File:Wordpress_registration_page.jpg|700px]]
  
 
In contrast, the Google example below, the identification requirements include name, DOB, country, mobile phone number, email address and CAPTCHA response. While only two of these can be verified (email address and mobile number), the identification requirements are stricter than Wordpress.  
 
In contrast, the Google example below, the identification requirements include name, DOB, country, mobile phone number, email address and CAPTCHA response. While only two of these can be verified (email address and mobile number), the identification requirements are stricter than Wordpress.  
[[File:Google_registration_page.jpg|800px]]
+
[[File:Google_registration_page.jpg|700px]]
  
 
== Tools ==
 
== Tools ==
 +
 +
HTTP Proxy
  
 
== References ==
 
== References ==
  
 +
[http://mashable.com/2011/06/09/user-registration-design/]
  
 
== Remediation ==
 
== Remediation ==
  
 
Implement identification and verification requirements that correspond to the security requirements of the information the credentials protect.
 
Implement identification and verification requirements that correspond to the security requirements of the information the credentials protect.

Revision as of 16:33, 21 November 2013

Summary

Some websites offer a user registration process that automates (or semi-automates) the provisioning of people with system access. The identity requirements for access vary from positive identification to none at all, depending on the security requirements of the system. Many public applications completely automate the registration and provisioning process because the size of their userbase makes it impossible to manage manually. However, many corporate applications will provision users manually, so this test case may not apply.

Test objectives

Verify the identity requirements for user registration align with business/security requirements

Validate the registration process

How to test

  1. Verify the identity requirements for user registration align with business/security requirements
    1. Can anyone register for access?
    2. Are registrations vetted by a human prior to provisioning, or are they automatically granted if the criteria are met?
    3. Can the same person/identity register multiple times?
    4. Can users register for different roles/permissions?
    5. What proof of identity is required for a registration to be successful?
    6. Are registered identities verified?
  1. Validate the registration process
    1. Can identity information be easily forged or faked?
    2. Can the exchange of identity information be manipulated during registration?

Example

In the Wordpress example below, the only identification requirement is an email address that is accessible to the registrant. Wordpress registration page.jpg

In contrast, the Google example below, the identification requirements include name, DOB, country, mobile phone number, email address and CAPTCHA response. While only two of these can be verified (email address and mobile number), the identification requirements are stricter than Wordpress. Google registration page.jpg

Tools

HTTP Proxy

References

[1]

Remediation

Implement identification and verification requirements that correspond to the security requirements of the information the credentials protect.