Apple introduces two-factor verification for Apple IDs

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 finally bitten the bullet and started offering two-factor authentication (2FA) for Apple ID users.

Good news!

If you have an Apple ID, you'll know that a lot is at stake if you lose control of your account.

That's because Apple IDs aren't just simple website logins, but make up the authenticational core of your entire digital relationship with Apple:

An Apple ID is the login you use for just about everything you do with Apple, including using iCloud to store your content, downloading apps from the App Store, and buying songs, movies, and TV shows from the iTunes Store.

The risk you're exposed to if a malcontent gets hold of the password for your Apple ID became globally obvious last year.

A neo-celebrity post-modern journalist named Mat Honan famously had his digital life owned and then laid waste by an internet ne'er-do-well who tricked Apple support staff into resetting Honan's Apple password.

As we reported about seven months ago, the person who attacked Honan's account wasn't happy just with breaching security at Apple.

The cracker also took the trouble of performing a remote wipe of Honan's iDevices, instantly turning the data on his iPhone, iPad and Macbook Air into digital shredded cabbage.

The crook was also able to take over Honan's Gmail account, his Twitter account and (through account linking) the Twitter account of Gizmodo, with whom Honan had a trusted journalistic relationship.

Protecting all of those assets with a single password that could be guessed, keylogged, stolen or simply changed by means of a social engineering phone call just wasn't enough.

A few months before Honan's digital wipeout, Apple introduced an additional layer of security for Apple IDs by pushing its users into adding a raft of answers to additional "security questions".

The theory behind this approach is that crooks will need to beg, steal or borrow more than just your password in order to masquerade as you, thus providing you with modest insurance against a poorly-chosen or stolen password.

? I'm not a big fan of auxiliary security questions, sometimes called knowledge-based authentication, because I don't accept that you can make a guessable password strong by augmenting it with yet more guessable answers to questions you've chosen on your users' behalf. Worse still, users can't change the answers to absolute security questions like "what was your first car", which also naively presumes that everyone in the world has not only owned a car but also managed to keep its make a secret from everyone else, even their friends.

Now, Apple has gone an extra mile, making 2FA available, at least to some of its users. (At the moment, you have to be in the US, the UK, Australia, Ireland, or New Zealand.)

Actually, Apple doesn't call it 2FA, preferring instead the term two-step verification.

It works by sending an SMS to one of a number of mobile devices you have registered with Apple; the message contains a one-time passcode that you need in addition to your regular password:

By avoiding the name 2FA, Apple is actually making a slightly weaker, but more honest, security assertion.

That's because there is nothing to stop you getting Apple to send your SMS verification codes to the same device on which you actually use your Apple ID.

Indeed, I suspect that many users will use two-step verification this way, and it isn't really two factor authentication if the same factor - your iPhone, for instance - is used for both steps of the process.

That's because someone who controls your iPhone to the point that they can acquire your password can, probably with not much more complexity, acquire in real time the contents of SMSes sent to your iPhone.

Nevertheless, Apple's new security feature does the right thing: it introduces single-use, random passwords to the Apple ID login process.

Another neat thing Apple has done, even though it sounds at first blush like a user-unfriendly move, is to cut its own support staff entirely out of the password reset loop for anyone who enables two-step verification:

In addition, with two-step verification turned on, only you can reset your password, manage your trusted devices, or create a new recovery key.

Apple Support can help you with other aspects of your service, but they will not be able to update or recover these three things on your behalf.<

Yes, that puts all of the password recovery burden on your shoulders.

But it also provides a strong assurance against getting Honanised, because "can't" is a much stronger security situation that "shouldn't".

If Apple's staff cannot recover or reset your password, then even the Mitnickest social engineer in the world won't be able to talk them round.

So take Apple's advice, write down the 14-character emergency recovery key created when you enable two-step verification, and lock it away somewhere at home.

Follow @duckblog

PS. Don't succumb to temptation. Take Apple's own advice that you "should not store your Recovery Key on your device or computer since that could give an unauthorized user instant access to it."

View the original article here

NIST, US government's vulnerability database, brought down by ironic malware

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 US's national vulnerability database has been offline for days thanks to a multi-server infection by severely ironic malware.

Kim Halavakoski, chief security officer at Crosskey Banking Solutions, broke the news Wednesday night on his Google+ page.

Halavakoski said that he was trying to research vulnerability information from the National Vulnerability Database (NVD) and other websites operated by the National Institute of Standards and Technology (NIST).

Instead of results, he got what was still showing up as of Friday morning: a "Page not available" message.

When he asked NIST what was up, a spokeswoman told him that the organization doesn't know when the database will be back up, but they're sweating bullets to get it back fast.

According to her statement, the public-facing NVD site and other NIST-hosted sites were taken offline when NIST discovered malware on two servers on Friday night.

NIST took the servers offline after a firewall picked up on suspicious activity and blocked "unusual" traffic from reaching the internet.

While investigating the malware, NIST discovered an unspecified software vulnerability.

So far, nothing vile has seeped out as a result. NIST says:

Currently there is no evidence that NVD or any other NIST public pages contained or were used to deliver malware to users of these NIST Web sites. NIST continually works to maintain the integrity of its IT infrastructure and acts to limit the impact of malware on its systems. We regret the impact this has had on our services.

An interesting note: in a subsequent post Thursday morning, Halavakoski noted that a site report shows that the day after NIST detected the malware, it switched its sites from IIS 7.5 to Linux and Apache.
At any rate, beyond the Microsoft vs. open-source debate, the hack of a database that catalogs vulnerabilities is little short of "pure evil", to borrow Halavakoski's summation.

Those hackers really know how to hurt a security guy/girl. Good luck wiping your servers clean, NIST.

Follow @LisaVaas
Follow @NakedSecurity

Images from Kim Halavakoski

View the original article here

Hackers launch DDoS attack on security blogger's site, send SWAT team to his home

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.

Brian Krebs

Thankfully, award-winning US computer security reporter Brian Krebs is safe.

Nobody was harmed. But they could have been.

Given a DOSed website, a fake and libelous FBI letter sent to his website host, and a dinner party delayed by a SWAT team training guns on him and ordering him to "Put your hands in the air!", Krebs last week surely endured the most dramatic retribution ever meted out to a security blogger.

