Let’s Talk about Security

This morning, Burlington Electric Department announced that they’ve disabled their online bill pay system, citing security flaws in how they store customer passwords.  They will be working to update their systems to meet modern security standards, and to put outside auditing procedures in place, before reinstating the system.

The unexpected cost of this sort of rewrite and audit is extremely taxing to even the largest businesses, and can be fatal to small businesses.  Some businesses might even face hefty fines from credit card processors, if flaws like this are discovered.  Furthermore, since over 55% of users reuse the same username and password on all their accounts, any potential leak could lead to major monetary losses for your users.  Finally, there is a potentially greater loss due to customer loss of faith that comes as a result of the discovery of such flaws.

For these reasons, it’s crucial that strong, easily upgraded security systems by put in place from day one, to prevent unexpected costs in the future.

Here at Burlington Bytes, security is an everyday concern, but to most people it’s a bit of a mystery. We decided it was a good time to clear the air, and give you all a primer on basic password security from the developer’s side.

Wait, I Just Check a Password, Right?

In the earliest days of internet security, the process basically involved three steps: You’d store a password for each user in your database, and check it when they tried to log in.  If successful, you’d put a cookie on their system that stored the password, to authenticate on other pages automatically.  This is, in essence, what Burlington Electric’s system did.

It seems secure on the surface, but storing passwords to check means that there is a list of user passwords somewhere, that someone has access to.  That someone could be your Database Administrator or it could be a hacker who has gained system or database access.  In either case, if that list gets out, you have a serious problem on your hands.

Also, storing user passwords in a cookie leaves the users account open to attack from viruses on their own systems.

So.. Can’t I Just Encrypt my Database?

As it became clear that this method was insecure, some businesses began encrypting passwords in their database, and unencrypting them to check.  Unfortunately, this is only a stopgap solution, as someone (or some system) still has access to the encryption key, and either obtaining the key or brute forcing the system would still provide the same list of usernames and passwords as the original process of just storing passwords.

Ok, then what about these Hash things?

Hashes are at the core of how modern website security works.  A hash is a number produced by a Hash Algorithm.  Hash Algorithms are amazingly complex and hard to explain, but the basic result is this:

Any data (e.g. password) fed to a hash algorithm will produce a statistically unique hash value.
However, the original data cannot be calculated from the hash.

Put simply, hashing is a one-way process.

Once plain-text passwords and encrypted passwords were shown to be unacceptably weak, hashing passwords came into prominence, with one of the most common algorithms being the MD5 Hash.  Websites would store the MD5 of a password in the database, and just take the MD5 of any password entered by the user, and compare them.  This seemed fairly secure, but had two major flaws.

The first flaw was that MD5 hashes (along with several other popular hash algorithms, like SHA-1) were proven to be vulnerable to attack.  Once an attacker knew the MD5, they could reverse it in minutes, providing a password that would work on the system (even if it wasn’t the same password the user originally created).

To combat this weakness, security experts began using more secure hash algorithms like SHA-256.  However, as computing power continues to grow, and more discoveries are made in computer security, more hashing functions are certain to become insecure.  That is one of the core principles for good security: all security must be regularly assessed and upgraded.

The second flaw was that some passwords are fairly common (given a large enough pool of users), and if two users had the same password (hunter2, for example), the hashes stored in the database will be identical.  So, if you can gain access to the database of hashes, you can access multiple accounts by reversing one hash.  With common hash functions like MD5, attackers create and share massive databases of common passwords and their hashes, called rainbow tables.  These tables can make reversing common hashed passwords instantaneous.

Ok, SALTING?  Now you’re just making up words.

To address the issue of these rainbow tables, a new process was created, called Salting the Hash.  It’s actually pretty simple.  When a user chooses a password, like Hunter2, the system creates a unique long random number, called a Salt.  This salt is stored with the username in the database.  Before hashing the password, the system adds the salt to the end, ensuring that no two identical pieces of data are entered into the hashing function.  This means that User A and User B might both have the password Hunter2, but User A’s salted password is Hunter28543098639, and User B’s salted password is Hunter25374628950.  as a result, User A’s salted hash is a5d98b44e49f0937581bb38b76598fdf9663f1fef6d1bf6bbe003c60d57b3994, and User B’s salted hash is 2d168ab0e6c931b113e181fa44a9b96e1569f92fae81ebb4a356c81c9103ea7c.  Neither of these is likely to appear in a precomputed table of hashes, and reversing one hash will not help an attacker reverse the other.

I know OAUTH isnt a real word.  I took English in School…

If you’ve ever seen websites offering “Connect with Facebook” or “Login with Google”, you’ve come across a new option for login security, called OAUTH.  OAUTH uses a known good service, such as Facebook or Google, to handle all the password and identity verification for you.

For low-risk websites like forums or sites that allow commenting, it can be a fast way to skip a lot of the problems intrinsic with security, but it comes at a cost.  In an OAUTH system, your service is only as secure as your user’s facebook or Gmail password, and those services often are subject to a much greater number of attackers than most businesses.

Instead of relegating all login tasks to a third party, many new sites are now simply using a third party to verify logins, with two factor authentication.

Ok then, Smart Guy, What the Heck is Two Factor Authentication?

Despite proper salting and hashing, ensuring strong passwords, and even changing them regularly, it is still very possible for an attacker to gain access to your user’s password.  After all, it’s only a set of numbers, letters, and symbols.  It might be used on an insecure site, or written down somewhere, or sniffed from an insecure wifi connection, or gained via a keylogger or virus on your computer, or one of a million other ways, but unfortunately, it is possible to for an attacker to gain access to your user’s password.  Two Factor Authentication is an optional method of improving login security by using a third-party trusted service and a trusted device, like your user’s smartphone.

With a two-factor system like Authy in place, when an enabled user enters their username and password, they get a notification on their phone, asking if they want to log in, and providing them with a one-time, time-limited token that they enter on their computer (or a prompt to just allow the connection).  Most people are familiar with a simplified form of two-factor used in “forgot my password” forms, where they email a one-time link to you.  This is simply an evolution of that process to leverage a device that is in your users’ pockets all day, and is a little harder to gain access to.

Unfortunately, as not all users have smart phones, Two Factor is not yet a universal security requirement, but rather an option to improve security for tech-savvy users.

Ok, I’m confused and annoyed, but I think I get it.  Is that everything?

Unfortunately, safely checking a user’s credentials is only the very tip of the iceberg when it comes to building a secure system.  Developers need to deal with Cookie-hijacking, Session Persistence, Token invalidation, SSL Forgery, MITM attacks, Cross-site scripting attacks, Brute Force attacks, PCI Compliance, Social Engineering, SQL-Injection, Remote Execution, File Inclusion Vulnerabilities, (D)DOS attacks, and thousands of other issues in the ever-changing landscape of Information Security.

As a small business, attempting to create a secure system on your own is a risk you don’t want to carry.  That’s why we keep security in the forefront of our work here at Burlington Bytes.  Contact us, if you’d like to put our expertise to work, protecting your customers.