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

Well...

[fuzzyfuzzyfungus]

I sure am glad that my right to pay steve 30% of the price for everything I want to run on my iDevice is at least keeping me secure!

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.

Re:Well...

[Anonymous Coward]

To be fair, Microsoft and Ubuntu linux password systems are not any more secure. Apple is no worse than they.

Do you have a citation for this? It was my understanding that most keychains use the login password to encrypt the passwords rather than other data available on the device.

Re:Well...

[Lumpy]

Last I checked a android phone that has the same specs as my iphone cost the SAME AMOUNT or more.

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.

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

[Anonymous Coward]

As for cost - well my new Windows 7 desktop cost $200. Can I find an OS 10.6 mac for that price? Probably. If I search long enough (five years later) - see? Found one. ;-)

There you go again, trolling people who happen to hold a different set of values than you.

Which you are certainly free to do so. But don't be surprised when we exercise our freedom to call you what you are (a troll). Whining about how we're "censoring" your troll posts just makes you look immature.

Re:Well...

[E IS mC(Square)]

Are you saying they need to do some R&D on their own while they can just steal Nokia's hard work AND sue them too??

Re:Well...

[E IS mC(Square)]

Never challenge an apple fanboi with facts. It makes them say weirdest things.

Re:Well...

[E IS mC(Square)]

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

Re:Well...

[GooberToo]

I'm assuming he was ignorantly referred to the old SMB password mechanism where the hash, which was transmitted in the clear, in of itself is the password.

SAMBA supports it because they must for compatibility with Microsoft but even Microsoft long abandoned that approach specifically because it was so insecure and trivial to bypass. Accordingly, SAMBA has likewise moved on. Furthermore, SAMBA documentation makes it very clear that enabling backwards compatibility is very insecure and certainly not a good idea.

If that's not what he's referring to, then I can't imagine how he possible came to such a conclusion - as you rightly pointed out.

Re:Well...

[sew3521]

I do not see why this is voted -1. Commodore makes a good point about security...

Re:Well...

[perryizgr8]

stop being ridiculous! they don't need no R&D!! not when they can just steal stuff from companies that have invested lotsa $$ in research.

Re:Well...

[Anonymous Coward]

"R&D, to god-damned hell with R&D! We have no R&D. In fact, we don't need R&D. I don't have to show you any stinking R&D, you god-damned cabrón and ching' tu madre! Come out from that shit-hole of yours. I have to speak to you."

Apple's military-grade encryption, cracked

[broknstrngz]

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

Re:Apple's military-grade encryption, cracked

[Iphtashu Fitz]

Gurl'yy fjvgpu gb ebg39. Nsgre nyy, vg zhfg or zber frpher!

Re:Apple's military-grade encryption, cracked

[the_one_wesp]

Yea, well, mine's better, I use rot13 twice! Crack this, sucker!

Re:Apple's military-grade encryption, cracked

[sempir]

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

If they had of used Kant instead none of this would have happened. Jung is a prick.

Re:Apple's military-grade encryption, cracked

[Anonymous Coward]

Perhaps they should upgrade the cipher, to rot26. Such as my message is encrypted.

Re:Apple's military-grade encryption, cracked

[deblau]

Gurl'yy fjvgpu gb ebg39. Nsgre nyy, vg zhfg or zber frpher!

ebg39: vg'f whfg yvxr ebg13, bayl guerr gvzrf nf frpher! Xvaqn yvxr gevcyr QRF sbe qhzzvrf. Gur wbxrf jevgr gurzfryirf.

Re:Apple's military-grade encryption, cracked

[Red Flayer]

If they had of used Kant instead none of this would have happened. Jung is a prick.

Emmanuel Kant was a real pissant.

Should've used Hobbes.

Re:Apple's military-grade encryption, cracked

[Anonymous Coward]

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

Your hovercraft is full of eels?

Re:Apple's military-grade encryption, cracked

[goombah99]

Yea, well, mine's better, I use rot13 twice! Crack this, sucker!

I decrypted your message by applying ROT2 thirteen times.

Re:Apple's military-grade encryption, cracked

[cthulhu11]

Iä! Iä! Cthulhu Fhtagn!

Oh, look, they sell something

[Anonymous Coward]

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

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.

Re:Oh, look, they sell something

[Anonymous Coward]

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

Which wouldn't be necessary had Apple done their security right. Welcome to the free market.

Relies on Jailbreaking

[jgtg32a]

Root access is there anything it can't do?

Re:Relies on Jailbreaking

[Bigby]

Decrypt passwords in a typical Unix shadow file

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

[Anonymous Coward]

Decrypt passwords in a typical Unix shadow file

Which is not what was hacked. These were external passwords (eg. to your mail account.)

Re:Relies on Jailbreaking

[jbezorg]

But what the article didn't say was that the phone needed to be jailbroken by the original owner to start the process. Only that Jailbreaking is part of the process. Someone may infer that from your statement and that is not the case.

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

For evaluating the practical strength of iOS device encryption security, we assume an attacker with physical access to the device, e.g. accomplished by theft
or when finding a lost device. The assumed device is protected with a strong passcode, which is unknown to the attacker. The complexity of the passcode
does not play a role for this evaluation, but is assumed to prevent an attacker from gaining access by simply guessing. Also, it is assumed that the device has not been jailbroken and so all original iOS protection mechanisms are in place.

When the device is found, it is assumed to be in the locked4 state with activated data protection5. An unlocked device would provide the possibilities for
user space exploits and could reveal more secrets. However, this leakage could not be accounted to the protection mechanism we wanted to evaluate.

