test.com

Last week we were starting to test an application that I implemented for a customer. Part of that application does approval workflows, so we had to create test users. We did not want to disturb real users with emails, so the customer created the test users with “name.lastname@test.com” email addresses.

After about a week we started getting bounce messages from postmaster@test.com ;)

The emails that were sent also contained user names and passwords for newly created users. Granted, only for test systems that are not accessible from anywhere, but still: in this day and age, you need to be careful with email systems.

I wonder how many emails, and how many ones with “interesting” content, the postmaster for test.com is receiving from people all over the world…

Time to ask yourself: what are you entering in the email address field when you’re testing something, or providing dummy data in a web registration form?

Real world passwords

Bruce Schneier reports about data from a MySpace phishing attack and provides interesting data about passwords, such as

“Common Passwords: The top 20 passwords are (in order): password1, abc123, myspace1, password, blink182, qwerty1, fuckyou, 123abc, baseball1, football1, 123456, soccer, monkey1, liverpool1, princess1, jordan23, slipknot1, superman1, iloveyou1 and monkey.”

I’m not surprised.

From my own experience, there are two possible schemes at work in todays real world:

  1. Strong password policies, changing too often, too complex demands (at least 8 chars, two numerals, two special characters, change every 2 weeks): People just write them down.
  2. Weak policies: people use favourite words and add increasing numbers, if necessary to comply (password01, password02, …)

This is simply not working. We urgently need to move to a system that eliminates the human element, such as SecurID or other token mechanisms.