Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Apple and Amazon Security Flaws Led to My Epic Hacking

wired.com

Post reply on HN
Print view View original

41–50 of 264 posts

Re: How Apple and Amazon Security Flaws Led to My Epic Hacking

#41

Post by cstejerean »

danweber wrote: post #26
prawn wrote: post #12

Earlier quoted context omitted.

If you're trying to remote-wipe your computer so that a thief doesn't access your sensitive data, wouldn't you want the data to be lost permanently?

Could be. But that's a very different problem. Old-school computer security breaks things down into the CIA categories: Confidentiality is for things you want secret. Integrity is for things you want to not be altered. Accessibility is for things you want to be able to reach. Honestly, very little of data requires confidentiality. Yet that's what encryption is usually used for. I would, by an order of magnitude, rath…

Losing a laptop can and will happen at some point. At that point, if you don't have a backup you will lose access to your data period. Full disk encryption means nobody else will get to that data.

Keep an unencrypted backup in a secure location, not on a device you are bound to lose in a coffee shop or airport.

Re: How Apple and Amazon Security Flaws Led to My Epic Hacking

#42

Post by daigoba66 »

cheald wrote: post #15
danweber wrote: post #7

We need people to be able to regain access after losing a password, and we need only the right people to have that. This is a very hard problem. One thing that we should have is a "cool down" period. If you want to regain access to, say, your GMail account, then it will take 48 hours of waiting, and phone calls and emails will go out to your contacts before that is completed, so the real person has a chance to protes…

If you ever reach the point that your account is so hard to recover that it requires human customer service intervention, the recovery process needs to be tedious and thorough. "Okay, I'll need a notarized copy of a photo ID and once we have that, we'll give you a call to the number we have on file to confirm the change." It's not perfect, but it would require an extremely dedicated and targeted attack to bypass, as…

I agree, if you get locked out and need to regain access it should as hard as possible to get back in.

On the flip side, we perhaps need to come up with something better than usernames and password for authentication. There are plenty of services where I simply cannot remember my password and/or username. I'm getting better about writing them down inside a password protected master file. But for many of those services I rely on the account recovery procedures; a vast majority of which are vulnerable once the attacker has access to my e-mail inbox.

Re: How Apple and Amazon Security Flaws Led to My Epic Hacking

#43

Post by rdl »

graeme wrote: post #30
landr0id wrote: post #28

Earlier quoted context omitted.

Google has actually made it even less of a hassle by instead trusting a computer forever instead of having the session last 30 days [1]. This can be seen two ways though: less of a hassle for the user, and less secure. I wonder why Google doesn't give the option for the session lasting 30 days or forever. [1] http://i.imgur.com/A9Wu5.png

That's horrible. It was already very easy, I don't see the need.

You don't have as many computers as I do, or as long a password as I do, I suspect. Having to type a random long passphrase with special characters on the weird keyboards of multiple devices every month was a pain. Even worse, for devices I infrequently use, I ended up basically having to do this every single time I wanted to use the device.

Re: How Apple and Amazon Security Flaws Led to My Epic Hacking

#45

Post by DHowett »

danweber wrote: post #7

We need people to be able to regain access after losing a password, and we need only the right people to have that. This is a very hard problem. One thing that we should have is a "cool down" period. If you want to regain access to, say, your GMail account, then it will take 48 hours of waiting, and phone calls and emails will go out to your contacts before that is completed, so the real person has a chance to protes…

On Apple devices, I believe that remote wipe is "Change the encryption keys for the block storage. It's as good as random data now."

That might also be why a PIN is available for "stopping" the wipe. (As an aside: the group got what they wanted, and one of the members even seems remorseful: they have the PIN necessary to unlock the device, but this was never touched upon.)

At the very least, that is why iOS devices take split seconds to "wipe", as opposed to the time it would take to write thirty-two billion nul bytes to flash.

Re: How Apple and Amazon Security Flaws Led to My Epic Hacking

#46

Post by rdl »

spacemanaki wrote: post #22
irq wrote: post #5

Earlier quoted context omitted.

