Many of the most notable data breaches have involved the compromise of user passwords

on various web services. The severity of the breach really depends upon the state of the passwords at the time of the breach and/or the method by which they are stored.

Methods of Password Storage

Ideally, passwords should be stored in an encrypted form, called “hashes” and additionally salted. Salting adds a random element to the password hashes that make it very difficult for an attacker to brute force hashes he may have obtained during the breach. This is not to say that it is impossible for an attacker to crack the password hash, only much more difficult.

Unsalted password hashes, while encrypted,  are vulnerable to simple brute force attacks. Many tools exist that can make this process very simple for an attacker. If the password is a simple dictionary word, or less than ten or so characters and having low complexity, the hash can be cracked in seconds. Thanks to newer processing techniques that can utilize GPU (graphical processing unit) power, even 12 character passwords can be brute-forced in a reasonable amount of time.

Some on line services and companies have even been found to use techniques which they call “encryption” but are more “obfuscation.” If a service claims to use something like BASE64 to encode passwords, this is not encryption at all, and an attacker need only to convert the text back to normal text to read the password.

In past breaches, some companies and services have been found to store passwords in clear text. In December 2009, Rockyou.com was breached, exposing the customer data of some 30 million customers. All of the data, including passwords, was found to be stored in clear text. Password complexity and length were of no benefit to the security of rockyou.com users. To this day, the Rockyou.com password list (which was widely circulated after the breach) is a standard file used when attacking anything utilizing passwords due to its size. It is representative of popular passwords still used by many people today.

If the company or service you use stores its passwords in clear text, there is little to protect you.  Depending on the type of service being provided, such as with an on-line bank, it would be worth your while to read about their security practices and even contact them before signing up.

Password Resets

Company employees should never be able to access the clear text of your password. If they can retrieve it for you, this points to a glaring hole within their security. The most they should be able to do is provide a link by which you can reset the password. If you forget your password and request a new one, and you are sent an email with your old password it clear text, this typically means that they either do not encrypt their data or they are using an easily reversible process. If they can reverse it,  an attacker may be able to do so as well. Also, think about the fact that your password was just emailed to you in clear text. Can you be certain that your emails cannot be intercepted and read by others? If you are in a coffee shop or airport terminal using a public wireless network, the answer to this question is a clearly “no.”

Password Creation

While you cannot create a password long enough protect you against companies storing it or being able to retrieve it in clear text, you can create one that makes it extremely difficult for an attacker to brute force if encrypted. We assume that most on-line services are providing some basic level of encryption, but are they salting the hashes? It is best to not leave our security in their hands.

