iPhone Attack Reveals Passwords In Six Minutes

angry tapir writes "Researchers in Germany say they've been able to reveal passwords stored in a locked iPhone in just six minutes and they did it without cracking the phone's passcode. The attack, which requires possession of the phone, targets keychain, Apple's password management system. Passwords for networks and corporate information systems can be revealed if an iPhone or iPad is lost or stolen."

Comments

Re:Well...

[intellitech]

Give them a break! It's not like they have billions of dollars in annual profit which could help them do some serious security R&D.

Apple's military-grade encryption, cracked

[broknstrngz]

Fb gurl'ir svtherq Nccyr jnf hfvat ebg13, abj jung?

Relies on Jailbreaking

[jgtg32a]

Root access is there anything it can't do?

Re:Relies on Jailbreaking

[broknstrngz]

This isn't about the phone, it's about the Keychain. I'm not sure whether the Mac version is identical or not, and whether FileVault uses it or not, but if both these conditions are met, it's bad. Really bad.

Re:Relies on Jailbreaking

[maxwell demon]

What about Firefox's password storing ability? At least if you use a (reasonably secure) master password, you shouldn't be able to crack it even on a machine with root access, right?
What about the Gnome password manager? Would you be able to crack that without knowing the user password?

But then, there's always the issue with a running session. You typically enter the master password only once per session, so if the attacker can break in while you are logged in/have the browser open (and already provided the master password), I guess the attacker could indeed access your passwords.

Re:Relies on Jailbreaking

[v1]

Whatever. Being root does not somehow magically allow you to decrypt abitary data.

The data decrypted isn't arbitrary. It's information the phone requires when it starts up. Therefore the phone itself has to have some way (usually protected by root privileged objects) to unlock that information.

Any phone, or computer for that matter, that has automatic login enabled has to make this sacrifice. The iphone auto logs in as user "mobile". OS X (and therefore iOS) has a very convoluted/obfuscated way to unlock the user keychain based on automatic login, but of course no matter how much they obfuscate it, it can be defeated given enough time and dedication, by people that are capable of reverse-engineering your binaries.

This isn't a security blunder by Apple, it's a necessary tradeoff made by any operating system that features auto login. The only way to strengthen this is by encrypting the actual key with the unlock code, but four digits isn't enough entropy to even be worth the effort. You might turn a 6 minute hack into a 7 minute hack if you're very lucky. And as others have pointed out, that's about as much inconvenience as users will tolerate in an unlock code.

Re:Oh, look, they sell something

[Suki I]

> Last year the institute began selling a Java phone application for securely storing passwords.

Oh, look, they sell something that makes the problem go away. Surprise, surprise.

If the problem is replicated by others, then their program is quite valuable.

Every single smart phone has same problem

[goombah99]

THink about it.... Do you enter a passwrod when start your phone? No? well then how is the built-in keychain locked? it's not. et might be encoded but the phone itself has to have the password. If you can jailbreak it or if like android, it's already jailbroken for you, then you have no password security.

Re:Every single smart phone has same problem

[clang_jangle]

THink about it.... Do you enter a passwrod when start your phone?

Of course I do. Any real geek probably has a password set, and a suitably short timeout. Still, physical access to any device trumps almost any security measure. The headlines scream "iPhone" but this can be done with any mobile device, once you have it in your possession.

Re:Every single smart phone has same problem

[Dare nMc]

physical access issues are more about getting full use of a device, not about getting to the secure data stored on the device. IE if they get ahold of my Laptop, I fully expect the thief to be able to get a windows login, and even a admin account up, but he isn't going to get my web/banking passwords from mozilla. Although I wouldn't be surprised if they can install a trojan that could get these on my next login, if the device were given back to me. But really 6 minutes after grabbing the device to have the passwords, that are claimed to be stored encrypted?

Better solution

[NEDHead]