Krebs has a good idea of the specific criminal element behind the trio of attacks. Since the dramatic events of Thursday, he's traced the denial-of-service attack to a common operator who apparently launched a similar attack on Ars Technica following its coverage of Krebs's victimization.

As described by his fellow security scribe Dan Goodin at Ars Technica, Krebs is known for work that includes:

In short, Krebs has enemies.

Last week, one or more of those enemies targeted him, likely in retaliation for his most recent investigation.

On Friday, Krebs detailed in a post how the ordeal started the day before, when his site was targeted with "a fairly massive denial of service attack."

That same afternoon, a technician from Prolexic called. Prolexic is a company that Krebs hired to protect his site, KrebsOnSecurity.com, from DOS attacks.

Prolexic forwarded a letter they'd received earlier that day, purporting to come from the US Federal Bureau of Investigation.

The letter, which Krebs reprinted here, falsely claimed that Krebs's site was "hosting illegal content, profiting from cybercriminal activity, and that it should be shut down," Krebs writes.

Both Prolexic and Krebs dubbed it a hoax - an assumption Krebs confirmed with a quick call to the FBI.

As Prolexic tidied up his DOSed site, Krebs got to work tidying up his home in anticipation of dinner guests. His office phone rang while he was vacuuming, but he ignored it.

That, it turns out, was an unfortunate choice, given that the call came from law enforcement who were trying to verify what would turn out to be a spoofed emergency call showing Krebs's number on caller ID.

As he was vacuuming, Krebs noticed plastic tape on the front-door threshold, left over from securing an extension cord. He opened the door to unpeel it.

He tells of what happened next:

"When I opened the door to peel the rest of the tape off, I heard someone yell, 'Don't move! Put your hands in the air.' Glancing up from my squat, I saw a Fairfax County Police officer leaning over the trunk of a squad car, both arms extended and pointing a handgun at me. As I very slowly turned my head to the left, I observed about a half-dozen other squad cars, lights flashing, and more officers pointing firearms in my direction, including a shotgun and a semi-automatic rifle. I was instructed to face the house, back down my front steps and walk backwards into the adjoining parking area, after which point I was handcuffed and walked up to the top of the street.

"I informed the responding officers that this was a hoax, and that I’d even warned them in advance of this possibility. In August 2012, I filed a report with Fairfax County Police after receiving non-specific threats. The threats came directly after I wrote about a service called absoboot.com, which is a service that can be hired to knock Web sites offline."

Krebs had filed a police report last year on the suspicion that he would be SWATted.

SWATting is the practice of falsely reporting an emergency, as a prank or as revenge against a victim upon whom descends emergency services - or, in Krebs's case, armed law enforcement.

Krebs' persecutors had, in fact, spoofed an emergency call to make it appear that it had come from his phone.

As Sophos's Chester Wisniewski noted last April when he wrote about fraudulent calls targeting US banks, caller ID spoofing can be particularly convincing in the US, given that the call display service used by most phone companies here does a reverse lookup for the name information based on the caller ID number provided by the call.

Once a criminal determines the phone number he wants to have fraudulently show up as his caller ID number - Krebs's phone number, in this case - it's trivial to display that number on the call recipient's display.

Caller ID spoofing has been around for years through various technologies: ISDN PRI circuits used by collection agencies, law enforcement, and private investigators, all of whom have used it with varying degrees of legality; spoofing services such as Star38.com; and through Voice over IP (VoIP) technology.

Given how trivial it is to spoof caller ID, it's surprising that people put any faith at all in the technology - most particularly that law enforcement do.

In fact, the police who took Krebs's report warning that he might be targeted by SWATting hadn't even heard of the practice.

All too readily, we tend to put faith in appearances. We believe caller ID identifies the true identity of a caller.

Or somebody flashes a piece of silver and we obediently hand over our licenses or wallets, or we open a door and allow strangers inside our home or our cars, without verifying whether what we've seen was an authentic emblem or a plastic toy badge.

We - the police included - trust in the technology we use. Criminals will always exploit that trust.

Krebs's work, along with other security reporters and researchers, is to poke sticks into hornets' nests, to borrow a friend's analogy.

In this case, the sting from angry hornets could have had fatal consequences, as Krebs points out:

"I have seen many young hackers discussing SWATing attacks as equivalent to calling in a bomb threat to get out of taking exams in high school or college. Unfortunately, calling in a bomb threat is nowhere near as dangerous as sending a SWAT team or some equivalent force to raid someone’s residence. This type of individual prank puts peoples’ lives at risk, wastes huge amounts of taxpayer dollars, and draws otherwise scarce resources away from real emergencies. What’s more, there are a lot of folks who will confront armed force with armed force, all with the intention of self-defense.

"The local police departments of the United States are ill-equipped to do much to stop these sorts of attacks. I would like to see federal recognition of a task force or some kind of concerted response to these potentially deadly pranks. Hopefully, authorities can drive the message home that perpetrating these hoaxes on another will bring severe penalties. Who knows: Perhaps some of the data uncovered in this blog post and in future posts here will result in the legal SWATing of those responsible."

Well said, Brian. We all hope so too, for your sake and for the sake of all security researchers, law enforcement personnel and victims of attacks like the one you experienced.

Follow @LisaVaas
Follow @NakedSecurity

SWAT team and telephone image courtesy of Shutterstock.

View the original article here

Sophos CEO suffers from a watery end for #ComicRelief

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.

Red Nose Day is a UK-wide fundraising event organised by the Comic Relief charity every two years which culminates in a night of comedy and moving documentary films on BBC One Television.

In the past we have put members of our senior management team into a gunge tank, staged boxing matches on bouncy castles and had a spacehopper race around the Sophos car park.

But this year, we decided to become a bunch of dunkards.

A large tank of water was brought into our offices, and a high tech mechanism devised which involved throwing tennis balls at a switch. If the tennis ball hit with enough ferocity, the Sophos worker would be plunged into the water - to the delight of their baying co-workers who had sponsored their preferred victims.

It was no surprise to find that Sophos CEO Kris Hagerman was high on most people's list for a dunking, and he came prepared with sunglasses, Hawaiian shorts and flipflops. This was definitely a man who knew where his towel was.

Sophos CEO Kris Hagerman is going down.... #comicrelief vine.co/v/bdDYnWbBQwA—
Graham Cluley (@gcluley) March 15, 2013

