iPhone Attack Reveals Passwords In Six Minutes 186
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."
Apple's military-grade encryption, cracked (Score:3, Funny)
Fb gurl'ir svtherq Nccyr jnf hfvat ebg13, abj jung?
Re: (Score:2)
Gurl'yy fjvgpu gb ebg39. Nsgre nyy, vg zhfg or zber frpher!
Re: (Score:2)
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.
Every single smart phone has same problem (Score:3)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
"...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 (Score:4, Insightful)
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: (Score:3)
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
Re: (Score:2)
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 p
Re: (Score:2)
This seems contradictory: if physical access trumps security, why bother with the annoying password?
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
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?
[NOT] Every single smart phone has same problem (Score:3)
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
Re: (Score:2)
Re: (Score:2)
Yea, well, mine's better, I use rot13 twice! Crack this, sucker!
I decrypted your message by applying ROT2 thirteen times.
Re: (Score:2)
Emmanuel Kant was a real pissant.
Should've used Hobbes.
Relies on Jailbreaking (Score:3)
Re: (Score:2)
Decrypt passwords in a typical Unix shadow file
Re: (Score:2)
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
Re: (Score:2)
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 [h-online.com]
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 (Score:5, Insightful)
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: (Score:2)
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: (Score:2)
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 p
Re: (Score:2)
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 [fraunhofer.de]
Re: (Score:2)
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: (Score:2)
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: (Score:2)
#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: (Score:2)
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
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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 di
Re: (Score:2)
Root access is there anything it can't do?
According to the actual paper [fraunhofer.de]
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.
iPhone version ?? (Score:2)
iPhone 4 & iOS 4.2.1 (Score:3)
Better solution (Score:2)
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 (Score:2)
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: (Score:3)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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 forge
Re: (Score:2)
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: (Score:3)
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 (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
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 wa
Re: (Score:3)
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
Re: (Score:2)
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 [wikipedia.org] .
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
Re: (Score:2)
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: (Score:2)
Cupertino's enviroment... (Score:2, Funny)
...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
Re: (Score:3)
Sounds like every job I've ever had.
Re: (Score:2)
It seems like you've confused the bay area with Los Angeles. It's currently a balmy 51 F in Cupertino.
Apple iOS File System Encryption (Score:5, Interesting)
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: (Score:2)
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: (Score:2)
http://wikee.iphwn.org/s5l8900:encryption_keys [iphwn.org]
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: (Score:2)
From the Paper: http://www.sit.fraunhofer.de/en/Images/sc_iPhone%20Passwords_tcm502-80443.pdf [fraunhofer.de]
it is using the latest/current device. (Score:5, Informative)
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 [fraunhofer.de]
Re: (Score:2)
Point taken. Comment addressed at: http://apple.slashdot.org/comments.pl?sid=1989624&cid=35162734 [slashdot.org]
Re: (Score:2)
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: (Score:2)
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: (Score:2)
"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: (Score:3)
The six minutes, and unencr
Re: (Score:2)
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 partiti
Re: (Score:3)
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 [inf.furb.br] 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 sc
Re:Apple iOS File System Encryption (Score:5, Interesting)
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: (Score:2)
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 fil
Hey at least... (Score:2)
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: (Score:3)
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 you
Soon to be rectified (Score:3)
Re: (Score:2)
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: (Score:2)
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 pra
Re: (Score:2)
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 o
Free way to prevent this (Score:2)
Physical control of a device (Score:2)
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.
True Story (Score:5, Funny)
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 (Score:5, Funny)
Anyway in the end we flushed her baggy
Is "flushed" the expression drug fiends use nowadays? We used to say "snorted"...
Re: (Score:2)
Re: (Score:2)
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.
Motorola Atrix Android solution (Score:2)
http://www.ur-news.com/review-att-motorola-atrix-4g.html
Re: (Score:2)
Honeycomb (Score:2)
Re:Well... (Score:4, Insightful)
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: (Score:2)
Last I checked a android phone that has the same specs as my iphone cost the SAME AMOUNT or more.
Re: (Score:3)
And it takes more than 6 minutes to crack the passwords on them. What's your point?
Re: (Score:3, Informative)
>>>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
Re: (Score:2)
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 id
Re: (Score:3)
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: (Score:3)
> 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: (Score:2)
Have at it:
http://opensource.apple.com/source/keymgr/keymgr-22/ [apple.com]
Re: (Score:2)
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 [fraunhofer.de]
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: (Score:2)
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: (Score:3, Insightful)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:3, Informative)
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 encrypte