When creating a password, think pass “phrase” rather than pass “word.” Choose a phrase that you can remember but has complexity. Phrases like “AllMyShoesAreBlue” are decent. Even better adding numbers or characters such as “AllMySh03sAr3Blu3″. This increases the size of the character set and makes brute forcing take much longer. Avoid common phrases such as cliche`s, movie titles, or famous quotes.

The reason I stress “phrase” rather than “word” is because you need good password length. Given the methods and computing power attackers have at their disposal today, I personally would never choose a passphrase with less than a minimum of 15-20 characters if allowed by the application.

Password Diversity

Suppose you are using an on line service and you choose a really good pass phrase such as IH@ve@nt$1nMyP@nt$ (I have ants in my pants).  Unknown to you, this service stores its passwords in clear text and eventually, this company is the victim of a data breach. The length and complexity of the password does not help you. It is out there for all to see. Many of the passwords in the rockyou.com  password list are very long and complex, but they were stored in clear text.

This situation may not be so bad. It is only one company that was compromised. However, if you use the same password for everything, the attacker may be able to use other exposed data, such as your email address, to compromise other services and companies that you use.  In other words, an attack on your World of Warcraft account could lead to an attack on your online bank account.

Because of this risk, it is highly advisable to practice password diversity. Different passwords should be used, especially for services involving finances or personal information. One breach should not provide attackers the proverbial “keys to your kingdom.”

The complaint oft expressed by people when discouraged from password reuse is “how in the world do I remember all these different passwords? And now you want them to be more complex phrases?” It is an understandable gripe. Fortunately tools exist to help keep you passwords organized, protected, and readily available, such as Password Safe and KeePass.

With KeePass, you can organize passwords into different groups and categories, and will also generate passwords for you. The database file is, itself, encrypted and protected with a password. Whatever you do, don’t forget your KeePass password.

Other tools and methods exist for the purpose of storing, organizing and securing passwords. Whatever you use, make certain it is from a reputable source. You do not want to hand your entire password collection over to an attacker.

Summary

We can seldom be completely certain what on-line companies and services do to protect our passwords if they do not explicitly provide the information on their website. In all honesty, that representative you speak with on the phone may have no idea either. Play it safe and take control of your own security. Use long pass phrases, try to make your passwords diverse, and store them in a reputable tool like KeePass if needed.

Today DHS issued a warning to all users of the Niagra Framework that vulnerabilities existed which could give attackers control of the system and all of the devices managed therein.

The attack is based on directory traversal–the ability of an attacker to navigate beyond the prescribed file areas of a system into more sensitive system areas. In this case, attackers could access the file containing usernames and passwords.

In response, “Cybersecurity Officials” (whatever that means) suggested the following:

• “Disable the ‘guest’ and ‘demo’ user accounts if enabled,” says the alert, issued by the department’s Industrial Control Systems Cyber Emergency Response Team. The alert advised other steps:
•  Lock out accounts that receive excessive invalid login attempts.
•  Use stronger passwords.
•  Change default user names and passwords.
•  Limit user access to the file systems

Many of these steps may or may not make sense if, in fact, the attackers have access to the password files. What is unknown (at least to me at this point) is in what form these passwords are stored. Cleartext? Hashed? Salted?

The painful part of this story is the fact that it took so long to publicly admit the vulnerability.One of the hackers who discovered it, Billy Rios, made the following statement:

“We are disappointed that it took so long for the public to become aware of this issue,” Rios said. “According to the Washington Post article, Tridium became aware of this vulnerability ‘almost a year ago, when a Niagara customer that uses the software to manage Pentagon facilities turned up issues in an audit.’ ”

A year? And this software managed facilities at the Pentagon?

In apublic statement, Tridium’s parent company, Honeywell, issued the following statement:

“Tridium understands the importance of security and is committed to helping our customers make any necessary adjustments to their Niagara AX Framework software to ensure the highest security. We’ve released a security alert guiding our customers how to verify that their system is properly configured to protect against directory traversal. In addition, we will soon be providing a software update that hardens those settings against inadvertent user changes.”

It is clear that the only reason an alert was issued at this point was the public disclosure of the vulnerability. Had hackers not detected this, it is likely that those vulnerable would still be in the dark. And isn’t it amazing that, a vulnerability that existed for a year, once disclosed, can only at this point have a timely update issued. Why wasn’t this update issued when it was first discovered?

In nature, we find special relationships between organisms where one organism acts as a host for another. In other words, the hosting organism is part of the hosted organisms life cycle. These kinds of relationships are called “symbiotic.” Three common types exist:

1. Parasitic- In a parasitic relationship, the hosted organism gets benefits from the hosting organism. This may be in the form of nutrition, shelter, protection, etc. The distinguishing feature of this relationship is that the hosting organism is harmed–albeit perhaps in a small way– by the hosted organism. Some examples are fleas, tapeworms, and bot-fly larvae.

2. Commensalistic – A commensalistic symbiotic relationship is similar to a parasitic relationship except that, while the hosted organism gains benefit from the hosting organism, it does no harm to that hosting organism. Birds nest in trees, remoras eat the food scattered about when the shark eats, and neither does any perceivable harm to its host.

3. Mutualistic – A mutaulistic symbiotic relationship is, as you may have guessed, is a relationship where both organisms benefit. A bird that feeds on parasites in a crocodiles teeth and the clown fish that both protects and is protected by the anemone are good examples.

Much like in nature, computer malware (viruses, trojans, worms, etc) has a life cycle that relies on a hosted system to thrive. Malware, by nature, is parasitic. Even if it’s not actively doing damage by destroying files or rendering systems unbootable, it’s still sapping system resources. Because it does harm, there are two consequences. First, harm being done is usually in some way detectable. Second, because it does harm, system owners typically want it removed.

However, malware has by and large shifted over the years in both its design and purpose. Viruses were at one time more flamboyant and overtly harmful. Windows would pop up on the screen to inform you that your system had just been “pwned.” Often these windows would bear some moniker or handle of the perpetrator. Some viruses would destroy or encrypt files, and boot sector viruses would render systems unable to even load the operating system. These viruses were written usually by individuals or small groups for the purpose of notoriety. “Bragging rights” was usually the goal. Because of the attention such viruses drew, attempts were quickly made to remove them. While many viruses made international news, they typically did not survive for a very long time. Overtly harmful malware has a short, albeit flamboyant, lifespan.

Today, the primary focus of malware producers is financial or political gain. Their focus is persistent presence on systems, using them in collective networks known as “botnets” to send spam or perform attacks. The goal is to remain on your system for as long as possible. Anything that would draw attention to the malware, like pop-up windows or system file damage, would be counter-productive. The malware is written to sit in the background performing its task while the user works on that spreadsheet or plays that game. The user should have no knowledge of the malware’s presence. This is what producers of malware desire, which brings us to the point of this article.

As I wrote earlier, malware is parasitic and does harm. Harm raises alarms and is usually detectable. In the shift in focus, modern malware is less parasitic and more commensalistic. Like the remora eating the scraps around the sharks mouth, the malware seeks to reap the benefits of the system. Should the remora do harm to the shark, it might get eaten itself, thus ending the relationship.

Malware writers would rather the malware’s relationship with the system to be purely commensalistic. If no harm at all is done to the system, the malware could sit on the system like the bird in the tree, undetected and unhindered.

However, here is one place where the parallels between symbiotic relationships in nature and in computer systems break down. In nature, commensalism exists where the hosted organism does no harm, at least measurably, to the hosting organism. Even if malware does not destroy files or produce pop-up windows, it still uses (or steals, rather) system and network resources. And even if it could by some technical miracle reduce the amount of resources being used to practically nothing, there is still the issue of permission.

We differ from trees as organisms in this illustration in that birds do not require nesting permission from trees. Though the birds do no harm, if we were the trees we may be shouting “hey, who gave you permission to nest in my branches? Get out!” We demand our sovereign system rights, and an application had better not install unless we allow it. The Sony root kit fiasco of several years ago is a good indication of the dander to be raised when software is installed on people’s systems without there permission.

Also, we forget the concept of ownership when we deal with the natural aspects of symbiotic relationships. While a tree might not “mind” the bird in the branches, the owner of the property where the tree is planted might not like the birds on the trees. Trespassing, regardless of whether the trespasser does any harm to the property, is still regarded “harm” in the minds of many, therefore the relationship between system and malware could never be considered commensalistic without permission being granted by the owner, and unless the malware provided some measurable benefit, this permission would normally never be granted. If these measurable benefit did exist and the harm was negated, the relationship would be mutualistic rather than commensalistic.

This permission would also need to be freely given, not based on extortion-like threats. If malware provided benefit but threatened to destroy system files if attempts were made to remove it, this would still be considered by most to be harm. Recently, I read the book “Daemon” where a complex form of intelligent malware began taking over everything. When the daemon took over a company, it promised absolute prosperity as long as it was allowed to exist and perform unhindered. Resistance, however, was met by not only financial harm but physical as well. Although companies thrived financially under the daemon’s control and both received great benefits, the relationship was built on extortion and could not be considered mutualistic.

Also, there could be no deception in a mutualistic relationship, for deception, by nature, is harmful. The malware could not prevent itself as something else. This would be no different than a trojan application. The malware would have to present itself honestly to the user. It would not need to disclose all that it does, however, just get permission from the user to do whatever it wants. In any case, the malware (if it could still be called that) would need to deliver on its promises. If it either harmed the system or failed to provide the promised benefits, it should be removable by the user. An invited guest that refuses to leave is no longer a guest but an intruder.

Even if all of these criteria were met, we should still reject such software. Though benefits may be realized and harm to our systems may be a thing of the past, surely this software is harming others. An ethical red flag should shoot up when we realize we are actually giving, in a digital sense, aid and comfort to the enemy. We should find the idea repulsive that our systems are being used to send out Viagra emails or being used to DDOS a newspaper website. People, however, are basically self-centered. Should malware achieve this level of mutualism, many will buy into it.

It’s probably pure fantasy to believe malware could ever have a mutualistic relationship with the system, and the efforts of malware writers to reach that commensalistic level are probably asymptotic at best. As malware approaches that line and fades more into the white noise of normal system services and activities, however, detection will become increasingly problematic.

Based on what I’ve presented, could it really be said that even our symbiotic relationships with legitimate software is truly mutualistic? Are companies truly up front with us about what their software actually does on our systems and networks? Does that document reader software company tell you up front of the resource hit you will experience when you use it or the network traffic generated when it attempts to update itself? What about vulnerabilities known but are as yet undisclosed by that company?

Should truly mutualistic malware arise, we should avoid it and do all we can to combat it. However, I doubt it will be that much less worthy of our trust than much the licensed software we install on our systems on a daily basis.