For that past few years I’ve been the recipient of a monthly reminder from Emug (Edmonton Microsoft User Group). The contents of that email is where the problems lay. Every month that email comes in and it contains 3 pieces of information (plus a lot of boilerplate):

1. A link to the Emug mailing list admin site
2. My username
3. My password in clear text

It doesn’t take much thought to know that storing clear text password is a prime security issue. Sending those passwords in emails doesn’t make it any better. Emails can be intercepted. Systems can be hacked. It’s happened before. Just read about the hack of PlentyOfFish.com. Or the hack of HB Gary. Two things stand out in these attacks. First, PlentyOfFish stores its passwords in clear text which made it easy to compromise the entire user base once access was achieved. HB Gary (an IT security consulting firm no less) had many users who used the same password between different systems which made it easy to hop from system to system gaining different access.

Most web users don’t heed advice to have a different password for every user account they create. First, it seems unreasonable to try to remember them all. Second, most people believe that using their dogs name combined with their birth date is never going to be hackable. As system designers and operators (which the Emug membership is a professional community of) we should know that we can’t do much of anything to prevent users from choosing bad passwords. We can, however take the steps to ensure that those passwords are adequately protected.

So with all of that in mind I decided to call the Emug people on their password practices. I sent an email of concern to them along with a request that they take the time to do the correct professional thing with regards to their members passwords. The response I received back included…

I know what you're saying about the passwords though, the first one you get is randomly generated and if you ever did go on and change it to a common one then it is there within all the options you can also set it to the option of the password reminder. The option "Get password reminder email for this list?" is a user based control option and you can set that to your liking. It's in with all the digest options.

That’s great. So basically the Emug response was “You don’t have to see that we store your password in clear text if you just go uncheck this one box”. Jeez guys, thanks. So you’re suggesting that I should feel that my password is secure just because I’m not seeing it in an email anymore? Security through naiveté?

Most places / sites/ subscriptions now have an automated email reminder method. It does make you ponder its value but I think the focus on that this is a very low level security setting.

Okay…so because you think “most places/sites/subscription now have an automated email reminder” it’s okay for you to follow the same bad practices? Really? What happened to professionalism? Or integrity? Yah I know, that takes effort and you’re just a volunteer running a community group. Except for one little thing: the members of that community entrusted you with their passwords. There was an implied belief that you would protect those passwords in an acceptable manner. Clearly you’re not.

I also ask you to enumerate “most places / sites / subscriptions” please. I don’t get an email from Google Groups, StackOverflow, etc that contains my password in clear text. I know that those are professional companies and you’re not, but remember that professionalism has nothing to do with the size or revenue of your organization.

The piece of the email that really rubbed me the wrong way was this:

The mailman list serve server and application is maintained centrally not by us for the record. It is more of a self-service model and is intentionally designed for little to no maintenance or requirement to assist an end user.

So you don’t administer the system. That’s fine.  Yes, the current system may have been designed/implemented to require as little end user support as possible. That’s fine too. Here are my beefs. You have the choice to change what tooling you’re using. I’m pretty sure that you’re able to use Google to find replacement options. It will take some time and effort to see the change through, but don’t you think the integrity of your member’s passwords is worth it?

So to Brett, Colin, Ron and Simon: Please show a modicum of professionalism and take care of this issue. Since you chose not to continue the conversation with me via email, I’ve resorted to blogging. I’m submitting your mailing list email to www.plaintextoffenders.com. I’ll be contacting other community members in the hopes that they can get through to you. I suspect they won’t be able to, but I feel that I have a professional obligation to at least try.

In our Brownfield Application Development book, and in previous posts on this blog, Kyle and I have talked about the different personalities that you can encounter while working on a development project.  Unfortunately many of the types we listed, and that you see and remember, are negative.  Because development is such a social task (whether you like it or not) conflicts in personalities, styles and objectives are easily surfaced.  Add on a heavy dose of introversion and natural social ineptness and you have a cauldron of simmering conflict just waiting to bubble over.

During the hiring process HR and dev teams do their best to eliminate candidates that are obviously going to bring these types of issues with them.  Sometimes it works, occasionally they slip through and you have to deal with them.  Unfortunately, it’s very rare to see the same diligence applied to the transfer of people from one internal team to another.  The results can be disastrous.  About a year ago this happened to my team (I say my because I was the tech lead for the project).

We, as a cohesive and very productive team, were ticking along meeting deadlines, turning out high quality code and generally getting praise from the clients for these things.  Management decided that we had more work that we were going to take on and decided to transfer another of the already on-staff developers to our project to assist with the new work load.  Don’t start thinking the Mythical Man Month and adding resources to an already late project.  We weren’t late.  In fact we were ahead of project schedule at that time.  On top of that the work being assigned to the new team member was isolated in it’s own branch with a thought of it being included in a future release, not the one we were currently working to finish.

Knowing that this developer would be working in isolation I decided that the impact to the team was minimal and shed any worries I had at the time.  Things moved ahead for a few weeks before they came to a crashing halt.  I won’t get into details about what happened but the underlying problem was that the developer recently assigned to our team didn’t have the same beliefs or culture as the rest of the team did.  The result was a series of very animated and heated conversations that led to a requirement for serious and significant policing of the development actions of this person.  In the end the original team had to declare to management (above the project management level) that having this individual working on the project was adding significant risk to the current release and had already jeopardized the following release.  The result was that the offending developer was removed from the project and a 100% re-write of his code (four months effort) was required to bring it to the project’s quality standard.

The lesson that I wanted to convey from this incident was that you have to be diligent in the screening of any person joining your team, regardless of if they are an external or internal hire. Blindly accepting a new resource since they are already within the organization doesn’t preclude them from introducing risk and conflict to the project.  If you are a team/technical lead, architect or manager for a team, you have a responsibility to protect your team from distractions, morale killers and risks.  In this case flags should have been raised months before this individual joined the team, but trained with it.  The statement “It doesn’t matter what the client wants, I’ll give them what I think they need” was boldly stated and I failed to remember that when the speaker was pushed onto our team.  I failed my team by not filtering based on this past interaction.  Don’t let internal recruitment cause you to fail yours.