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.

Facebook StoriesIt seems like all the major social platforms are working day and night to copy each other’s features. Lately, it seems they all have their sights set on the newly-public Snapchat, who launched their stories feature ages ago. Instagram soon followed,  and this week the mighty Facebook is launching a story feature.

Stories are not a new concept – users can now post images, videos, and more to a “story” as opposed to their news feed. These are intended to be ephemeral, lasting a few hours or a day, and then the disappear. Users can send these to all their friends, or like Snapchat and Instagram, direct them a specific user.

Facebook will allow drawing, stickers, and more to be added to photos. Facebook’s spin on the story will include a feature they are calling “masks,” which is a lift of Snapchat’s filters feature. Snapchat’s filters are fun but they have some pretty serious science behind them. Here are a few examples of masks Facebook will ship:

Facebook Masks

As you can see, they will be heavily advertiser focused. In the example above, you can see an Aliens move tie-in, Minions, and Guardians of the Galaxy. These IPs all have new movies coming out this summer. After all, Facebook is an advertising company, first and foremost.

Here’s what I thought when I saw this news this morning. If every platform and tool has an ephemeral stories feature, then none of them do. My time is limited, and now I have to think about what platform I should or need to post my stories on. None of them? All of them? Where do I reach the most amount of people?

For example, for some reason, I have a huge following on Snapchat. Literally tens of thousands. I post stories there and they do well with many views. Now, with Facebook launching stories, will that audience erode? Do I have to post the same content on Facebook where I reach less people, or do I focus my limited energies on the platforms where I already have brand value?

And that’s me as an individual. This is going to add a whole new layer of complexity for brands, institutions, and companies. They will need to decide where it makes sense for them to spend their time and resources to reach their key audiences as well. The Verge says this:

Where to post your daily story now becomes a daily concern for a certain subset of youngish, social media-savvy people. Facebook says stories belong everywhere that people are talking online, but what if the format is a fad? And what if forcing it on users across its entire family of app leads to a general fatigue with the idea? The company says each of its apps has a distinctive audience, and I believe it. But there’s also plenty of overlap. There’s a risk here that Facebook’s mania for stories will be interpreted as overkill by its users, and the feature will ultimately fade into the background. (This happened with live video!)

This stories war has the potential to also create confusion among users. If Facebook puts a large amount of attention and advertising around the Stories feature, will that slowly decrease the amount of news feed posts people and brands are doing? Will brands want to spend money to promote their posts to news feeds if the traffic isn’t there to see it?

Personally, I’m all for stories if it stops people posting freebooted videos and “inspirational” quotes on their news feeds.

I was updating the Jetpack plugin in WordPress today, and looked through the settings to find it has a “show related posts” feature. As a way to keep visitors on your site, it’s a decent way that doesn’t add much over head to the page size or load times, so I thought “sure, why not” and turned it on.

It worked fine out of the box, which is always nice. I went to a post to see the feature in action and one of the related posts was one from 2009 about cloud servers from Mosso.

The upside of having a blog going for nearly a decade is that there hundreds of posts to pick from. Nearly all the posts have been tagged and categorized. That’s good. As is the long tail of search. Many visits to this and other sites come from users doing very specific searches.

The downside is that in the world of technology, things change fast. Posts written a year ago are sometiems out of date. New versions of software are released. There are new features added to platforms. Some things go away.

Take Mosso, for example. Rackspace purchased and integrated Mosso several years ago, rendering my platform review useless and outdated.

Or all the posts I did in the late aughts about Amazon Web Services pricing. You see the pattern.

Here, then, is the question. Should a blog, especially one focused on technology, leave up old posts as a historical record? Alternatively, should blogs delete/draft posts after a certain number of years, considering the speed at which that world changes?

Perhaps a disclaimer could be added to posts over a certain age telling users of their age and possible obsolescence.

There’s value in both methods. It’s something I haven’t really thought about until today. I have drafted a few of the very early posts I wrote here due to errors, the vast majority of them are still are live.

What is your rule of thumb when it comes to leaving old blog posts online?