Verizon to share your information – Unless…

From Gizmodo:

Verizon is currently sending out notification letters chock full of legalese to its customers. Here’s a summary: You have 45 days to opt out or you “agree” that Verizon can share your personal data.

Nice.

I was going to go for full frontal snark, but don’t feel the need after reading the comments on Gizmodo and Slashdot. Lets just say that they weren’t exactly positive.

I killed my Verizon account years ago. Any bets on whether my data gets included? (Or did they sell it years ago…)

Password Security – Protecting your user base

You know how to protect your own password; how do you protect your user’s passwords?

It is well understood that you should use a different password for each secure site you visit. Given the routine use of email addresses as logins, using a single “universal password” turns a successful attack on one of your accounts into access to all of them.

Not good.

On the other side, if you run a secure site, you need to protect your users, in case they don’t know this, and are not as careful as they should be. (And many of them won’t be…)

This was brought home a few years ago, when I had a project that required me to hack the passwords to my client’s web site. We were moving their site to a platform with incompatible password support, and their user’s passwords were (properly) encrypted, so we couldn’t move the password file directly.

There were many ways to approach this problem, but we wanted to make it as invisible as possible. So, as part of this effort, I put together a quick crack program to see how many of the passwords we could discover ourselves.

We ran the program for a couple of weeks and cracked around 25% of the passwords through a combination of dictionary and brute force attacks. What’s worse, most of these passwords broke the first day.

Why were these passwords so easy to break?

Two reasons:

• Bad passwords, and
• Easy to crack password protection.

The bad passwords were: words from the dictionary, common passwords (”asdf”, “abc123″), easily broken through brute force (”a”, “aa”), or default passwords that were never changed.

The weakness of the password protection wasn’t as obvious, as they’d used the conventional approach of storing a secure hash of the password. Checking passwords was accomplished by hashing the password and comparing the hash value with the stored hash. If they match, you can assume the password was correct.

The problem with this, however, is that the hash value is the same for every account using that password. To understand why this is a problem, let’s look at the design of the crack program I wrote.

The attack worked by constructing a hash table of every unique password hash. It then hashed trial passwords and did a single hash table look up to see if that password matched one used by any of the users. This approach wouldn’t have worked, however, had an effort been made to ensure that the hashed password values would always be unique.

An easy way to create unique hash values would be to calculate the hash of a combination of the user name and password. Now, the crack program wouldn’t be able to do a single test for the hashed value of password “abc123″, it would have to calculate a separate hash value for each user name.

In our case, with over 30,000 users, the crack program would have taken 30,000 times longer to run! We still would have been able to do the dictionary part of the attack, which ran in about a minute, but the brute-force part would have been out of the question. Even still, the dictionary attack would have taken several weeks to complete.

How do you protect your user base?

• Require reasonable passwords,
• Ensure that password hashes are unique, and
• Make your users change default passwords.

(And don’t count on being able to crack your password file…)