The attacker’s PC used to gain access to passwords has not been synchronized with the attacked device before. Therefore no secrets can be used by the attacker that are created between the owner’s PC and his device.

In the described situation, device encryption commonly should provide protection against attacks from the outside. If the device is still turned on — e.g., not
run out of battery meanwhile —, we assume that no remote wipe6 command was received in the meantime (e.g, theft remained unnoticed, no network connection, etc.). In any case, the attacker turns off the device and removes the SIM card to prevent a further remote control. In this described state, we have conducted our tests with iPhone 4 and iPad WiFi+ 3G hardware with the latest firmware 4.2.1.

Re:Relies on Jailbreaking

[Anonymous Coward]

But what the article didn't say was that the phone needed to be jailbroken by the original owner to start the process.

From the paper: http://www.sit.fraunhofer.de/en/Images/sc_iPhone%20Passwords_tcm502-80443.pdf [fraunhofer.de]
[...]
Also, it is assumed that the device has not been jailbroken and so all original iOS protection mechanisms are in place.
[...]

One of these things is not like the other, one of these things just does not belong...

Re:Relies on Jailbreaking

[Anonymous Coward]

Which is not what was hacked. These were external passwords (eg. to your mail account.)

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

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

[jbezorg]

But what the article didn't say was that the phone needed to be jailbroken by the original owner to start the process. Only that Jailbreaking is part of the process. Someone may infer that from your statement and that is not the case.

Context asshole. Quit living in a soundbite world.

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:Relies on Jailbreaking

[Anonymous Coward]

Huh. I guess a workaround would be to jailbreak yourself, install sshd, completely lock down the iphone so it can't be accessed remotely by anyone but the owner through ssh and then remove Cydia to prevent deinstallation/reinstallation of sshd. That would close off their access route.

Posting AC because I'm moderating.

Re:Relies on Jailbreaking

[TrancePhreak]

You can jailbreak an iPhone without knowing the unlock pin.

Re:Relies on Jailbreaking

[makomk]

But what the article didn't say was that the phone needed to be jailbroken by the original owner to start the process.

That's because, as the linked paper makes quite clear, this isn't true. The iPhone doesn't have to be jailbroken by the existing owner. The jailbreaking is done by the attacker as part of the attack process after the locked phone is obtained. The quote "Also, it is assumed that the device has not been jailbroken and so all original iOS protection mechanisms are in place" describes the state the iPhone is assumed to be in when obtained by the attacker, and is quoted in precisely the correct context.

Re:Relies on Jailbreaking

[Alsee]

Relies on Jailbreaking Root access is there anything it can't do?

Jailbreaking and root access can't do squat if things are properly encrypted.

The entire point of the is story is that the iPhone's encryption is done improperly. The encryption is done with a key sitting on the device, without involving your password at all. The iPhone is stupidly programmed to check if you entered the right password and then simply use the stored key to decrypt your data.

If you jailbreak you can skip the password check and directly use the decryption key. This is a massive case of D'oh! This is a perfect case of why "jail locking" devices or using DRM are powerful threats against security. Jail locking and DRM and Trusted Computing inherently involve invalid security assumptions. Any security model built on top of invalid security assumptions WILL fail rapidly, and it will fail badly.

Re:Relies on Jailbreaking

[Cronock]

Re-read what you're quoting before calling him an a-hole for being correct.
to paraphrase: the exploit can be accomplished using physical access, the device locked and not jailbroken. Make sure you're correct before throwing a tantrum.

Re:Relies on Jailbreaking

[CheerfulMacFanboy]

Root access is there anything it can't do?

According to the actual paper

Secrets within other protection classes, such as passwords for websites, could not be revealed in our lost device scenario. In our proof of concept implementation, these secrets — marked "protected" in Table 1 — were available to the script only after entering the passcode to unlock the device, which by assumption should not be possible for an attacker.

Re:Relies on Jailbreaking

[jbezorg]

#1 - "The article didn't say was that the phone needed to be jailbroken by the original owner to start the process."

True or False?

#2 - "Only that Jailbreaking is part of the process."

True or False?

#3 - "Someone may infer that from your statement and that is not the case."

Subjective.

[ Quoted text showing #2 to be true ]

Re:Relies on Jailbreaking

[jbezorg]

But what the article didn't say was that the phone needed to be jailbroken by the original owner to start the process.

That's because, as the linked paper makes quite clear, this isn't true.

Why do you stop reading at that point? Does "Only that Jailbreaking is part of the process." trigger some synaptic response where the text becomes invisible?

Are people so intent in proving someone else wrong on this forum that they latch onto a single statement and ignore the rest? Never mind, I know the answer to that question already.

Re:Relies on Jailbreaking

[profplump]

If you use the "Master Password" feature there is a system-level Keychain that contains the FileVault disk keys. Otherwise the two are unrelated; a user's Keychain file is actually inside the FileVault.

On OS X systems the Keychain API/etc. is more or less the same as on iOS but a user's Keychain encryption is based on the user's login password (or if different, the keychain password), so this same attack isn't feasible (unless you do something dumb like turn on auto-login and don't set a separate keychain password). The iPhone instead uses a system similar to the system-level Keychain on OS X -- there's some machine-specific data that's used as a key to prevent trivial opening of the file, but anyone with access to the original host can get that same data.

The solution to it is pretty simple -- require a password when the phone is booted -- but many people won't go for that. Apple could at least *allow* a Keychain password though.

Re:Relies on Jailbreaking

[CheerfulMacFanboy]

Decrypt passwords in a typical Unix shadow file

Which is not what was hacked. These were external passwords (eg. to your mail account.)

