After watching the fabulous video, here's what I think I learned... (There's the mention that other OSes have "other attack vectors", but if this is the worst, well, it's a lot more trouble than starting FireSheep...)

https://www.youtube.com/watch?v=Oh4WURZoR98&t=56s
YouTube Mathy Vanhoef
KRACK Attacks: Bypassing WPA2 against Android and Linux

• Clones network on different channel
• then it only works on "improperly configured websites", like uk.match.com (edited)

https://www.youtube.com/watch?v=Oh4WURZoR98&t=1m11s
YouTube Mathy Vanhoef
KRACK Attacks: Bypassing WPA2 against Android and Linux

Quote:

"we make sure the victim can access the internet through our malicious network"

• Course I'm assuming this youtube dude knows what he's talking about
• Might be paper author?
• here's the real trouble:

https://www.youtube.com/watch?v=Oh4WURZoR98&t=1m52s
YouTube Mathy Vanhoef
KRACK Attacks: Bypassing WPA2 against Android and Linux

Quote:

Hacking app has to start "sending special wifi frames that can command android to connect to a different channel", which is the OS specific side of the vulnerability for Linux and Android.

• ^ And there's your issue. :wink: So not super simple, but not a copper wire tap either

And even then, you'll lose the https badge in your browser when you're on those "improperly configured sites". Not good, but not a wide-open Heartbleed either, if I understand it correctly.

Labels: encryption, security, wifi, wpa2

"At Least 500 Million Yahoo Accounts Hacked in Late 2014" via Macrumors.

Yahoo today confirmed that "at least" 500 million Yahoo accounts were compromised in an attack in late 2014, leaking customer information like names, email addresses, telephone numbers, birthdates, hashed passwords, and both encrypted and unencrypted security questions and answers.

Does this surprise anyone at this point?

You know, I think if I had a huge cloud company with hundreds of millions of users, I'd consider having at least three sets of teams writing at least the fascade of the software -- the server-side controller methods -- so I could rotate from one to another every sprint or so to throw off would-be hackers. As soon as they made progress hacking one, it'd be replaced by Team 2. By the time we got back around to Team 1, they'd have iterated once or twice, and the hackers would have to, if not start over, pivot. Or maybe any user would have an X% chance of bringing up Team 1, Y% 2, Z% 3 each time they started a session.

I'd likely do the same for the users' data, splitting them into into several different databases, and maybe rotating users back and forth. Several different architectures using several different databases, all pitching to a consistent UI and user experience. If you interface well, it's no problem.

I realize there are obvious downsides. Maybe Team 2 has a horrible design, and it's easily cracked. That is, I'm in some sense three times as likely to get hacked as before, even if it's a much smaller set of users that's compromised.

But even more importantly would seem to be to sniff your network traffic like heck to see when 500 million sets of birthdays had left the network. Bizarre.

Ultimately, though, RMS (hrm, apparently not Stallman) is on point: If it's on a computer, in a network, given enough time, it'll eventually be free to anyone else on that network. Networked zeroes and ones want to be free.

Labels: encryption, free, rms, security, yahoo

Daring Fireball, quoting the NY Post:

Master keys for every elevator in the city, major construction sites, subways and skyscrapers are being freely sold online, despite a city law that makes it illegal for unauthorized persons to possess them.

A New Jersey-based lock company is peddling an unlimited supply of New York City’s “1620” fire service keys on eBay at $15.50 for two.

Access to the Big Apple keys is sharply restricted. It’s unlawful for anyone other than firefighters, law-enforcement personnel, elevator contractors or inspectors and building owners to have them.

But a Post reporter bought two keys to the city with no questions asked from UltimateSecurityDevices.com, an online arm of Northeast Lock Corp. in Clifton, NJ.

Gruber's response:

This is, effectively, what the Department of Justice wants for the iPhone.

Here's the part that I think is widely underreported/argued/claimed, and it's painful to see Gruber skip over it: Networked devices aren't like physical ones in that there's not absolute geographical protection. If you want to break into my elevator, you at also have to be there. If you want to break into Director Comey's car trunk, you have to be beside his car. And I bet there's at least one camera on you.

I can't break into a NY elevator or Directory Comey's car trunk from overseas. But folks can break into your PC or phone more easily overseas than they can in your driveway.

Your "back door", if you have one, is accessible to anyone on the network, not just the guys who drive to your neighborhood. Joel Spolsky talks about barriers to entry. Actually having to get there is one of the biggest.

This is why I wrote, "A better neighborhood for our personal data". We have one small street, geographically speaking, with a billion-plus people all living there, their personal data exposed to any other unscrupulous schmoe living on our single street. A locksmith once told me that a lock keeps an honest man honest. A billion men aren't all going to be honest, man.

PS Google: Beetee Dub, I didn't write about better neighborhoods for our data in 2002, okay? Why can't Google index blogspot correctly? I've consistently seen search issues (or items that would pop up in blogger's interface when searching, but not on Google) with my blog. I mean, it is at least marginally in Google's own interest to support blogspot well, right? Right? /sheesh

Labels: encryption, gruber, networking, safety

MacRumors recently ran a story titled, Justice Department Calls Apple's Privacy Case Stance a 'Marketing Strategy', which seems pretty interesting on its face. Is Apple's denial to crack an iPhone simply to save face?

There has been a sort of conspiracy theory side to this that's well represented by Marco Arment's post on the topic:

It’s their excuse to establish precedent and permanent backdoors for themselves so they can illegally spy on anyone’s data whenever they please. They’re shamelessly using a horrible tragedy to get themselves more power.

