Email Address Password
Remember Me

Or Create a (Free) Account.
2004JanFebMarAprMayJunJul Aug Sep Oct Nov Dec
2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Oct Oct

Sat 12th Feb 00:28 2011: Password protection policies

Never send passwords by email or indeed in any electronically copyable format.


In this case, the question was, is the password still 88j4bb3rw0cky88 or is it now 88Scr3am3r88?

Stripping out the 88 at either end, the password is either jabberwocky or screamer, passed through various filters. There was no need to include the exact password. There was also no need to mention both passwords. If Greg had asked "is it scream yet"? then no password would have been exchanged, and Jussi would have been able to answer "No" whilst still giving a useful answer.

Even if Greg had asked "is it still jabber?", a lot of work would still need to be done to brute-force the password.

The 88 technique (especially if regularly changed, and better still if something random but different is put at the start and end of the password) is a reasonable way to avoid rainbow tables. Pasting both possible passwords verbatim into email drives right through what otherwise appears to be a reasonably well-planned password policy.

What is particularly frustrating, is that Greg apparently knew what the current and next password would be, but didn't simply try them both before sending them both in plaintext email. These user errors (PEBCAK) can undermine the best password protection strategies.

Comments for 'Password protection policies'

You could post a comment if you were logged in.

You are logged in as 0

create an account

Steve's urandom blog
Share on Twitter Share on Facebook Share on LinkedIn Share on Share on StumbleUpon
My Shell Scripting Book:
    Shell Scripting, Expert Recipes for Linux, Bash and more
is available online and from all good booksellers: