Monthly Archives: November 2014

Passwords And Security: Upgrading Password Encryption Algorithms

Imagine you are happily programming away one day, when your boss comes over and says “Hey, remember when we sent the results of our security audit to that big potential partner, XYZ Corp?” “Of course” you say, “If we partnered with them it would be huge. Whatever happened with that?” Well, he says, “They came back to us with some security upgrades they’d like us to implement before they can integrate with us. Apparently they don’t like something called M D 5 … do you know what that is?” You knowingly nod, “Yeah, it’s the encryption algorithm we use to store passwords in our database. It was popular in 1995 when the first code for our legacy product (the fart app) was written, but it’s now known to be pretty weak.” He responds, “Well we need to upgrade that to something more secure. Can you make that happen?” “Sure”, you say, “There are some algorithms that are stronger, like SHA-512 and BCrypt. I’ll give some thought to the actual migration strategy before choosing the new algorithm.”

The Issue

You don’t store passwords in your database in plain text so you don’t actually have access to the original password. How can you re-encrypt your passwords if you don’t have the original to re-encrypt?

Some Possible Solutions

Re-Register Everybody

You could clear all the passwords and require users to re-register.
PRO: this is easiest for the developer/code/database, and you only ever has to ever worry about a single encryption algorithm at a time
CON: this is very invasive and will probably piss off a lot of people.

Re-Encrypt All Passwords At Once

You could add more protection immediately by encrypting the already-weakly-encrypted passwords using the new algorithm, so they are doubly-encrypted.
PRO: immediately have more protection for all passwords, transparent to users
CON: every login requires more hash calculation, this strategy complicates the code, the conversion cost for 100K users with BCrypt at 500ms each is 13 hours (single threaded) which may exceed your maintenance window

Re-Encrypt Passwords Incrementally

When the user logs in, you do briefly have access to the plain text password. You could test incoming passwords with multiple algorithms one at a time, once you find a match you can overwrite old encryptions with new as necessary as users log in.
PRO: transparent to users
CON: potentially need to calculate the hash multiple times, need to support multiple algorithms in perpetuity

Store Extra Encryption Information

Finally, you could store information about the encryption algorithm on a per-password basis in its own column, and use the appropriate algorithm for login. You can migrate passwords incrementally (as described above) as users log in.
PRO: shows conversion rate, can later reset just select users, only single hash is ever required
CON: more complexity in code, requires database schema update


The solution you use might depend on your specific scenario and requirements. But that said, which approach would you use? Is there another approach not listed here that you would use?



Filed under Software Engineering

Basic Security: How to Store Passwords

Let’s talk about security and how to store passwords. This can be a fairly involved subject, but we can start at the beginning. Let’s ask the question at the highest level: how do people log in? And how can we store credentials so that our users log in securely?

The Insecure Way

Here is one workflow for the login process, let’s call it “The Completely Insecure Way”

  1. Precondition: Passwords are stored in plain text in the database
  2. The user types in a username and password to a web browser
  3. The server receives this password
  4. The server compares it directly against the password stored in the database
  5. If they are the same, the user entered the correct password and may continue

For the love of all that is good, please don’t ever do this!

Why is the insecure way insecure? Because if an attacker is able to access your database, they can see and use every password in the system. “Ok” you say “But my system is the backend for an app that makes fart sounds, it doesn’t store credit cards or anything. It’s inconvenient but not the end of the world if I lose control of those passwords.” Actually, this is extremely dangerous. Not only does the attacker have access to data on your system, it is likely that some users re-use the same passwords across multiple systems. They should not, but some do! If an attacker had access to a set of passwords linked to email addresses, they could just make the rounds on banking systems to try logging in with those same credentials. The results could be disastrous.

So, how can we safely store passwords to allow people to log in?

The More Secure Way

Here is another workflow for the login process, let’s call it “The More Secure Way”

  1. Precondition: All passwords are encrypted, and only the encrypted text is in the database
  2. The user types in a password
  3. The server receives this password and immediately encrypts it
  4. The server compares this encrypted password against the encrypted password in the database
  5. If the encrypted text matches, the original passwords must also match, so the user entered the correct password and may continue

I’m skipping a lot of details about how the actual encryption happens and various things to keep in mind, but this is just a high level overview.