I keep my list of passwords taped to the back of the phone...well, really, my password...which is just my name spelled backwards, but I cleverly spelled it the right way on my sticker.

Physical Access

[pitdingo]

If an attacker has physical access to a computer(PC, Server, phone, etc...), is there anyway to stop them? Is there really any unbreakable way to encrypt your data?

Re:Physical Access

[0123456]

Is there really any unbreakable way to encrypt your data?

Uh, yes. It's called a one-time pad.

And just encrypting your list of passwords with a decent master password would take a lot more than six minutes to crack.

But I'm guessing iThing users don't want to be entering a sixteen character random password on a touchscreen 'keyboard' each time they need to log in somewhere.

Re:Physical Access

[rainmouse]

It's easier to steal or loose your phone than it is to break into your home and steal your desktop and considering the majority of people use the same passwords for email, Facebook, Amazon shopping and online banking, I'd consider this a serious security breach. Yes you can call people dumb for not being tech savvy but isn't that the target audience for apple products? (I don't mean dumb, just non-technical minded folk)

Re:Physical Access

[0x537461746943]

Unbreakable as in the resources required would be very significant to get access... yes. Laptops that use pre-boot authentication have solutions to protect them as long as they are powered off when stolen. The problem with phones of any kind is that they are always powered on so a pre-boot authentication scheme does not work for them. Even if you tried to protect the key the device has to have it in memory to decrypt the data so there could be a way to get it. For those using "GOOD for Enterprise" instead of the built-in exchange functionality you are protected. GOOD is a separate app that requires a pass phrase to access the data. I don't really like this solution because it is not integrated but that is a benefit from a security standpoint.

Re:Physical Access

[gabebear]

The keychain on the iPhone is locked only by software restriction... it doesn't use encryption(there isn't any password to encrypt with). If you backup your iPhone with iTunes without enabling "Encrypt iPhone backup", then you will see all your saved keychain in plain text in that backup.

This attack relies on a jailbreak to get around the normal keychain software security measures... although once an attacker has root on a running system, nothing it safe.

Re:Physical Access

[natehoy]

Actually, if Apple had even encrypted the keyring decryption key with the passcode of the user, the default of a 4-number passcode means it would take up to 10,000 tries to get to the keyring. Still not terribly secure, but better than leaving the key hanging out of the ignition as things appear to be at the moment.

Re:Physical Access

[natehoy]

The problem with phones of any kind is that they are always powered on so a pre-boot authentication scheme does not work for them. Even if you tried to protect the key the device has to have it in memory to decrypt the data so there could be a way to get it.

You can still lock the phone and make the data inaccessible for any practical purpose.

Look at the Blackberry model.

  - Filesystem is encrypted by a long key.
  - Long key is present on the phone, but key is encrypted by the user's login password.

I have a moderately complex password controlled by a set of rules my company sets, and the phone locks itself after 15 minutes of non-use.

When the phone is locked, the OS still has access to the keyring so it can check my email and stuff, but I have no way of getting at any of that information because the user interface doesn't work until I unlock the phone.

If you try to unlock my phone and mess up the password ten times, the phone overwrites the long decryption key with garbage. It then proceeds to write garbage over the entire filesystem (rendering it indistinguishable from most of my corporate email, but I digress).

Re:Physical Access

[maxwell demon]

Now, is there any way to lock down a device with cryptography and not require authentication with a password, every time you pick it up?
No, there really isn't.

Yes, there is. For example, you could implant an RFID tag in your hand, and have the phone unlock by communication with the RFID tag, using a short-distance reader.
Well, you didn't say a practical way, did you?

Re:Physical Access

[mlts]

Yes. Compartmentalize the data into as many little pigeonholes as possible, and only have the cubbyhole open/mounted/decrypted that is being worked on at the moment. When done with it, dismount/encrypt it.

