Better security through public shaming

Hat tip to @pmhesse

The folks behind plaintextoffenders.com are doing a great service to the Internet.

You should never be seeing your password in an email from a company. If they are sending a password there are two major issues.

    Email is not inherently secure. The traffic carrying that message can be sniffed, and then your login info is known.

    They are not hashing passwords in their database. It’s possible that they are performing some sort of encryption on the passwords, but it is clearly reversible, and therefore capable of being hacked.

The companies found on the site tend to be smaller businesses, which are a prime target for attacks.

From Wired

“Hackers are increasingly going after small businesses,” says Jeremy Grant, who runs the Department of Commerce’s National Strategy for Trusted Identities in Cyberspace.
…“They have more money than individuals and less protection than large corporations.”

So if you get an email with a password in it, go ahead and submit to plaintextoffenders.com. Hopefully the exposure will get them to fix the problem.

Advertisements

Forcing better passwords

I promised an update to address poor passwords after discussing multiple instances of “12345” being used on a Syrian email server.

Passwords are everywhere.  You need them to log into your operating system, websites, email servers, etc.

….and they are terrible from a security standpoint.  Yet there’s not really a better option for user authentication.  So how can we reduce password insecurity?

At the OS-level, password complexity rules should be enforced.  In a Windows environment, this is a single setting that ensures users choose passwords that contain a mix of capital letters, lower-case letters, digits, and special characters.  There are some other restrictions as well, preventing the user name from being part of the password and restricting password reuse.

In a Linux environment, we have PAM (Pluggable Authentication Modules), a flexible framework that allows you to control how passwords and authentication are handled.  Combined with cracklib you can validate passwords against a dictionary of common, easily cracked passwords.  So, even if something technically meets your complexity requirements (PassWord123!) you can still block it.

Windows can also get this sort of control, but it is a bit more involved.   As I mentioned above, there is just a single setting to enforce password complexity rules.  When enabled, that setting uses the default Windows password filter included in the OS.  If that doesn’t give you enough security, a custom DLL can be coded and hooked into the Registry.

Of course, having a decent password to login to your system doesn’t help you if your email password can be hacked.  On a Linux server, we go back to PAM.  Any application can be written to utilize PAM, so find an email server where you can control the password security.  If you are running the mail server on Windows, you have to hope the vendor has methods available for you.

Re-examining the dump that started all this, I have to wonder what Anonymous is actually presenting here.  Is the mySQL query the results of something run directly against the mail server, or did they get a list of hashed passwords, crack them, and load the results into their own database?

The presence of one or two decent passwords in that list lead me to think they weren’t cracked, which would mean that these were stored as plaintext in the database.

I’ll gloss over the fact that passwords should all be hashed and salted, since that’s off the topic at hand.

To enforce better passwords stored in a database, we could create a trigger to check against a dictionary before committing the row.  So, when a user sets their password, an update or insert query is generated.  Before that update is processed, a function runs to check the password and gracefully fails if the password isn’t up to snuff.

In a properly secured database this gets a bit tougher to implement, since the query should contain a hashed and salted value. Theoretically, the database trigger could take the salt value for the user (which is stored elsewhere in the database), then compare the value in the query to the dictionary by applying the salt and hashing.  However, depending on the size of the dictionary used, this could require too much computing power to be reasonably performed every time a user updates a password record.

To close, I’ll link XKCD’s take on what makes a good password.

Idiots and their luggage.

Recently, the Syrian government’s webmail server was compromised by Anonymous.  They went on to dump the users and passwords on the system.

The most common password?  12345.

This story broke last week, but countless websites are not telling it correctly.  The  error is that they claim the President’s account was hacked and his password was 12345.  I started off writing this post with that information, but I like to do a little something called “fact-checking” before I commit information to the Internet.  I linked two original sources above.  Haaretz, the Israeli publication that seems to be the original source had their information correct.

The attack took place overnight Sunday and the target was the mail server of the Syrian Ministry of Presidential Affairs. Some 78 inboxes of Assad’s aides and advisers were hacked and the password that some used was “12345”.

It seems pretty straightforward, but apparently reading comprehension isn’t an important skill to be an Internet journalist.

The other problem is that most people assume the breach was due to the weak passwords.  That is not necessarily the case.  The passwords on display are the passwords used to get into an individual user’s email box… to dump the users and passwords from the email system they would need remote access to either the server or the mySQL instance*.  Hopefully that access was not guarded by such weak passwords.  I believe it is most likely that the server (or database) was accessed through an unpatched vulnerability.  Once access was obtained, they dumped out the passwords, and then went through the webmail interface to sift through all of the email boxes.

All that said, weak passwords are a major issue.  I intend to post a follow up soon with some steps to prevent bad passwords.

 

 

*Please don’t put your databases online unless absolutely necessary.

Well that didn’t take long.

2012 got interesting pretty quickly.

Zappos’ database was breached, leading to the exposure of 24 million customer records.

The database contained userames, email addresses and “cryptographically scrambled” passwords.  The worst scenario is that the passwords were simply hashed (instead of hashed and salted).

Someone with access to those database values can run a common password list through the different hash algorithms and probably crack a large percentage of those 24 million records in minutes.

They then have an email address and password, and the first thing they do?

Try to log into that email account with that password.

This is why password reuse is very dangerous.  Especially when combined with weak passwords.

 

Then we had the SOPA/PIPA blackout, which thankfully stalled any congressional action on these poorly thought out bills.

As written, that legislation would have circumvented the rollout of DNSSEC.  The secure implementation of DNS (DNSSEC) adds signature verification to the normal DNS function of mapping a human-readable name to an IP address.  When DNSSEC is able to be widely adopted, it will substantially curtail DNS hijacking attacks. (wherein an attacker seizes a users DNS request to get the IP address for, say http://www.mybank.com, and returns an IP address where the attacker has set up a fake server to harvest credentials/install malware/etc.)

Immediately following the SOPA blackout, the FBI took down the file sharing site Megaupload.com.  I happen to believe this is merely coincidental, unlike some conspiracy-minded folks on the Internet.

Naturally, this provoked a DDOS from Anonymous, briefly taking down the webpages of the DOJ and Universal Music Group and accomplishing nothing.

 

Regarding password policy

A recent xkcd brings up an important tenet of password strength.

In general, when it comes to passwords:

length > complexity

A site that requires a minimum of 6 characters but enforces complexity is more likely to have some compromised accounts than a site that requires 12 character passwords regardless of complexity.  (One caveat:  The 12 character password CANNOT be a dictionary word.)

Now, a “problem” that arises with using a random passphrase like “correct horse battery staple” is that if it becomes a standard practice, the cracking programs will be changed to simply pass every dictionary word in combination with every other one.

But this isn’t actually a problem.  Say we take a dictionary of 5,000 common words.  The number of 4-word combinations would be 5,000^4, or 625 quadrillion.  Let’s suppose we pass this through a supercomputer capable of one million attempts per second.  It would still take about 20 years to go through every combination.  Of course it should find the correct one sometime before then, but nevertheless it’s a difficult task to pull off.