This is more secure because if an attacker manages to access your database, they can NOT see and use every password in the system. They just see garbled text instead of a usable password. They could still try to brute-force hack the passwords (encrypting every possible password until they accidentally find a match) but this takes much longer and is much more difficult.


Never ever ever store passwords in plain text in your database. Always store them encrypted.

Leave a comment

Filed under Software Engineering

Sorting Through Your Sorting Options

Here’s a classic from XKCD. For some reason I just bust up laughing out loud every time I read this!

By the way, don’t forget to look at the alt text for the comic. Then realize that this. has. been. done. The stacksort is simultaneously amazing and horrifying!

1 Comment

Filed under Software Engineering

Maintaining Your Professional Network

What is Linkedin for? Finding a new job, right?

I used to think that, but I have been pondering Linkedin and decided that for the general technology worker it’s not just for finding jobs. You can use it to reconnect with former colleagues and bring them into YOUR workplace, you can use it for helping your friends and former co-workers by asking each other general or tech questions, you can reach out to acquaintances for exploring new business, side project, or startup ideas.

But no matter your use for Linkedin (indeed, for your general professional network no matter how you keep track of it), you should recognize that your professional network is made up of actual human beings who have their own personalities, wants and needs, desires and fears, agendas and goals. Actual human beings aren’t (and don’t like to be thought of as) cogs that you can use or discard at your convenience – hence the common disdain for recruiters who might treat them as such. (I do know good recruiters, honest!) So you have to maintain your relationships by spending the time, by reaching out to each person you know and relating to them as an individual, not as a cog in your professional networking machine.

So keeping in mind that we WANT to keep in touch with people on a professional level, and that we need to treat our professional peers with respect, this leads us to ask some questions: How often should you contact professional peers? How much time should you spend on these kinds of activities? I reached out to my professional network (!) to find out how people are maintaining their network these days.

Spend The Time

First and foremost: you need to spend the time. Sounds simple, but in practice of course we all have many competing interests vying for our time. So: how much time?

The higher up the corporate ladder your are, the more having a strong network is actually part of your job. Some higher level professionals spend up to 25% of their time on networking alone, and this is justifiable by the nature of their work. But even the average software engineer benefits from having a strong professional network, and should spend SOME time maintaining contact with other professionals outside of their daily workplace. Just 30 minutes every week could keep you in touch with a significant number of people, and this represents less than 1.25% of your work time. Sounds like a good use of your time if you put it that way!

Focus on Them

I’ll be frank: some software engineers (not you, of course!) don’t always have the best social skills. It might take some work meeting new people, or reaching out to people and maintain your relationships if you don’t have a pressing daily need to do so. So once you’ve found the time and are having a conversation or meeting for lunch: find commonalities, find the other person’s interests, and spend time there. Being interested in someone goes a long way to smoothing out your conversation. “Me” is usually peoples’ favorite topic 🙂 And if you find people too busy to meet for lunch or after work (especially upper level managers, directors, etc) a lot of people meet for breakfast. It’s an easy way to meet up without the overlapping meetings that so often occur over lunch and later in the day.

Yes, Recruiters Too

Recruiters are not former co-workers, they are not usually your friends. So it might sound odd to recommend spending time in keeping in touch with them. But one director I know keeps in touch with recruiters to build his reputation as a go-to guy. For linkedin, this could mean making quarterly connections with recruiters. The relationship of helping and the building of trust goes both ways: if you are happy to help them find the people they are looking for, they are happy to help you find the people you’re looking for. It’s good to be at the front of their minds when they see an engineer who’s an amazing fit for your organization, or an opportunity that’s an amazing fit for you.

But I Haven’t Talked With This Person For Five Years!

Sometimes we lose touch, it happens. If it’s been five years since you talked to someone, be up front that you’re working on networking and trying to keep in touch, and just have a conversation. Some people maybe don’t want to pick it up after that long, others might be intrigued by a blast from the past. Just don’t let it then go another five years!

Wrap It Up

This is all just my own musings about networking and linkedin and so forth, and notes from other conversations, not necessarily a final guide to all this.

What do you do to maintain your professional network? How often do you get in touch with people and how much time do you spend?

Leave a comment

Filed under Software Engineering