I do this with my laptop and TrueCrypt. If I'm done with my Quickbooks instance, I suspend the VM and dismount the partition the VM disks are in. Doing this is the only real way of ensuring security in case of physical compromise. Of course, in a lot of cases, one can't really dismount critical server services, or go VM happy on a corporate desktop, but keeping tasks separate and only mounting what is needed is a good way to minimize damage is a good practice.

Re:Physical Access

[Ferzerp]

This is mostly correct. But encrypted data *is* safe if the keys are not stored on the system in question as long encryption was implimented sanely.

Cupertino's enviroment...

[Anonymous Coward]

...isn't attractive to the best of breed programmers. It's hot, there's lots of traffic, the smog is so bad you can't see the sun. Not to mention the bizarre corporate structure and superstar status Apple thinks itself as. The internal security is hell, nobody is on the same page. Your pulled off one job to do another and someone else completes your job in a half-assed manner and then you get the blame. There's this high level of greed that permeates the top dogs, they are looking at locking down all their computers, turning them into consoles. I hope someone high up in Apple see's this and comes to fire me, I really do.

Re:Cupertino's enviroment...

[StikyPad]

Sounds like every job I've ever had.

Apple iOS File System Encryption

[jallen02]

In IOS >4 with a modern device (3GS or better, iPad included) this article is blatantly incorrect.

"The attack works because the cryptographic key on current iOS devices is based on material available within the device and is independent of the passcode, the researchers said.". Not true. In iOS4 they use a variant of PBKDF2 to generate an encryption key that is used along with the device key alluded to in this article to decrypt "class keys". The class keys are then used to access data at the various protection levels (Never, After First Unlock, Only When Unlocked). Each of those levels of data has a separate key. Those keys are required to decrypt the individual keys on each file. Each file has an encryption key set on it in the meta data (which means you do have to reformat your system and set a reasonable passcode).

Because of the PBKDF2 variant brute forcing is infeasible. Because of the device key you have to try this IN the device and are limited to Apple's hardware for forcing.

All of this is possible because Apple has an AES-256 hardware chip that blazes through crypto for that algorithm.

Remote wipe uses yet another key (the file system key). So each file encryption key requires a "Class key" and a "file system key" to be decrypted. Lose either one and the file system is history. So remote wipe is accomodated in newer versions of iOS by just forgetting the file system key.

In short, this article is not providing an accurate portrayal of "current/latest" devices. Though I am not sure how many people: Have the newer hardware, have iOS 4 AND have reformatted their filesystem to accomodate the required metadata.

Re:Apple iOS File System Encryption

[jallen02]

I feel I should clarify. The article summary is a bit misleading and the paper is not, exactly, misleading.

In the version of iOS they tested you have the option of encrypting your keychain entries using the mechanism I describe (which means they would come us as "protected"). And as the PDF article mentions they could not extract the device key (forcing a local brute force attack if you want the passcode set for the device). If the protection level is set to encrypt the keychain entry with the device passcode it can't be recovered through some flaw in the encryption (that we know about).

So the article is basically saying, "Gee we can access things that aren't flagged to be protected with the device passcode". Which is, well what any reasonable observer expected since that is exactly how it was described over a year ago. It is good to see a working implementation.

Apple's real flaw here is that they did not force this encryption for *everything*. Instead they rely on developers to pass in certain options when storing keychain entries (and or when writing files to disk). Without these options the data is, sadly, recoverable. Apple even only encrypts the Mail app out of the box, which does not set the best example. That said they are basically making a very technical commentary on design decisions by Apple and I think this point gets lost in all the scare mongering. It would have been much more coherent (but not have gotten as much PR) to simply make this clear straight away.

Re:Apple iOS File System Encryption

[fermion]

I will note that the first step is to remove the sim card. We see that once the sim card is removed, (assuming the phone is not on another network accesible to the owner) there is a large amount of time to break the phone. The six minutes is not an issue, so the lack of protection is not an issue. Arguably the real security flaw, and on most smart phone, is we are storing extremely sensitive data on devices with are easily lost or stolen, but without effective countermeasures.