Comic Relief is a great charity to support - so make sure to visit the Red Nose Day website to find out how you can help raise funds.

So far the "Sophos Dunkards" team has raised approximately £7000 for charity. Thanks to all who helped!

PS. If you want to see more, check out our Sophos Dunkards photo album on Facebook.

http://twitter.com/gcluley

View the original article here

Apple ships OS X 10.8.3 - 11 remote code execution vulns patched, Snow Leopard and Lion get fixes too

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 shipped the latest point release of its flagship Mountain Lion operating system.

This brings current-version Mac users to OS X 10.8.3.

You can upgrade in three ways:

Let Apple's own Software Update from the Apple menu take care of it via the App Store.Download a standlone updater (541MByte) to take you from 10.8.2 to 10.8.3Download the Combo updater (794MByte) to take you from any earlier OS X 10.8 flavour to 10.8.3

Unless you have a bandwidth-related reason not to go for the biggest download, I recommend you go for the Combo updater.

It's worth having around even if you only have one Mac, in case you need or want to reinstall Mountain Lion.

With the most recent Combo updater handy, you can install plain old OS X 10.8 and then leap in one bound to the latest point release.

Apple, as usual, links to its regular landing page for security updates, knowledgebase article HT1222.

But that page, as usual, is lagging behind the actual update situation, with the most recent entry (as at 2013-03-15T20:40UTC+11) being Apple's Java security fix from 04 March 2013.

? If anyone at Apple is reading this, please beg your product managers to reorganise their update workflow so that the security notifications go live at the same time as, or before, the actual updates are published. After all, you invite your users to visit HT1222 from the start; I suggest that it'll be much easier to persuade people to be early adopters if you have all your informational ducks in a row from the start.

Having said that, the version-specific security update page is live, and can be found at knowledgebase article HT5672.

On security grounds alone, the update sounds well worth applying quickly.

There are fixes for 21 CVE-listed vulnerabilities, 11 of which are documented as offering remote attackers the potential for arbitrary code execution.

