A topic that comes up quite often when discussing cyber security is the use of passwords and what is the right size and complexity and how often should you change them. The confusion around password usage often derives from a lack of understanding about what they are used for and the risks associated with improper use.
Knock three times and tell them “Charlie sent me”
Something such as a password would seem to be a pretty simple and obvious thing right? You pick a simple word you can remember, such as your wife’s name, you make a note of it on a “sticky,” which you attach to your PC just in case you forget, and you are good to go. I’m trying to be funny but the sad fact is that I see things like that all the time. Usually because the person has no idea about how passwords are compromised and what makes that process far less difficult for the bad guys.
To begin with, a password serves two purposes: First, it acts as a proof of identity to the computer onto which you are trying to login; second it acts as a barrier to prevent others from being able to login on that same computer pretending to be you. With most computers that support multi-user operations, each user is given a unique ID that is going to be associated with the access rights granted to that user and the files and software created and used by that user. But in most such cases user IDs are created using a simplistic scheme such as your first name, last name and, (if there are more than one of you), a number. So I might have an ID such as “tim.shaw2”. It isn’t very difficult to guess that another user named Jim Phelps probably has a user ID in the form: jim.phelps# where the trailing number is something between 1 and 9. It won’t take many attempts to figure that out. So user IDs are not a very effective way of uniquely identifying a user. This is why unique passwords were added. For some applications, there is a desire to have even better proof that a person is actually the valid user they are claiming to be, and in those application technologies such as biometrics are used to give even stronger proof that a person is the actual user they claim to be. But for most of us a password is the way we prove our identity to the computer-based systems and devices we use.
We mentioned the purposes of having passwords above, but we have not actually defined what a password really is: a shared secret – only you and the computer know what your password is … as long as you don’t write it down and stick it to your PC or office wall. Of course for your computer to be able to compare what you type-in to the password you both agreed to use when you initially specified the password it has to maintain a copy. But unlike writing it on a sticky note in most computers the password is scrambled using something called a hashing algorithm and only the scrambled version remains in the computer.
This is because in older operating systems the passwords themselves were maintained in a file and in memory and this made them too easy to steal. If you could get a copy of a memory dump or a system backup you could search it for passwords. Today more secure systems store only a “hashed” copy of the password. A hashing algorithm is a ‘one-way’ encryption scheme meaning you can’t unscramble it to get the original password back. When you enter your password the computer hashes it and compares that to the stored hash value. If they match your password was correct.
So how do the bad guys steal or “break” your password if the password doesn’t actually exist in the computer? That question, and its answer, set the stage for why most passwords need to be long and complicated and changed on a regular basis. I am not going to address insecure protocols wherein your ID and password are sent across the network, making them potentially available to snag. That issue is separate from why passwords need to be complicated and change occasionally. It has to do with the need to encrypt sensitive message traffic.
Breaking/cracking a password is the process of figuring out what your password must be by taking possible passwords you may have used and hashing them and comparing the hash value to the one stored on the computer. In some cases that process can be performed on the computer itself if the necessary data and software can be loaded and executed. But realistically most of the time passwords are broken (or ‘cracked’) by getting a copy of the hash file containing all user password hashes and taking that file to another computer where the cracking tools can be used. Readily available tools such as “Jack the Ripper,” which can be downloaded from the Internet, can take a long list of possible passwords and run through them one at a time generating a hash and comparing that value to the ones in the stolen password file. The longer your password the longer this process can take. If the attacker knows anything about your password policy the process can be speeded up by not trying possible passwords that don’t meet your policy. So if passwords, for example, must be 8 characters or more, the attacker will skip any possible passwords that are shorter. (A good reason not to let everyone know your password policy.)
Most such attacks work off of word lists of commonly used passwords or words in the dictionary and so avoiding use of actual words (and your name) is a good password practice. A brute force version of this method just runs through every combination of ASCII characters, including numbers and punctuation characters, to find your password. Using a distributed network of computers even a really long and complex password can be broken in a few weeks to a few months. (Using just a single PC the process could take many, many years.) And that is why you need to change your password every so often – so the bad guys don’t get enough time to crack it before you change it and force them to start over again. There are also something called ‘rainbow tables’ available on the Internet and these tables contain pre-computed hashes for millions of possible passwords. Such tables get quite huge and unwieldy for longer-length passwords (12+ characters) but when used they provide an almost instant ability to crack passwords of a short to moderate length.
So that brings us back to the two questions about passwords: how long and complex should they be and how often should you change them? The answer to those questions depends on the possibility of your hashed password file (the so called SAM file in a Windows computer) being extracted from your computer and taken away to be cracked. There are bootable CD and USB toolsets that let you boot-up your PC into the tool set without starting Windows. Using those tools one can extract the SAM file from the hard drive. There are remote exploits that enable access to the SAM file on a running system. If your system has the vulnerabilities this requires, then a remote attacker could get your SAM file and ‘crack’ your passwords. This is why most IT departments require 10+ character, complex passwords (e.g. special characters, numbers, upper/lower case letters) and ask you to change them monthly. Of course that often leads to people writing down their passwords in non-secure places because it becomes challenging to remember them.
Now all of this is well and good if we are taking about a PC or server running Windows (or Linux or OS-X) but does it apply to all digital devices and systems? Clearly, it can’t, as you have devices such as PID controllers, protective relays, PLCs, trend recorders, annunciator panels, Ethernet switches and other digital/smart devices, which don’t support this more advanced password functionality. Many of these types of devices either support one universal (and not terribly complex) password that all your instrument techs know or possibly two such passwords: one for read-only (look-see) access and the other for making changes, which all your techs know. In these cases, the purpose for the password is only to act as a barrier to prevent unauthorized use/access. Since many people may need to know those passwords their use provides no unique user authentication. On some of these devices, the password may be limited to a numeric sequence because the thing only has a numeric keypad for user input. You may have hundreds of these sorts of devices in your plant and changing all their passwords every month would be a Herculean task. They probably came from the manufacturer with a default (“factory”) password –
why not just use those? After all, if you forget one you can look them up with a Google search (as can everybody else!)
For the vast majority of these types of devices (but not all of them) there is no way to extract the stored password, either locally or via a network communications means, unlike with a PC. This means you have to ‘brute-force’ the password to find the correct one. If I can attempt a remote login to the device, and it places no limits on the number of tries I can have, then I can write a program to send all possible passwords until I find the right one (so hopefully that communication pathway is monitored for attacks or only enabled when needed). But if the device is isolated your only option is to stand in front of the device and enter password after password on its local HMI till you find the correct one.
As that activity might look suspicious it is unlikely to go unquestioned and thus an attacker would have limited tries before being forced to move along. In such a situation it is potentially unnecessary to change the device’s password unless someone who knows it is terminated.
Rather than changing passwords in such isolated devices on a periodic basis, some plants have elected to change them only when they are used. I know of a plant where device passwords are treated like keys. If a tech needs the password for a device they are given it from a master list and after they perform the needed work, the password is changed and recorded in that same master list, which is held by someone in authority and trusted. This scheme means that if someone leaves, you have very few devices that would need a new password.
So something as seemingly simple as a best practice for passwords is actually not simple at all. And there are lots of other cyber security factors that also seem simple at first look but have a lot of intricacies that are not immediately apparent and that can make them ineffective if not addressed properly. But that will have to be the subject matter for a future column.
About the Author
(William) Tim Shaw (PhD, CISSP, C|EH, CPT) has been active in industrial automation for more than 35 years and is the author of Computer Control of BATCH Processes and CYBERSECURITY for SCADA Systems and co-author of Industrial Data Communications. Tim has contributed to several other books, and is a prolific writer of papers and articles on a range of technical topics. Tim has been directly involved in the development of several DCS and SCADA system products and regularly teaches courses for the ISA and the University of Kansas on a range of topics from cyber security to process automation and basic process instrumentation and measurement. Inquiries or comments about this column may be directed to Tim at timshaw4@verizon.net.
