Banks & Credit Unions, Check Your Website for these Security Issues this New Year

It’s nearly 2011. At this point in the evolution of online services in the banking industry there should be no need for another blog post covering the basic fundamentals of securing online forms on retail banking websites. Or so one would hope, but that’s not the case. A random sampling of small bank and credit union websites will reveal that either bankers don’t have the knowledge or they choose to ignore it. In all likelihood, it’s a mixture of both. As you plan for 2011, save yourself some inevitable future grief and add a thorough website security review to your checklist for the new year, paying special attention to the tools on your website that collect personal information from customers.

Here are a few simple guidelines your development team should follow when creating your online applications.

Require SSL Encryption

SSL is common for loan apps, new account apps and other forms where banks ask for social security numbers, account numbers and other sensitive data, but it still surprises me at how many Contact Us forms I see that don’t require SSL. Just play it safe and make every form on your website require SSL. Even if you tell customers not to enter personal information in the form, they still will. For less than a hundred bucks you can buy an SSL certificate and protect your entire website. Why take the chance and open yourself up to the unnecessary liability? Use SSL for every form.

Never Store User Input in the Web Accessible Folder

If you’re not a programmer or system admin, you may have no clue what this means. If that’s you, don’t worry about the technical details, just know that this is common and it’s dangerous. At least once a month I run across a bank or credit union website that collects information from a web form and saves it to a text file, database or XML file in a folder beneath the root of the website. Usually the sys admin sets permissions on the folder that prevents anonymous access, but this isn’t good enough. Customer supplied data should never be stored in a file inside the root folder of the website or any subfolders beneath the root. Always store it outside of the root and preferably on a completely separate server with no web access whatsoever. Furthermore, your web app should be storing the data inside a database to provide an additional layer of security.

Always encrypt or hash personal data

You’ve followed the previous guidance and now you’re storing the data you collect from customers on a separate database server with no web access. That’s good, but you’re not done yet.

You also need to make sure that you’re encrypting that data inside the database. The Pentagon gets hacked and I’m willing to bet that you don’t spend as much money or resources on security as they do. When it comes to storing your data, assume that it will get stolen. By encrypting the data inside the database, you’ve just made a hacker’s job a lot more difficult, maybe even impossible, to get your data if you’ve used solid encryption practices. Whether you use our MemberProtect product or something else, make sure that you’re keeping this data safe even if it should fall into the bands of bad, bad people.

Regarding passwords, always store hash values rather than encrypted passwords. Hashes cannot be reversed and therefore hackers cannot decrypt them even if they were able to gain access to your database and steal your user database.

Never Send Form Data via Email

We see this scenario far too often. Smallville Credit Union sets up an online loan application. They’ve heard all about SSL, the web committee nods in agreement that SSL is good and sets their loan app to require SSL. Then they blow a gaping hole in their security plan by setting up the loan app to send the form data via email to applications@smallvillecu dot com. Worse yet, the email is sent using a public CGI form processing script on some server owned by an unknown entity in some country with a 12 syllable name.

Use email only for notification purposes, but never, ever, ever send sensitive form data through email. Never.

Use Secure Form Viewers

So if you’re not supposed to use email, how in the world do you get the form submissions? As we discussed earlier, the form data should be encrypted and stored in a separate database server without web access. To view the form submissions, you need a form viewer, typically a website that requires you to logon and then uses roles & permissions to control which forms you can view. The form viewer needs special security consideration though. It should:

  • Require SSL
  • Require a username and complex password
  • Require multiple authentication methods. At a minimum it should use challenge questions & computer registration. But a better solution is to use multi-factor authentication token, such as a keyfob or a product like Authly that uses a person’s cell phone as a keyfob.
  • Require IP address restrictions whenever possible. IP restrictions prevent users from logging onto the secure application if their IP address does not match a list of allowed IP addresses for that organization or user.
  • Use a product like MemberProtect to perform audit logging to track the ID of the user, data & time of logon, IP address, computer fingerprint and form submissions the user viewed viewed during each session
  • Perform automatic data purging to destroy form submissions after they’re no longer necessary. This period is usually 24 to 72 hours after the appropriate person has viewed the form data.

I recommend that you review your current applications to make sure they meet these minimum security requirements. If they don't, ask your web developer to upgrade them to meet at these criteria, or contact InetSolution and we'll help you.

blog comments powered by Disqus
What can we do for you?

About

A blog by InetSolution about programming, security, design and marketing for banks, credit unions and e-commerce.

Subscribe to our feed