There are also various fixes for problems relating to data leakage or incorrect authentication (which invariably leads to data leakage because it permits users to see things they shouldn't).

The most interesting bug-fix, however, is CVE-2013-0967, whereby "visiting a maliciously crafted website could allow a Java Web Start application to be launched automatically even if the Java plug-in is disabled."

It'll be something of a surprise for anyone who was relying on Apple's new-found strictness against Java to find that turning Java off in your browser didn't necessarily have the desired effect!

Since running Java applets exposes you to a whole additional raft of possible security holes, this fix reinforces my suggestion above that this is an update worth applying as soon as you can.

Another noteworthy update is that the amusing (if unfunny) "fIle colon slash slash slash" bug is now a thing of the past.

That was a flaw in Apple's background data recognition software, which aims to auto-highlight text such as URLs displayed by applications such as word processors, text editors, browsers and email clients.

If you typed "file colon slash slash slash" (which denotes a local URL, i.e. a file or directory on your computer) then you'd be OK.

But if you mixed the case in the word "file", for example as "FiLE", OS X would fail an overly-strict internal error check and the affected application would almost immediately crash.

Irritating, for sure. But not very severe, and in any case now a bug of the past.

Safari gets bumped up to version 6.0.3, just in case you hadn't already fetched that as a standalone update.

And Windows 8 can now much more easily be installed alongside OS X, thanks to an upgraded version of Boot Camp.

Lastly, if you have one of the newfangled Retina MacBook Pro laptops, the Mac-oriented website Macobserver.com claims that 10.8.3 will squeeze 20 minutes more out of your Mac's battery than 10.8.2 did.

That's about it.

As an early adopter, I grabbed the Combo update as soon as I could and applied it.

I haven't had any trouble...yet, so I'll give you a cautious "thumbs up" to go ahead right away.

If you're an early adopter too, and you've grabbed 10.8.3 already, please let us know in the comments how you got along.

Your observations will help those who are still nervous of large-sounding point updates to make up their minds...

Follow @duckblog

NB. The Snow Leopard (10.6.8) and Lion (10.7.5) updates aren't full-on point updates. They're designated Security Update 2013-001 instead, and include all the 10.8.3 security fixes mentioned above. Like all updates explicitly labeled "security update", they're implicitly recommended for immediate deployment.

View the original article here

High-rolling gambler uses casino's own surveillance system to scoop $32 million...

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 high-rolling gambler has allegedly won $32 million at a casino in Melbourne, Australia, thanks to a little network hackery carried out by accomplices.

Games like poker are much easier to win if you know some or all of your opponents' cards.

After all, it's hard to sustain a bluff if the person you're bluffing has actually seen your hand.

In this case, the un-named "whale" - casino argot for a player who wagers large amounts of money, often on giant-sized individual bets - is said to have relied on his accomplices to feed him information about what other players at his table were holding.

His accomplices were able to snoop on the other players because they had remote access to the casino's own surveillance system, giving them a bird's eye view from CCTV cameras right inside the high-rollers' room.

The $32 million was apparently scooped in the course of eight big-stakes hands.

To increase their chance of catching cheaters (and thereby, no doubt, to discourage gamblers from trying to cheat in the first place), casinos typically have substantial networks of cameras giving high-quality, real-time video feeds.

So, this is an excellent reminder that the modern trend towards "big data" - where you hoover up as much information as possible, in as much detail as you can manage, about as many of your customers as you can - cuts both ways.

"Big data" can not only help to uncover patterns that expose fraud and criminality, but also end up enabling it.

(Why would you needs a miniature camera cunningly mounted on an ATM to skim PINs from unsuspecting users, if you could just hack into a shopping mall's CCTV system and let someone else's camera do the work?)

By the way, do you have video surveillance in your workplace?

If so, how well do you protect your own CCTV network, which may very well include proprietary software and equipment, from prying eyes?

It's not just your employees' privacy that's at stake, but possibly also (as the Melbourne casino found out) the financial health of your business...

Follow @duckblog

View the original article here

Reuters journalist who allegedly conspired with Anonymous hackers is suspended

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 Reuters journalist has been indicted by a US federal grand jury for allegedly handing over the login credentials of his former employer, Los Angeles Times parent company Tribune Co., to people claiming allegiance to the hacker movement Anonymous.

Reuters.com, which currently employs 26-year-old Matthew Keys as a deputy social media editor, suspended him with pay on Friday.

An employee at the company's New York office said that Keys's workstation was being dismantled and that his security pass had been deactivated, according to subsequent reporting from Reuters.

The US Department of Justice announced the indictment [PDF] on Thursday.

Keys was indicted on three criminal counts:

Conspiracy to transmit information to damage a protected computer, Transmitting information to damage a protected computer, and Attempted transmission of information to damage a protected computer.

Prosecutors claim that Keys promised to give hackers access to Tribune Co. websites, and that one went on to deface a story on the company's Los Angeles Times website.

From a Department of Justice statement:

"Keys identified himself on an Internet chat forum as a former Tribune Company employee and provided members of Anonymous with a login and password to the Tribune Company server... After providing log-in credentials, Keys allegedly encouraged the Anonymous members to disrupt the website."

The exact wording of said encouragement, according to the indictment, being Keys telling the hackers to "go f**k some s**t up."

On Thursday, Keys tweeted that he had found out about the indictment the same way most of us did: via Twitter.

I am fine. I found out the same way most of you did: From Twitter. Tonight I'm going to take a break. Tomorrow, business as usual.—
Matthew Keys (@TheMatthewKeys) March 14, 2013

The story told by court filings is of a disgruntled former employee who acted as a double agent with Anonymous hackers, working both with them and against them.

The case began in December 2010, when Keys allegedly provided the login credentials for a computer server belonging to KTXL FOX 40's corporate parent, the Tribune Company.

The indictment maintains that Keys identified himself on an Internet chat forum as a former Tribune Company employee and that he handed over a login and password for the server.

According to the indictment, the hacker ultimately defaced a Los Angles Time news story, changing its headline, byline and sub-headline to include the name "CHIPPY 1337".

Also, a line in the article was changed to read:

"House Democratic leader Steny Hoyer sees 'very good things' in the deal cut which will see uber skid Chippy 1337 take his rightful place, as head of the Senate, reluctant House Democrats told to SUCK IT UP."

The indictment further claims that Keys chatted with the hacker who claimed credit for the defacement, offering to try to regain access for him after system administrators fended off the hacker and locked him out.

When he learned of the hacker's ultimate success in defacing the Los Angeles Times page, Keys allegedly responded, "nice."

It's a long and twisty story, involving famed (and subsequently busted) former Anonymous top dog Sabu having outed Keys back in March 2011.

http://tinyurl.com/mattkeysexposed AESCracked/Matt Keys was former producer for Tribune sites. Gave full control of LATimes.com to hackers.—
The Real Sabu (@anonymouSabu) March 22, 2011

Buzzfeed has done a great job of pulling together all the intricacies of Keys's story, including an image of the defaced Los Angeles Times new story, a blog post from Keys about losing his job at the local FOX Affiliate in Sacramento, California, and more, including this statement from Keys's current employer, Thomson Reuters:

"We are aware of the charges brought by the Department of Justice against Matthew Keys, an employee of our news organization... Thomson Reuters is committed to obeying the rules and regulations in every jurisdiction in which it operates. Any legal violations, or failures to comply with the company's own strict set of principles and standards, can result in disciplinary action. We would also observe the indictment alleges the conduct occurred in December 2010; Mr. Keys joined Reuters in 2012, and while investigations continue we will have no further comment."

Will Keys get fired from Reuters? Should he?

Buzzfeed checked in with a Reuters employee who said that yes, if Keys is found guilty of divulging login credentials while at Reuters, he will have violated the company's Trust Principles, which is grounds for immediate dismissal.

What if Keys is found guilty of working with Anonymous only before Reuters hired him?

It's hard to imagine any reputable news venue countenancing the type of betrayal alleged in these charges.

If I were a Reuters editor or lawyer, I'd be finding ways to ensure Keys didn't come back from his suspension in the eventuality of a guilty verdict.

This case may look a little muddy given that journalists working undercover can act as double agents, but the fact is, Keys wasn't working for the news outlet at the time of the breach he allegedly helped to bring about.

As far as what non-journalists can take away from this, the lesson is this: priority No. 1 should be to shut down accounts for terminated employees.

Shuttering accounts should be a priority, but it often isn't.

You can't assume that a disgruntled former employee won't open up your systems to spammers, plant malware, or replace the CEO's presentation with porn.

If found guilty, Keys is looking at a maximum of 10 years in prison and a fine of up to $250,000.

Follow @LisaVaas
Follow @NakedSecurity

View the original article here

Google Glass pre-order scammers set up shop on the web

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 this week, Naked Security writer Lisa Vaas wrote an opinion piece about Google Glass privacy concerns.

The story received some lively comments, but here's one that caught my eye when I found it sitting in Naked Security's moderation queue.

Someone with a Brazilian email address, and going by the name of "YIN", had left a message in Chinese, pointing to a website that suggests it is related to pre-orders of Google's new magic glasses.

Some helpful folks at Sophos kindly translated the message for me:

"This service is available for sale. I've done my part."

We chose not to approve the comment, but when we visited the link we were taken to a professional-looking website - googleglass-?presale.com - which appeared to be attempting to extol the virtues of Google's internet-enabled headgear.

So, is this a legitimate Google website? Judging by the WHOIS information, it's run by a guy in Brazil - and he's only just created it.

Of course, it's very possible that the WHOIS information for this site has been populated with bogus informastion - and the person referred to has no connection with the site, or what it attempts to be doing.

But one thing's for certain. It doesn't look like the site is an official one run by Google.

And I doubt that Google is leaving comment spam (in Chinese) to promote Google Glass pre-orders on third-party blogs and news sites either.

Should you not care about these tiny details, you might want to do what the website tells you to do, and pre-order Google Glass for them for $499 (plus tax) via PayPal.

Strange. I feel sure that Google would have encouraged me to use Google Checkout instead.

As the hype around Google Glass continues to grow, it's inevitable that more and more scammers will emerge trying to make a quick 500 bucks from unwary internet users.

So, there's nothing more to say than... keep them peeled. :)

Follow @gcluley

View the original article here

Has HTTPS finally been cracked? Five researchers deal SSL/TLS a biggish blow...

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.

Cryptographers have once again put SSL/TLS (that's the padlock in HTTPS) in their gunsights and opened fire.

This time, they've done some severe damage.

The attack they've devised doesn't work against all possible ways that TLS can be used; it requires you to capture somewhere between millions and billions of connections that all contain the same plaintext; and it only works well for the first 200 bytes or so of the transmitted data.

Nevertheless, it reveals a deep-rooted problem in using the RC4 encryption algorithm to secure your TLS traffic.

"Wait a moment," I hear you saying. "RC4 is a symmetric cipher, meaning that it uses the same key to encrypt and decrypt. TLS relies on public key cryptography, based on public/private key pairs. So how can RC4 affect TLS?"

The answer is that public key encryption is much too slow for scrambling all your network traffic, so TLS uses a hybrid approach.

You use your public/private key pair only when setting up a TLS connection, as a secure way to negotiate a random session key you can use with a symmetric cipher.

Once both ends of the connection have secretly agreed on a secret key, the actual data you want to exchange over TLS is conventionally encrypted using a regular, symmetric cipher.

There are many ciphers to choose from: OpenSSL, for example, supports AES, Blowfish, DES, Triple-DES, RC4 and many more.

Wait a moment," I hear you saying. "RC4 has known flaws sufficiently serious that they blew apart the WiFi encryption system known as WEP. So how can RC4 still be around for securing web traffic?"

The answer is that RC4 shouldn't be around.

Experts have recommended avoiding it completely, at least for any newly-written applications, for several years.

But replacing or banning RC4 in existing cryptographic implementations is a much trickier problem.

Indeed, according to the authors of of this latest research, RC4 is the cipher chosen for about half of all TLS traffic.

So it's the part of TLS they decided to attack.

The researchers also decided not to give their attack a groovy name like BEAST, or Lucky Thirteen, claiming that "naming one's attacks after obscure Neil Young albums is now considered passé."

Instead, the paper they're working on (the full details aren't out yet, as the researchers are still working with vendors on countermeasures) is known as AlFardan-Bernstein-Paterson-Poettering-Schuldt (AlFBPPS), being the authors' names in alphabetical order.

RC4 is a stream cipher, so it is basically a keyed cryptographic pseudo-random number generator (PRNG). It emits a stream of cipher bytes that are XORed with your plaintext to produce the encrypted ciphertext.

To decrypt the ciphertext, you initialise RC4 with the same key, and XOR the ciphertext with the same stream of cipher bytes. XORing twice with the same value "cancels out", because k XOR k = 0, and because p XOR 0 = p.

Stream ciphers are handy for general-purpose network protocols because they can encrypt a single byte at a time, rather than processing only fixed-size multibyte blocks, so input data never needs to be padded.

? A PRNG can offer high-quality randomness without being cryptographic. Mersenne Twister, for instance, produces excellent random numbers from a starting key, known as a "seed". But if you know any 64 successive outputs of the algorithm for any given seed, you can reconstruct the internal state of the PRNG at that point and predict all future outputs, without ever knowing the seed. A cryptographic PRNG sequence can only be reconstructed if you know the starting key.

The problem is that although RC4 is a cryptographic PRNG, it's not a very high-quality one.

For more than a decade, we've known that it produces statistically anomalous output, at least early on in each stream of cipher bytes.

In 2001, Israeli cryptographers Itsik Mantin and Adi Shamir published a seminal paper entitled "A practical attack on RC4".

(Adi Shamir is the S in RSA; the R in RC4 is Ron Rivest, who's the R in RSA.)

Their paper is brief, but more than enough to undermine RC4's claim to randomness.

In particular, Mantin and Shamir examined the second output byte produced in any RC4 cipher stream, and found that the value zero turned up twice as often as it should:

You should see a zero as the second RC4 output once for every 256 keys on average; Mantin and Shamir showed that you would see it with a probability of 1/128.

This result, incidentally, was the basis of the attack that broke WEP, the original encryption protocol used in Wi-Fi networking, and forced its replacement with a newer encryption system called WPA.

AlFBPPS went much further than anyone else had done with RC4.

They produced statistical tables for the probability of every output byte (0..255) for each of the first 256 output positions in an RC4 cipher stream, for a total of 65535 (256x256) measurements.

By using a sufficiently large sample size of differently-keyed RC4 streams, they achieved results with sufficient precision to determine that almost every possible output was biased in some way.

The probability tables for a few of the output positions (which are numbered from 1 to 256) are show below.

(In a truly random distribution, each probability would be 1/256. The numbers here are multiplied by 256, so that each value ought to be 1, and the lines in the graphs should be perfectly horizontal at Y=1. Given a large enough sample size, any deviation from 1 reveals a statistically-exploitable anomaly in RC4.)

The authors realised that if you could produce TLS connections over and over again that contained the the same data at a known offset inside the first 256 bytes (for example an HTTP request with a session cookie at the start of the headers), you could use their probability tables to guess the cipher stream bytes for those offsets.

As Dan Bernstein very concisely put it at the recent Fast Software Encryption 2013 conference:

Force target cookie into many RC4 sessions. Use RC4 biases to find cookie from ciphertexts.

Here's how it works.

Imagine that you know that the 48th plaintext byte, P48, is always the same, but not what it is.

You provoke millions of TLS connections containing that fixed-but-unknown P48; in each connection, which will be using a randomly-chosen session key, P48 will end up encrypted with a pseudo-random cipher byte, K48, to give a pseudo-random ciphertext byte, C48.

And you sniff the network traffic so you capture millions of different samples of C48.

Now imagine that one value for C48 shows up more than 1% (1.01 times) more frequently than it ought to. We'll refer to this skewed value of C48 as C'.

From the probability table for K48 above, you would guess that the cipher byte used for encrypting P to produce C' must have been 208 (0xD0), since K48 takes the value 208 more than 1% too often.

In other words, C' must be P XOR 208, so that P must be C' XOR 208, and you have recovered the 48th byte of plaintext.

The guesswork gets a little harder for cipher stream offsets where the skew in frequency distribution is less significant, but it's still possible, given sufficiently many captured TLS sessions.

AlFBPPS measured how accurate their plaintext guesses were for varying numbers of TLS sessions, and the results were worrying, if not actually scary:

However, given the huge number of TLS sessions required, The Register's provocative URL theregister.co.uk/tls_broken might be going a bit far.

Initiating 232 (4 billion), or even 228 (260 million), TLS sessions, and then sniffing and post-processing the results to extract a session cookie is unlikely to be a practicable attack any time soon.

If nothing else, the validity of the session cookie might reasonably be expected to be shorter than the time taken to provoke hundreds of millions of redundant TLS connections.

On the other hand, the advice to avoid RC4 altogether because of its not-so-random PRNG can't be written off as needlessly conservative.

If you can, ditch RC4 from the set of symmetric ciphers your web browser is willing to use, and your web servers to accept.

Go for AES-GCM instead.

GCM, or Galois/Counter Mode, is a comparatively new way of using block ciphers that gives you encryption and authentication all in one, which not only avoids the risky RC4 cipher, but neatly bypasses the problems exposed in the Lucky 13 attack, too.

Easy for me to say, to be sure, but dropping old ciphers, especially those with known problems, is always the best plan.

Follow @duckblog

PS. If you run a website and you have already dropped TLS-RC4 support, please leave us a comment below to say whether any of your visitors were inconvenienced as a result. Did anyone complain? Did it cost you any transactions?

View the original article here

Germans bombarded in malware attack, shipment firm caught in crossfire forced to suspend email address

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 particularly vociferous malware campaign has been forcefully spammed out in the last 24 hours, targeting German internet users.

The malicious emails, which have are intercepted by Sophos security products, contain an attachment which pretends to be a PDF file, and claim to come from an air shipment company and use the subject line "Luftfrachsendung AWB".

Here is an example of a typical email that was intercepted by the team at SophosLabs:

Hallo,

anbei der AWB bitte bestätigen ob alles Ok ist.

Danke

Mit freundlichen Grüßen

Attached to the emails is a file called AWB-Avis 123-12345678.pdf.zip (the numbers can vary) which carries the malicious payload.

Sophos products detect the attack as the Troj/Agent-AAJO and Troj/Agent-AANK Trojan horse.

Astrid, one of the translators here at Sophos, tells me that the German used in the emails isn't perfect (which might help raise suspicions) - but here's a rough translation for non-German speakers:

Hi,

Please confirm the enclosed AWB is OK.

Thank you

Yours sincerely

What makes the attack stand out from all of the other attacks that we have intercepted in the last few days is its sheer scale, dwarfing all the other malware attacks that SophosLabs has seen sent out via email in recent days.

The shipping company referenced in the email has posted a message on its website saying that it has had to suspend its normal info@ email address because of the sheer number of emails it is receiving, and has offered an alternative address for contact instead.

ATTENTION! Email Spam and Virus warning: Unknown parties are currently sending large quantities of spam emails with the false sender address of info@first-class-zollservice.de. The subject line reads "Airfreight shipment AWB". The email has an attachment that is infected with a Trojan!

We therefore advise that if you receive such an email, you delete it without opening. Please do not try to open the attachment!

For this reason, the info@email address has been disabled info@first-class-zollservice.de until further notice. You can contact us in the meantime, using the email address "24stunden@first-class-zollservice.de"

You have to feel some sympathy for an innocent company which has had its business disrupted by a cybercriminal scheme.

Make sure that you are reducing the risk of your computers being infected by malware in an attack like this.

As well as keeping your wits about you, and ensuring that you and your colleagues never open unsolicited attachments, always ensure that all of your computers are running up-to-date anti-virus software.

Follow @gcluley

View the original article here

PWN2OWN results Day Two - Adobe Reader and Flash owned, Java felled yet again

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: Adobe, Adobe Flash, Apple, Apple Safari, Featured, Firefox, Google, Google Chrome, Internet Explorer, Java, Microsoft, Oracle, PDF, Security threats, Vulnerability

PWN2OWN 2013 is over.

Day Two ended in a similar fashion to Day One, with everyone who went in to bat slugging the ball into the crowd.

Yesterday, all the mainstream browsers (sorry, Opera fans!) except for Safari fell, though no-one actually tried Safari and failed.

Java fell three times yesterday, though under the contest rules, only the first attacker was due to win the $20,000 prize.

But in a fit of largesse, the sponsors announced that they'd pay up not just to the first successful attacker in each category, but to everyone who popped any of the products:

That put a biggish additional lump of cash on the table, with two more Java attacks to pay out on from yesterday ($40k), and a possible $100k extra if Pham Toan's scheduled attack on IE 10 worked out.

As it happened, IE 10 wasn't owned today.

From the results shown below, it looks as though Pham didn't actually make his attempt, as he's no longer listed at all, not even as trying and failing.

But a pre-registered contestant named Ben Murphy stepped up instead.

Not in person, but through a proxy (I assume this means a human proxy appearing live but following Ben's instructions), who successfully popped Java for a fourth time in the competition.

The final results look like this:

With HP's announcement that everyone will get paid for each attack, the prize monies will be divvied up as follows:

James Forshaw: Java = $20KJoshua Drake: Java = $20kVUPEN Security: IE10 + Firefox + Java + Flash = $250kNils & Jon: Chrome = $100kGeorge Hotz: Adobe Reader = $70kBen Murphy: Java = $20k

The total damage to the prize fund comes out at a whopping $480k.

That's only a fraction of the $p million that Google put up independently for its own Pwnium competition, held in parallel.

That was a chance to hack Chrome OS, Google's locked-down/open-source "browser is the operating system" platform that is largely based around the Chrome browser.

Chrome OS, like Android, is built on a Linux base.

In a similar way that Android has been adapted to suit mobile applications on phones and tablets, Chrome OS is adapted for web applications and the cloud.

Google will no doubt be rejoicing, from both a financial and a marketing point of view, because no-one managed to own the Chromebook (Google's name for laptops designed to run Chrome OS) used in the Pwnium 2013 contest.

And that ends the fun-and-games at this year's CanSecWest conference.

Now all that remains is to discuss whether this sort of "hacking as a professional sport" is the right way to encourage vulnerability research.

Is this competitive approach to vulnerabilities and exploits creating a market for malware that might end up out of control?

Or is it simply matching willing sellers with willing buyers, with some of the the edginess of sports-like competition thrown in?

Let us know your opinion in the comments below...

Follow @duckblog

Tags: Adobe, cansecwest, chrome, Exploit, Firefox, flash, IE, Java, Pwn2Own, reader, Safari, vulnerability

View the original article here

Google Doodle celebrates Douglas Adams and HHGttG - remember, "DON'T PANIC!"

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.

Today's Google Doodle celebrates what would have been the 61st birthday of Douglas Adams, the British satirical author who gave the world The Hitchhiker's Guide to the Galaxy.

What started as a BBC radio show morphed into a book, which in turn became a series of books.

In true Adamsian style, the HHGttG series, as fans call it, is resolutely referred to as a trilogy.

(It comprises five books.)

Adams died in 2001, at just 49 years old, of a heart attack caused by an undiagnosed problem with his coronary arteries.

The HHGttG referred to in the radio show's title is a sort of intergalactic Wikipedia-meets-eBook travel guide for freeloading space travellers.

The Guide left behind a range of catch-phrases that have entered popular speech, notably amongst techies and geeks, because they apply so well to the vagaries of IT and IT support.

The best-remembered, and most frequently heard, are probably:

* Mostly harmless, which is how the Guide summarises Earth. (Even in an electronic travellers' Wikipedia, there are bound to be a few articles that are on the brief side.)

* Don't panic, written on the cover of the Guide "in large, friendly letters."

Regular Naked Security readers will have spotted irregular references to HHGttGisms in our articles, from my use of a giant DON'T PANIC logo in an article about a vulnerability that the media was blowing out of proportion, to Graham Cluley's perfectly purposeful deployment of the term hoopy frood, intergalactic slang for "cool dude."

As it happens, Graham's dip into the space traveller's argot related to another Google Doodle, back in 2010, when Google celebrated the 30th birthday of the game Pacman with a playable version on its search engine's home page.

Googlers, of course, are HHGttG fans of the first water, with an operating system distribution called Android, and even a short-lived series of mobile devices under the brand name Galaxy.

The Android in the Guide series is Marvin the Paranoid Android, a robot with a "brain the size of a planet" who is perpetually bored and depressed due to his untapped intelligence.

At a claimed 50,000 times smarter than a human and 30,000,000 times smarter than a live mattress, you can begin to see Marvin's point.

DON'T PANIC is an excellent guideline when it comes to computer security response, especially when malware is concerned.

Sometimes, what seems like an obvious response may be quite the worst thing to do.

That's been true since the earliest days of malware.

Boot sector viruses, like Michelangelo (which had its 21st anniversary just a few days ago on 06 March 2013), used to be the most common sort of infection.

And received wisdom said, "Format your hard disk - it's the quickest and easiest way to remove the virus."

Except, of course, that a regular FORMAT removed everything except the virus, which survived intact in your PC's Master Boot Sector, and could cannily outlive the reinstallation of DOS, the copying back of all your software, and the recovery of your data from backup.

Assuming you had a backup, that is.

Reimaging infected computers is much quicker and more reliable these days, but it's often overkill, and (if you need to do it en masse) can still take ages and be pretty inconvenient for your users.

Your best defence, as always, is not to get infected in the first place.

But even with the best will in the world, malware can slip through. If it does, always remember those two useful words.

Don't panic!

If in doubt, get in touch with someone you know (preferably someone you have actually met!) and trust...

Follow @duckblog

PS. I've been clicking around on the HHGttG Doodle, but I haven't yet found the button that, when pressed, illuminates a sign saying, "Do not press this button again." If there is such a click sequence, and you find it, please let us know in the comments!

View the original article here

$5 million class action lawsuit over LinkedIn data breach dismissed

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.

Any damage done to LinkedIn users over the massive June 2012 data breach was abstract, not actual, a US judge has ruled.

Thus did a $5 million class-action lawsuit against the networking site get dismissed, before the case ever breathed the air of a court trial.

The breach resulted in the compromise of 6.5 million users' passwords.

Within hours of the passwords being posted online, over 60% of the stolen passwords had been cracked.

Within days of the June breach, the lawsuit was filed on behalf of all users by two premium LinkedIn users in the US, Katie Szpyrka and Khalilah Wright.

It charged LinkedIn with failing to use basic industry standard security practices - a failing that, the plaintiffs claimed, led to the data leak.

Specifically, the suit claimed that LinkedIn didn't store passwords in salted SHA1 hashed format, thereby failing to adhere to its Privacy Policy's promise to use industry standard protocols and technology to protect personally identifiable information.

Here's what the security part of LinkedIn's privacy policy said at the time:

In order to help secure your personal information, access to your data on LinkedIn is password-protected, and sensitive data (such as credit card information) is protected by SSL encryption when it is exchanged between your web browser and the LinkedIn website. To protect any data you store on our servers, LinkedIn also regularly audits its system for possible vulnerabilities and attacks, and we use a tierone secured-access data center.

However, since the internet is not a 100% secure environment, we cannot ensure or warrant the security of any information you transmit to LinkedIn. There is no guarantee that information may not be accessed, disclosed, altered, or destroyed by breach of any of our physical, technical, or managerial safeguards.

It is your responsibility to protect the security of your login information. Please note that emails, instant messaging, and similar means of communication with other Users of LinkedIn are not encrypted, and we strongly advise you not to communicate any confidential information through these means.

Unfortunately for the plaintiffs, they failed to provide evidence of injury coming out of the breach that was "concrete and particularized," as well as "actual and imminent," US District Judge Edward J. Davila wrote in his decision (PDF).

The plaintiffs claimed to have gotten gipped after they ponied up the premium membership fee but then didn't get the industry-standard security the privacy policy promised.

The thing is, Davila responded, the plaintiffs didn't pay extra for that security, given that it was promised to both premium and basic (free) memberships alike.

Rather, what the premium account holders actually got in return for their fees were advanced networking tools and enhanced usage of LinkedIn's services, not great security.

He wrote:

The User Agreement and Privacy Policy are the same for the premium membership as they are for the nonpaying basic membership. Any alleged promise LinkedIn made to paying premium account holders regarding security protocols was also made to non-paying members.

Thus, when a member purchases a premium account upgrade, the bargain is not for a particular level of security, but actually for the advanced networking tools and capabilities to facilitate enhanced usage of LinkedIn’s services.

The [suit] does not sufficiently demonstrate that included in Plaintiffs’ bargain for premium membership was the promise of a particular (or greater) level of security that was not part of the free membership.

Besides, Davila said, the plaintiffs didn't even read the privacy policy to begin with (at least, they didn't allege to have read it in the suit), so how can they claim that they forked over the money for premium memberships based on what it claimed?

As far as injury goes, while Wright claimed that her password had been posted online, it didn't result in identity theft or somebody getting into her account, the judge said, so the claim of financial harm or injury just doesn't fly.

He wrote:

Wright merely alleges that her LinkedIn password was "publicly posted on the Internet on June 6, 2012". In doing so, Wright fails to show how this amounts to a legally cognizable injury, such as, for example, identify theft or theft of her personally identifiable information.

One lesson we can take from this is, apparently, that users have to take security promises and privacy policies with a grain of salt.

Beyond that, the nuances of whether a company will be found liable for security lapses, and the whys and why-nots, intrigue me.

I initially conjectured, when the lawsuit was first filed, that LinkedIn had its work cut out for it in defending itself. I was clearly wrong.

What do you think: should LinkedIn get off the hook this easily? Should a company be held liable for not meeting industry standards for security?

Please share your thoughts in the comments section below.

Follow @LisaVaas
Follow @NakedSecurity

Privacy Policy image from Shutterstock

View the original article here

Microsoft to patch security vulnerabilities on Tuesday - including some rated as "critical"

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.

Patch Tuesday is bringing seven security fixes, with Microsoft deeming four of them "drop-everything-and-fix-this-now" critical.

The patches are for Windows, Internet Explorer and Office, as well as a sprinkling for Windows Server and Silverlight.

Microsoft says that four of the patches will address "critical" vulnerabilities.

"Critical" is, of course, Microsoft's highest severity rating.

It covers self-propagating malware such as network worms or common-use scenarios in which code is executed without warning or prompt, such as when users open booby-trapped email or suffer drive-by attacks from maliciously rigged webpages.

In this patch go-round, Microsoft warns that critical flaws might allow for remote code execution on Windows, IE, Silverlight and Office.

Another critical vulnerability would allow for elevation of privilege on Office and Server Software.

Flaws rated "important" could lead to elevation of user privileges or the disclosure of user data or personal information.

On Microsoft's vulnerability executive summary page, the company says that two of the patches address publicly disclosed holes - in Windows and Exchange Server.

One of those two security updates, bulletin MS13-011, addresses a Windows vulnerability that would allow remote code execution via a boobytrapped media file, such as an .mpg; an Office document, such as a .ppt file containing a rigged and embedded media file; or maliciously crafted streaming content.

Hackers exploiting that vulnerability could gain the same user rights as the current user.

Bulletin MS13-012, an update for the second publicly disclosed vulnerability, fixes a Microsoft Exchange Server WebReady Document Viewing hole that could also allow remote code execution.

The problem here is with the security context of the transcoding service on the Exchange server when a user previews a maliciously crafted file using Outlook Web App (OWA).

Of course, as soon as Tuesday comes, malicious hackers will be glued to their screens. They'll be checking out Microsoft's patches and will get to work on code to exploit computers whose owners or system administrators haven't patched, pronto.

As for the vulnerabilities that have been publicly disclosed, well, those attackers have that much more of a head-start.

This month, as with every Patch Tuesday, the longer you wait to apply the security patches, the more time attackers will have to finesse, and launch, their attacks.

So don't delay: patch as soon as possible.

On the surface of it, March doesn't look half as gnarly as the monster-sized 57 updates that Microsoft dumped on our doorsteps in February.

But numbers don't tell the whole story. For every corporation, every patch brings the possibility of conflicts.

So this week, tiptoe gently around the support people. Lord knows they'll be busy making sure the place stays afloat.

Follow @LisaVaas
Follow @NakedSecurity

View the original article here

Helping users make better security decisions by design

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.

As a technically minded individual I fall into the same trap as many others. I obsess over implementation and every tiny detail when designing something, often everything but how users will interact with my creation.

Nearly ten years ago I was asked to help design the Sophos Email Appliance. More precisely, I was asked to represent the role of the user in the process.

This was one of the best decisions we ever made from a usability perspective. While the technical details of how we would securely provide technical support and auditing still had to be worked out, just as much time was being spent on how it would work for an administrator.

Many of the same processes were explained by Adam Shostack of Microsoft in the closing talk at Vancouver BSides last week.

Using Star Wars as an example, Shostack explained the importance of context in security prompts and guidelines for designing user experiences that make sense and lead to good security outcomes.

His team at Microsoft has created a wallet card for developers to use when designing security prompts to remind them to think carefully about all of the aspects involved.

The acronyms they chose are NEAT and SPRUCE. Not exactly the easiest to remember, but if you work with them everyday they might stick.

Is your security/privacy user interface:

(N)ecessary - Can you change the Architecture to eliminate or defer this decision?
(E)xplained - Do you explain everything necessary to make a good decision?
(A)ctionable - Have you determined the steps needed for the user to make the decision?
(T)ested - Is the UX NEAT for all experiences, both benign and malicious?

When you involve the user in a NEAT decision explain the follow six elements:

(S)ource - Clearly state who or what is prompting the user to make a choice
(P)rocess - Give the user actionable steps to follow
(R)isk - Explain what bad thing could happen if the user makes the wrong decision
(U)nique knowledge user has - Tell the user what information they bring to the table
(C)hoices - List available options and clearly recommend one
(E)vidence - Highlight information the user should use to inform their decision

While I don't use much software from Microsoft (my primary desktop is a Linux box) I have to agree that the NEAT/SPRUCE model results in superior outcomes.

Internet Explorer 9 and 10 do a fantastic job of presenting security information to users. If something is risky and not very important IE doesn't interrupt your workflow.

Better yet, applications like Office open files in a usable form while quietly warning you about disabled macros.

I can read/use the document safely and if something doesn't work the way I expect I notice the warning that contains a description of the risks of enabling active content in Office.

Security isn't always about buffer overflows, zero-days and the red menace "stealing ur corprate secretz".

Spending extra effort to only present usable, informative information to users can go a long way to protecting them and enabling them to make decisions that cannot be determined with more lines of code.

http://twitter.com/chetwisniewski

Road sign image courtesy of Shutterstock.

View the original article here