Researchers have devised a method for stealing passwords stored on locked iPhones and iPads that doesn't require cracking of the device's passcode. The technique, disclosed on Thursday by members of the Fraunhofer Institute for Secure Information Technology, requires physical access to the targeted iPhone or iPad, so remote …
Should they now?
“The passwords for network related services should be available directly from device startup, without having to enter the passcode first.”
Not sure I agree with that. If that's their only reason for this design decision then IMO it doesn't hold up. How hard would it be to prompt for the passcode during boot, and then enable networks once the keychain is unlocked?
On Kubuntu, for example, your wallet is locked during and after boot, and you can't connect to any networks until you put in your passphrase. It's also entirely separate to your login password, which is your standard Unix fare.
The way (k)ubuntu handles it is ridiculous
My wlan password is not a highly secure secret - it's just something I don't want to actively go round telling to random strangers in passing. I therefore really don't want to put it in the keychain and be forced to type in a root password during boot. The only easy way to avoid typing in the password during boot is to set the keychain password to blank, which then exposes my other passwords to an active hacker. For convenience (and given how little I use the keychain) this is worth it, but it's hardly good security.
One used iPhone £5
I'll take it :)
Now, when do I get my fiver
Send me your email address
I'll send via PayPal your account immediately and even pay the postage.
Please send me your email address
I'll send payment immediately (PayPal, Bank Transfer) and will also pay postage and packing.
Re: For Sale
password hack or not, it's still gonna be out of your price range boy
Really, am I seeing this right, they're stored in cleartext, not even MD5?
Maybe I'm wrong about that....I hope!
Yes they need to be ...
because they are being presented automatically to other systems which require plaintext username/passwords (hopefully over SSL - for those services which allow it). This is no different to browsers remembering user credentials for websites and performing auto-fill of logon forms.
The difficulty is that the master password to unlock the keychain is not being set by the end-user (its probably generated randomly at firmware install time [and hidden somewhere in eerom] or locked to a hardware id) but instead is accessed automatically through API calls ... If Apple enforce the same keychain unlocking functionality found in OSX and the problem goes away (well it gets harder to break and requires brute forcing .. which should cause autowiping of the data after 10 attempts).
I have worked on the design of a similar system in the past
There is bugger all you can do. You can be extremely inventive on what you chose for the passphrase which unlocks a device certificate or the encrypted password storage (a good design should just reuse the cert for the pass-store anyway). However, the passwords themselves kept in the passwords storage need to be clear text. There are very few protocols out there which support an authentication mechanism where the client does not need to keep a cleartext password.
Similarly, there is very little to be done against such an attack. A similar attack can be devised for other phone OS-es. Nokia, Android, etc all keep passwords somewhere and an application which has managed to achieve system privs will have no problem reading them out of the password store.
A good analysis but simple for Apple to fix ...
The key point appears to be that iOS allows access to the keychain through standard API calls without prompting the user to enter a password (which is what happens on OSX) ... Apple could fix this by requiring the user's unlock passcode to be entered on to the device and using it to unlock the keychain ... turn the passcode on by default and require it to be entered at boot time and when connecting to a PC.
Hopefully Apple's new head of security will get on to this one asap.
If the device has already been passcode unlocked. Everytime you put it down it would need to relock the keychain thus rendering the device useless while locked.
you just set autolock
The title is required, and must contain letters and/or digits.
Bingbong, but surely this means that e-mail checking etc can't happen in the background and notify you, plus other services that require the password to be there...
Or are these done by session keys that are useful for a short time only?
Doesn't necessarily have to be a problem ...
Remember the issue is that at certain points (e.g. boot time, plugging in the connector) any application can call the API to decrypt the keychain without requiring user interaction and that is where the real problem lies (its the smartphone equivalent of autorun). Make it so that any NEW application instance to run and access the keychain MUST be when the device is unlocked and you *should* neuter this particular attack vector. At boot time the device should wait until it has been unlocked before running the main applications (including mail) or performing a sync. The tricky part might be how to recover a locked device .. simple, treat it as a blank device and rebuild it from scratch erasing all the user data.
Background running applications have, at this point, been started in an unlocked state and so would either have access to their entry in the keychain cached in RAM (and maybe have iOS clear this location each time the device is unlocked - forcing a reread of the keychain) or would keep open a TCP connection session to the remote service (ala iOS Push Notification) and therefore not needing to reauthenticate (but suffers if you lose network connectivity). The keychain itself would be locked and unlocked when the device is locked and unlocked.
Apple needs the device on the network etc at boot so that remote wipe, "where is my phone" etc can work. If not the whoever stole it would just have to reboot and the phone would be forever offline.
Also as Richard Cartledge pointed out, for this to be really effective the device would need to relock everything at sleep: breaking push email, push notifications, and the services as above..
A bit of a chicken+egg problem and not an easy thing to solve, really.
No, it's very easy to solve
It's not a hard problem at all. For example, Symbian OS solved this one about six years ago. It's just sheer laziness.
What's required is a sensible security model where the data isn't released to any tom, dick or harry process that asks in the right way. Only one process ever needs to read your WiFi or VPN credentials, and that should be the only process that can read it. For the most part, email or browser passwords are similar except in the case where you might want to share accounts between multiple clients, though I don't think I've ever seen such an arrangement.
The folly here is relying on a security model that was invented in the 70s for multi-user mainframes to secure single user devices almost half a century later.
Not just laziness...
I agree with you on the poor security model, however can't really blame Apple for using what is an industry standard now.
Fine grained, OpenVMS style (also from the 70's btw) access control would be nice, but once you have physical access to the machine is anything really safe and thus worth the extra complexity? It's a bit like modern airport security, we have to go through a lot of restrictions for increasingly little incremental security.
The solution you propose also has it's problems: if the phone is rooted already then the process (in file or memory) that is allowed to read the passwords can easily be changed. Solving this would need many more layers, and so it is an hard problem...
"... can't really blame Apple for using what is an industry standard now ..."
Why not? Apple always insinuates that the sun rises and sets on Cupertino and that their products are superior to other peoples
Clearly Apple is the same as others and not a cut above..
We knew that
We knew that because Google told us that last week. And gave us faux outrage. "After using Google, Bing presented different search results".
Finally, something really clever from Apple.
A phone-sized device that you can easily drive a Coach and Horses through.......
The title is required, and must not contain letters and/or digits.
Great, now Apple have a real excuse to fight jail breakers.
Jailbreaking is the security flaw
“After using a jailbreaking tool, to get access to a command shell", its at the point you iphone is owned, recovering passwords etc is a matter of time. The fact that the iPhone can be jail broken is the serious security flaw, on any other device it would be called an exploit.
Re: Jailbreaking is the security flaw
> The fact that the iPhone can be jail broken is the serious security flaw, on any other device it would be called an exploit.
So if I make a malicious app to do the same thing that typing in the shell does, what would you call it?
No need to worry
The passwords are all in German, so should it be robbed and hacked we know it would have been zee Germans
Speeded up film...
...yet more honestly speeded up than 'Sequences shortened' iPhone ads!
Closed system, closed environment, closed minds!
Just see the Apple devs right,"*fingers in ears*, "La la la! Not listening to you! Security is fine, you can't get to the O/S so don't worry! La la la!"
thanks for being another one
Another moron who didn't bother to actually read or understand the source before commenting.
First off, this only exposes a small number of passwords, not all of them. Why not? well, MOST of the passwords on iOS 4 are already using 2 available encryption technologies preventing their access. These are the password systems 3rd party apps have access to (and are encouraged to use), Apple mail uses, Safari uses, and more. The number of core apps supporting this has been increasing with each further release of 4.x. It is simply a matter of completing the process on VPN, Exchange, and IMAP account access systems in order to close this gap.
Oh, and for the rest of you, you do realize the very same data is stored in a database on Android, accessible WITHOUT even jailbreaking the device, right? You know, since the base file system on Android is NOT EVEN ENCRYPTED as it is by default in iOS 4.
and physical access, if they have it, you loose, period. Matters not the device make or OS revision, they have ALL been hacked. This is a low priority threat requiring detailed knowledge and access to unreleased code, access physically to a device, and all it gets a hacker is access to your VPN passwords (which without additional authentication is useless), and/or access to an iMAP e-mail account (and if you're storing data inside your mail server that's critical, you already failed, your e-mail passwords are easy enough to get by a number of active bot networks).
I thought that once the black hats had physical access to any type of device, it should be considered game over.
Maybe it isn't just "Game Over"
Depending on WHOSE iPhone is stolen, it could be "Game's JUST Beginning", and that would be very bad for certain people.
Just install Keeper
"Keeper" is a password app for iPhone and it doesn't use the keychain, so everything in there is safe and secure. End of story.
- Review Reg man looks through a Glass, darkly: Google's toy ploy or killer tech specs?
- +Comment 'Stop dissing Google or quit': OK, I quit, says Code Club co-founder
- Nokia: Read our Maps, Samsung – we're HERE for the Gear
- Ofcom will not probe lesbian lizard snog in new Dr Who series
- Rejoice, Windows fans: Stable 64-bit Chromium drops for Win 7 and 8