Errm, no. Mostly internal Passwords actually (which may actually be worse, like VPN & WiFi secrets), and not the Mail passwords (with one exception, surprise: MS Exchange):

http://www.h-online.com/security/news/item/Lost-iPhone-lost-passwords-1186579.html

Not all data was accessible however – Apple has added extended security features to iOS 4, which allow apps to improve the security of data on the file system and in the keychain by assigning them attributes such as NSFileProtectionComplete and kSecAttrAccessibleWhenUnlocked. These attributes cause the data to be encrypted, so that the iPhone cannot decrypt them without the user's passcode.

At present, however, few applications utilise this feature, which is only available on iOS 4 – even Apple's own apps barely make use of it. A significant exception is the Mail app, which uses the kSecAttrAccessibleWhenUnlocked attribute when saving passwords for accessing email. The password stealing demo was unable to decrypt these passwords. Interestingly, the password was not protected when, for example, a Google Mail account was addressed as an MS Exchange account. The researchers were also unable to access passwords saved in Safari.

Re:Relies on Jailbreaking

[jbezorg]

Part of the process is powering down and removing the SIM card to isolate the phone so it can't be accessed remotely by anything and prevent the phone from receiving the wipe command. Would your suggestion brick the phone with the SIM card removed? If it would, that's a suitable alternative.

BTW, I tried Norton Security for Android. The "Clear Data" button under app management cleared the remote wipe passwords too.

Uninstalled.

Re:Relies on Jailbreaking

[Cronock]

1. the article clearly states that the phone is NOT jailbroken by the original owner. It is jailbroken by the attacker. So, FALSE.

2. You're right that they say it's part of the process, but the CONTEXT of your sentence ("Only" being the key term) because they explain clearly when jailbreaking is used: False

Please, RTFA

Re:Relies on Jailbreaking

[Cronock]

#3. You were clearly stating something that was not true, possibly confusing people. Not really subjective.

Re:Relies on Jailbreaking

[jbezorg]

I did RTFA ( before I originally posted ) and I apologize. I had an "OMG! There's an argument on the internet!" moment.

"The article didn't say was that the phone needed to be jailbroken by the original owner to start the process."

I meant that in the literal sense. That the article never states that the phone needs to be jailbroken by the original owner to start the process. In the context of a response to the parent post titled "Relies on Jailbreaking" and what is the norm for Jailbreaking an iPhone entails and the lack of detail in where it fits in the process within the parent post. So I state it. I even post a quote from the white paper that says it does not. I though I was being pretty clear. Obviously not. Some people have reached the conclusion that I am implying that the phone needed to be jailbroken by the original owner to start the process.

I can't help but laugh at the irony considering the intent of my original post.

It's also interesting to see the-glass-is-half-full and the-glass-is-half-empty effect as my original post was modded up for a while. Some people apparently used the rest of my post to push the meaning of the first sentence into it's literal meaning. Others saw the conflict and pushed it into the implied meaning.

Re:Relies on Jailbreaking

[makomk]

Why do you stop reading at that point? Does "Only that Jailbreaking is part of the process." trigger some synaptic response where the text becomes invisible?

I read the entire paper linked. It's quite clear. In section 2, it describes the state that the iPhone is in prior to the attack: "it is assumed that the device has not been jailbroken" (amongst other assumptions, including the device being locked). Then in section 3 it describes the approach that the researchers used to attack the locked, unjailbroken device: "The first step is needed to be able to access the keychain database. This step depends on the device’s iOS version and hardware but in general can be achieved with a jailbreaking tool and by installing an SSH server on the device without overwriting user data."

Can you actually point me at anything in the paper that says the iPhone must be jailbroken by the owner prior to the attack, or are you just trolling?

Re:Relies on Jailbreaking

[jbezorg]

I will repost my response to Cronock

"The article didn't say was that the phone needed to be jailbroken by the original owner to start the process."

I meant that in the literal sense. That the article never states that the phone needs to be jailbroken by the original owner to start the process. In the context of a response to the parent post titled "Relies on Jailbreaking" and what is the norm for Jailbreaking an iPhone entails and the lack of detail in where it fits in the process within the parent post. So I state it. I even post a quote from the white paper that says it does not. I though I was being pretty clear. Obviously not. Some people have reached the conclusion that I am implying that the phone needed to be jailbroken by the original owner to start the process.

I can't help but laugh at the irony considering the intent of my original post.

It's also interesting to see the-glass-is-half-full and the-glass-is-half-empty effect as my original post was modded up for a while. Some people apparently used the rest of my post to push the meaning of the first sentence into it's literal meaning. Others saw the conflict and pushed it into the implied meaning.

http://www.rot13.com: So they've figured Apple was

[Anonymous Coward]

http://www.rot13.com: So they've figured Apple was using rot13, now what?

So....?

[Anonymous Coward]

Since the iPhone itself can always decrypt those passwords, there is no way to prevent it from being done by a human - it doesn't make sense and all attampts to achieve the goal is just illogical. Why do pepole see this as a security problem?

Re:So....?

[Anonymous Coward]

It is a security problem...An unsolvable one though. This won't stop people wanting to make a profit from selling something by telling it can solve this problem while it doesn't.

Now, itf there were a law to stop people from telling lies...Oh, well you can't count on politicians to make one! It would get them all jailed on the spot. Same goes for most journalists and anyone working in marketing.

In fact you have no chance to get a law like that: all the people with any kind of power do use lies a lot.

Re:So....?

[Anonymous Coward]

Why not just design the phone to encrypt the information with a passphrase, or even the passcode people already have? The security issue is that the information to decrypt it is *located on the device*. Encryption is useless if you have the key in the same place as the encrypted data.