The six minutes, and unencrypted passwords, are important because it allows criminals to steal low or unknown value assets and crack them at a rate such that the operation might still prove profitable. Clearly if this is no longer an issue that is a good thing. But that still leaves emails, browsing history, phone numbers, and other personal data. Again this may or may not be issue with only iphone. Android is easily rooted, and anything unencrypted should theoretically be available. I doubt email is encrypted.

This may be why corporate still prefers RIM. There are no consumer based compromises made for security.

Re:Apple iOS File System Encryption

[QuantGuy]

Your statements are generally accurate about how the iOS 4 cryptosystem works. However, they apply only when the applications in question are actually requesting data protection services from the OS. If an application doesn't require data protection, these restrictions won't be enforced. See this presentation from last year's WWDC (the person who posted it probably broke NDA, but whatever).

The Fraunhofer paper states that some types of sensitive materials could be obtained without the passcode. Hence the screaming headlines. But it is just as interesting to note that some items WERE NOT accessible without the passcode, which implies that they were protected using the data protection techniques you described (and as outlined in the PDF).

I think what happened here is that the items that the Fraunhofer researchers were able to access were related to apps didn't require data protection, OR the specific keychain items were marked kSecAttrAccessibleAlways or kSecAttrAccessibleAlwaysThisDeviceOnly. That's a guess.

If that's true, then all that is needed is for Apple to make a few minor code changes to the apps so that they observe the proper data protection policies.

iPhone 4 & iOS 4.2.1

[slb]

Oops, Should have not only read TFA but followed the links ! The paper from the Fraunhofer Institute linked in the article describes everything. (PDF 92 kB)

Physical control of a device

[Terwin]

Since when has anyone even vaguely knowledgeable about security had any illusion that a device is still secure when a hacker has physical control over the device?

I lock my phone so that I have privacy from casual curiosity/pranks, I fully expect that every password I have on the thing will need to be changed as soon as it is stolen.

Re:Well...

[Bert64]

On linux perhaps you can use the plaintext login password (which is not known to the system until the user logs in or you can crack the encrypted hash)...
On windows the authentication system is such that the encrypted hash (which is stored on disk) is actually sufficient to authenticate...

On a phone you won't typically enter a password to boot the device, so it has to store the key on the device somehow.

True Story

[DarthVain]

For a buddy's bachelor party we went white water rafting, and rented a huge cabin for the weekend. When we first arrived, we were all staking out beds (18 of us), and some of them were of the slide under the couch futon variety. While we were pulling one out, we found a woman's wallet from the previous occupants. It belonged to a girl in her early 20's that was clearly there partying it up. Her wallet contained everything, ID, credit cards, iPhone, etc.. (even a little white baggy of nose candy). Anyway the iPhone was locked, but one of the guys took it and said (his words not mine) "lets see how dumb this bitch is...". He typed 1,2,3,4 into the iPhone and nothing. Then he said, hey hand me her ID (which all the guys were checking out as she was rather hot), and then typed in her birthday as found on her ID into the iPhone... Click. Two tries. Her phone had plenty of photos of her and her girl friends which we all checked out. Anyway in the end we flushed her baggy, and using the contacts of her iPhone called up her Mom and some of her friends to get hold of her, told her we found her stuff, got her address and at the conclusion of our weekend mailed her stuff back to her. When we talked to her on the phone, we suggested she change her password to something a little stronger.

Moral of the story, 1) People pick stupid passwords anyway, you hardly need some sophisticated password cracking system in many cases, 2) don't loose your iPhone with a stupid password at a party resort unless you want a bunch of stupid guys ogling your photos... We also may have taken a photo of one of the guys on the toilet using her phone, not sure if that ever got erased or not...

Re:True Story

[t0p]

Anyway in the end we flushed her baggy

Is "flushed" the expression drug fiends use nowadays? We used to say "snorted"...

