Google Search

Showing posts with label probably. Show all posts
Showing posts with label probably. Show all posts

Thursday, December 5, 2013

Would you tell Google your Wi-Fi password? You probably already did…

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...

Follow @duckblog


View the original article here

Thursday, August 23, 2012

Blizzard owns up to data haemorrhage - painful but probably not too bad

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.

Big-time online entertainment outfit Blizzard has just owned up to a data haemorrhage.

One silver lining here (and you know how much I like to find those in any security calamity) is that there doesn't seem to be any weasel-wording going on.

Blizzard president, CEO and co-founder Michael Morhaime himself has taken up his virtual pen to explain that:

Some data was illegally accessed, including a list of email addresses for global Battle.net users, outside of China. For players on North American servers (which generally includes players from North America, Latin America, Australia, New Zealand, and Southeast Asia) the answer to the personal security question, and information relating to Mobile and Dial-In Authenticators were also accessed. Based on what we currently know, this information alone is NOT enough for anyone to gain access to Battle.net accounts.

Blizzard strongly suggests - but manfully doesn't pretend to guarantee - that financial data such as credit cards, billing addresses, and real names weren't got at.

(As you can imagine, the conundrum at the heart of any breach is working out what didn't happen. Breaches invariably lead to a lot of "what ifs", including, "What if the crooks covered their tracks or left a false audit trail?")

A second silver lining is that Blizzard stored and managed its authentication data sensibly.

There are numerous ways to do this; Blizzard chose to use the Secure Remote Password (SRP) protocol, which offers the double whammy of in-transit security (like SSL/TLS or Diffie-Hellman-Merkle) and at-rest security (like hashing-and-salting).

Greatly, if not excessively, simplified, SRP uses public-key-crypto-style calculations so that:

* The client and the server are able to exchange authentication data securely.

* Data packets from an authentication session cannot be reused.

* No hashes or dictionary-attackable data are visible in the client-server exchange.

* The server never needs to write the user's password to disk.

* The server needs a copy of the user's password in memory only once, at password setup time.

In short: sniffing SRP traffic tells you nothing about the user's password, and stealing the server's authentication database doesn't directly reveal any password secrets either.

Nevertheless, since Blizzard's servers hold enough data to verify that you know your password and can type it in correctly at your end, anyone who has a clone of Blizzard's authentication system has what he needs to run a password-guessing attack.

So the usual advice applies:

1. If you chose unwisely, your password could be guessed quickly. Stop choosing unwisely!

2. It's worth changing your Blizzard password right away, even if you did choose wisely.

3. If you've used the same password elsewhere, change that one too, and don't reuse passwords again.

4. If you store authentication data for your users, using solid cryptography to protect it in case it's stolen is good, but not losing it in the first place is even better.

And, even though it doesn't get the data back:

5. If you do suffer a security breach, a sincere apology like Mike Morhaime's goes a long way.

Follow @duckblog
-

Thanks to Naked Security readers Krazymouse and Matt B for the heads-up on this story.


View the original article here