Re:So....?

[Anonymous Coward]

People are not going to accept password-locking a phone. Perhaps facial identification could gain acceptance. USB-drive auth won't be favored either. Gesture input unlocking is too difficult for the morons. What else is there?

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.

Re:So....?

[Anonymous Coward]

You do realize the iPhone has the same 10 attempt wipe technology, yes?

This sounds like a brute force attack which would in all likelihood trigger the wipe if someone has turned it on.

Context?

[Anonymous Coward]

Is six minutes good or bad? How long does it take with other phones?

Re:Context?

[Anonymous Coward]

Decrypting stuff should take, oh, about the heat death of the universe.

But as with most with most exploits, it looks like this isn't a problem with the encryption method, but the implementation. The encryption hasn't been hacked, they just found the password.

It doesn't matter how good the lock is if you leave the key under the mat.

Re:Context?

[jbezorg]

In addition to having physical access, The paper assumes that the phone has not received a wipe command, that the phone is not jailbroken and is running the latest firmware 4.2.1.

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

6 min is well under the amount of time to:

- Realize you've misplaced your phone
- Do the pocket pat down
- Retrace your steps a little to confirm you've misplaced your phone
- Get someplace where you can send the wipe command.

Re:Context?

[jbezorg]

I should also point out that the attacker's first move is to power down the phone and remove the SIM card to prevent remote control and receiving the wipe command.

Re:Context?

[Amnenth]

Perhaps phones should have a 'wipe non-volatile memory if SIM is removed/replaced' option in the future.

Re:Context?

[maxume]

Then the attacker 'just' has to physically extract the contents of the non volatile memory.

Of course, that isn't going to be especially easy, but if the data on the phone is that important, why not just protect it with a boot password?

Re:Context?

[mkiwi]

Is six minutes good or bad? How long does it take with other phones?

Six minutes is slightly over average, but I imagine the time reduces with larger screens such as the one on the iPad.

apples are hard to crack!

[Anonymous Coward]

its false! i don't believe it.

apples says my iphone is ultra secure and i believe them. damn you researcher! i hope you gain 200 pounds weight in your lifetime. now where's my ipad?

Where's the source?

[Anonymous Coward]

If only we had access to the keychain source code - the famed community could have fixed it. (Or at least contributed a patch)

Re:Where's the source?

[NatasRevol]

Have at it:

http://opensource.apple.com/source/keymgr/keymgr-22/

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

[xaxa]

1) Maybe the keychain should be encrypted using the unlock code.

2) Maybe the phone should have a private key used for authentication (except the first time). The key could be encrypted with a passphrase (used at power-on) and/or a passcode (the unlock code).

Re:Every single smart phone has same problem

[Anonymous Coward]

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

Yes.

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.

Er.... Use the lock password to encrypt the keychain?

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

[Anonymous Coward]

1) Maybe the keychain should be encrypted using the unlock code.

How many bits does it take to express your unlock code? The longest code is all the digits from 1-9 in some order.

2) Maybe the phone should have a private key used for authentication (except the first time). The key could be encrypted with a passphrase (used at power-on) and/or a passcode (the unlock code).

Users won't tolerate an unlock code that is a strong password.

Re:Every single smart phone has same problem

[Anonymous Coward]

Uh, wrong. The only thing rooting an Android phone does is place the su binary on the phone. Are you going to say that Linux desktop is equally weak then because it has su?

However, if you don't update the kernel after temporarily gaining root, then yes, it isn't secure.

Re:Every single smart phone has same problem

[Bert64]

Have a bootup password that's only required when powering on the phone, if you further configure the phone that it won't communicate via usb unless you've already entered the unlock code then you are at least relatively safe... Someone would need to steal your phone while its already powered up, dismantle it and try to read from memory.

Re:Every single smart phone has same problem

[aaarrrgggh]

Brute forcing the unlock code wouldn't be that much harder if it can be done externally, and you are (practically) limited to a shorter passcode on a phone.

You could have a QR code or something similar that the camera needs to see in order to unlock... but how quickly will that become abused? Any time you go for a stand-alone device, you are going to have compromises.

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?

Re:Every single smart phone has same problem

[drjzzz]

"Of course I ...[have]... a password set, and a suitably short timeout. Still, physical access to any device trumps almost any security measure."

This seems contradictory: if physical access trumps security, why bother with the annoying password?

Re:Every single smart phone has same problem

[clang_jangle]

For the same reason everyone locks their doors, in spite of the fact that all locks are defeatable: it works *most* of the time.

Re:Every single smart phone has same problem

[drjzzz]

By that analogy, you are locking and walking away from your phone? No, you are holding onto your phone. You would not lock your door if you were going in and out frequently, say to the porch or the barbecue.

Re:Every single smart phone has same problem

[DeAngeloLampkin]

Still, physical access to any device trumps almost any security measure.

Yes. This is just as true with a mobile phones as it is with a website. If someone got physical access to a website harddrive that stores a username, then a large percentage of users are screwed, encrypted passwords or no encrypted passwords due to vulnerabilities to dictionary attacks.

-DeAngelo www.braincano.com

Re:Every single smart phone has same problem

[Anonymous Coward]

Deliberately obtuse, ain'tcha?

Re:Every single smart phone has same problem

[Anonymous Coward]

... or if like android, it's already jailbroken for you, ...

See your doctor. Immediately.

Re:Every single smart phone has same problem

[Tordre]

assuming a non-encrypted laptop and the default password saver it is trivial to get ones saved password from Firefox, Chome, or IE. in Firefox, is as much as saying show me my stored passwords.