Re:True Story

[ephraimX]

...but if her password had been stronger, you would have been much less likely to be able to track her down. Maybe it's a reasonable compromise: some dudes see your pix, but you get your $600 phone back.

Re:Hey at least...

[Svartalf]

Considering that it has nothing to do with source code and more implementation of security (Crypto's easy...security's blindingly hard to get right...) combined with an ill-advised notion that it's secure and we should keep passwords on the iOS devices in the first place...

Passwords should NOT be so hard that you have to write the idiot things down. If it's complex, hard to remember, the human factor comes into play and you end up with stupidities like this- they're not the security you need to concern yourself as much as everyone seems to do with them.

Re:What

[Cronock]

Nobody says they're unhackable. I think youre thinking about the classic "macs are more secure" debate, which is much different. But nobody with an ounce of geek in them would stretch so far to say something is unhackable. Anything can be hacked when an appropriately skilled person is given enough patience, physical access, and the right tools.

Re:So....?

[natehoy]

The key is that, apparently, the iPhone has enough information onboard to decrypt the passwords. This is a huge mistake. It's like leaving the key in the lock on your house. I'm hoping this story is bullshit, or if it's true Apple can resolve this quickly in the next OS release.

Assuming the assertions in the article are true...

I can only compare this to the Blackberry, since I own one and have researched its security model. All information in the filesystem as a whole (including the keyring) is encrypted by a key that is itself encrypted by the passcode you set to log in to the device. The password has strength parameters set in (minimum 8 chars, one number, etc). The phone locks itself after 15 minutes of non-use. My company sets all of these parameters and I can't override them.

I can choose optional portions of the filesystem that can be outside the encryption (all or portions of any SD chips you install, your address book so you can make calls when the phone is locked, etc). But email and passwords and such are protected (unless you're stupid enough to put passwords in your address book and not encrypt the address book, of course).

So if you get your paws on my Blackberry and it's locked you have to figure out the password in order to decrypt the key that allows access to the filesystem and keyring. After 10 bad tries, the phone overwrites the decryption keys with garbage and then starts formatting the filesystem.

That's not to say it's 100% secure - if you pull the SIM the phone can never receive the "wipe" command (so you have 10 tries or you can attempt to copy the contents of internal soldered memory), and of course you can pull the SD chip and copy it so you can decrypt that at your leisure.

But, hell, it's at least difficult.

it is using the latest/current device.

[kangsterizer]

OR you could read the PDF which states CLEARLY:

"The results were taken from
a passcode protected and locked iPhone 4 with current firmware 4.2.1. "

That is the latest iOS and the latest iPhone, mind you.

http://www.sit.fraunhofer.de/en/Images/sc_iPhone%20Passwords_tcm502-80443.pdf

Soon to be rectified

[mswhippingboy]

Honeycomb and Ice Cream will offer full data encryption options.

Re:Well...

[WaffleMonster]

>>>I sure am glad that my right to pay steve 30% To be fair, Microsoft and Ubuntu linux password systems are not any more secure. Apple is no worse than they.

Bzzt... the correct answer is both operating systems are more secure.

If windows syskey is used properly via startup storage device, TPM or startup password the nt hashes are stored in an encrypted database.

Ubuntu uses salted sha512 for password encryption by default. The length of time it takes to crack a password depends entirely on the security of the password.

In neither case will either Windows or Linux operating systems give up the has material without credentials or bypassing the OS by accessing the storage device directly.

Re:Well...

[E IS mC(Square)]

And it takes more than 6 minutes to crack the passwords on them. What's your point?

[NOT] Every single smart phone has same problem

[JPyObjC Dude]

I have not heard of anybody successfully hacking a password protected Blackberry. Even with physical access. Maybe there is a way but it is probably too costly and time consuming to even consider. Definitely no such hack has been documented.

If anyboyd has any examples where a password protected BB is cracked, I would be interested to hear about it :)

- JsD