"Rude password - login denied": the AT&T April Fool that wasn't

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

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.

Follow @duckblog

View the original article here

NASA suffers major data breach over stolen laptop that wasn't encrypted

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

In March 2011, algorithms used to command and control the International Space Station were exposed.

In March 2012, it was the personally identifiable information (PII) of 2,300 employees and students.

In another incident, it was sensitive data on NASA's Constellation and Orion programs.

This time around, on 31 October, it was PII on an unspecified, but large, number of NASA employees and contractors.

All these instances involved the theft of unencrypted laptops from NASA. With this most recent theft, the space agency is finally doing something about these incidents, beyond the limited scope of its previous remediation efforts.

NASA announced on Tuesday that, effective immediately, the agency is jumping on the encryption fast track.

By 21 December, no NASA-issued laptops containing sensitive information will be allowed to leave a NASA facility unless whole disk encryption software is enabled or sensitive files are individually encrypted.

In a message sent agency-wide to all employees, Associate Deputy Administrator Richard J Keegan Jr. informed NASA staff that somebody or somebodies broke into a locked vehicle and stole official NASA documents on 31 October.

The laptop contained records with PII for a large number of employees, contractors and others, Keegan said.

He gave no explanation as to why the agency waited weeks to inform employees.

The computer was protected only with a password and lacked whole disk encryption, which left the information accessible to thieves.

NASA is taking standard breach precautions, including contracting a data breach specialist, ID Experts, to notify those whose PII was compromised.

The agency is offering free credit and identity monitoring, recovery services in cases of identity compromise, an insurance reimbursement policy, educational materials, access to fraud resolution representatives, and a call center and website.

It's recommending that anybody affected activate these services ASAP.

NASA is also recommending that those affected be wary of suspicious phone calls, emails, and other communications from individuals claiming to be from NASA or other official sources that ask for personal information or verification of it.

NASA and ID Experts won't be contacting employees to ask for or to confirm personal information, Keegan said, so any such communication is sure to be bogus.

NASA's embrace of full-disk encryption has up until now been less than comprehensive.

After the March 2012 stolen laptop and PII exposure, the agency pledged:

...a full review of current IT security policies and practices with the goal of making changes to prevent a similar incident.

At that time, NASA promised that all laptop computers at NASA Kennedy Space Center, not just ones with PII or sensitive data, would have their hard drives encrypted by September 2012.

In retrospect, it would have been smarter to extend that initiative to all hard drives, throughout the entire agency, not just those at Kennedy.

But that is, apparently, a lesson that NASA has now taken to heart and will implement with all due haste.

The new full-disk encryption applies to all laptops containing PII, International Traffic in Arms Regulations (ITAR) and Export Administration Regulations (EAR) data, procurement and human resources information, and other sensitive but unclassified (SBU) data.

Keegan said that NASA's Administrator and CIO have laid out the marching orders for agency CIOs to complete whole disk encryption of the maximum possible number of laptops by 21 November.

NASA plans to complete the effort by 21 December, after which no unencrypted laptop, regardless of whether it contains PII, will be allowed to leave its facilities.

In the meantime, employees working remotely or traveling have been told to use loaner laptops if their NASA-issued laptop contains unencrypted sensitive information.

On Wednesday, a security vendor (or then again, more likely, many security vendors, but only one wrote to me directly) sent out a statement on the NASA breach that said,

"OK, whole-disk encryption might be good, but is it good enough?"

It's a question worth asking. As he said, data is in fact moving to and from laptops, in emails, files, and as data traveling to and from apps and servers.

Fortunately, NASA has also declared that storage of sensitive information on smart phones or other mobile devices is now taboo.

Let's hope they also have an eye toward all the places that data propagates, whether it's in emailed attachments, on mail servers that might be in the cloud, on smartphone mail apps, on backup tapes, or in any internal or outsourced operations.

Follow @LisaVaas
Follow @NakedSecurity

NASA image, courtesy of Songquan Deng / Shutterstock.com. Secure laptop and rocket images courtesy of Shutterstock

View the original article here