Re:Every single smart phone has same problem

[Graff]

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.

And that's exactly what is happening here. The only thing that they can get is stuff like network credentials which need to be active in order for the phone to get data while it is locked by the user. User data, including most of the application data associated with the user and the user's own personal keychain, is still secure.

Click through the article to the actual description of the method and you'll see exactly what kind of data is exposed.

Is it a security hole? Yes, it is but not in the way that many people think. It's more of a hazard to corporate users where someone might be able to use this kind of information to get on an internal network. There are ways to harden networks against these sort of threats and most big corporations have these kinds of protections in place.

Re:Every single smart phone has same problem

[drjzzz]

answer is no... not deliberate. inadvertently clueless, if clueless is what it is....

I tried locking my phone (knowing it was recommended) but the hassle of unlocking overcame the slight worry of being (a little) insecure. Think of your wallet - if you lose it, it's a *real* pain, cash, ID, credit cards canceled then renewed, etc etc. Your phone? Much more likely somebody will just wipe it clean, not try to use any data maliciously. I hold onto my phone almost as surely as my wallet.

why A/C?

Re:Every single smart phone has same problem

[treeves]

"...steal your phone while its already powered up..."

If you're like me, that would be roughly....100% of the time. (maybe 4 or 5 9's)

Re:Every single smart phone has same problem

[uninformedLuddite]

1) Maybe the keychain should be encrypted using the unlock code.

or the last 12 digits of pi ;)

Re:Every single smart phone has same problem

[perryizgr8]

Do you enter a passwrod when start your phone?

yes. i enter the pin to unlock the sim card and then i enter the 6 digit phone unlock code. both on my nokia and older sony ericsson. you were saying?

Re:Every single smart phone has same problem

[JimFive]

Any analogy can be stretched too far. You are also unlikely to drop your house at a restaurant and not notice that you had lost it.
--
JimFive

iPhone version ??

[slb]

What a useless report if we don't know which version of iPhone is targetted ? If this attack is effective against an iPhone4 then that's very interesting news, overwise who cares, we already know that 3GS and previous models are wide open.

Re:iPhone version ??

[Anonymous Coward]

iPhone 4 according to the video linked from TFA

Re:iPhone version ??

[lupee]

ask permission before, now I am building a blog that requires access traffic. and you might be able to see some collections of wallpapers for the iphone here. thank you in advance.

Collective Wallpaper | iPhone Wallpapers

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.

Re:Better solution

[fattmatt]

that's the same password I have on my luggage!

Re:Better solution

[NEDHead]

Huh! I didn't know anyone else had the same name as me.

Re:Better solution

[Anonymous Coward]

You cheap bastard. I had mine engraved.

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

[Anonymous Coward]

yes, there is: choose good algorithms, use big keys, accept little performance overhead, ignore police requests to be able to always decrypt..

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

[spud603]

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?

Yes? Well, not really 'unbreakable', but impractical in a lifetime to crack. In fact, this is exactly what encryption is meant for: keep data secure even if it is publicly viewable.

Re:Physical Access

[jo_ham]

For the Keychain, supposedly yes. On OS X itself the keychain can be locked independently of your user account. By default it is not - it shares the same password as your login, and unlocks when you log in. You can have it use a different password though and it stays locked until you allow access. Thus even if your machine is stolen and someone changes the password to your account they can't get into your keychain.

This is also what happens if you change the password using the OS X install disk (if you forget your user password) - it will allow you to change it, but the keychain password remains unchanged (even if it was the same as the user pw initially), preventing your passwords from being revealed.

All the system apps keep passwords in here, so your mail accounts, web page logins, wireless passwords etc are all protected.

I have no idea if this is the same on the iPhone. Presumably the keychain unlocks when the phone unlocks, I am unsure.

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

[Anonymous Coward]

full disk encryption?

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

[Anonymous Coward]

Physical access means a device can be pwned... eventually. What's important then is how long the device can keep its mouth shut. Like when special forces are trained to withstand torture: it is assumed that the soldier will crack eventually. But as soon as the soldier's capture is known, steps are taken to change up everything he knows about.

To me, the interesting part isn't the fact the data can be obtained. It's the fact that it only takes 6 minutes.

Re:Physical Access

[Anonymous Coward]

Is there really any unbreakable way to encrypt your data?

Sure there is:
http://en.wikipedia.org/wiki/One-time_pad

Oh, and more feasibly, but not perfectly secure:
http://news.techworld.com/security/3228701/fbi-hackers-fail-to-crack-truecrypt/

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.

Re:Physical Access

[Anonymous Coward]

Either that or a device would have to have a checksum of the passphrase in memory. The only things you need are a decent password and a difficult-to-reverse way of turning it into an integer.

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.

Re:Physical Access

[ThatMegathronDude]

I'm implanting an RFID reader into my hand so that I can grab your authentication details just by shaking your hand.

Re:Physical Access

[maxwell demon]

Won't help you if the right protocol is used (encryption/authentication to the RFID chip).

Re:Physical Access

[maxume]

I wouldn't cut a chip into my hand, but how about a proximity device in my watch that used some cryptographic stuff for authentication?

Re:Physical Access

[kwerle]

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?

Yes. There are many ways to encrypt data so that it is practically unbreakable. There is only one known encryption known to be perfectly unbreakable - as others have mentioned: http://en.wikipedia.org/wiki/One-time_pad .

Hollywood movies portraying the decrypting of anything is just bunk.

"practically unbreakable" in this case means "unbreakable in our lifetimes using the power of all the computers in the world".