2-factor auth has been cracked before [1] and will be again until there is a standard on how to implement it. With implementations differing between companies, a cracker can play one org's weakness off another org. Like in this case, using the freely-available trailing 4 digit CC code from Amazon to get into Apple. If both companies agreed to a standard that made it obvious such practices were non-compliant, this wou…

> 2-factor auth has been cracked before I wish people would stop bandying this about as if there was an actual flaw in the 2-factor app or the protocol or crypto algorithms used. The linked breach was likely due to a social engineering attack on phone company support staff. Yes, it's concerning, and something Google and the phone companies should be investigating, but no, 2-factor auth wasn't "cracked." Someone who's…

Given your iCloud account and/or root on the PC paired to your iPhone, I think it would be possible to compromise your Google Authenticator app. At the limit, jailbreak the connected phone, but I think it could be done more simply (all you need to do is run the Authenticator app and see the screen within 60 seconds, which should be possible from a connected, paired Mac).

On Android, way way easier, due to lack of secure device storage. Just get a copy of the disk image and then you've got the seed too.

It's still better than a password, but not as good as an actually secure independent factor. Sadly the SecurID sucks.

Re: How Apple and Amazon Security Flaws Led to My Epic Hacking

#47

Post by rdl »

mechanical_fish wrote: post #6
brown9-2 wrote: post #2

It turns out, a billing address and the last four digits of a credit card number are the only two pieces of information anyone needs to get into your iCloud account. This is scary.

I have actual work to do, work that I have been putting off too long, so let's try crowdsourcing this question on HN: What should one try to do to protect against this? Hypothetical actions to take: Make sure that an email address that's doing double-duty as a login identifier for a given service is unique to the service and appears nowhere on the web or in outgoing mail. Take particular care to have a "recovery" ema…

Standard procedure when setting up MDM for a company is to disable iCloud. All remote wipe/etc. done by your own servers, not by Apple.

Apple is really bad at running online services. It's a shame that they short-sightedly decided to go to war with Facebook and Google (who are good at services and bad at hardware) rather than playing more nicely together.

Re: How Apple and Amazon Security Flaws Led to My Epic Hacking

#48

Post by evanmoran »

rdl wrote: post #43
graeme wrote: post #30

Earlier quoted context omitted.

That's horrible. It was already very easy, I don't see the need.

You don't have as many computers as I do, or as long a password as I do, I suspect. Having to type a random long passphrase with special characters on the weird keyboards of multiple devices every month was a pain. Even worse, for devices I infrequently use, I ended up basically having to do this every single time I wanted to use the device.

http://passwordsafe.sourceforge.net/

Then use dropbox to keep the .safe file synced across machines

Re: How Apple and Amazon Security Flaws Led to My Epic Hacking

#49

Post by btilly »

mechanical_fish wrote: post #6
brown9-2 wrote: post #2

It turns out, a billing address and the last four digits of a credit card number are the only two pieces of information anyone needs to get into your iCloud account. This is scary.

I have actual work to do, work that I have been putting off too long, so let's try crowdsourcing this question on HN: What should one try to do to protect against this? Hypothetical actions to take: Make sure that an email address that's doing double-duty as a login identifier for a given service is unique to the service and appears nowhere on the web or in outgoing mail. Take particular care to have a "recovery" ema…

Have a billing phone number. If a stranger tries to get access, call that phone number before you can get access.

This massively raises the bar for social engineering.

Re: How Apple and Amazon Security Flaws Led to My Epic Hacking

#50

Post by danweber »

prawn wrote: post #39
danweber wrote: post #26

Earlier quoted context omitted.

Could be. But that's a very different problem. Old-school computer security breaks things down into the CIA categories: Confidentiality is for things you want secret. Integrity is for things you want to not be altered. Accessibility is for things you want to be able to reach. Honestly, very little of data requires confidentiality. Yet that's what encryption is usually used for. I would, by an order of magnitude, rath…

Interesting - hadn't heard that CIA thing before. I run a business. A good deal of what is on my laptop I would put in the confidentiality category. I guess apps and settings would come under integrity.

Yeah, one of the points of CIA is to help you identify which problems you want to fix. A lot of business assets do require confidentiality, and you have to spend correspondingly more money and time dealing with it.
Post reply on HN