First Steps to Securing Your Information in the Internet Age
At the end of 2010, the Gawker Media consortium of blogs was hacked. User accounts and personal information for many (or all?) registered users were taken. This was particularly embarrassing for Gawker, which counts amongst its properties Gizmodo, the popular tech blog, the opinion on the internet was that they "should have known better."
It seemed, a few years ago, that you couldn't open the newspaper (or watch TV news, or view online news sites) without seeing some story about compromised corporate databases in the headlines. Lots of big companies — credit cards, banks, credit reporting agencies — suffered from, and succumbed to, attack.
Other than the Gawker incident, there hasn't been much talk about this in the news lately. Have the attacks stopped? Most industry experts don't think so. Nor do they believe that all IT systems have somehow become so secure they are no longer vulnerable. Instead, companies have just stopped reporting such attacks, in an effort to keep up consumer confidence. After all, would you want to deal with a bank that had just lost your account information?
Our MultiValue installations typically present much smaller targets than, say, Chase or Wells Fargo, but I'm sure that none of us would relish the thought of telling our customers, "Sorry, someone has stolen your personal information from my computer system." Yet odds are we are as vulnerable to these attacks, or more, as the Big Guys. What can be done to make our systems more secure?
Recognize You Have A Problem
Does anyone access your computer, either physically on a console, remotely via a network, or over the Web? If the answer is "yes," then your system is vulnerable. Even if you only use RS232 serial connections (remember them?) to old-fashioned terminals (remember them?), if someone has physical access to your system, they can physically extract the data. Modern PC-based systems will have USB ports, but even older dedicated MultiValue machines had floppy drives. As the number and types of connections to the outside world increase, so does your exposure; if your system is accessible from the Internet, there's the possibility that anyone in the world can reach it.
Minimize Your "Window Of Exposure"
The first step towards securing your system is to minimize the amount of confidential or compromising data that you store, if possible. Many of our applications accept confidential data, such as credit card numbers, and store them away as part of data records without thought as to whether they might be used again. This kind of data should be cleansed from the system.
Of course, there is also confidential data that cannot be removed from the database; a perfect example of this kind of data is the user password. In these instances, our goal must be to keep the data useful to our application, but useless to anyone accessing the data improperly.
Making Data Both Useful And Useless
In order to achieve this goal, our main weapon is encryption — specifically, a type of encryption called "hashing." A hash is a one-way encryption. When data is appropriately hashed, it is impossible (or very difficult, and hopefully beyond the means of the majority of hackers) to decrypt and find the "clear text" original information. This means that you cannot ever "recover" the original data, which is sometimes inconvenient; but it also means that loss of that data does not endanger the end user's account. For the remainder of this article, when discussing encryption in general, we are specifically referring to hashing of data.
While all of the MultiValue databases encrypt the password used to access the fundamental user accounts, many applications have additional passwords that application developers build into their login and authorization processes, and often these passwords are stored in clear text. Even though you may not consider any of the data in your application "confidential," the fact that many users will re-use the same password for many different activities means that you should do your utmost to keep the password secure.
A first pass may be to encrypt the password using the built-in encryption "user exit" or algorithm provided in your MultiValue database. Then, when validating the user during the logon process, rather than comparing the text they have typed in with the clear text password stored in your data files, your application must first encrypt the text that the user has typed with the same algorithm, and then compare the encrypted value with the encrypted password stored in your data files. Your application will have the same level of authorization security as before, but now the data stored in the system is useless to others.
Securing Browser Access
An additional complication arises if the application is available over the Internet via a web browser. It is possible for the data sent from the browser to the host to be intercepted and interpreted, and thus any passwords could be comprised. One solution is to use the "https" protocol, which encrypts all the data traveling between the browser and the web server, but this introduces a performance penalty, and if the only "secure" data is the password, it may be overkill.
An alternative (in those instances that don't require full "https" security) is to encrypt the password in the browser before sending it across to the web server. In this way, the "plain text" password is never transmitted, and thus cannot be intercepted; the encrypted value is stored in the database, and it is the encrypted value that is again compared before access is granted to the system.
In fact, it is possible to enhance this scheme so that it provides additional protection against anyone trying to "spoof" your system — for example, someone intercepting the encrypted password and then transmitting that to your server so that they could pretend to be an authorized user.
OpenInsight's web product, O4W, uses this enhanced method to protect the user data and prevent "spoofed" authentication. The basic+ routine that generates the login page builds a script that includes the current date and time, and encrypts those values — along with the user-entered password — before sending the information back to the server (fig. 1 and fig. 2).
Fig. 1 Generating the form
Fig. 2 Behind the scenes: Encryption "event" on button
Notice also the inclusion of a variable called "Salt". A salt is used when generating an encrypted value to make the value more unique. When storing the passwords in the database, O4W combines the clear-text value and the salt (uniquely generated for each O4W site), so that even the same password will generate different encrypted values on different systems. The salt, in combination with the date and time, are combined with the clear-text user entered password, which are then all sent back to the server in a single hash value.
The host, when receiving the encrypted values, validates that the date and time are within acceptable limits (five minutes, in our example), and then combines the date, time, and previously stored encrypted value, to make its own hash. If the hash passed in from the browser matches the hash generated from the data on the server, the user is validated and authorized to continue (fig. 3 and fig. 4)
Fig. 3 Retrieve and "sanity check" passed in values
Fig. 4 Behind the scenes: Generate hash in authorization routine
Don't Compromise The Security You've Built
O4W uses a standard encryption algorithm (sha1), though different implementations may use different algorithms. However, it is critical that the algorithm used be 'strong' — resistant to attempts to crack it. Do not attempt to create your own encryption algorithm, or hashing scheme. Unless you are a trained cryptographic analyst, it is unlikely that any "home grown" algorithm will provide strong security.
If you are planning to implement the security scheme described above, you must make sure that the encryption algorithm is available to use in the browser as well as on the MultiValue platform. The built-in encryption "user exit" or algorithm will probably not be available; instead, you may be able to implement one of the MD5-based algorithms in your MultiValue application, and include a comparable javascript function to perform the encryption in the browser (O4W uses the same javascript library from within OpenInsight as it includes in the browser, guaranteeing that the calculation will be identical).
Once the data has been encrypted on your system, as mentioned above, it is impossible to recover a "lost password." Your application should be designed to allow for an administrative override, if applicable, or the ability to generate a new random (temporary) password for the end user.
While encrypting your data might eliminate the possibility of the convenient, old-fashioned "Email your lost password?" option, it also reduces the risk that undesirable third parties can get access to your users' data — which is the biggest inconvenience of them all.