From the article:
"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. This means attackers with access to the phone can create the key from the phone in their possession without having to hack the encrypted and secret passcode."

So Apple is encrypting the data using a key generated from data that is stored on the phone, itself. It's like you hiding a key to your house and leaving clues on the outside of your house where you stored the key. This is Apple's fault.

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.

Re:Cupertino's enviroment...

[sockonafish]

It seems like you've confused the bay area with Los Angeles. It's currently a balmy 51 F in Cupertino.

Re:Cupertino's enviroment...

[Anonymous Coward]

I've gotta say from years of experience that pretty much every single statement you made is the exact, diametric opposite of what it's like there. I don't know if it's some weird joke or what. It has its own unique annoyances like any job anywhere has, but you make no mention of any of them.

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

[0123456]

So where are the keys stored?

If the keys are in the device and visible to software, then anyone with root access can get the keys. Otherwise you need some kind of secure key storage which would require an attacker to dismantle the phone and take the key storage chip apart, or the user has to enter it every time.

Re:Apple iOS File System Encryption

[Anonymous Coward]

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

It may well be that there are inaccuracies introduced by reporter, as usual, but if you go to the source the video clearly shows this being done to an iPhone 4 running iOS 4.2.1.

Re:Apple iOS File System Encryption

[jallen02]

http://wikee.iphwn.org/s5l8900:encryption_keys

That is why the user's passcode is so critical. When you unlock the device it is created once (derived using PBKDF2) and then the passcode is gone. The derived key is held in memory to decrypt the class keys. When the device locks the class keys are (for sure) encrypted and the derived key is forgotten as well.

Re:Apple iOS File System Encryption

[jbezorg]

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

In the described situation, device encryption commonly should provide protection against attacks from the outside. If the device is still turned on — e.g., not
run out of battery meanwhile —, we assume that no remote wipe6 command was received in the meantime (e.g, theft remained unnoticed, no network connection, etc.). In any case, the attacker turns off the device and removes the SIM card to prevent a further remote control.

Re:Apple iOS File System Encryption

[Anonymous Coward]

Wrong-o:
"In this described state, we have conducted our tests with iPhone 4 and iPad
WiFi+ 3G hardware with the latest firmware 4.2.1."

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

[jallen02]

From the article:"This decryption is possible,since on current (3) iOS devices the required cryptographic key does not depend on the user’s secret passcode"

That is what I take issue with since that is not 100% accurate. The quote, for the device they tested (4.2.1, with file system encryption on) should be, "This decryption is possible IN MOST SITUATIONS,since on current (3) iOS devices the required cryptographic key does not depend on the user’s secret passcode".

However you can set flags on files and keychain entries that DOES make the user's passcode required.

Re:Apple iOS File System Encryption

[Cronock]

I don't fully understand the exploit because I'm unfamiliar with the keychain on the iPhone but I am familiar with it on the Macintosh, but I'm assuming it uses a similar setup. On the mac, if your login password matches the keychain password, it automatically unlocks the keychain, otherwise it asks you for a keychain password. Since there is no login password on the iPhone short of the screen lock, how is it managing to lock down these to begin with. Also, is there something similar to putting a custom password in as your keychain password that we can do in the short term to bypass this issue?

Re:Apple iOS File System Encryption

[ei4anb]

Have you read the paper? It says:

"It uses system functions to access the keychain entries, which made it not necessary to reverse engineer the encryption mechanism of the keychain items."

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

[tlhIngan]

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.

Going by sales of the iPhone 4, a lot. And the number of people who update to the latest is huge as well.

And the way iPhone updates are handled, it's effectively a reformat of the filesystem - iTunes backs up your data and apps, then proceeds to wipe the filesystem partitions and formats them. It then sends the new filesystem image over (the ipsw is just a DMG file), waits for the iPhone to reboot and then iTunes restores the apps and backup.

If you watch your iPhone carefully, it reboots several times during the process, including after the restoration sync.

Apple does this to avoid issues related to updating - as a backup is obtained by iTunes (apps are reinstalled, data is backed up and restored), it's far easier to do a clean install than an incremental update. It's also why the IPSW updates are so freaking huge - it's a reinstall of the whole OS (FYI - it's bigger than Windows XP's install media these days).

It avoids issues of old files confusing the new OS (always a problem with incremental updates), missed files, the effort creating a delta, etc. It also lets the user start from scratch again - a lot of issues that get reported turn out to be fixed if you don't restore the backup (like the proximity sensor). And it means a tool can wipe the entire media when you sell it, and iTunes can put in a fresh OS for the new owner.

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.

Hey at least...

[Haedrian]

At least its more secure than Android because its closed source. Its not like anyone *gasp* found a way of looking at the iOS source code is there?. Isn't that right Mister Trend Micro chairman?

Re:Hey at least...

[Anonymous Coward]

The sad fact is that the iPhone is indeed much more secure than Android. iOS uses full hardware encryption for the file system, Android has none. This attack just exploits some gaps left over from previous iOS versions. There were lots of data and passwords this attack could NOT crack, by the way. Apps that use the new encryption APIs properly are secure. It's just that by far not all apps are aware of this yet.

With Android you have all data if you have the phone, no matter what.

Re:Hey at least...

[Anonymous Coward]

On the flip side to that.... Android doesn't have full disk encryption, so it is like saying I don't fail because I don't try. I have an android phone, but having come from a blackberry that is the one feature I miss (I am a security nerd, what can I say).

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.

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)

Free way to prevent this

[2names]

"...and if you hold it juuuuust like *this*..."

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:Physical control of a device

[maxwell demon]

