« Previous Post | Blog Home | Next Post »


Truston Discovers a FDIC Data Security Flaw

Posted on Sep 30, 2006 by Tom Fragala

Updated below...

Shame on the FDIC. I was tooling around their web site when I stumbled across a page that helps you determine the amount of your FDIC insurance (it may be more than the typical $100,000). I was stunned to find that their Electronic Deposit Insurance Estimator (EDIE) asks for very sensitive data on an un-encrypted page. This is inexcusable. The form asks the user to enter a “EIN# (Tax ID)” which is either a social security number or the business tax ID (just as sensitive as a SSN from a business perspective).

I am blown away at this remarkable oversight. It means any visitor that submits a tax ID using that web form is sending highly confidential information, in clear text, over the Internet. If any government entity should be exhibiting security best practices it is the FDIC. Data stolen this way is virtually undetectable. There’s no feasible method to determine if a hacker copied that data somewhere between your PC and the FDIC web site.

Does anyone care about this?

fdic screenshot

Update: I sent an email about this to webmaster@fdic.gov and I got this reply back from the Chief Web Officer of the FDIC:

Neither version of EDIE collects SSNs or Account numbers. The section that calculates the coverage of business accounts does have an input field for Employee Identification Numbers (EIN), but there is no validation, so a user with security concerns can substitute either a ‘dummy number’ (so long as they consistently use the same number) or a nickname for their business. We need the EIN field since that is the most reliable method of calculating corporation, partnership, and unincorporated association account coverage.

As you may know, EDIE does not retain any data after a user exits the system. The data is stored only as long as the user is entering data and generating a report. Once the user either exits the system or starts to calculate coverage for another set of accounts, the data is lost.

We are enhancing the application and we are looking at adding text to the help screens in order to clarify this issue. Thank you for your feedback. If you have any further questions, feel free to contact me at the number below.

And this is my response:

Thanks for the reply. I am still confused on a few points. If users can substitute dummy numbers, why even ask for an EIN in the first place? And if dummy numbers are OK, why, in a subsequent sentence, do you say “we need the EIN field...” I’m sure I am missing something obvious, so I apologize.

As far as EDIE retaining data, it’s good to know that it isn’t stored on your servers after exit. However, the user does transmit the EIN data over the Internet in clear text, if they choose to enter it. And without clear warnings, I suspect most users either wouldn’t know better or would assume it’s secure since it’s a FDIC site.

Based on my understanding of applicable law, accepting EIN data in clear text via a browser means that web page may not comply with The E-Government Act of 2002 (Public Law 107-347), which mandates that government agencies follow the guidelines developed by the National Institute of Standards and Technology (NIST) as outlined in Special Publication 800-53. In other words, use encryption to protect sensitive data submitted on public web servers.

The rules and laws are Byzantine in nature, so let me know if my information is not correct. If it is correct, please follow up to let me know your agencies plans for complying with the requirements.



Filed under: Data Breach, Privacy

Comments

TBanker on Apr 10, 2007

I thought you might also be interested in knowing that the FDIC had a security breach that comprimised personal information on former employees.

Post a Comment