And I gotta admit, when I first read it, I thought I bought it. But when you read through the government's motion to compel, you really don't see any of this. They say they don't have any problem with Apple having a clean room where they created fbiOS, and they can destroy fbiOS as soon as the phone's contents are extracted.

Which means part of this is a sort of developer's misunderstanding, both on Arment and Apple's parts, potentially. If you write this fbiOS that allows you to try as many passcodes as you'd like without fear of the OS wiping the phone once, and you know the FBI is going to be back asking for you to do it again, why would you destroy it? Wouldn't it take time to write it the right way again? Simple business math tells you to keep it all around for the next time.

And there's the only place where we have a backdoor problem. The backdoor fbiOS is going to live at Apple, and if it leaks, well, it's everywhere. Apple's going to have to play cat-and-mouse with its own fbiOS at some point if it leaks.

What's strange to me is that the FBI needs Apple to do this. I have to assume they'll compensate Apple for the time it takes to crack the phone, but why don't they already have this expertise in house? I realize iPhone-as-black-box is much tougher to crack than it would be for Apple, but it's scary that the FBI can't get into these things. Imagine what another nation state could do with their data. Our intelligence is pretty obviously going in blind.

More interesting to me, perhaps, is how the government flips the EULA that infects shrinkwrapping everywhere [that shrinkwrap still exists, which is, I guess, almost nowhere now]. If you say this software is yours, and you're going to control it to the point that you can change its features at any time, well, then it's still yours, capiche?

Apple designed, manufactured and sold the SUBJECT DEVICE, and wrote and owns the software that runs the phone -- which software is preventing the search for evidence authorized by the warrant. Indeed, Apple has positioned itself to be essential to gaining access to the SUBJECT DEVICE or any other Apple device, and has marketed its products on this basis.
...
Apple has designed the phone and software updates so that Apple's continued involvement and connection is required.

Ouch. Clever.

I still hate how badly the current FBI director doesn't understand the Internet [in his public comments], but Apple's losing this one, folks.

Labels: apple, encryption, privacy

From PCMag, but it's certainly not the only one (I caught it on the CBS Evening News last night. I know, I'm an old soul.)

Hollywood Presbyterian Medical Center has paid the ransom demanded by hackers after being under seige for more than a week.

The hospital paid 40 bitcoin ($17,000) to regain control of its computer network, Allen Stefanek, the hospital's president and CEO, said in a statement. Earlier reports put the ransom amount at about $3.4 million, but that was "false," according to Stefanek.

Staff began noticing "significant IT issues" on Friday, when the hospital declared an internal emergency. In the days since, computer-based tasks were carried out via pen and paper, hundreds of patients were diverted to nearby hospitals, and the Radiation and Oncology departments were temporarily shut down.

As I posted in a Disqus comment there...

It's time to ensure that patient information is not exposed on the Internet. I don't care if the answer is hospitals keeping their own intranet completely separate, moving data via physical device (my preference) or if we somehow come together to pay for a second, wholly physically-distinct "securenet", we've got to stop allowing companies to be so lazy with data and not hold them accountable for the poorly foresight.

The is the difference I don't think even James Comey, current head of the FBI, seems to understand when he parallels encrypted data with locked car trunks you can't open. When it's on the Internet, you've commoditized geography. Anyone who gets on the Internet, anywhere, can knock on your Internet networked data's door.

Come on, folks. It's past time to move our personal data to a better neighborhood.

Labels: encryption, hack, privacy

Labels: encryption, govt fail, privacy

I saw this report the other day and it confused me. My understanding is that the entire contents of an iPhone with a passcode (or pass phrase) are encrypted. If Apple can somehow decrypt the contents, then there’s a backdoor, and the possibility exists that someone else will discover the backdoor. (Let alone the problem of Apple being able to do it.)

Charlie Miller, who knows way more about this stuff than I do (and probably as much as anyone outside Apple), is also confused.

Charlie Miller ‏@0xcharlie

I'm still wondering about this: http://m.cnet.com/news/apple-deluged-by-police-demands-to-decrypt-iphones/57583843 … seems to say that apple can forensically examine iPhone 5 which shouldn't be possible

Thanks followers. Apple probably uses a signed ramdisk and then brute forces from there.

Labels: apple, cryptonomicon, encryption, security

The ATF's Maynard said in an affidavit for the Kentucky case that Apple "has the capabilities to bypass the security software" and "download the contents of the phone to an external memory device." Chang, the Apple legal specialist, told him that "once the Apple analyst bypasses the passcode, the data will be downloaded onto a USB external drive" and delivered to the ATF.

It's not clear whether that means Apple has created a backdoor for police -- which has been the topic of speculation in the past -- [or] whether the company has custom hardware that's faster at decryption, or whether it simply is more skilled at using the same procedures available to the government. Apple declined to discuss its law enforcement policies when contacted this week by CNET. [emph mfn]

Labels: apple, encryption, security

I finally stumbled onto a very simple solution tonight, vim. Vim is a text editor that was originally developed as vi for the Unix platform and has somehow managed to stave off death for over 30 years despite it’s draconian user interface. Amongst all the improvements and extensions over the years is the :X command. This encrypts the file you are working on with a password of your choosing.

The algorithm used is breakable. A 4 character key in about one hour, a 6 character key in one day (on a Pentium 133 PC). This requires that you know some text that must appear in the file. An expert can break it for any key.

Labels: encryption, privacy, problem solved, vim

This secured channel helps protect your search terms and your search results pages from being intercepted by a third party. This provides you with a more secure and private search experience.

Labels: encryption, Google, privacy