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