“Rude password – login denied”: the AT&T April Fool that wasn’t

Earlier today, fellow Naked Security writer Graham Cluley pointed me at a fantastic April Fool’s story.

AT&T, the tall tale told, had introduced a policy that prohibited passwords that “contain obscene language.”

There was even a handy screenshot to add some vernal veracity (or autumnal authenticity in the Southern Hemisphere):

“Very droll,” I thought.

After all, it surely wasn’t true, since:

• How would they tell? (Computers aren’t yet that smart at understanding the nuances of human language.)
• Why would they care? (Passwords aren’t for other people to know.)
• Who would ever see it? (Passwords aren’t stored in plaintext. They’re salted and hashed.)

In short, unless a human, fluent in dozens of languages, were to review your choice, there wouldn’t be much hope of reliably and usefully detecting a password couched in obscene terms.

Anyway, no human except you is ever going to see your password in cleartext, and even you will probably only ever see it as a series of **** characters in a password entry dialog.

But it looks as though this is a true-but-wacky story rather than an April Fool.

Some of AT&T’s other limitations make sense, such as preventing your username and password from being the same, and checking against a list of commonly-used bad choices to urge you in the right direction when picking a new password.

For web-based logins, much of that sort of validation can be done in client-side JavaScript, so that poorly-chosen passwords never leave your browser but are rejected (presumably with some helpful explanation) straight off the bat.

But how, and for that matter why, would you go about weeding out every password that might contain obscene language?

Would you back yourself to write computer software that could sensibly detect text that “offends against moral principles” or is “repugnant”, in the no-nonsense terminology of the New Oxford American Dictionary?

Or would place names like Scunth0rp3 and M1dd13s3x fall feebly foul of the regulations, as they used to in the early days of naive obscenity filters?

→ Those are poor choices for passwords, if only because they’re words from a dictionary, or at least from a gazeteer. But they should fail on those grounds, not because they fall foul of some kind of substring or regular expression match against swear-words.

The problem is, of course, that a “no obscene language” rule introduces more concerns that it will ever solve, including the following:

• The more extensive the server-side obscenity checking, the more likely it is that the plaintext of your password will needlessly be written to disk or sent off to other run-time verification scripts.
• The desire to have visually inoffensive passwords raises the concern that the intention is to store them reversibly, accessible to support staff for password recovery purposes, rather than salted and hashed for safety.
• Many strong and randomly generated passwords will be rejected because they contain some sort of potential “obscenity”, thus needlessly reducing the available password entropy and assisting password crackers to skip over known-prohibited combinations.

In fact, a Twitter network engineer claims to have spotted this AT&T limitation when a randomly-generated password was rejected:

In short, it’s good to prevent your users from choosing obviously-risky passwords such as letmein and pa$$word.

But rules that illogically reject a potentially large swathe of letter and number combinations serve only to reduce the range of otherwise-excellent passwords available for use, and to simplify the task of password crackers in pre-filtering their own lists of password candidates.

And there’s that nagging suspicion that the requirement for “obscenity-free” passwords implies that someone else might see them some day and be outraged, or that they might end up mailed to you in plaintext and blocked by a naive spam filter somewhere on the way.

And that shouldn’t be possible, since your password shouldn’t be stored reversibly in the first place.