Sins of the coder

Frequently I will bring up the subject of passwords and the need for better user education. But, this responsibility to practice proper password hygiene does not rest solely with the end user

Frequently I will bring up the subject of passwords and the need for better user education. But, this responsibility to practice proper password hygiene does not rest solely with the end user. I often find myself shouting at my monitor when I encounter a security failing on a website.

A perfect example was from a website that I signed up for last week (and quickly removed myself from) which sent me the following email.

Dear Dave,Thanks for ...........!We look forward to speaking with you soon.In the meantime, you may want to visit the [URL]to get a better idea for the [products] that we sell.Oh, and for your records, here are your account details:Your Username: daveYour password: [youhavegottobekiddingme]Speak with you soon!The [vendor] Team

Once I found a mop and bucket to clean up the mess from having my head explode, I sat down and tried to think of something rational to say in response. I let them know that this wasn't a good practice and explained that I would gladly sign up again once they addressed this along with other issues.

Website/application security does not have to be difficult. That being said, we find issues time and again. I have had discussions at companies over the years where it would have been far cheaper to engineer in security at the outset than try to bolt it on afterwards. I'm not sure why this is a hard message for organizations to hear.

One great resource that I think should be required reading is "The Web Application Hackers Handbook" by Dafydd Stuttard and Marcus Pinto. This is one of many excellent examples that developers can use to help improve the security of their applications by understanding the issues that affect them. 

Another problem that I have in addition to the emails that are sent with clear text passwords are the password creation limitations. One financial institution a few years ago limited users to creating a password that was a maximum of four characters long and on numbers and letters. Not overly difficult to puzzle those out in short order. After getting an earful from the security community they bumped that up to eight characters. Yay...ish?

This year I encountered another financial institution that prompted me to create a password that was six to eight characters in length and only letters and numbers. This is a multi-billion dollar company. I'm curious as to why they would limit a password in this fashion. Sure, I could put on a tinfoil hat and say it's easier to reverse it and so on. But, I'm curious as to what the rationalization would be for this sort of behaviour on the part of the developers. 

I only touched on passwords in this piece but, I could easily turn this into a series of "WHY DID YOU DO THAT?" posts. For example, a bank that has iframes on it's exit page from Internet banking. 

What could possiblie go wrong?

Oh...wait...

Enable your users with the ability to pick good passwords.

(Image used under CC from djwudi)

To comment on this article and other CSO content, visit our Facebook page or our Twitter stream.
Insider: Hacking the elections: myths and realities
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.