Passwords guard everything from our cellphones to our bank accounts, but they often present a relatively weak challenge to hackers looking for the information that passwords should protect. New research from the University of Alabama at Birmingham, in collaboration with the University of California at Irvine, proposes and tests a variety of methods that add a strong second layer of security to a password.
In a paper presented at the 2014 Network and Distributed Systems Security Symposium, researchers offered innovative options to improve the security of two-factor authentication systems while also ensuring the systems’ usability.
“There have been many attacks on servers that store passwords lately, such as the breaches at PayPal and LinkedIn,” said Nitesh Saxena, Ph.D., associate professor in the Department of Computer and Information Sciences and a core member of the Center for Information Assurance and Joint Forensics Research.
Many people use the same few uncomplicated passwords repeatedly, making them easy to remember. Passwords are typically stored on servers in a hashed form. Hackers can garner passwords either by an online brute-force attack, or by hacking a server with poor security and using a “dictionary” of passwords to test offline.
“A single server break-in can lead to several of a user’s accounts being compromised, because they’re using the same password in several places,” Saxena said.
Two-factor authentication schemes, such as Google Authenticator, or hardware tokens, such as RSA SecureID, use a second device to generate a temporary personal identification number, or PIN, that the user must enter along with their password. But current two-factor schemes present the same vulnerabilities to server hacks as password-only authentication, Saxena says.
“If someone hacks into the server, they could learn the passwords via an offline dictionary attack,” he said. “Learning the passwords wouldn’t compromise the second authentication factor, but the user might be using that same password elsewhere. The hacker might not be able to log into Facebook if Facebook uses two-factor authentication, but they could log into Twitter if Twitter uses the single-factor authentication using the same password.”
The paper proposes and tests four two-factor schemes that require servers to store a randomized hash of the passwords and a second device, such as the user’s security token or smartphone, to store a corresponding secret code. The paper presents these schemes at several levels of computer system bandwidth, effectively turning four schemes into 13 security options.
“Rather than requiring the user to enter both their password and a PIN generated by an app, the user could enter a password, and their smartphone could automatically send a PIN over a Bluetooth connection or through a simple QR code,” Saxena said.
Saxena and his co-authors, UAB graduate student Maliheh Shirvanian, Stanislaw Jarecki and Naveen Nathan of the University of California at Irvine, analyze each scheme in terms of security provided, usability and deployability.
The schemes are geared toward using soft tokens, like smartphones. Using smartphones to provide secret codes can give a security system the flexibility to protect several passwords with a single soft token.
“Hard tokens are traditionally used within the context of a company that needs more security,” Saxena said. “With soft tokens in play, you can use just one token, such as your smartphone, to log into different websites securely.”
However, the proposed approaches are applicable to hardware tokens too.
“With each of our proposals, you get a high level of security with the same or better level of usability than the current two-factor authentication schemes,” Shirvanian said.
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.
US privacy and computer security advocate Micah Lee describes himself, amongst other things, as "a staff technologist for EFF and the project maintainer of HTTPS Everywhere."
In other words, he has a healthily holistic view of the use of encryption on the internet.
So it wasn't surprising, earlier this week, to see him post a suggestion to the Android Open Source Project about security.
His suggestion was entitled "Backup and restore" should offer encrypted backups:
The "Back up my data" option in Android is very convenient. However it means sending a lot of private information, including passwords, in plaintext to Google. This information is vulnerable to government requests for data.
If you're an Android user, the option he's talking about is the Backup & reset page in Settings:
In the screenshot above, the feature is turned off.
Most users, however, probably have it enabled because it is, as Micah points out, very convenient.
The idea is that if you lose your device, or merely feel the need to reflash it, you can much more quickly get back to where you were.
Instead of just reinstalling your favourite apps and starting afresh, your new device will know how to get online straight away, how to get into your Twitter account, and how many Angry Birds levels you haven't conquered yet.
Clearly, Google keeps a raft of configuration data on your behalf, because if you have the option enabled and then decide to turn it off you get this dialog:
So how risky is this option?
It's not risky in the sense, for example, of the recent flaw in the Tumblr app on iOS.
There, Tumblr forgot to secure the actual transmission of personally identifiable information (PII), such as your password.
That meant that crooks at a coffee shop, for example, might easily be able to sniff out and extract your Tumblr password.
The Android issue is more subtle: the data is encrypted in transit, and Google (for all we know) probably stores it encrypted at the other end.
But it's not encrypted in the sense of being inaccessible to anyone except you.
That's obvious because, as a comment on Micah's abovementioned posting pointed out, you can recover your data from Google even after you've wiped (or lost) your device, or changed your Google account password.
In other words, Google can unilaterally recover the plaintext of your Wi-Fi passwords, precisely so it can return those passwords to you quickly and conveniently even if you forget your device password and have to start over.
That's just the sort of convenience which many users will trade against security.
So, let's say some Three Letter Agency were to use some prismatic techqniue to acquire those Wi-Fi passwords from Google.
Is that likely? If so, would it be bad?
I have to say that it probably would be, if only because the list of Wi-Fi networks and passwords on your device is most likely much more extensive than just your own network in your own home.
You'd effectively be helping to built a list of passwords to go with the already-existing and extensive maps of Wi-Fi access points built up over years, both by Google and others.
You probably don't want to help anyone, friend or foe, to do that.
The solution is to encrypt everything "for your eyes only" before you back it up anywhere, especially into the cloud.
And the problem with that is it's not quite as convenient, not least because there's no password-free way to recover that backed-up data, for example if you forget your password.
That's the dilemma we all face.
Are you prepared to accept a digital equivalent of locking your keys in the car forever (for example if you forget your full-disk encryption password and didn't save the recovery key)?
Or would you prefer to have what amounts to a backdoor to your own, or worse still, to other people's, personal information?
What do you think? Let us know in the comments below...
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.
You are not paranoid about surveillance - at least, not as far as Facebook is concerned.
It appears that Facebook founder Mark Zuckerberg and his minions, in the early days, had a master password with which they could sign in to any user account and poke at whatever data we entrusted to the site.
The Guardian gleaned this from Zuckerberg's former speechwriter, Katherine Losse.
Losse told the media outlet that users should be guarded with their private data on the site - a timely warning, given the launch of Facebook's social search tool graph search.
Losse - aka Facebook employee No. 51 - joined the company in 2005 as a customer support staffer and worked her way up to being Zuckerberg's ghostwriter. She left in 2010 and, according to the Guardian, is now regarded as a rogue former employee by Facebook itself.
In 2012, she released a book, The Boy Kings, about those early years.
Recent revelations about the US National Security Agency's (NSA's) voraciously hungry appetite for surveillance may have left many users of social networking sites fretting about the government sucking up our private data, but Facebook has been privy to that data - including our passwords - from its infancy, Losse told the Guardian.
As The Guardian's Siraj Datoo points out, that's a little scary, given that plenty of users likely have never changed their passwords since they first signed up.
To make matters worse, many people commit security blasphemy by using the same password on multiple sites.
To make matters spontaneously combust in worse-osity, Losse wrote in "The Boy Kings" that in its early years, Facebook passed out the master password like candy, without vetting any of the support staffers.
Here's an excerpt from the book, courtesy of coverage from CNet's Jennifer Van Grove:
"Jake introduced us to the hanky application through which users' e-mails to Facebook flowed. Once we learned how the software worked, Jake taught us, without batting an eyelid, the master password by which we could log in as any Facebook user and access all their messages and data... I experienced a brief moment of stunned disbelief: They just hand over the password with no background check to make sure I am not a crazed stalker?"
As Losse told The Guardian, social networking users tend to assume they're the only ones who can access the information they input, but at most companies, it's probably not true, given that "at least some of the staff need to have access to user accounts in order to do their jobs."
She said:
"There has to be a way for the staff to manage and repair user account issues, and for this reason user data within most startups, especially when they are young, is never completely locked up from company staff."
At any rate, Facebook doesn't hand out a master password anymore, it says.
Nowadays, the company told CNet, employees don't have password access:
"An audit by the Irish Data Protection Commission included a detailed review of the level of access to user data that employees have at Facebook and found that we have an appropriate framework in place. Facebook employees do not have access to users' passwords."
It is, of course, preferable that we have as clear a picture as possible of what companies do with our personal data, so this history of early data yahooism is welcome.
If it helps Losse to sell more books by tying it in to concern about PRISM-like surveillance, that's OK, as far as I'm concerned.
The more light we shed on these formerly murky matters, the better.
Facebook from its start could watch us, listen to us, and, probably, make fun of us and our soppy, trivial and/or really embarrassing posts and data.
Now it can't, it assures us.
If that helps to ease your compulsive surveillance suspicions, paralyzing fear of electronic privacy violation, or even, to borrow the Joy of Tech's formal diagnosis, PRISM Anxiety Disorder, all the better.
Thank you, Ms. Losse, for letting us know.
Follow @LisaVaas
Follow @NakedSecurity
Images of Facebook silhouette and Mark Zuckerberg courtesy of Kobby Dagan / Shutterstock.com.
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.
Last week Motorola execs showed off experimental biostamps - digital "tattoos" capable of authenticating you to your phone.
Could this be the ultimate solution to the problem of authentication, or is it just a sci-fi pipe dream?
The biostamps are basically flexible electronic circuits attached to the skin, which theoretically can communicate wirelessly with any device which needs to check who you are.
The concept evolved from medical research, and was picked up by Google subsidiary Motorola Mobility, who are looking into making it a reality.
An alternative option, also presented by their bosses at the recent Wall Street Journal D11 conference, is a pill which emits identifying signals from the stomach.
The problem of identity is the biggest headache in computer security. Verifying you are who you say you are is at the heart of most security issues, and being able to pose as someone else - to their bank, say, or to their email or social networking provider - is the main aim of the vast bulk of malware and cybercrime.
What's needed is an end to the weak, clunky and decrepit authentication system on which we base most of our security - passwords.
With the speed modern computers can process guesses, and humanity's apparently incurable lack of originality, their usefulness has reached an end.
So what should we do instead?
Two-factor authentication is much in the headlines lately.
Most of us carry some sort of mobile device, so why not use it to prove who we are? In combination with a traditional password, that should make things much more secure.
Nice idea, as far as it goes. But still clunky and awkward.
It relies on you having your device handy, and requires you to faff around consulting it and feeding in complicated codes between devices. Also, not all that secure, as man-in-the-middle attacks have proven.
So a way of uniquely identifying a person, simply and automatically with minimal mental effort, could be a great step forward.
Fingerprints seem like the obvious option, but the laptop I'm typing on has an alleged fingerprint reader, and I seem to be able to pass its test with my elbow, while my finger is completely ignored. Effective contact-less authentication without moving a muscle seems far better.
But are these "electronic tattoos" or swallowable dongles really viable? And if they are, are they really the right way to go?
They sound like something from a sci-fi movie, but in the past reality has caught up with some pretty wild ideas from the sci-fi world.
The first problem with Motorola's ideas as they are is that they are temporary.
These biostamps apparently last only a couple of weeks, while the pill version might last longer but would eventually be, ahem, ejected.
So they'd need to be replaced. You wouldn't want to go too long without your ID, so you'd maybe keep a stash of pills/stamps handy, in your wallet say, or beside the bed.
Bad move. Get your wallet stolen or your house burgled, suddenly your 100% verifiable identity's been shared with the whole black market.
An alternative would be to have the things built on-the-fly and dispensed by a dependable source. Maybe a machine in the street, which you would authenticate yourself to using the last dregs of power in your previous patch or pill.
The dispenser and the process of creating the dingus would have to be pretty hack-proof though, which has proven to be beyond humanity's abilities so far.
Longer term you might think it would be good just to have a permanent implant, put in at birth. Now we're really hitting sci-fi territory - Hollywood loves a nice implant.
As things develop you could maybe include some storage in there too, at first just a handy flash drive for moving your files around but further ahead perhaps backing up your memories to save space in your brain.
Beyond the obvious civil liberties problems, there are religious issues with such body modifications.
And of course there will always be slow adopters. In any decent dystopia there has to be an underground resistance movement of course, but they can usually be overcome with a tough regime of drugs and brutally enforced compliance.
Next up, you'd need the thing to know you were alive, and ideally awake. The pills are powered by stomach acid, so should die when they leave the body.
Hopefully they would have some controls to prevent them being rinsed off and rebooted.
With the stamps though, you wouldn't want a bad guy tearing it off or, even worse, removing whatever body part it's attached to and taking that to the nearest ATM.
The biostamps are based on a design meant for health monitoring anyway, so that shouldn't be a problem. Where it gets difficult is if the health monitoring goes too far and starts trying to guess when you're going to die.
From there it's only a short step to controlling how long you deserve to live.
Knowing you're awake is important so that you couldn't be doped or knocked out and used as a snoozy key to your house/phone/bank account etc. Detecting consciousness is likely to be fairly viable, but really you'd want the thing to know that you actually want to be identified, to avoid brush-past ID theft.
This issue exists with current contact-less bank cards, but there it can be overcome with simple signal-blocking wallets.
To do it with built-in kit we're looking at mind-reading, which I'm sure the big search providers and social network sites would love a piece of.
It wouldn't take long to start seeing adverts beamed straight into the brain.
Things look pretty bleak for the biostamp then. A fun idea, but probably not a viable solution to the authentication problem.
It looks like we're going to be stuck with passwords for a while at least, so make sure you practice safe password management.
And keep watching the skies!
Follow @virusbtn Follow @NakedSecurity
Image of hand bar code and vital signs courtesy of Shutterstock. Image of biostamp courtesy of MC10.
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.
Oh, the joys of late night television in the United States!
When there's nothing funny on American TV, you can always rely upon an infomerical selling some crazy product to have you chuckling or simply agog in disbelief that anyone would ever buy such a thing.
Ellen DeGeneres clearly feels the same, and she recently focused some attention on a product that claimed to solve a computer security problem experienced by many internet users - how to remember your passwords.
Take a look at the video below about the "Internet Password Minder":
As one of the customers featured in the infomerical breathlessly explains:
"I don't have to worry anymore about security or identity theft... I now have all my passwords in one place. It's great"
At first I thought perhaps the people behind the "Ellen" show had made the infomercial as a spoof, but now I'm not so sure. After all, I find it hard to believe that *any* infomericals are real.
As Ellen amusingly asks, wouldn't it be cheaper to save money and write all your passwords on a $5 bill?
You could even keep the (patent-pending - don't steal the idea!) $5 bill password minder in your wallet if you liked - much more convenient than the book-sized Internet Password Minder!
Sheesh.
Here's my own video explaining how to generate a tough, hard-to-crack password that is still easy to remember.
(Enjoy this video? You can check out more on the SophosLabs YouTube channel and subscribe if you like)
If you can't remember your passwords, and have difficulty juggling different passwords for different websites, then just use password management software like KeePass, 1Password or LastPass.
It makes a lot more sense than Ellen's Internet Password Minder or a $5 note.
Well done for Ellen for raising awareness of password security issues with her large TV audience in an amusing way.
PS. Just as I was about to publish this article, I found a comment on Ellen's website from someone who claims to be the woman in the infomercial who no longer worries about identity theft.
Follow @gcluley
Hat-tip: Paul Baccas of SophosLabs, who hasn't yet explained what he was doing watching Ellen.
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.
A security researcher from San Jose in California has published a how-to guide detailing a number of vulnerabilities in various Linksys routers.
Phil Purviance, who goes by the handle of SUPER.EVR (EVR stands for Exploitation Vulnerability Research), reported the holes privately on 05 March 2013:
Hello Cisco PSIRT, I would like to report several vulnerabilities in Linksys network equipment. A public advisory regarding these issues may be released 30 days after sending this report.
And Purviance certainly lived up to his threat, publicly releasing the gory details on 05 April 2013 on his blog.
I don't want to get sidetracked into a discussion about the disclosure process here - whether 30 days was long enough, whether it was fair to expect a reply after emailing Cisco, which no longer owns the Linksys brand, or whether explicitly documenting the holes was wise.
You'll have to make your own mind up on those issues, because the purpose of this article to zoom in on one of the holes to see what we can learn from it.
The vulnerability we'll be looking at is:
Linksys EA2700 Password Change Insufficient Authentication and CSRF Vulnerability
Imagine that you are trying to penetrate a network inside a building that is monitored by security guards, offers no remote computer access, and is surrounded by an electric fence and motion detectors.
You're not going to get inside, but now imagine yourself holding up a placard outside one of the office windows saying, "Kindly enable remote login on port 5128 and change the password to b4nana," and waiting a while.
Imagine if it worked!
That's a simile for one of the bugs that Purviance found.
It gets the tag CSRF, for Cross Site Request Forgery, because it lets you embed, in an external web page (that's the placard outside the window), a URL that refers to a configuration script that will run on your router (that's the list of instructions on the placard).
So the Cross Site Request isn't a demand from an angry web server, but rather a web page that deliberately takes you to site B via site A.
In this case, visiting an otherwise innocent-looking external site can cause your browser to initiate internal actions on your router.
And if the router assumes that you are authorised simply on the basis that you are issuing the request from inside the network, an external attacker can easily use you as his "inside proxy" to violate security.
The unprotected configuration page found by Purviance permitted just the sort of silent reconfiguration jokingly shown on our placard: enabling external router admin (something you should never be tempted to do by choice), changing the password, and more.
So much for the metaphorical electric fence, the security guards and the motion detectors.
Of course, for this attack to work, the criminal needs to know what internal URL to embed in his external web page, which means he needs to know the internal name or IP number of your router:
That's so that when your browser processes the dodgy URL, the malicious reconfiguration request goes to the right web page on the right router, and produces the right HTTP request, as in the example above.
In Purviance's example, as above, he chose 192.168.1.1, which is a good guess for many networks.
? Private IP address ranges for your home or business network run from 10.0.0.0 to 10.255.255.255, from 172.16.0.0 to 172.31.255.255, and from 192.168.0.0 to 192.168.255.255. Advocates of security through obscurity suggest choosing randomly from the available private spaces, and as long as you don't rely on this as a security measure in its own right, you might as well do just that.
By the way, the problem of internal command-and-control URLs embedded into external websites (the Cross Site Request part) is why many web services require you to enter your password again to authorise key operations, even if you are already logged in.
That not only does prevents curious (or malevolent) colleagues from making long-term changes to your configuration if you inadvertently leave your screen unlocked, but also makes attempted alterations caused by CSRF more obvious.
Requiring re-authentication not only makes the CSRF fail, but also draws your attention to the attempt because an unexpected password dialog pops up.
So, the lessons to learn from this bug are:
Don't gripe at websites that ask for your credentials again when performing configuration or security-related tasks. The inconvenience is a small price to pay for the additional safety.Keep your eye open for firmware updates for your routers and other network hardware. Security patches don't just apply to desktop operating systems and applications.When writing web services that are worth password-protecting, don't just protect access to the URL of the relevant starting page. Make sure that the individual URLs that accept and process commands (whether by GET or POST requests) are all authenticated, too.Logout from web services when you aren't using them. Don't needlessly leave yourself in the position that accidental or unexpected clicks can have unintended side-effects.
? Yes, the last point above includes logging out routinely from Facebook, Twitter and your webmail, too. It's much more convenient to stay logged in all day, but much less safe, and very much less secure.
As for closing this hole if you have a Linksys EA2700 router, Dan Goodin of Ars Technica reports that:
A statement issued by officials from Belkin, which recently acquired the Linksys brand, said the vulnerabilities documented by Purviance had been fixed in the Linksys Smart Wi-Fi Firmware that was released in June.
And according to Linksys, the June 2012 firmware release was itself superseded in July, October and November last year:
Purviance didn't make it clear, in his vulnerability disclosure, which firmware version he used during his research.
But if you aren't on the latest firmware version, you probably ought to grab it anyway.
After all, this isn't the first time we've written about vulnerabilities in, and the external misuse of, SoHo routers.
And if you're really keen, you can use the hacking-by-numbers tool Metasploit to do a penetration test against your own router, as exploit modules for Purviance's holes are already available online.
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.
Over the last few months, I've spent a significant proportion of my time researching the CVE-2012-0158 vulnerability.
I'm glad to say that that research has paid off, and I will be presenting a technical paper at the Virus Bulletin conference in Berlin, later this year.
The paper, "Between an RTF and OLE2 place: an analysis of CVE-2012-0158 samples", will be a summary of my research so far into the threat.
One of the issues in detecting CVE-2012-0158 samples is that the delivery mechanism can be RTF, Word or Excel files.
Word and Excel files can be password-encrypted, meaning that it can be harder for an anti-virus scanning engine to see the malicious code.
The problem the attackers have, of course, is that they not only have to trick users into clicking on the attachment with social engineering, but also need to dupe their potential victims into entering a password.
With Excel, however, there is another method and that is to save the boobytrapped file as "Read Only".
"Read Only" applies the same encryption method and uses a default password chosen by the Microsoft programmers: "VelvetSweatshop".
Here is a short video showing how malware can use this default Excel password in its attempt to infect unsuspecting computer users.
(Enjoy this video? Check out more on the SophosLabs YouTube channel.)
If you would like to know more about the CVE-2012-0158 vulnerability then I urge you to attend the Virus Bulletin conference later this year. While you are there you can also listen to and meet other experts from Sophos:
My SophosLabs colleagues Numaan Huq and Peter Szabo also have a reserve paper at the conference: "Trapping unknown malware in a context web".
A strong showing for the SophosLabs experts at this year's Virus Bulletin conference, I'm sure you will agree. We look forward to meeting many of you in Berlin.
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.
San Francisco-based document sharing site Scribd has admitted to a network intrusion.
Scribd bills itself as The World's Largest Online Library, and with a suggested 50 million users or more, it's hardly surprising that the site has attracted the attention of cybercriminals.
Details are scant, but a notification published on the company's online Support Desk states:
Earlier this week, Scribd's Operations team discovered and blocked suspicious activity on Scribd's network that appears to have been a deliberate attempt to access the email addresses and passwords of registered Scribd users.
Because of the way Scribd securely stores passwords, we believe that the passwords of less than 1% of our users were potentially compromised by this attack.
We have now emailed every user whose password was potentially compromised with details of the situation and instructions for resetting their password.
Therefore, if you did not receive an email from us, you are most likely unaffected.
The comment that less than 1% of users were potentially compromised "because of the way Scribd stores passwords" could probably have been made more clearly.
At first blush, I was inclined to interpret this to mean that 99% of passwords were stored securely, presumably by salting and hashing, leaving only a small proportion open to the scrutiny of intruders.
? We've seen cases before where websites have upgraded their password handling systems to make them safer, but seem to have failed to migrate all users to the new system in a timely fashion, leaving some users in an insecure limbo.
The good news, if you read on, is that it looks as though none of Scribd's passwords are stored in cleartext, as the company goes on to say that:
Our investigation indicates that no content, payment and sales-related data, or other information were accessed or compromised. We believe the information accessed was limited to general user information, which includes usernames, emails, and encrypted passwords.
Scribd isn't claiming any certainty in what was taken (the verb believe implies acceptance without proof), but that's not unexpected.
Determining precisely what was stolen after an electronic break-in is tricky, and pedantic readers will be quick to point out that, technically, nothing was stolen because the original copies of the data remained behind.
Scribd also isn't clarifying how the passwords were encrypted, and the company probably doesn't actually mean encrypted, either.
Salting and hashing passwords is supposed to be a one-way process that allows the passwords to be verified, but not decrypted to reveal the original cleartext.
Assuming they were hashed and salted, then, stealing the password database doesn't directly reveal anyone's password.
But it does let the crooks mount an offline attack on the database, hashing a dictionary of passwords one-by-one and noticing when a guessed password is verified against the database of hashes.
And since Scribd isn't saying what password security algorithm it used, you have little choice but to assume it was a hashing process that doesn't slow down determined attackers much.
That's why the following behaviours are important:
When you choose a password, don't pick anything obvious. Attackers put the most likely passwords at the top of their dictionary lists, so the tougher your password, the later it will fall, if at all.Don't use the same password on multiple sites. Doing so means that your login details on the most important site are at risk from an attack on the least secure one.If you store password databases, use a strong salt-and-hash system (e.g. bcrypt, scrypt or PBKDF2) that makes it much harder and slower for attackers to go through their password dictionary, but not so slow that it's impracticable to verify individual passwords when your users login.
Scribd has put up an online "breach checker" which lets you check individual email addresses against the list of probably-pwned accounts:
It would have been a nice touch if the company had used HTTPS for this particular page, rather than sending your email address, and the notification of whether it was on the at-risk list, via unencrypted HTTP:
On the other hand, since anyone can check anyone's email address anyway, and since you probably received an email advising you to change your password already if your account was potentially pwned, it probably doesn't matter.
To learn more about managing, choosing and policing passwords in your organisation, why not listen to our popular Techknow podcast on this very topic?
(If you prefer to listen offline, you can download the podcast for later.)
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.
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.
Apple has had a good-bad-good-bad week of it in the computer security environment.
Cupertino released iOS 6.1.3, a modestly-sized update (at least by modern standards) of 18MByte that promised to fix a lock screen bypass bug.
Admittedly, that bug didn't give a crook access to your whole phone or to all its data, and you had to make a phoney emergency (911) call during the exploit.
But a lock screen is supposed to be a lock screen, and so Apple did well to publish an over-the-air update, patching this and other holes, in just over a month.
It soon went pear-shaped for Apple, though, with iOS thorn-in-the-side hacker "videosdebarraquito" quickly devising a wheeze to bypass the 6.1.3 lock screen.
Once again, the attack requires a fair amount of fiddling, including popping out the SIM card; only gives access to the phone itself and your photo gallery; and won't work if you turn voice dialling off.
But a lock screen is supposed to be a lock screen, especially if it's the lock screen of an update that was shipped to patch a flaw in the lock screen.
Think that was a problem?
Then you might want to feel sorry for Apple, which faced even bigger woes on the authentication front this week.
Seven months ago, Apple faced a huge blast of negative publicity when a journalist lost his fruit-flavoured digital life after an attacker tricked Apple's support staff into handing over his Apple ID password.
So, to widespread approval, including from Naked Security, Apple this week announced the introduction of a two-step verification feature for Apple ID logins.
You login as usual, then Apple SMSes you a one-time magic code which you need to type in to complete the authentication process.
Not perfect, and nowhere near as good as a standalone access token like your bank might have given you, but a definite step forward.
But then came news that Apple's password recovery, at least for those who haven't turned on, or don't want to or can't turn on, two-step verification, was deeply flawed.
For flawed, read, "Broken."
Apparently, all you had to do was to know was your victim's email address and date of birth, and to paste a specially-formed URL into one of the fields on Apple's official password recovery site (the inanely-named "iForgot").
By doing so, you could jump over the security-related part of the reset process and score a password stealer's hole-in-one.
? Why anyone's date of birth should be considered a secret suitable for security purposes beggars belief. By definition, at least in the developed world, your birthday can't be a true secret, since the law requires it to be registered officially (in plaintext, no less) within a short time of your birth. Furthermore, society actively encourages you celebrate it at least semi-publicly every year, a situation that is incommensurate with secrecy.
Whether this exploit relied on cross-site scripting (where a URL for an unofficial site is accidentally processed in the security context of a legitimate site), or command injection (where a database lookup is mistakenly processed as a command), is not clear.
Whatever the cause, Apple quickly took the iForgot page down and then brought it back up, apparently after closing the hole.
Turning on the new and much-vaunted two-step verification would have neutralised the attack, but sadly the Apple two-step isn't yet available worldwide.
It's only officially supported in the US, the UK, Ireland, Australia and New Zealand, and even in the UK, many users (including Naked Security's own Graham Cluley) say that aren't able to turn it on yet anyway.
It's a pity that Apple announced its new security feature as though it were ready when clearly it was not.
Marketing allows for a bit of puffery, and the software industry has long relied on "pre-announcements" (less politely known as vapourware) to promote products that aren't quite ready yet.
But let's all agree to go easy on the vapourware-style pronouncements on security issues.
Don't invite people to adopt new security features unless they really are ready and working precisely as claimed.
After all, it's the early adopters in security who are your best shot at getting the rest of the world to change for the better, too...
Follow @duckblog
PS. If you can turn on two-step verification, I recommended that you do, especially if you have any purchases or data tied up in iTunes, the App Store or iCloud. Two-step verification raises the bar for the crooks.
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.
After being hacked, Evernote, quite responsibly, has sent out emails to its users informing them of the security breach - and letting them know that it has decided to reset all passwords.
The email goes on to give some password advice - including a warning:
Never click on 'reset password' requests in emails - instead go directly to the service.
That's a very sound piece of advice, because of the obvious threat - after millions of Evernote customers had their usernames and email addresses stolen - of phishing email attacks.
But take a closer look at the email that Evernote has sent out, with the subject line "Evernote Security Notice: Service-wide Password Reset":
Uh-oh, in the same email that Evernote tells users not to click on 'reset password' requests sent via email, they have clickable links.
And what might make some recipients pause for thought is that the links don't go directly to evernote.com, but instead link to a site called mkt5371.
Now, before you panic that someone is attempting to phish your Evernote credentials with a craftily-designed email, just relax.
This was just carelessness on Evernote's part. mkt5371 is a domain owned by Silverpop, an email communications firm who Evernote has clearly employed to send emails to its 50 million or so affected users.
The links in this case *do* end up taking you to Evernote's website - but go silently via Silverpop's systems first.
Presumably that's so Evernote can track and collect data on how successful the email campaign has been.
That's a technique commonly used in a normal marketing email communications, but looks very out of place in an email about a security breach which tries to hammer home the point to "Never click on 'reset password' requests in emails - instead go directly to the service".
You could certainly understand why someone freaked out by the Evernote security breach would be alarmed to receive an email with links like that.
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.
Filed Under: Featured, Windows
OK, so Dead in Six Hours isn't quite what the paper is called. I made that up.
It's actually called Exacerbating Global Warming. (It is. Really.)
In the paper, researcher Jeremi Gosney describes a pet project of his.
He's lashed together 25 AMD Radeon Graphics Processing Units (GPUs) into a specialised computing cluster.
It will cost you about $20,000 to build one, and you'll need twenty rack units of space in a server room. (That's just under a rack-metre.)
You'll also need an industrial-style power supply delivering 7kW, which is where the paper's title comes from, plus some half-decent air conditioning.
In return for your investment, claims Gosney, you'll be able to brute-force all regular eight-character Windows passwords from their NTLM hashes in about six hours.
That's about four times faster than Gosney's previous top-end hashbusting machine, which needed 24 hours - an entire day! - to do the same job.
Why so fast? And why Windows passwords?
The reason is that NTLM relies on one of the easiest-to-crack hashing systems still in widespread use: a straight, unsalted, uniterated MD4 hash of your password. (The raw password is presented in little-endian UCS-2 format, with 16 bits per character, not as an ASCII string.)
If you have a UNIX-flavour command prompt and some common utilities handy, you can convert any ASCII password to its NTLM hash like this:
Note that, with no salt, everyone who chooses "password" as a password will end up with the same hash, so you can use a pre-computed database of common hashes.
But with Gosney's cracker, you might as well not bother pre-calculating anything: you can churn through nearly 400,000,000,000 MD4 hashes per second and save yourself the space you'd need to store the lookup table.
Big deal, you say. Microsoft no longer recommends NTLM anyway, and Active Directory logins don't use it.
But perhaps consumers and small businesses should be worried? After all, if you have an ad hoc network of Windows computers, without Active Directory or a Windows domain, you're still wedded to NTLM.
In fact, any local accounts on a Windows PC have NTLM hashes stored locally in the Security Accounts Manager (SAM) database. Grab the hashes, and you can attack them offline.
Big deal, you say. If hackers can leech your SAM database, they've already got Administrator rights, so they don't need your password.
But if they do get and crack your password hashes, they may be able to get back in later at their leisure, even if you close the security hole they used to grab your SAM data. And they'll have the plaintext of your password, which could cost you if you have used it anywhere else.
So here are two lessons we can learn from this:
• Eight characters just isn't long enough for a password these days.
? Choose long and complex passwords, or use a password management tool to help you. That way, you keep ahead of the bulk cracking tools. If eight characters gives 98-to-the-power-8 choices, adding just three more randomly-chosen characters multiplies that by a further 98-to-the-3, or close to 1,000,000-fold.
• You probably have other passwords even more easily crackable than your Windows one.
Some websites or online services may even even keep plaintext, or unhashed, copies of your password. Cracking time for those is zero.
? Don't use the same password for multiple accounts. That way, you don't lose the keys to the whole castle if any of your individual passwords is compromised.
Oh, and if you're looking for the briefest of technical challenges over the holiday season, why not satisfy yourself how risky simple passwords are by having a go at the hashes in the Windows 8 screen shot above?
Estimated time to crack once you're ready to go, even without a GPU: well under a second.
Here they are, cuttable-and-pastable for your cracking pleasure:
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.
The Australian Defence Force Academy (ADFA) is the latest high-profile organisation to become embroiled in a data breach.
Students at the Academy apply both to the Defence Force and to the University of New South Wales (UNSW), which runs the academic side of ADFA's operations in Canberra.
It turns out that a hacker calling himself Darwinare breached the UNSW's servers about a month ago and sucked down a heap of SQL database records, including those of ADFA students.
He then uploaded the data to an anonymous dump site, where interested members of the public can acquire it at will.
Fast-forward four weeks to today, and the breach is starting to attract attention, no doubt because of the connection of UNSW Canberra with the Defence Force Academy.
It's certainly a bad look for both the University and the Academy.
It's not the end of the world, fortunately. No juicy Defence secrets such as troop movements, aircraft plans, coastal patrol schedules, or weapons purchases have been revealed.
And UNSW did the right thing, candidly explaining the breach to those affected the day after it was reported. The breach included student ID, full name, email address and date of birth; similar data about staff was dumped, too.
Nevertheless, it shouldn't have happened, and there can be no excuses.
Worst of all, the data dump reveals that UNSW was storing usernames and passwords for at least one of its computer systems in plaintext.
To be fair, these passwords were meant just for initial login, and were therefore expected to have a short life. But passwords should never be weak or guessable, or, for that matter, stored in plaintext. And the algorithm for generating the passwords in the dump is like a timewarp back into the 1970s.
They are all just seven or eight lower-case letters long. Many are repeated. All are meant to be pronounceable - surely an unnecessary step for a password that is intended to be typed in once and then changed - which leads to a conspicuous lack of randomness. Only a small set of digraphs (two-letter pairs) is used.
That produces some comic results. One percent of the passwords, for example, end in -poo, making them rather sadly self-descriptive.
Make sure this doesn't happen to you.
Harden your web services! Bring your password handling into the 1990s, if not actually the twenty-first century! Do it today!
Thanks for listening.
Follow @duckblog
Do you run a web server at home, perhaps for friends and family, or even just for fun? How well protected are you?
Why not try our free Sophos UTM Home Edition?
You get a web application firewall, web and email filtering, IPS, VPN and more for up to 50 IP addresses.
Turn that spare PC into a full-on network security appliance!
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.
Two months ago, we wrote about the conclusion of the NIST Cryptographic Hash Algorithm Competition.
The winner was Keccak - now officially dubbed SHA-3.
Despite the formal ratification of this new standard, NIST's earlier hashes remain commonly used. Indeed, we can expect to see SHA-1 and SHA-2 in the wild for years - possibly even for decades.
SHA-1, in particular, is still widely encountered in password hashing.
Password hashing is where you use a cryptographic hash function in some part of your password archival system to create a one-way function.
A one-way function is a process that's easy to compute in one direction, but complex - or, better yet, computionally infeasible - to work out in reverse.
So, if you store one-way password hashes instead of the actual passwords, attackers who steal your database can't directly recover those passwords. They have to try password after password themselves, until they get lucky.
? Using a one-way function to store passwords is not a replacement for keeping your password database secure. It's additional security that offers a touch of defence-in-depth, just in case your server does get broken into.
Because one-way functions can't be computed in reverse, cracking cryptographically-hashed passwords is inevitably a brute-force affair. It means computing a one-way function over and over again.
As a result, password cracking experts put a lot of effort into improving the performance of widely-used password hashing algorithms, notably including SHA-1.
In June 2012, for example, researchers magnum and JimF (Jim Fougeron) contributed code to the password cracker John the Ripper that boosted raw SHA-1 password hashing speeds by 80%.
And, for the same release, Tavis Ormandy came up with an optimised implementation offering a 115% performance improvement, albeit limited to passwords under 15 characters.
? Password crackers are easily abused. You probably want to control their use inside your organisation. But they have a legitimate defensive purpose: to find poor password hygiene on your own network before the bad guys do.
Now, Jens Steube, author of the pasword cracking tools in the hashcat family, has added to the optimisations against SHA-1 when cracking passwords.
Steube described his work in a paper at the recent Passwords^12 conference in Oslo, Norway.
Steube's password cracking improvements reduce by 21% the number of computer instructions needed to compute a SHA-1 hash. This may allow previous optimisations - such as the the ones described above - to be tweaked yet further for additional speed.
Steube noticed that SHA-1's "inner loop" can be usefully slimmed down if you are repeatedly computing hashes from input data in which only the first input word (32 bits, or four bytes) changes each time.
For a password attack, this can easily be arranged.
Greatly oversimplified, the SHA-1 algorithm consumes its input in blocks of sixteen 32-bit words (512 bits, or 64 bytes), mixing each block into a cumulative hash of five 32-bit words (160 bits, or 20 bytes).
for block in blocks() do for i = 17 to 80 do -- each step here extends the original 16-word input -- block to 80 words by adding one word made by mixing -- together four of the previous sixteen words. block[i] = minimixtogether(block,i) end for i = 1 to 80 do -- each step here mixes one of the words from the 80-word -- "extended block" into the five-byte hash accumulator hash = giantmixtogether(block,i) endend
The giantmixtogther() function that scrambles the extended input into the hash uses a range of different operations, including NOT, AND, OR, XOR, ADD and ROL (rotate left).
But the minimixtogether() function used to condition the input data uses only XOR and ROL. Because of its relative simplicity, Steube found a way to skip the minimixtogether() loop, and to calculate the "expanded" input values block[17] to block[80] directly inside the giantmixtogether() loop.
Steube's method still needs some precalculation, but multiple separate hash evaluations can share this precalculated data if only the first block (i.e. the first four characters) of the input has changed.
If you were hashing a randomly-selected series of files, for example, this would do you no good.
But when conducting a brute force attack against passwords, it's a simple matter to put your input into a suitable sequence so that the first four characters change most rapidly, followed by the rest of the password. (Just imagine a car odometer with the digits reversed.)
If you can do this, then implemeting Steube's tweaks will make your code run 25% faster. Just like that.
And there you have it: yet another reminder that security is an arms race.
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.
Millions of blogs hosted on WordPress.com can breathe a sigh of relief - although a hacker did manage to break into thousands of sites and publish a make-money-fast advert, it wasn't because of any vulnerability on the WordPress.com site itself.
Instead, it seems users had simply been careless with their password security.
The alert was initially raised by The Hacker News (THN) and Sucuri, after some blog owners received messages from WordPress.com telling them that their passwords had been reset.
One affected WordPress.com user told THN that he had discovered hackers had published a page containing a money-making advertisement (pictured below).
A Google search for
site:wordpress.com "Im getting paid!"
finds evidence of thousands of sites that suddenly found they had unwittingly published "Im getting paid!" webpages.
Although some theorised that the hacker may have exploited a vulnerability on WordPress.com (which would be a very serious problem as the WordPress.com infrastructure is used by many of the world's most popular blogs and news sites), the truth seems to be rather more pedestrian.
Barry Abrahamson from Automattic (the company which runs WordPress.com) told Naked Security that there was no compromise of the WordPress.com servers, and that rather than vulnerability the most likely cause of the problem was "people sharing the same password across multiple services."
According to the firm, it spotted the problem quickly, notified affected users and reset passwords.
It's good news that the sites hosted on WordPress.com weren't hacked due to a vulnerability. After all, many blogs choose to host on WordPress.com in order to avoid the headache of managing their own security and updates on self-hosted WordPress installations.
So, remember folks - please use different passwords for different websites. If you use the same password in multiple places, it only requires your password to be stolen in one place for it to have an unpleasant impact on your other online activities.
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.
If Skype users didn't have enough to worry about this week security-wise (with a worm spreading across the system), there's now another threat to warn about.
Emails have been spammed out by cybercriminals, posing as messages from Skype, claiming that you have changed your password on the service.
Here's an example of one such email (click on it for a larger version):
If you look carefully, you may spot that the spammers made a clumsy spelling mistake:
Password successfully changed Your new Skype password has been set.
You can now view your attached call history and inscturtions how to change your account settings. If the changes described above are accurate, no further action is needed. If anything doesn't look right, follow the link below to make changes: Restore password Talk soon, The people at Skype
Perhaps surprisingly, the links really do point to the genuine Skype website at skype.com.
However, a file (Skype_Password_insctructions.zip) is attached to the email, and if you make the mistake of unzipping and executing its contents (Skype_Password_inscructions.pdf.exe) you run the risk of infecting your Windows computer.
The malware, which is detected by Sophos products as Troj/Backdr-HN, opens a backdoor onto your computer, giving remote hackers access to your system.
The danger is, of course, that users worried by the recent worm will be frightened that their Skype password has been changed without their consent, and open the attachment - and thus infect their PC.
As always, be on the lookout for unsolicited suspicious emails and always be wary of opening attachments which arrive out of the blue. In this case, the file is using the well-known "double extension trick" to dupe the unwary into believing that they might be clicking on a PDF rather than executable code.
Follow @gcluley
Thanks to SophosLabs researcher Julie Yeates for her assistance with this article.
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.
Paul Ducklin was back on this week for our special Friday the thirteenth edition of the Chet Chat.
We started our discussion by talking about the hype cycle surrounding the DNS Changer malware and the predicted internet blackout for affected users. Paul suggested the media misportrayed the impact on users and a more measured approach would have been more appropriate.
As usual Microsoft released a bevy of patches this Tuesday. Most importantly they released MS12-043 to fix the zero-day vulnerability in MSXML (CVE-2012-1889). Paul shared some advice for organizations struggling with patching and change control processes.
Some media outlets reported that there was malware on the Apple App Store this week, but we disagree. Paul and I explained what happened and pondered approaches Apple might take in the future to avoid a repeat incident.
Paul brought us a story from the "dog ate my homework department" where the city of San Diego, California blamed malware for a rather spectacular fireworks fail this Independence Day. At least they proved when you combine all colors of light you do in fact get white...
Lastly we discussed the loss of password databases by Yahoo!, Formspring, NVIDIA and Android Forums. While things like hashing are important, a better strategy might be to secure your network and not have your databases stolen in the first place.
(13 July 2012, duration 15:11 minutes, size 10.4 MBytes)
You can also download this podcast directly in MP3 format: Sophos Security Chet Chat 94, subscribe on iTunes or our RSS feed. You can see all of the Sophos Podcasts by visiting our archive.
http://twitter.com/chetwisniewski
Tags: Android Forums, chet chat, CVE-2012-1889, dns changer, dnschanger, Find and Call, fireworks, Formspring, MS12-043, NVIDIA, Patch Tuesday, Podcast, yahoo
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.
About three years ago, developer Cameron Morris had a personal epiphany about passwords, he recently told ZDNet's John Fontana: The time it takes to crack a password is the only true measure of its worth.
Not whether it has a minimum of x or a maximum of y characters, not whether it's got blah-blah amount of numbers, not whether it includes your frou-frou leetspeak ch@r@ct3rs, not whether it contains the verboten from lists of taboo words.
Syntax laws like those make up the typical password policy creations most organizations use and that many security practitioners preach.
But if you religiously follow such policies, Morris notes, you get situations like this: Facebook graded as "weak" a password he made up of 35 characters using the first letters of a random phrase, while it deemed a password "strong" when it matched the social network's creation policies, which allow for use of common words.
Morris's Facebook-appeasing password?
"cracked1!"
The time it would take to crack that supposedly strong password, according to tools that Morris has created to estimate password strength: less than one day.
Morris, a developer at defense contractor Partnet, told reporters that he came to his realisation after a half hour spent creating a tough-to-crack password.
That 30 minutes of password creation labor was followed by the realization that he'd have to go through the whole rigamarole again when he had to change it in a month's time.
Stop right there. That has the aroma of a password myth.
As Paul Ducklin and Chester Wisniewski discussed in a Sophos Techknow podcast, "Busting Password Myths", the idea that regular password changes lead to better security dates back to the days when passwords were stored in plain text files on Unix systems.
Regular password changes actually decrease security, for a few reasons: 1) your poor users are going to start using sucky passwords because they're easy to remember and to increment, and 2) doing something security-related on a regular, predictable schedule (quarterly? monthly?) is a gift to hackers.
This regular password change-out distracts the IT department for a predictable chunk of time on a predictable schedule. Predictability is a gift you don't really want to hand to attackers.
At any rate, being influenced by the myth that regular password change equates to good security, Morris thought it would be neat to set password expiration based on the strength of a password. He couldn't find a way to measure password strength, though.
Hence, he started building a collection of tools to do just that.
Those open-source tools are out now. Morris handed them over to the Open Web Application Security Project (OWASP) in January.
Morris is inviting people to give them a try. One tool, called Passfault Analyzer, predicts how long it will take to crack a given password.
He also created a Password Creation Slide-Tool that lets administrators configure password policy based on the time to crack, the possible technology that an attacker might be using (from an everyday computer on up to a $180,000 password attacker), and the password protection technology in use (from Microsoft Windows System security on up to 100,000 rounds of the cryptographic hash function SHA-1/).
The tool lets users move a slider bar to increase or decrease the amount of time passwords should take to crack.
All good, yes? But then came the next step in what came to be a password kerfuffle: Morris's premise and tools quickly lit a fire under SecurEnvoy, maker of two-factor authentication technology.
SecurEnvoy blogged that, basically, Morris was right about password creation policies, but he didn't take it far enough, because, in fact, conventional ID/password security is toast.
The company's blog quoted co-founder Steve Watt as putting it this way:
"This isn’t to say that Cameron is wrong - far from it - it’s just that the reasons why passwords are coming to the end of the line in today’s online environment are multi-faceted, with company password policies being only one issue of concern."
"One of the other major issues we have observed is that people have great difficulty remembering more complex passwords than the six or eight alphabetic strings that most Internet users rely on. Because of this, they fall back on an eight digit passphrase that is usually a family member’s name or place of birth, and which—unfortunately—are all too easy to hack using brute force password attacks."
It will not shock many readers to find that Watt proposes that the answer is what his company sells: i.e., tokenless two-factor authentication.
Watt does have good points about corporate password policies: they spawn mutant, impossible to remember passwords. Users wind up storing them on their mobile phones or, worse, writing them on sticky notes or on the undersides of their keyboards.
This is, in fact, the heart of the matter that Morris got right, SecurEnvoy says: overly complex passwords prompt users to find easy ways to remember them.
Yes. But the idea that passwords are going away is nuts.
The reasons for this were well laid out by ZDNet's Manek Dubash.
Dubash suggests that two-factor authentication isn't going to save us, given that we're all bringing our smartphones to work and logging on to Facebook in the enterprise:
"The reality today is that the division between enterprise and personal environments has all but evaporated."
"In the course of their jobs, people increasingly access their personal services at work using their personal devices. And enterprises cannot mandate two-factor authentication for access to Facebook, for example, which might well be the chosen method of communication of a key supplier, or a way of communicating with potential customers."
"All FB wants is a password, and it's not alone."
So if two-factor authentication isn't going to save us, what's the answer?
I rely on password generation using the scheme that Sophos's Graham Cluley teaches in this video.
So I put one of my Graham-inspired passwords - containing seven characters - through Morris's Analyzer and found that it would take approximately one day to crack it.
I would prefer that it get up into the range of a year, at least, if not a few centuries, and that is exactly what happened when I appended a range of characters from the keyboard, left to right and then the same string right to left.
Presto! Up in the centuries range.
That points not to a flaw in Graham's technique, of course, but rather a confirmation of Carnegie-Mellon's 2011 study (PDF) that concluded that length was the only thing that really influences password strength.
ZDNet's Dubash, for his part, writes that he uses a "tiny portable password generator," as well as KeePass, an open-source password manager that can even be bolstered with two-factor authentication.
It's all good. We have a technique from Graham that shows us how to create easily remembered passwords. We have password managers. We have a bunch of busted security myths from Chet. We have the Carnegie Mellon study that shows that making them long makes them strong.
And now we have a tool to analyze that strength in terms of how long it takes to crack a given password.