Potential Risks Using Reference Code Based Authentication For Web Based Application Form That Contains SSN

Question

I'm currently building a web based membership application form that will require a user to enter an SSN and other identifiable information. Part of the requirements of the membership application is to allow a user to be able to resume their application and pre-fill of the information they already entered into the form fields. The stakeholders do not want to burden the user with a username and password. We have come up with the following alternative authentication method.

A user can start an application and click a button to "Save" their application. When they click "Save" an email is sent to them and they receive a 6 character alpha numeric reference code.

To "resume" the application the user must then enter the 6 character reference code as well as their birth date, last name, and last four digits of their SSN.

My question is, on a scale of 1 to 10 what would the risk factor in allowing a user to authenticate in this manner. What is the probability that someone could load someone else's application if they brute force attacked the web based form. And if the risk scale is high, then what can I do to increase the security on this form. I can't implement a password system and the reference code needs to be simple enough that someone could over the phone present the code to a customer service agent.

Additional Security:

• Reference Codes will expire after 1 week on non-use.
• Reference Codes will expire once the form has been submitted.
• The web application is using HTTPS and TLS to transfer the data.

About 200 applications will be submitted per week, so around a max of around 200 applications might have active reference codes in a given week.

Answer 1

First of all, I wonder if your form is so long that it actually makes sense to implement all of this rather than simply have the user fill out the missing details.

Second, you don't mention the country, I will assume you are targeting United States citizens.

Moreover, not everyone there has a SSN, so I will further assume that people without one cannot enroll there.

Your requisites are

the user must then enter the 6 character reference code as well as their birth date, last name, and last four digits of their SSN

I don't really like the way this came out. Apparently, someone came up with that as an authentication method, and then you have to verify if it's secure enough for your needs, rather than actually designing the authentication after your system.

According to the 2010 US Census, there are 2,442,977 people with a surname of Smith out of 308,745,538, which means that every week there will usually be between 1 and 2 people (1,58) with that last name in your platform.

Using only the last name would obviously have been a bad idea. But what about the other items that are being mixed? The date of birth will be roughly spread through the year (unless this is a membership application for a leaplings association!), and the SSN would appear to further distribute that. Alas, it is long known that Social Security Numbers are Not Random, and based on birth date it might be possible to predict the SSN, so as a security measure I don't think you should be relying on those 4 digits.

All of these are public data anyway, and -even when using the full names- are inherently flawed ways of identification, leading to mixup stories such as the one of Lisa Davies or Jessica Ishak. The whitepaper The Trouble with Names/Dates of Birth Combinations as Identifiers concludes that 8.3% of people aren't uniquely identifiable by names and DOB.

However, you have an extra ace to play here which is the 6 character reference code. Presumably, you would generate it in a way that two people with same name and date of birth would receive different reference codes. Preferably, giving out different reference codes to different people. This is the strongest piece we can rely on.

These reference codes must be generated in some random way, certainly not a sequential code. Assuming you were not including vowels in order to avoid generating words deemed offensive, and even ignoring numbers, you have 21⁶ = 85,766,121 combinations. Ample enough to give an unique code to each user, and have the entries so sparse that it would be hard to guess a valid one (assuming you use an adequately random generator).

Thus, you can do a proper job using only the stated reference code. You should however take bruteforce protection into account on the resumption form, so that for instance users get asked to fill out a captcha instead of the other stated data, and include throttling limits on multiple attempts of resuming invalid codes.

Answer 2

First off, saving SSN data puts your system in a very special definition of legal accountability. Think twice about doing this if not absolutely necessary.

"... What is the probability that someone could load someone else's application if they brute force attacked the web based form ..."

The probability numbers alone make the approach pretty solid and with rate limiting on attempts, brute forcing is unlikely, BUT!

A more likely scenario derives from implementation details.

What happens when instead of providing continuation credentials, the user simply starts a new form with the same SSN?

What about more than one person with the same SSN?

After login validation, is the SSN available on the client side? If so what if it's altered in stream? What about the form identifier? Is it the SSN or something else? What if that's altered in stream?

If client information is validated only at login, spydering in stream data may become possible post rate limited validation.

In short, your logon continuation technique is probably not the weak link. There is of course no way I can know for sure, but just examples to consider.

Good Luck!

Answer 3

To start, I think it's important to point out that SSNs are basically useless as identifying information. They are not a secret code. Aside from all the data breaches that have included them, they were long generated in non-random manner. The idea that knowing an SSN is proof of identity is pretty bunk. I think your main problem may be with the initial registration.

that said, let's assume that the personal details are known to the attacker since this is all public info. So the only real security is the 6-digit code. Presuming you have a good secure PRNG, there are million different possible numbers. In lieu of anything else, this can definitely be brute-forced.

To prevent brute-force attacks, the simplest approach would be to prevent someone from attempting many logins to the same account in a short period of time. You could enforce, say, a 5 second delay after each failed attempt and double it on every failure.

Answer 4

Why don't you just send them a link?

The link can potentially contain unique 64 characters, which would be much stronger than a reference code and they would just have to input last name and the last 4 digits of SSN.

Why not use 2FA?

