Social Security Number Validation: A Tester's Guide to Uncovering Hidden Defects

It's amazing how many ways you can break software validation of social security numbers (SSNs), especially in the United States! It's almost like the government wanted to give testers more surface area. Jokes aside, SSN validation is really important to get right. Let's take a look at what's going on 

Introduction to SSNs

Ok, so tell me more about SSNs (USA):

SSN Rule 1: SSNs follow the following format: ###-##-####. The first part is called the Area Number. The second part is called the Group Number. The last part is the Serial Number. These parts will be important later. For now, let’s just focus on the format.

Let’s see what the validation rules are:

• Try non-numeric characters like letters, emoji, whitespace, or extra dashes
• Try putting dashes in the wrong spots
• Goldilocks: Too long, too short, big numbers, little numbers
• Try some number -parsing characters; for example. use exponent 1e10, -102, 2.39

The ###-##-#### format is identical to the way it appears on users' government cards. This is important. Users have a hard time remembering all the digits at one time. The breaks in the format allow them to look up and down and start again. From a usability standpoint, your app would do well to mirror this behaviour.

Some applications will automatically inject the dashes for you. That’s a whole other area for finding defects. Try backspacing, or try jumping back in the string and editing a number.

SSN Rule 2: The Area Number cannot be 000, 666, or 900-999. 

Let’s test that rule:

• Try numbers that supposedly are not allowed. They should fail validation.
• Try numbers near those reserved ranges such as 665, 667…

SSN Rule 3: The Group Number may not be 00.

SSN Rule 4: The Serial Number may not be 0000.

Rules 3 and 4 seem pretty straightforward. Let’s test how our application handles them:

• Try 00, 0000 respectively. They should fail
• Try both 00 and 0000 at the same time (123-00-0000), and check the error message. Sometimes if two errors occur at once, error messages can get garbled.

How June 25, 2011 Changed Everything

Well, not quite everything, but the U.S. government relaxed some of the validation rules a little bit for SSNs issued on or after June 25, 2011. 

Software development teams still have to keep their eye out for social security numbers issued BEFORE June 25, 2011 and implement the more forgiving standard for SSNs issued later as well. 

SSN Rule 5: SSNs issued before June 25, 2011 may not have an Area Number of 734-749 or a value greater than or equal to 773. Area numbers were used to differentiate districts (for example, 001-003 designated New Hampshire residents) and those ranges were reserved as a result. 

Here are a few area numbers you can test with:

001-003: New Hampshire

691-699: Virginia

766-772: Florida

SSN Rule 6: SSNs issued before June 25, 2011 used a sequential Group Number. You can use this group number to validate the year the number was issued. For example, SSNs starting with 417-57 were issued in 2003 in Alabama.

Here are a few examples you can test with:

1997 - Alaska: 574-25-...

1994 - Delaware: 221-86-...

2001 - Kansas: 509-21…

Ok, so rules 5 and 6 might not be worth implementing at your organisation, but they could be useful for fraud detection. Before applying any of these rules you’ll need to verify that the number was issued before June 25, 2011. 

Publicly Advertised SSNs

SSN Rule 7: SSNs that are issued specifically to be publicly advertised are not valid. In 1938, a wallet manufacturer thought it would be fun to insert a paper (pretend) SSN card in every wallet they sold 🙄. They used SSN 078-05-1120 in stores across America. This SSN was actually valid and belonged to the manufacturer’s secretary! Since then, over 40,000 people have claimed to have that SSN. You can read the full story here.

Let’s test how our software validates the rule: 

• The following SSNs are considered public and invalid. 078-05-1120, 721-07-4426, 219-09-9999

SSNs In Other Countries: The BSN System In The Netherlands

In the Netherlands they also have an SSN system called the BSN (short for Burgerservicenummer). Spoiler alert, there’s not nearly as many rules for this one.

BSN Rule 1: BSN uses the following 9 digit format - #########. 

Let’s test how our software handles the BSN format:

• Try non-numeric characters (alpha, emoji, negatives, whitespace)
• Goldilocks: biggest possible number (999999990), smallest possible (000000000), less than 9 characters, more than 9 character

BSN Rule 2: The nine digits must comply with the Eleven Test, which is essentially a checksum similar to credit cards. Let me explain with an example:

• BSN 323416391: 
  • 3*9 + 2*8 + 3*7 + 4*6 + 1*5 + 6*4 + 3*3 + 9*2 + 1*-1 = 143
    • We’re doing #*9 + #8…. #*2 + #*-1
  • 143 mod 11 = 0 (mod 11 must return zero for the checksum to be valid)

If that is a bit too complicated for you, don’t worry. You can use a generator to do all the fancy maths for you.

Let’s test it:

• Try a few valid BSN, try a few invalid BSNs
• Try BSNs with all zeros
• Try BSNs with big numbers (mostly 9s)
• Try BSNs with leading zeros

Tools To Generate SSNs And BSNs

It’s tough to keep all these rules straight and actually get on with the work of testing real values in your app. Here are a few resources that can help you get started quickly:

• SSN Generator for June 25, 2011: This webpage has a great database of pre-2011 SSN rules you can test with. Choose your regions and years and it’ll generate a nearly endless supply of SSNs.
• BSN Generator: This webpage generates lists of valid and invalid BSNs you can test with. It’s pretty straightforward. The site generates mock bank account numbers by default, but if you flip the selector you can get the citizenship numbers.
• Testing Taxi Edge Cases: This Chrome extension incorporates all the “Let’s test it” rules above and generates valid and invalid SSNs and BSNs. It also autofills the values right into your text field.

To Wrap Up

Validation rules for social security numbers are tricky and need special attention in test. But they aren't impossible to navigate, especially with number generation tools and understanding of some gotchas. As a tester, if you're mindful of the potential pitfalls in this area and you implement manual and automated tests for them, you'll be making a great contribution to the quality of the product you test,

For More Information

• Testing Ask Me Anything - Testing in Compliance and Regulation, Milan Kuveljic
• Using Personal Data In Test Safely: How To Comply With the GDPR, Ioan Solderea
• Go Old School: Why Test Techniques Aren't Dead!, Sue Atkins