Trusting the Social Security Administration?

Back in September 2013, Brian Krebs wrote about Social Security fraud at the My Social Security web portal, 

The SSA and financial institutions say they are tracking a rise in cases wherein identity thieves register an account at the SSA’s portal using a retiree’s personal information and have that retiree’s benefits diverted to prepaid debit cards that the crooks control ... The trouble really began earlier this year, when the Treasury started requiring that almost all beneficiaries receive payments through direct deposit ... At the same time, the SSA added the ability to change direct deposit information via their my Social Security Web portal. Shortly thereafter, the agency began receiving complaints that identity thieves were using the portal to hijack the benefits of individuals who had not yet created an account at the site.

Poor choices made by the Social Security Administration, regarding how they verify identities, left an opening for bad guys to buy personal information and use it to steal Social Security payments. Krebs suggested that the only defense was to create an account for yourself before bad guys did it for you.

Almost three years later, nothing has changed. In early August Krebs noted that it is

still relatively easy for thieves to create an account in the name of Americans who have not already created one for themselves. All one would need is the target’s name, date of birth, Social Security number, residential address, and phone number. This personal data can be bought for roughly $3-$4 from a variety of cybercrime shops online.

That SSA failed to change an insecure system was, of course, not news. The news Krebs was writing about last month, was their new insistence on two factor authentication. Now, the Social Security Administration would not let you login without a one-time security code that they texted you. 

There are two problems with this.

Needless to say, the people least likely to use text messages are senior citizens, the target audience for Social Security.

Then too, text messages are not secure. This is old news. 

The timing was interesting too. The SSA announced their new texting system the same month that the National Institute of Standards and Technology NIST) said not to. 

NIST released a draft proposal at the end of July (Digital Authentication Guideline 800-63B) warning federal agencies that texting for two factor authentication will no longer be a recommended practice. 

The SSA mandate for texting security codes lasted all of two weeks. Of course, they didn't back off for security reasons. 

The concept of using an extra code to supplement a password is, of course, a good one and Krebs sees a brutally obvious solution. 

I would like to see the SSA make it mandatory to receive a one-time code via the U.S. Mail to finalize the creation of all new accounts,... it’s mystifying to me why it doesn’t already do this by default.

All this got me looking at the www.ssa.gov website where I discovered three issues, presented below from least to most important. 

GREEN ADDRESS BAR

There is an FAQ section of the site devoted to "How We Verify And Protect Your Identity" and one of the questions (below) got my attention because I haven't seen a green address bar in years. 

On OS X, Safari, Chrome and Firefox all display a white address bar at ssa.gov. On iOS, Chrome uses white, Safari uses gray. On Android, both Firefox and Chrome display a white address bar. The Chrome browser on Chrome OS uses white. On Windows, Firefox, Chrome and Opera are white, white and white. The Edge browser uses gray, but when you hover the mouse over it, the address bar turns white. So, where does green come from?

Internet Explorer. It's the only browser that changes the address bar to green, and it does so, when viewing a website with an EV (Extended Validation) certificate. Mind you, this is a good thing, and I wish more browsers would change the color of the address bar, as its a great way to distinguish domain validated certificates from the more trustworthy Extended Validation ones. 

And, good for SSA for using an Extended Validation certificate. Many companies that should, such as Wells Fargo, Amazon and Walmart, do not.

That said, the answer to the question is more wrong than it is right. A green address bar really means you should use a different web browser. 

And, while an Extended Validation certificate provides better assurance that you are actually at the website you think you are at, it does not, in and of itself, make a website safe.

For one thing, all encryption is not the same (more on that below) and the safety of a website has to include the data not being stolen from the back end, something the US government has failed at in the worst possible way.

And, by claiming that green is good, they may well scare away non-technical people (their demographic) who see a white or gray address bar.

Then too, in the limited testing I did with Internet Explorer, the address bar sometimes said "Identified by DigiCert" (above) instead of "Social Security Administration". I don't know why.

ADOBE FLASH PLAYER

To many techies, the Adobe Flash Player is the mother of all security flaws. Sure enough, ssa.gov uses Flash - and it's hidden. That is, nowhere do you see the normal gray puzzle piece that browsers blocking Flash display over sections of a web page devoted to Flash. I didn't realize that Flash was running under the covers until Safari on OS X asked about authorizing it.

My best guess is that Flash is being employed by the Foresee survey shown above.

I say this based on JavaScript files (here and here) that ssa.gov pulls in from answerscloud.com and on Foresee developer documentation that says they provide their clients with a .swf (Flash) file and that Flash is used to send SessionReplay information to ForeSee.

Although the survey message says you were randomly selected, that does not appear to be true. I was presented with the survey pretty much every time I tested ssa.gov on a new computer.

AND NOW, THIS

For years, SSL Labs, from Qualys, has been the gold standard in checking the many technical details that make a web site secure. So, imagine my surprise when ssa.gov got a perfect score on their SSL server test.

It wasn't long, however, before disappointment set in. The image at the top of this blog has a red arrow indicating the link to "SIGN IN/UP". Click on that, and then on "my Social Security" and you end up at https://secure.ssa.gov/RIL/SiView.do (see below).

The important point here, is that we have moved from www.ssa.gov to secure.ssa.gov. Technically, "www" and "secure" are subdomains of the main domain name, ssa.gov. I mention this because each subdomain can have its own security profile. And, in the case of ssa.gov they do. In fact, faq.ssa.gov has a third security profile, different from the first two.

Despite its same, secure.ssa.gov is not secure. It's not even close.  

As you can see in the SSL Labs report above, the supposedly secure section of ssa.gov scored a C, which is pretty bad. The report is very long and detailed, but the two orange stripes (enlarged below) are the worst issues.

The message "The server supports only older protocols, but not the current best TLS 1.2" refers to different versions of the underlying protocols providing the security.

In the beginning, HTTPS web pages used the SSL protocol but all versions of SSL have since been disgraced. SSL has been replaced by TLS (web pages are still HTTPS) and there are three versions of TLS with 1.2 being the latest.

Any website that cares about security supports TLS 1.2. Both www.ssa.gov and faq.ssa.gov support it. But, secure.ssa.gov does not, an oversight that Qualys considers so big that the grade is capped at C, no matter how secure everything else may be.

The older versions of TLS are 1.1 and 1.0. I am not sure how secure version 1.1 is considered, but certainly version 1.0 is not considered secure. Amazingly, secure.ssa.gov only supports TLS 1.0, it does not even support version 1.1.

Another company, High-Tech Bridge, also offers an SSL/TLS Server Test and they too, note this problem. Their warning states that "The support of TLSv1.1 is mandatory according to NIST guidelines." So, the Social Security Administration is violating NIST guidelines. I guess no one at NIST is ready to retire. 

The other big mistake, has to with Forward Secrecy which I wrote about back in June 2013. It's a long topic, but an important one. Without Forward Secrecy, websites leave themselves open to being spied upon and there is no reason not to use it.

The other section of the website, faq.ssa.gov, was rated B by SSL Labs. Here too, there is no support for Forward Secrecy but at least TLS 1.2 is supported. The other big security mistake in the "faq" subdomain is support for weak Diffie-Hellman (DH) key exchange parameters. Frankly, that's over my head. 

If the Social Security Administration can do everything right for the "www" portion of their site, how do they fall down so badly on the other subdomains?

This being a Defensive Computing blog, perhaps the best thing to do is to block all on-line access. SSA points out that "You can block electronic access to your information at any time, for any reason." Hopefully that will keep the Chinese out too.

More about ClickHigh-Tech BridgeQualysSSATechnologyTestWells Fargo