We have a lot of great content to show you

This is definitely one of those blog posts that will serve as a reminder to me when I forget the answers in the future.

I’m using Visual Studio 2013, when I noticed a message under the Product Videos header that said, “We have a lot of great content to show you, but we need your permission to keep it updated”.

I am the kind of person who enjoys knowing what is going on and staying current and I think everyone knows that Microsoft really seems to care about developers. As such, they put out a lot of amazing content through their channels and partner channels. I wanted in on this gig. So, I did some digging and to “give permission”, I needed to go to the Tools menu and select Options.

Then, from the dialog box that popped up, I select Startup on the left and then put a checkmark in the box next to “Download content every:”. I left it at the default of 60 minutes and clicked OK.

My startup screen then immediately refreshed and now I have a list of videos that I can check out.

Podcast Episode 15 – Is College Worth It?

In this week’s episode, I tackle the tough question of whether a college degree is worth the expense. My focus is for programmers, but you can easily apply my logic to your course of study.

If you listen to the podcast, I can understand if you might think that I have a confirmation bias because I ultimately recommend the course that I’ve taken. I have honestly been aware of that and tried to take it into account as I formed my opinion to share on this podcast. I not only looked at my life, but at others who took many different paths and compared the outcomes. Over and over again, I saw a pattern emerge and that pattern is what led to what has now become episode 15 of the podcast.

As I mention on the episode, if you disagree with me, I’d love to hear your side. I hope that you also will try to look past only your own experience, but I’m interested in everyone’s opinion. You can just comment here on this blog post or make your own blog or podcast rebuttal and just let me know here or on my Twitter.

You can also subscribe to the podcast at any of these places:

Thanks to all the people who listen, and a special thanks to those who have rated me. I really appreciate it.

The episodes have been archived. Click Here to see the archive page.

Why Salt Your Hashes?

Note: Post has been updated below

Salted hashes? Have I decided to blog about breakfast?

No. By “Hash”, I mean “cryptographic hashes” and by “Salt”, I mean “additional input added to a one way hashing function”. Back in Episode 4 of my Podcast, I talked about a system that was written from the ground up to manage users, passwords, and permissions. During my little rant, I talk about storing passwords as the result of a one-way hashed value, but I didn’t really elaborate.

I realize that many of my regular readers may know this information, but I’ve been surprised at how many that I’ve found who do not. Hopefully, I can shed some light to those who don’t know and also become a viable source in search engine results for when the question is asked.

Let’s get the easy part out of the way first. We KNOW not to store plain text passwords, right? Some people know that and choose instead to store the passwords via two-way cryptography, meaning they can encrypt and then decrypt the password to compare it or email it you. That is also a terrible idea. Now, your entire system is only as secure as the security around your decryption key or decryption certificate. You’ve just made an attacker’s job very easy.

The better way to store passwords is to only store the result of a one-way hash. Then, when someone presents their password for authentication, you just hash the input and compare that to what you have stored in the database. However, even though this is good, it is still not right.

Take this for instance. Here is a sample table with hashed passwords.

Right away, you should be able to see a problem. The hashes for pete, jeff, and ron are all the same. A common attack against hashed passwords is a rainbow table. In that case, dictionary words (or common known phrases) are pre-hashed and those hashes can then be compared against a compromised database. Let’s take a look.

Now, by comparing, we can see that the password for pete is the word password. That means that the password for jeff and ron are also “password”. By only cracking one hash, we gain access to two other accounts. This is not good.

The fix is to “salt” the password before hashing it. You want that salt to be a unique value. Some people create a random value and then store the salt alongside the password in another database column. Others derive the salt from something like the row’s primary key, etc. Either way is fine (as long as your derived value won’t change).

Now, let’s examine our user table.

We notice right away that none of the user’s hashes are the same. I didn’t change the passwords, but the salt values made the passwords unique so that they all hashed differently. We can no longer tell whose passwords are identical. Also, our plain dictionary attack no longer works. Even though we’ve telegraphed to the attacker what salt to use, the attacker would have to generate rainbow tables across their entire dictionary for each individual salt.

This isn’t 100% secure (nothing is), but this is a best practice and certainly will slow the attackers down. This method of storage, combined with strong passwords should keep your data as safe as it can be.

Thoughts? Disagreements? Share them in the comments section below.

EDIT (5/16/2014): I talked on my podcast referenced above about how easy it is to get behind or to overlook things if you do your own security as yet another reason NOT to do it. I recommended just using existing products or frameworks that have already been hardened over rolling your own. As a perfect example, I talked about doing all of this, but forgot about bcrypt (and others) that are much more secure, salt the value for you, and already have libraries in all of the major languages.

Podcast Episode 14 – Mentoring

Episode 14 of the Pete on Software Podcast is out and this week, I’m sharing my thoughts on mentoring. The word mentor has been watered down to just mean people that you want to look up to and emulate. To me, a mentor relationship is a two way street and unless you are having personal interactions with your “mentor” on a regular basis, you’re doing it wrong.

To top it off, when looking to find potential mentors, we may be barking up the wrong tree in terms of finding what we really need. I don’t spend any time talking about why you need a mentor, because I felt that everyone knows why they need to have their own Yoda or Mr. Miyagi.

You can also subscribe to the podcast at any of these places:

Thanks to all the people who listen, and a special thanks to those who have rated me. I really appreciate it.

The episodes have been archived. Click Here to see the archive page.