You are currently utilizing only 1 value that changes, which is the reference code. Let's say the application contains very sensitive data. The CEO or any other person with the ability to access this data is a victim of BEC (Business email compromise). The attacker will have access to his link, he will know the last name and could potentially find the last 4 digits of SSN buried somewhere in the e-mails. 2FA is a way around this, rather than using the last 4 digits of SSN a constantly changing and independent value from OTP would provide much better security.

Prevent brute-force

To prevent brute-force on your application you can enable Throttling for the specific reference code. Let's say with this reference values 5 times the last name is input incorrectly within a specific time frame, a new reference code is sent to the e-mail. This will increase the difficulty to brute-force significantly.

Answer 5

The practice of a long or complicated form having a "come back later" option is not unusual: the Inland Revenue for example.

You say that you don't want to burden the applicant with a password or username, but I think you already have sufficient data to be a password/username by proxy: you capture email address, name, DOB, SSN, 6-digit password/reference. It might help to separate out identification, authentication and authorisation. While you capture the email address, name, DOB and full SSN how do you know that they are correct? If you are checking these against a third party database then you can use that data to confirm accuracy as presumably you really do need the full day of birth as well as the full SSN. That data is all about identification and only your stakeholders will know how certain they want to be about identity.

The person leaves and you want them to come back and not burden them with remembering a password, but you are burdening them with having to remember which date of birth they used, which variant of their name, having a SSN or not and finally the six-digit not-a-password. And they have to have entered a valid email address which they have access to.

If the requirement is that the six-digit-not-a-password is something that can be written down then you will have to go with six digits. If the requirement is not specifically that the code can be written down then you could go with a link. You are emailing this anyway. Have a GUID token in the form URL so that all the user has to do is copy-paste the URL. That URL GUID is valid for X days and once the form is complete it becomes invalid. You will end up with a URL that is similar to a Google Doc URL. Your stakeholders will understand this concept and they will potentially think "if it's secure enough for Google then it's secure enough for us"; depends on the level of expertise of your stakeholders. As you know, many sites use this method for a password reset. Your users and stakeholder may not know that this is how some REST APIs work: they have an API key sent in the header, and even SSH certificate-based authentication is really "only" a big old long password.

The advantage of this scheme is that it's easy for your customers. The GUID won't be stored in logs or seen by proxies because you are using TLS. There's lots of entropy in a GUID so almost no chance of collisions. They are impossible to enumerate. You have said that you are going to email the codes so you can just email the link.

There are some disadvantages. A 38 digit passphrase isn't the most convenient if you really want users to type it into a box.

One of the requirements (I missed prior to this edit) is that the code has to be able to be spoken to the service desk. I would go with the URL containing a GUID plus use the last six digits of the GUID as the token and then ask the person to provide one of the identification tokens and the six-digits over the phone or by text message. It's a bit of a cludge but it improves the entropy and provides a way for the code to be spoken. Using the last six digits of the URL keeps everything consistent. You cold use the surname they registered with or the email address. Surnames could be only two characters so that's only another 8 bits of entropy but better than nothing.

There are some disadvantages that apply to this and also apply to the general case of what you are describing: reliance on the security of the Mail User Agent, the Mail Transfer Agent, the end point, overlooking, shared mailboxes. A bad actor who knows the victim may already know their DOB and SSN (I don't have a SSN so I don't know if this is the case, but in the UK the NIN is pretty public). Brute force is unlikely but as good practice you will want to throttle attempts.

You ask about risk on a scale of 1 to 10. Risk is the product of impact to your business and likelihood. I can't answer for the former: you will need to undertake a business impact assessment to determine what the impact of a compromise to CIA is. In terms of impact to the rights and freedoms of the data subject if you were to do a PIA as required by GDPR then you might argue that a single record is a marginal risk to a data subject: there is not much an attacker could do and DOB + name is already pretty much public. Not so sure about SSN. The UK NIN + DOB + name could potentially be an identity hijack risk. A databreach would, I think, be notifiable to the ICO so your impact is going to be 3 to 6 on your scale. A loss of your entire database might be 5 to 8, but this question is about a single record assuming the infeasability of enumeration. The likelihood is requires that you undertake threat modelling: I can't say really how much of a target your database is. If it is very attractive, if for example being able to get hold of a member record directly led to a large cash reward then it's possible that someone could rent a botnet to try a collision or brute force attack. It would be unlikely to succeed of course, but they might try if the prize were worth it. It's more likely though that your database of credentials is exposed through poor internal practice. Your end users are unlikely to be highly security aware, so they may well store the credentials anyway.

Your threat model will tell you if you want to care about user behaviour, the user email or if you only want to focus on the part that you can control. If the site needs to be very resistant to an attack then you might want to consider posting the credentials in the snail mail to a pre-registered address as the UK Government Gateway does.

Assuming that your risk / threat assessment is limited to your technology and the security of the controls that you have in place then a GUID in the URL might be the easiest solution for your clients and your stakeholders should find it acceptable too.

If your threat assessment shows that you just don't want anyone to stumble across that URL during its active time window then you should consider allowing a login via a social media account, eg oAuth etc. That will give you their identity, it's easy for the user, it's "modern". But the downside is that you have to code oAuth which isn't exactly hard, you are giving up a bit of control to Google and of course it relies on your users having such an account.