In this day and age of websites being hacked, personal information being stolen, and companies large and small being targeted by hackers around the world, you would think most developers would go through their systems to make sure they are following best practices when it comes to security.

I understand “security” is big and scary and has many layers. Let’s start with something easy: passwords.

Facepalm for bad password securityLast week, I signed up for a service. I’m not going to put them on blast, but after I signed up, I received an email with my new account information, including my password.

My heart skipped a beat.

That’s very bad.

If you get an email from a website, large or small, and it contains your password, be very wary. In the vast majority of situations, they are not storing that password in a secure way.

When I pressed them, they said it wasn’t a huge deal because they weren’t storing credit card details in there.

The reality is this: it doesn’t matter what you are or aren’t storing in your database or application. If you have weak security in one place, you have weak security everywhere. I would hazard a guess that the password strength and security for the other servers on that network aren’t great either.

So why do companies launch web applications with terrible password security? Some of it may be lack of knowledge, but that excuse is harder and harder to believe in today’s world.

For some companies, that’s the way its always been done. For others, they store passwords in plain text to make life easier for customers who have lost theirs. They think it’s easier to give them their password as opposed to reset it.

Finally, there’s cost. If have to retrofit your web application to store passwords securely, there is time and effort and resources needed to do that. Company executives may not see the return on investment, which is unfortunate.

One of the most popular posts on this blog was on I did in 2008 about passwords. Specifically, you should never store a user’s password in your database as plain text. This means not saving in  your database or text file exactly what the user typed in.

When developers store passwords this way, and an unauthorized person gains access, that attacker needs to do no work to get all user data. This comes from MediaTemple, who was hacked in 2009 and it was discovered they were storing passwords in plain text.

“Clear Text” is a method of storing passwords in a database so that they are human readable. This preference was made to provide customers a convenient way of managing access to their services, e.g. connecting a PHP app to MySQL. The “clear text” method can be less-secure than methods involving “encryption”, where passwords are not human-readable. This is less convenient for customers, but adds a layer of security. Properly secured databases can store passwords using either method, with the information kept private. However, if a database gets compromised, the encryption method is the only way to keep the information secure.

If you want to securely store your passwords, use a decent hashing algorithm, use a salt, or use a strong password library such as Bcrypt. Don’t store them as plain text. It isn’t hard, and it will help secure the information your users have trusted you with.

I think it’s fair for users to think that sites they give their personal information to will keep that information secure.

Yahoo LogoYesterday, Yahoo announced that back in 2013, approximately 1 billion accounts were hacked, and information about those accounts, including names, hashed passwords, dates of birth, and more were taken. This is on top of the 500 million accounts that they announced last September had been hacked.

First off, Yahoo was using MD5 for hashing passwords. MD5 was shown years ago to be crytographically insecure. I know engineers at Yahoo are pretty smart, but this is pretty dumb.

Second, how do you let 1.5 billion accounts get compromised? Why does Yahoo not take security seriously? In an email to affected accounts, Yahoo said this about what happened:

Law enforcement provided Yahoo in November 2016 with data files that a third party claimed was Yahoo user data. We analyzed this data with the assistance of outside forensic experts and found that it appears to be Yahoo user data. Based on further analysis of this data by the forensic experts, we believe an unauthorized third party, in August 2013, stole data associated with a broader set of user accounts, including yours. We have not been able to identify the intrusion associated with this theft. We believe this incident is likely distinct from the incident we disclosed on September 22, 2016.

Here’s what’s worrying about the announcement. They can’t seem to find out how it happened. They posted this on a Tumblr (?!) site:

We have not been able to identify the intrusion associated with this theft.

Wow. Seriously? 10,000 employees and you can’t figure out how your systems got hacked, again?

If you have been affected by this or a previous breach at Yahoo, here is my professional advice:


If you are using Yahoo for your main personal email, stop immediately. Use Gmail. Yahoo has shown it does not take security and the safety of your data seriously, so don’t use them. Even if we don’t take into account that Yahoo was scanning emails for content and giving it to US intelligence agencies, it’s not safe.

Change all your Yahoo passwords immediately. Email, Flickr, Fantasy Football, all of it. Now. Stop reading this.

I have a spare email address there I use for signing up for dubious looking sites and other mailing lists, fantasy football, and some other things and I’m changing my password there just the same.

R.I.P. our data.


I heart WordPress. I was a long-time Movable Type user and advocate. When I started this blog in early 2008, I used it as an opportunity to learn and experiment with WordPress, and I’ve become as big a WP advocate as there is.

One of things that is very critical when it comes to WordPress is making sure your install is up-to-date. Security holes are quickly patched and old installations make easy targets for hackers and script kiddies worldwide.

There’s a pretty large-scale WordPress infestation going around right now. I’ve had to help a few bloggers I know with getting their installs cleaned out and up-to-date, in one case they had never updated beyond version 2.33 (2.8.4 is the most up-to-date).

If you are running a version earlier then 2.8.4, please update as soon as possible. WordPress has recently added in an auto-update functionality, but I still prefer the thoroughness of the WordPress Automatic Upgrade plugin. If you are running anything earlier than WordPress 2.7, that plugin will make your life much easier and you will be updated in just a few minutes automatically.

However, you may not know if your site has been hacked. If you are seeing URL’s like this one, you have been:$%7Beval(base64_decode($_SERVER%5BHTTP_REFERER%5D))%7D%7D|.+)&%/.

This blog post has detailed instructions on how to clean out the hack (including getting rid of admin users the bad code creates).