Well, the whole point of encryption is that the data is still secure if someone else gets the encrypted data. Otherwise, why bother to encrypt at all? If the encryption is easily broken, encrypting is just a waste of resources.

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:True Story

[Anonymous Coward]

If she lost her whole wallet containing ID, credit cards, etc., a weak phone password is the least of her security worries.

Re:True Story

[DarthVain]

Ya I thought about that, but then again we could have just sent it to her address on her drivers license really. If it was her parents place it might have taken a bit longer for her to get it, or we could have turned it into the resort, and it likely would have found its way back, but might take longer as well. Though at least the way we did it we were certain...

However that doesn't stop some less honest people from simply wiping the phone and selling on ebay or something.

Re:True Story

[Anonymous Coward]

It was cool of you guys to at least get her phone back to her. I'm sure many others would have laughed and said, "Awesome.... free iPhone!", played around with it, reset it to factory defaults, and started a new eBay auction listing ....

Regardless, the fact she left her whole wallet there was potentially a far bigger problem than anything she could have had on the phone. With access to her ID and credit cards, you could have probably created new lines of credit for her at some bogus "new mailing address" and destroyed her credit, buying all sorts of things under her name.

A long time ago, I once found a woman's wallet in a parking lot, between the edge of the paved lot and the fence. I imagine it fell out of her purse or something when she was getting in her car and another vehicle drove over it after that, pushing it down into the ditch. I intended to contact her and get her stuff back to her, initially, but then I realized that was going to take a bit of effort -- since there was just enough info in there to see that she was recently married and had a new last name, AND a hint that the address on things in there (like a movie rental card) was from before she moved in with whoever she just married. From the looks of the wallet itself, it may have been in that ditch for a while already before I found it, too. So I figured I'd just do the next best thing for her, and shredded all her stuff in it. (Chances are, she already called to cancel her credit cards, and could always go get a new copy of her drivers' license. There wasn't any cash in the wallet or anything like that.)

Until we can find a way to make it harder to lose small items that contain so much important information (like wallets), I don't know that worrying about "more secure passwords" on mobile phones is of prime importance.

Re:True Story

[sdguero]

Yeah,,, I'm trying to understand how not one of 18 dudes would step and say "Wtf are you doing flushing that shit?!!"

Booger sugar ain't that easy to come by...

Re:True Story

[Anonymous Coward]

Yeah, cause driver's licenses never have addresses on them or anything...

Re:True Story

[Anonymous Coward]

A photo of one of the guys on a toilet was taken using the phone that the guy on the toilet was using.

I presume there was a mirror involved?

Motorola Atrix Android solution

[mswhippingboy]

The Motorola ATRIX has the solution to this problem with it's built in fingerprint scanner.

http://www.ur-news.com/review-att-motorola-atrix-4g.html

Re:Motorola Atrix Android solution

[Anonymous Coward]

finger print scanners are never the answer, you can probably lift the fingerprint of the owner from the phone itself.
Or with some finger print scanners, left it from the scanner even.

Re:Motorola Atrix Android solution

[Anonymous Coward]

