What’s in a Password?

Nearly every week now we can read about a data breach case somewhere, where millions of user accounts and potential other sensitive data has been compromised. Most people are not even shocked by such news anymore, as it is starting to become humdrum.

One of the most common attacks used in such breaches is an SQL injection. This attack has ranked first place on OWASPs Top 10 faults in Web applications for many years. There are several well-known methods to prevent SQL injections, but unfortunately it is still often encountered in productive sites. Furthermore, mis-configured Web servers and vulnerabilities in remote management tools can allow attackers to gain access to systems and read potentially sensitive files.

There has long been a heated discussion about how best to store passwords and that discussion is still ongoing. Most people agree that storing passwords in clear text in a database is not a good idea. Although sadly it is still done in a lot of places, usually with the excuse of “no one has read access to the database, so what could possibly go wrong?” As history has repeatedly shown, this argument does not hold true for long.

As a user, you normally do not know how your passwords are stored on a service. One enlightening trick can be to use the password reset function. Some services will send you an email with your password in clear text, which obviously means that they store it in clear text to begin with. If in doubt, you can send the service an enquiry, but most will probably just assure you that they are using state of the art cryptography to protect your password, which does not tell you much.

But the keyword is correct, as most systems have started to use cryptographical one-way functions; so-called hash functions like MD5 or SHA1 are being used to store passwords. Note that these are not password functions, but rather functions that are normally used for creating message digests. By using them on the password and only storing the hash value, the problem of clear text passwords disappears. Unfortunately, attackers can create “rainbow tables”, with pre-computed pairs of passwords and corresponding hash values. With today’s cloud services, generating rainbow tables does not take too long and the combination values can easily be stored.  Such a set up would allow a simple lookup to break all common passwords within seconds.

To make it more difficult for rainbow tables to break passwords, services can use salt. A salt is a long random string, which is combined with the password before hashing. When used per user, this adds extra complexity as it means that even if two people have the same password (e.g. 123456) they would end up with a different hash in the table. More importantly, the attacker now needs a rainbow table for every possible salt, thereby making it a lot more cumbersome to crack the passwords of many users at once. However, brute-forcing the password of one specific user (e.g. an administrator) is still possible.

At this point, iteration or key-stretching can be introduced. By iterating hash functions over and over again, the whole process is slowed down. For normal usage during logon, a small delay does not matter much, but for brute-force attacks, this can add a few thousand years to your key breaking time. Some examples that can easily be integrated are bcrypt and PBKDF2. Of course, the bar can be raised even higher when using two-factor authentication, for example Symantec’s VIP service.

Regardless of the function that is used to store the passwords, it is always a good idea for users to utilize different passwords for different services. As if you use the same password on all services, once one of them has been broken (possibly due to a bad password storing process), then all of the others become known to the attacker as well. Whenever a data breach occurs, attackers typically try the email password combinations on other services—just to see if they’ve gotten lucky.

Needless to say that using a strong password in the first place is a must. “123456” is simply not a strong password and should not be used. If you cannot remember all of your different passwords, you can use a password manager. Your passwords can then be stored on your smartphone so that you have them with you all of the time. Of course, you have to ensure that when the smartphone is lost, no one can access your password manager, but that’s a whole other story.

Good Morning, Captain: open IP ports let anyone track ships on Internet

While digging through the data unearthed in an unprecedented census of nearly the entire Internet, Researchers at Rapid7 Labs have discovered a lot of things they didn't expect to find openly responding to port scans. One of the biggest surprises they discovered was the availability of data that allowed them to track the movements of more than 34,000 ships at sea. The data can pinpoint ships down to their precise geographic location through Automated Identification System receivers connected to the Internet.

The AIS receivers, many of them connected directly to the Internet via serial port servers, are carried aboard ships, buoys, and other navigation markers. The devices are installed at Coast Guard and other maritime facilities ashore to prevent collisions at sea within coastal waters and to let agencies to track the comings and goings of international shipping. Rapid7 security researcher Claudio Guarnieri wrote in a blog post on Rapid7's Security Street community site that he, Rapid7 Chief Research Officer H.D. Moore, and fellow researcher Mark Schloesser discovered about 160 AIS receivers still active and responding over the Internet. In 12 hours, the trio was able to log more than two gigabytes of data on ships' positions—including military and law enforcement vessels.

For many of the ships, the vessel's name was included in the broadcast data pulled from the receivers. For others, the identification numbers broadcast by their beacons are easily found on the Internet. By sifting through the data, the researchers were able to plot the location of individual ships. "Considering that a lot of military, law enforcement, cargoes, and passenger ships do broadcast their positions, we feel that this is a security risk," Guarnieri wrote.

Read 4 remaining paragraphs | Comments

Admin beware: Attack hitting Apache websites is invisible to the naked eye

Ongoing exploits infecting tens of thousands of reputable sites running the Apache Web server have only grown more powerful and stealthy since Ars first reported on them four weeks ago. Researchers have now documented highly sophisticated features that make these exploits invisible without the use of special forensic detection methods.

Linux/Cdorked.A, as the backdoor has been dubbed, turns Apache-run websites into platforms that surreptitiously expose visitors to powerful malware attacks. According to a blog post published Friday by researchers from antivirus provider Eset, virtually all traces of the backdoor are stored in the shared memory of an infected server, making it extremely hard for administrators to know their machine has been hacked. This gives attackers a new and stealthy launchpad for client-side attacks included in Blackhole, a popular toolkit in the underground that exploits security bugs in Oracle's Java, Adobe's Flash and Reader, and dozens of other programs used by end users. There may be no way for typical server admins to know they're infected.

"Unless a person really has some deep-dive knowledge on the incident response team, the first thing they're going to do is kill the evidence," Cameron Camp, a security researcher at Eset North America, told Ars. "If you run a large hosting company you're not going to send a guy in who's going to do memory dumps, you're going to go on there with your standard tool sets and destroy the evidence."

Read 7 remaining paragraphs | Comments