Only problem is all the other security issues with Android. If you're security conscious and really want to keep your information/data secure, BlackBerry is the only answer. If you don't care a whole lot iPhone would be the next secure. Finally if you really don't care at all about virus's / security etc. you can get an Android (Not flaming Droid, but if security is a concern, it's not the OS for you).

Re:Motorola Atrix Android solution

[mswhippingboy]

Sure, there is technology to lift a fingerprint, reverse the image and create a mold and use it to fool the scanner, but let's be real. How many average hackers are going to go through this much trouble to hack into someone's phone. If you are a CIA operative maybe this doesn't ensure your protection, but for the average Joe, it's more than adequate.

Re:Motorola Atrix Android solution

[Anonymous Coward]

i guess it would work for a randomly found device when you don't have access to fingerprints of the person. but when you can get the prints it's no biggie for a gummi bear.

First Tsutomu Matsumoto used gelatine (as found in Gummi Bears and other sweets) and a plastic mould to create a fake finger, which he found fooled fingerprint detectors four times out of five

http://www.theregister.co.uk/2002/05/16/gummi_bears_defeat_fingerprint_sensors/

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:What

[milkmage]

if you jailbreak it.. it's open to anyone and everyone.. did you RTFA?

"In a video that demonstrates the attack, the researchers first jailbreak the phone using existing software tools. They then install an SSH server on the iPhone that allows software to be run on the phone."

basically - "hey bad guys, here's my root fucking password. promise you won't hack my shit"

lastly - "Last year the institute began selling a Java phone application for securely storing passwords."
yeah. FUD for sales.

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

Re:it is using the latest/current device.

[jallen02]

Point taken. Comment addressed at: http://apple.slashdot.org/comments.pl?sid=1989624&cid=35162734

Re:it is using the latest/current device.

[kangsterizer]

Might as well state that what they wrote is not wrong.
What they get from the device are things like the Wifi access code and it is based on device based, passcode independent encryption.
This is a convenience trade off Apple made, but it is also a security issue.

OTHER things are encrypted with the passcode and they couldn't decrypt those. That is all clearly specified in the PDF.

Re:it is using the latest/current device.

[cheungpat]

iOS does have the protection levels like jallen02 mentioned. The attack is demonstrated on an iPhone with 4.2.1, so the protection levels apply. So why isn't those passwords protected? Clearly the passwords are at the 'Never' level (not protected at all). It is easy to see this even if your device is not jailbroken. After rebooting the device and before entering a passcode for the first time, the device is able to connect to a password-protected wireless network. No matter the password is encrypted or not, if the device can read it on its own, an attacker can certainly read it if they have physical access to the device. This is no different than losing a personal computer. I guess Apple needs to reconsider the protection level of sensitive data like passwords. It sounds reasonable to me to force user to enter a passcode before, say, logging into a wireless network, so that the passwords are protected by the user passcode.

Re:it is using the latest/current device.

[joh]

I guess Apple needs to reconsider the protection level of sensitive data like passwords. It sounds reasonable to me to force user to enter a passcode before, say, logging into a wireless network, so that the passwords are protected by the user passcode.

But this would mean the device couldn't stay connected while in standby, receiving mail etc.

*Lots* of these security shortcomings seem to be compromising between security and convenience. At least the iPhone has a fully encrypted file system, even if this doesn't always help.

Re:it is using the latest/current device.

[cheungpat]

But this would mean the device couldn't stay connected while in standby, receiving mail etc.

*Lots* of these security shortcomings seem to be compromising between security and convenience. At least the iPhone has a fully encrypted file system, even if this doesn't always help.

No. I think wireless network password should be set to After First Unlock protection level. In this level, the password is available to the OS after the user enter the passcode for the first time, so the OS could still connect to the network while in standby etc.

Honeycomb

[mswhippingboy]

Honeycomb will address this issue with a full data encryption option. While this will only be available on tablets initially, it will also make it into Ice Cream (2.4) for phones as well.

Soon to be rectified

[mswhippingboy]

Honeycomb and Ice Cream will offer full data encryption options.

Re:Soon to be rectified

[randomaxe]

Honeycomb and Ice Cream will offer full data encryption options.

Great, because planned obsolescence by way of refusing to release OS updates for older hardware certainly hasn't been an issue with makers of Android handsets in the past.

Re:Soon to be rectified

[mswhippingboy]

If you buy an electronic device today and expect to get all the new features of any new OS version that may come out for x number of years you're living in fantasy land. If you are smart, you purchase the device with the features it comes shipped with and the most you can reasonable expect is to "maybe" get bug fixes for a while.

Apple is no exception to this either. Sure, I can run iOS 4.2 on my iPhone 3G, and what does it get me? App folders, consolidated emails and much crappier performance (camera is practically useless because it's so slow to snap pics). Whoopty shit, I'm so impressed.

What about multitasking, iPhone locator service (without an extra $99/yr), homescreen wallpaper, etc?

The "planned obsolescence" you point out is a problem with the handset manufacturers, not with Android. Some manufacturers are better than others, so just do some homework before you purchase, or skip the homework and just buy into the Apple RDF and tell yourself your iPhone will get upgrades forever.

Re:Soon to be rectified

[randomaxe]

Perhaps you didn't read the part where I wrote "an issue with makers of Android handsets".

I agree, the Android OS itself isn't at fault, I don't know how one could get that out of what I wrote. My point (and one that I thought I was clear about, but apparently I was wrong) was that the Android OS is plagued with handset makers that sit on OS updates either out of laziness, out of a need to protect the bottom line ("adding functionality to products we've already sold doesn't make us any money!"), or out of a desire to sell the features in the newest version of the OS as "features" of the next iteration of the handset.

Apple does not have this problem, as they will offer iOS updates out to every device that can handle them (and, as you and I both seem to have learned the hard way with the iPhone 3G, even some devices that cannot properly handle them). This is a unique problem for Android handsets at the moment, but I suspect we will soon see this issue across Windows Phone 7 handsets as well, should anyone actually buy one.

good grief

[Anonymous Coward]

These people don't have anything better to do with their lives.

What a waste...

iPwn'd iD say.

[Anonymous Coward]

iPwn'd iD say.

Other smartphone OSes tested by anyone?

[Anonymous Coward]

I would be very interested in seeing the results of this kind of testing on all the major smartphone OSes when the phone is in the possession of the cracker (as in a stolen phone). If anyone knows of any such testing on any of the other OSes, please publish links.

The concern here is in knowing which smartphones are able to provide better security in a corporate environment. I use a personal Windows Mobile 6.5 device to connect to my company's Exchange 2010 mail server and wireless network, but most others in the company use a personal iPhone (for those who require a phone for work, the company issues a Blackberry). My company has enabled the requirement to have every smartphone that connects to the Exchange server password protected. I don't know how that works on other smartphones but on my WinMob6.5 it requires a password every dang time the screen times out (very annoying but I have no choice if I want to connect to the corporate network). The thought is that if a phone is stolen then any company data on the phone is "safe enough", but there's no real proof to back up that thought (even though a remote data wipe is possible w/ Exchange).

Thanks!

Re:Other smartphone OSes tested by anyone?

[arkane1234]

There's a big difference between password protected and uncrackable....
pretty much if you have a phone with data on it, your only doing encryption for insurance purposes in the corporate world.

Re:What

[TrancePhreak]

You can jailbreak the phone without knowing the unlock pin code. This means any iPhone you have physical access to can be jailbroken and have its passwords stolen.

Re:What

[makomk]

if you jailbreak it.. it's open to anyone and everyone.. did you RTFA?

You don't jailbreak it. The person who's stolen your locked, unjailbroken and supposedly secure phone jailbreaks it and then gets all the passwords off.

[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

Only if ssh-password is 'alpine'

[TiZon]

If you already have a jailbroken iphone and you changed your ssh-pasw for root, you should be fine....

Huge hole

[Anonymous Coward]

Most probably, it is the "single user mode" again...

Re:What

[milkmage]

the point is it has to be jailbroken...who does it is irrelevant

show me how to achieve this "hack" w/o altering the OS and you have something newsworthy