Apple's iOS 4 Hardware Encryption Cracked

adeelarshad82 writes "Russian company ElcomSoft is claiming to have cracked the 256-bit hardware encryption Apple uses to protect the data on iOS 4 devices, and is offering software that allows anyone to do it. ElcomSoft can now gain full access to what is stored on a gadget such as the iPhone 4. This includes historical information such as geolocation data, browsing history, call history, text messages and emails, usernames, and passwords."

Comments

Where there's a will...

[Anonymous Coward]

... there's a way. Always.

Re:Where there's a will...

[naz404]

FYI guys, ElcomSoft is the company where Dmitry Skylarov worked -- the research guys who cracked the encryption on Adobe's PDF files.

Skylarov was arrested after flying to the U.S. to give an eBook security talk at DEF CON under the DMCA for software copyright circumvention blah blah.

Re:Where there's a will...

[tehcyder]

... there's a way. Always.

Time travel?

Re:Where there's a will...

[Anonymous Coward]

Your mum's face is Sklyarov

Re:Where there's a will...

[jdgeorge]

I travel through time constantly. So, yes, there's a way, always, to do certain things within certain limitations, especially if you define "always" as "sometimes". Which is to say, the correct statement would be "where there's a will, there's a way to do certain things under certain conditions. Sometimes."

In some cases, the "way" is to redefine a problem to something completely different than an originally stated problem, and then address the new, solveable problem.

well...

[Anonymous Coward]

I'd better switch to Android pronto - I'm sure that's safe!

Re:well...

[errandum]

Or nevermind. The source where I read this news claimed that, but it seems it relies on a brute force attack, although they do have an algorithm to get a set of valid testing keys.

Re:well...

[newcastlejon]

How would you feel about taking a user-input password and using an algorithm to generate a computationally convenient key?

Re:well...

[Anonymous Coward]

How would you feel about taking a user-input password and using an algorithm to generate a computationally convenient key?

You mean like Password Based Key Derivation?

Re:well...

[Anonymous Coward]

You'd be correct :)

Re:well...

[errandum]

Not as good as a genuine key, but way better than something that can be guessed to some approximation. Assuming, obviously, that "user input" is a strong key to begin with.

Re:well...

[BitZtream]

Ahh, I love when people with no clue repeat crap they found on the Internet.

Show me something that doesnt' generate keys using an algorithm ... I won't be holding my breath. Any good security system uses an algorithm for key generation ... with a RANDOM mutator. Not all keys are created equal, some are known to be weak, throwing those out is paramount and users simply aren't worth shit at generating random keys, so you use an algorithm known to generate strong keys with a random mutator.

Let me help you out as to the standard way all of us that actually know about encryption do it: RFC 2898

Again, please do not talk about security and encryption when you clearly have no idea what you're talking about and are just spewing some blurbs you read from someone on the Internet, which again, you clearly didn't understand them when you read them.

Re:well...

[hoggoth]

Re: your sig:
> If God forks the Universe every time you roll a die, he'd better have a damned good memory.

Not if every possible universe exists simultaneously and every time you roll a die you simply move to the matching universe-state.

Re:well...

[errandum]

What?

First, there are a few almost 100% random generators. I prefer electromagnetic field variations, some use radioactive field decay, but there are more. Google them, I'm not here to teach you.

Second, I had a whole course dedicated almost exclusively to to encryption. I've implemented 3xDES, AES and RSA (C code, mind you, not easymode java). The first way to get your key broken is to make them predictable. It doesn't matter if you use a Password Based Key Derivation or not, if your universe of keys is known (in this case it's based on your phone's ID's, if what I read was true), enough processing power and you'll get there (it's what they seem to be doing).

Third and foremost, who the fuck are you to judge my knowledge based on those 3 lines? I know about salting, about making things slow enough to frustrate brute force attacks, etc. I wonder how you decided I did not, but please, fuck off.

Re:well...

[multipartmixed]

Ah, undergrads. I love how smart they are. Able to master an entire domain in a single semester..

Now, if you don't mind, I have to go hook my atomic vector plotter up to my preferred source of entropy (a nice cup of hot tea substitute). I'm going on a trip..

Re:well...

[Anonymous Coward]

You attended a class and wrote and implemented some code. That has nothing to do with your credentials of knowing security and encryption or that the things you implemented were actually secure. I've attended a Cisco switching class and used the help of Google to setup some routes between a few offices, that does not imply that I had a full understanding of what I was doing. All I know is I got working.

Re:well...

[errandum]

No one claimed I mastered it. I study computer science, so they give me the basics for when, someday, I have to implement things like that. I also studied books, articles by people that know way more than me and real use cases. (encrypted communications between USA and Russia, Kerberos, Enigma, etc)

I also learned the only way to make a key 100% secure (unique non repeatable keys), how many times can you guarantee a key to be secure, when to use asymmetric/symmetric cryptography, etc.

No, I did not master anything. But snide comments on how "I have no idea about what I'm talking about" are unfounded and idiotic. Using a simple algorithm to generate (even if salted) keys leaves you open to brute force attacks. That's a fact, and it doesn't matter how much you think I know about cryptography.

Re:well...

[Anonymous Coward]

What the hell are you talking about, you never use the plain unhashed or otherwise unmodified password as a key, where did you take security 101?

Re:well...

[Fjandr]

If every possible permutation exists simultaneously, there both is and is not a God, but where he is, he's irrelevant. Except when he's not. And he has an impeccable memory. Except when he doesn't. :)

Re:well...

[Anonymous Coward]

Ahh, I love when people with no clue repeat crap they found on the Internet.

Show me something that doesnt' generate keys using an algorithm ... I won't be holding my breath. Any good security system uses an algorithm for key generation ... with a RANDOM mutator. Not all keys are created equal, some are known to be weak, throwing those out is paramount and users simply aren't worth shit at generating random keys, so you use an algorithm known to generate strong keys with a random mutator.

Let me help you out as to the standard way all of us that actually know about encryption do it: RFC 2898

Again, please do not talk about security and encryption when you clearly have no idea what you're talking about and are just spewing some blurbs you read from someone on the Internet, which again, you clearly didn't understand them when you read them.

Wow your knowledge must be really worthless if the only people who don't know it are talking crap.

Re:well...

[Terrasque]

Okay, lemme see.... I have a password "hunter2". I also have supersecret porn I'd like to encrypt with AES. I'd like to use my human-rememberable password for the encrypted AES data.

Now, I challenge you to make a 256bit key from "hunter2" without using an algorithm to generate it... And yes, I'd do like to be able to decrypt it with the same password. And no, "hunter3" should *not* unlock it.

If you can do that, then I will admit that you *DO* know something us normal hobbyists don't.

Re:well...

[errandum]

why should I want to make a 256 bit key from hunter2? If you're going to generate a key using an algorithm, it is recommended that you use a 64bit initial key.

Apple seems to have done exactly that. They generated something something starting from a 4 digit number. That's why it only takes 40 minutes to access the information you need to decrypt everything.

Re:well...

[multipartmixed]

So, your initial post in this thread said,

DO NOT USE AN ALGORITHM TO GENERATE YOUR KEYS.

Big big fail, in my opinion.

Now you are suggesting that Apple are fools because they are not making users memorize 64-bit initial keys? That's a twenty digit number!

Also, you said that they should not use an algorithm at all to generate keys, because that is a big fail. So, in order not to fail, in your opinion, Apple must require users to type in a 256-bit key in order to access their data. A key which originated from a true source of entropy the phone has access to, like maybe RF noise.

So, chief, how many 79 digit numbers do YOU have memorized? None? Do you think maybe that's why the second responder in this thread was mocking you?

Re:well...

[Terrasque]

But... Why stop with 64bit? Let's just force people to remember a 256bit key. Which they'll have to type in every time they use the phone. And the timeout should be 15 seconds, so an attacker can't use an idle session.

Now, you start selling that. Meanwhile, Apple is for some reason having huge success with it's 4 digit number. For some reason, most consumers don't want to memorize and type in huge keys to use the phone.

On the other hand, those that go into advanced mode on the phone and turns on a proper password lock can put in a larger and more complex password.

Designing something secure works well in theory, but in real life, one have to make some tradeoffs. What you do is complaining about Apple's tradeoff, without giving any reasonable alternatives, and apparently without seeing the issue at all. Which is why he started mocking you in the first place :)

Re:well...

[bipedalhominid]

multipart/mixed did not say you had no idea what you were talking about. You did. The comment was snide-like but saved in the end with an excellent and pertinent reference to a wonderful book. Now for your homework, what's the name of the book?

Re:well...

[hoggoth]

I think you've summed it all up quite nicely. And haven't.

Re:well...

[errandum]

what I meant by an algorithm was:

X+1 = new key
Day of fabrication = new key
IMEI = new key

if you use that to generate your 256bit key you're failing.

And you misunderstood. Normal users chose nothing. It's apple that choses and no user should have access for to it.

PS: I was under the impression that an HEX 64 bit key was 10 numbers/letters. It's not a key a user should know, but if it was, is 10 that hard?

Re:well...

[errandum]

Very simple.

You use your 4 digits to unlock your phone.

Your encrypted files should not be encrypted by those 4 digits. And if those 4 numbers are part of the way they generate the key, the other part should not be accessible by anyone that already has those 4 digits. That was where they failed.

What's the point of having 256 bit encryption if, trully, they rely on something that weak?

Re:well...

[errandum]

"please do not talk about security and encryption when you clearly have no idea what you're talking about"

Please teach me english, I seem to be failing at reading.

You maybe you are. Not sure yet. But that part where he says "you have no idea what you'te talking about" is interesting.

Brute force tool, not a "crack"

[bbk]

This just lets you brute force the passkey, easy as if you're using a 4-digit numeric passkey there are only 10000 combinations.

If you're using a more complex alphanumeric key, which can be enabled with the iPhone config utility, then this probably won't work that well...

Re:Brute force tool, not a "crack"

[geekoid]

And there are tons of ways to make windows more secure.

People tend to be lazy.

Re:Brute force tool, not a "crack"

[Anonymous Coward]

This just lets you brute force the passkey, easy as if you're using a 4-digit numeric passkey there are only 10000 combinations.

If you're using a more complex alphanumeric key, which can be enabled with the iPhone config utility, then this probably won't work that well...

You think the root is locked with the front screen code? And that code is only four digits by default, it can be changed to any alpha numeric combo like a regular password. Again this is not what they have cracked.

Re:Brute force tool, not a "crack"

[kybred]

This just lets you brute force the passkey, easy as if you're using a 4-digit numeric passkey there are only 10000 combinations.

I wonder if it tries '1234' first?

Re:Brute force tool, not a "crack"

[Anonymous Coward]

This just lets you brute force the passkey, easy as if you're using a 4-digit numeric passkey there are only 10000 combinations.

I wonder if it tries '1234' first?

That's the stupidest combination I've ever heard of in my life. The kind of thing an idiot would have on his luggage!

Re:Brute force tool, not a "crack"

[Lokitoth]

'1234'? That's the password on my luggage!

Re:Brute force tool, not a "crack"

[Anonymous Coward]

quote fail

Re:Brute force tool, not a "crack"

[Mad Merlin]

And there are tons of ways to make windows more secure.

Such as wiping the drive, or unplugging the power and network cords.

Re:Brute force tool, not a "crack"

[Anonymous Coward]

I remember laughing to that joke in 1997

Re:Brute force tool, not a "crack"

[adisakp]

This just lets you brute force the passkey, easy as if you're using a 4-digit numeric passkey there are only 10000 combinations.

I wonder if it tries '1234' first?

Amazing! That's the combination to my luggage!

Re:Brute force tool, not a "crack"

[Anonymous Coward]

Android has Pattern Lock. It is much easier to swipe in a pattern then to type in a PIN. I guessed the PIN on my sisters fiance's iPhone in just a few tries. It was the year he was born. He couldn't guess my pattern, despite me using a fairly simply pattern. Maybe Apple should copy some Android features. The smudging of the pattern isn't a big deal if you wipe your screen regularly.

Re:Brute force tool, not a "crack"

[LordLimecat]

This isnt a story, because we've long known that bruteforcing 10000 combinations isnt hard. Throwing the iPhone's name out there is perhaps a way to make this sound impressive or novel, but its not.

Re:Brute force tool, not a "crack"

[Anonymous Coward]

What a buffoon! Every idiot knows that you should use a 5 digit password.

Re:Brute force tool, not a "crack"

[Anonymous Coward]

That's the same combination as my luggage

Re:Brute force tool, not a "crack"

[binford2k]

The pattern lock is less secure, not more. Think about it. With digits, what options do you have for position n+1 if position n is the value 1? With a pattern swipe, what options do you have?

Re:Brute force tool, not a "crack"

[tripleevenfall]

Numbers are stupid, there are only 0-9. Using letters is safer as there are 26. "password" is a much better password.

Re:Brute force tool, not a "crack"

[Anonymous Coward]

Mathmatically maybe, in theory while you are holding the phone in your hand trying it? Probably not because I'd bet few people pick a truely random 4 digit pin. Forcing everyone to have a 32 character alpha numeric password that has to be changed weekly results in everyone writing down their passwords decreasing the overall security compared to say an 8 digit alphanumeric that changes monthly.

Re:Brute force tool, not a "crack"

[Anonymous Coward]

1048576 combinations.

Re:Brute force tool, not a "crack"

[froggymana]

I prefer what cyanogenmod lets you do. With CM you can setup your own "pattern lock" to any shape and any length that you want. When your screen is locked you only see a blank space and have to guess the shape and direction it was drawn.... good luck :)

Re:Brute force tool, not a "crack"

[hawguy]

My pattern includes 6 dots. From each element, I have at least 5 choices (hint, you don't have to use the nearest dot, you can go between them to skip a dot).

So there are at least 15625 6 element pattern combinations. Actually there are more because from some dots you have more than 5 choices (like the center dot where you have 8 choices). It turns out that this guy already did the math:

http://beust.com/weblog2/archives/000497.html
4 dots: 1624 solutions
5 dots: 7152 solutions
6 dots: 26016 solutions
7 dots: 72912 solutions
8 dots: 140704 solutions
9 dots: 140704 solutions
Total: 389112

Ironically, my Exchange admin requires a 4 digit password, and I chose 2 repeating digits for ease of typing (I could easily swipe my pattern without looking at the screen, I have a hard time doing that with digits), so my phone is less secure.

Re:Brute force tool, not a "crack"

[sangreal66]

Easily defeated... Hold the phone up to the light and follow the grease trail

Re:Brute force tool, not a "crack"

[Anonymous Coward]

With digits, what options do you have for position n+1 if position n is the value 1? With a pattern swipe, what options do you have?

Eight -- no wait .. eight to the what power? Actually, the gesture probably rarely goes backwards, to the number is less than eight. But you've still got that pesky exponent.

Re:Brute force tool, not a "crack"

[logic_optimize_skate]

I don't believe the passcode being referred to is the passcode the user has to type in when the unlock the device. Otherwise all the iPhones with the 'Erase data after 10 failed passcode attempts.' option enabled would be immune.

Re:Brute force tool, not a "crack"

[Fjandr]

You can swipe unlock an iPhone, but it's even easier to break than a PIN, unless you're fastidious about cleaning your screen after every unlock.

Re:Brute force tool, not a "crack"

[Fjandr]

Which is exactly why you try it first. Apparently you aren't aware of the Gizmodo password frequency analysis, which is surely repeated almost everywhere that doesn't absolutely require the use of strong passwords to enable service.

Re:Brute force tool, not a "crack"

[Fjandr]

According to their stated keys/sec, it would take as much as 33,619,417.2 millenia to break my Blackberry password, since it's immune to dictionary attacks.

Re:Brute force tool, not a "crack"

[Anonymous Coward]

You don't need the config utility to enable complex passcodes any more. It's just a switch in the passcode lock settings.

Re:Brute force tool, not a "crack"

[hairyfeet]

Has anybody done a study on patten unlocks and what frequency we humans pick the same patterns? Because while I don't have a Droid just watching the video posted above my guess is along with the "left to right G shape" there will probably be a lot of people doing something like a cross, 4 box pattern, etc. We humans tend to like certain shapes and tend to go for those, such as tic tac toe.

So if anybody has a link comparing pattern matching to password guessing my bet is it would be interesting to see which is more prevalent, the same numbers chosen or the same patterns. Since I don't have the data and have to guess I bet ordinary folks probably pick the same patterns quite often, just like the old ASD123asd or Passw0rd passwords are used a lot.

Re:Brute force tool, not a "crack"

[aztracker1]

Damn, better change the combination on my luggage.

Re:Brute force tool, not a "crack"

[Nikker]

Over here when it comes to old memes, we put that shit on everything !

Re:Brute force tool, not a "crack"

[Vintermann]

> If you're using a more complex alphanumeric key, which can be enabled with the iPhone config utility,

So it needs to be enabled? how many users know how to do this, and do it?

This fits the Apple pattern of convincing people they have something cool and powerful, while in reality other people sit with the keys.

Re:Brute force tool, not a "crack"

[pinkushun]

hunter2

Re:Brute force tool, not a "crack"

[pinkushun]

Yes! So it's a device design flaw, the encryption itself is pretty secure if used properly. I see their software also lists Blackberry. Better change my 4-digit password too! gulp.

Here is a great analogy of how strong the encryption is, if a secure password is used:

Imagine a computer that is the size of a grain of sand that can test keys against some encrypted data. Also imagine that it can test a key in the amount of time it takes light to cross it. Then consider a cluster of these computers, so many that if you covered the earth with them, they would cover the whole planet to the height of 1 meter. The cluster of computers would crack a 128-bit key on average in 1,000 years.

If you want to brute-force a key, it literally takes a planet-ful of computers. And of course, there are always 256-bit keys, if you worry about the possibility that government has a spare planet that they want to devote to key-cracking.

from: http://www.interesting-people.org/archives/interesting-people/200607/msg00058.html

Re:Brute force tool, not a "crack"

[Anonymous Coward]

"Furthermore, certain files are protected with encryption keys tied to both the device and the user’s passcode,"

it means they can extract the keys and get some part of the filesystem without brute force.

1. what are those instantly recoverable files?
2. what does our password protect?

Re:Brute force tool, not a "crack"

[Anonymous Coward]

I think you're confusing the PIN to unlock the phone with the password associated with backups. This tool is for brute forcing the backups of the device iTunes makes, which you certainly could protect with a 4 digit PIN but I'd hope you wouldn't. Backups aren't encrypted by default, so if you've gone to the hassle of turning them on you've hopefully not set the password to 1234...

(To be fair, the mention of "Hardware Encryption" in the subject had me assume it was an attack on the phone too)

Re:Brute force tool, not a "crack"

[Fjandr]

I'd doubt the data is available to do such an analysis, and until touchscreen entry becomes common to access centralized software services it's likely to continue to be unavailable. With passwords, it's much easier to do as a result of the high number of compromised accounts when a large service like Gizmodo gets hit.

That said, I'd be inclined to agree with your guess about certain swipe patterns likely accounting for a very large percentage of devices that use that particular method of unlocking. People, when taken as a large group, tend to follow incredibly predictable patterns in average behavior.

Re:Brute force tool, not a "crack"

[tehcyder]

Also, Androids lock up quite quickly after incorrect swipes, I forget how many, but I did it myself once. You couldn't brute force that unless you knew the user's email and password.

Re:Brute force tool, not a "crack"

[archen]

That's why I stopped using the pattern lock myself. In order to keep it "secure", I had to continuously clean off the screen. Learning someone's pattern just means someone has to pay attention to your phone. Sooner or later the finger trail will be there even for those who bother to wipe it off on occasion will either forget to do it, or don't do it obsessively enough to really hide it.

Re:Brute force tool, not a "crack"

[V for Vendetta]

Perhaps you missed the point where ...

If the iPhone is synchronised with a computer it is apparently possible to extract the escrow key from the PC and use it instead of the passcode key.

... and therefore no brute force necessary.

Source

Re:Brute force tool, not a "crack"

[Eunuchswear]

Depends on the dictionary.

Re:Brute force tool, not a "crack"

[bipedalhominid]

I think it was 1982 in Houston. My sister had just shut down a small computer/software business and went back to good old UofH to finish her degree. She told me the only way to make these things secure is to deny power to the box and put them in a closet and never touch them again.

Re:Brute force tool, not a "crack"

[bipedalhominid]

I just us an a for a password now. Lowercase, single character, the fricking letter a. No brute force attack even tries that one anymore. :)

Re:Brute force tool, not a "crack"

[bipedalhominid]

I changed mine to 357.

Re:Brute force tool, not a "crack"

[Gumbercules!!]

4 people at my work attempted just this and all of them failed on my pattern. Additionally, I am in the habbit of wiping the screen with my sleeve as soon as I use my swipe pattern to re-lock the phone.

More to the parent point, before using the pattern, I did indeed use my birthday as my PIN. I know this is crap security - but it's not about protecting my phone from my people who know my birthday. It's about a) providing me enough time for me to realise my friend has picked it up and intends to mess with it (either options gives me the few seconds I need for this) as a joke or b) to stop a complete stranger from viewing all my details, easily. So in this case, both would work equally.

But I like the pattern because it's easier for me to work with and so far, no one else has ever guessed it.

To be honest, the amount of stuff on my Droid that I don't want a stranger to get access to is a little scary (like many people, I have saved my passwords for Facebook, eBay etc on it... I felt bad about doing it but I did it anyway), so I really just try not to lose it. Again, a crap security policy I will admit but I seem to have become quite apathetic about it.

Re:Brute force tool, not a "crack"

[Fjandr]

That's about as useful, in my case, as saying 'That depends on the computer' or 'That depends on the password being randomly among those chosen within the lifetime of the people cracking it.' As of today, none of those things have a chance in hell of mattering unless national security were involved. In the latter case, there's a much higher likelihood of alternate methods being far more effective.

Re:Brute force tool, not a "crack"

[adisakp]

Whoosh... that's the sound of a good joke flying over your head. Are NERDS no longer required to watch "Spaceballs" anymore?

Re:Brute force tool, not a "crack"

[adisakp]

Yeah... sorry I bought inferior luggage with only a 4-digit combo.

Re:Brute force tool, not a "crack"

[micheas]

Dictionary attacks on passwords tend to not use traditional dictionaries. Rather they use dictionaries of passwords that have been exposed via fishing attacks and then publicized.

All that has to happen is for someone using the same password as you to fall for a phishing attack and you will be vulnerable to dictionary attacks, even if your password looks something like: XHdHNP4S.

If that password has been exposed and is in the attackers password dictionary, you are vulnerable.

Re:Brute force tool, not a "crack"

[Fjandr]

That's about as likely as any of the things I listed in my above reply to Eunuchswear, which is to say not at all likely. In a lot of ways, it's even less likely, since people who tend to fall for phishing attacks tend to be those who wouldn't use a strong password anyway.

Re:Brute force tool, not a "crack"

[micheas]

About 80% of the passwords in my password dictionaries are mixed case and include at least one number, and generally qualify as secure passwords, other than the minor problem of being in a password dictionary. Further more a not insubstantial minority have a non-alpha numeric element in them.

Humans are predictable creatures of habit, with ingrained social norms. Password dictionaries are shockingly effective.(at least to me.)

Re:Brute force tool, not a "crack"

[Fjandr]

The likelihood of overlapping use of the same non-alpha characters in the same place, in the same password, is vanishingly small. Have you ever encountered, or seen anyone else encounter, that actually happening? If so, I'd be interested to see what 'strong' passwords those are, though not some obvious 'l33t' replacement scheme (given that any decent dictionary attack accounts for them without explicit addition).

Re:Brute force tool, not a "crack"

[micheas]

A few of them:

• 15felixJA!%
• 16mypiss!*
• a[[;es!
• Bb35618982!
• beto!@#$%
• E!@#$%^&*
• $eharst!!!
• Fahkit9!@#
• St@T^cx015
• ailidh^_^

Are all passwords in myspace.txt, which is a very widely distributed dictionary. I would give more examples, but cut and paste doesn't seem to work with slashcode and a beta version of chromium.

Re:Brute force tool, not a "crack"

[micheas]

The second problem is that people tend to invent the same schemes for creating unguessable passwords over and over again. The high repetition of passphrases is somewhat evidence of that.

People educated the same way will tend to come up with similar solutions to similar problems.

I have had a password that I made up fall in very short order, which I would assume was because someone else thought up the same clever password scheme I did. I run my current passwords through the latest dictionaries I can get my hands on periodically, and every once and a while I discard a password because it is in one of the dictionaries.

Basically, passwords suck, if you have people remembering them.

Re:Brute force tool, not a "crack"

[Fjandr]

I find it highly unlikely that those passwords were used by multiple people. Much more likely that they were used on multiple accounts by the same people. While the Myspace phishing list is useful as a dictionary source, the further down the list you get the less useful the passwords are in general.

The pattern of non-alphas that repeat 3 times isn't surprising. What is surprising is that, in looking through an analysis of the Myspace list of 34,000 released passwords, it appears that those above are the only 3 passwords in the entire list to use the # character. That also means they're not duplicated, which was part of an earlier point I made. I was asking for passwords that multiple people use, not one-offs that will never be useful unless targeted at the person they were originally stolen from. There may be a lot of them in dictionaries, but the likelihood of strong passwords using non-obvious replacement or pattern mechanism and incorporating numbers, letters, and characters, is still an extraordinarily small percentage.

Looking up the various professional analyses done on the major password database breaches, this is borne out repeatedly. Such passwords encompass an insignificant percentage of those broken. For example, passwords from the combined Myspace, phpBB, and singles.org password lists contained a whopping 0.61% occurrence of the use of non-alphanumeric characters. That, to me, is a significantly insubstantial minority.

Re:Brute force tool, not a "crack"

[tripleevenfall]

This was not a whoosh. It was an unrelated joke.

Company haha

[Anonymous Coward]

We are very legitimate Russian softwares company.

well...

[errandum]

They figured the algorithm used to generate the keys...

Security one-o-one is DO NOT USE AN ALGORITHM TO GENERATE YOUR KEYS.

Big big fail, in my opinion.

History repeats?

[Daetrin]

Will Apple start issuing lawsuits and court orders left and right to try and stop this? And if so will it distract people from Sony's recent actions along those lines?

Re:History repeats?

[pandrijeczko]

It's a case of "damned if they do and damned if they don't" for Apple currently.

This is precisely what happens when you turn yourself into an "evil" company like Sony did and Apple are a long way through the process of doing - you will attract the hacker community and there will be thousands of people simultaneously trying to shame that company.

It's "infinite monkeys & infinite typewriter" syndrome - the majority of hackers will have no success with breaking into the systems or devices, but because there's *THAT MANY* doing it *ALL OF THE TIME*, eventually some will be successful.

As someone who works in security, I can tell you honestly that no company reveals successful or failed hack attempts on their systems unless they really have to - in the case of the Sony credit cards, they *HAD* to because of the potential fraud on those cards that could take place.

So you can pretty much guarantee that Sony, Apple and other "Evilcorps" are being pounded & hacked all of the time, but they hush it all up as best they can.

Re:History repeats?

[macs4all]

This is precisely what happens when you turn yourself into an "evil" company like Sony did and Apple are a long way through the process of doing - you will attract the hacker community and there will be thousands of people simultaneously trying to shame that company.

How in the HELL can you compare Sony to Apple like this?

Apple doesn't hide rootkits in their software or media files.

Apple doesn't actively prohibit "rooting" of their devices.

Apple doesn't pursue the iOS "hacker" community with legal threats, DMCA takedown notices, etc.

Apple doesn't embrace DRM every day, and in every way (they DO have to put up with SOME DRM due to pressures from "content providers"; but it is obvious they chafe against it).

Apple doesn't infest its products with an OS (Windows 7) that has DRM from the driver-level up.

Now, let's compare the above to Sony...

Re:History repeats?

[betterunixthanunix]

Apple doesn't actively prohibit "rooting" of their devices.

http://gizmodo.com/303171/apple-says-unlocked-iphones-will-brick-after-software-update-+-what-does-it-mean

Apple doesn't pursue the iOS "hacker" community with legal threats, DMCA takedown notices, etc.

http://news.cnet.com/apple-iphone-jailbreaking-violates-our-copyright/

Apple doesn't infest its products with an OS (Windows 7) that has DRM from the driver-level up.

http://tech.slashdot.org/story/05/08/01/0421248/Mac-OS-X-Intel-Kernel-Uses-DRM

Re:History repeats?

[pandrijeczko]

Apple doesn't hide rootkits in their software or media files.

Maybe not. But they were summoned to the US Senate to answer questions on privacy concerns over what they track & why they track it unencrypted.

Apple doesn't actively prohibit "rooting" of their devices.

I think you need to read the last 2 lines about possibly denying sevice on this page.

Apple doesn't pursue the iOS "hacker" community with legal threats, DMCA takedown notices, etc.

It has put the mechanisms in place to do so in the future though.

Apple doesn't embrace DRM every day, and in every way (they DO have to put up with SOME DRM due to pressures from "content providers"; but it is obvious they chafe against it).

Apple dropped DRM from iTunes about 2 years ago. It could be argued that they bowed to pressure from their user base after the Sony rootkit and CD DRM fuss. I have not come across a DRMed CD for some years now because of the stink DRM caused.

Apple doesn't infest its products with an OS (Windows 7) that has DRM from the driver-level up.

I'm mainly a Linux guy, I'm still using XP for some stuff but haven't played with Windows 7 much beyond setting up some laptops for colleagues - therefore I'm no expert on it. However, I am not aware of any restrictions on Windows 7 that stop you running non-DRMed formats on it exactly as you can do on previous iterations of Windows. I am led to believe that it provides a *platform* for DRM, again probably bowing to the same pressures from the RIAA that you said it was perfectly okay for Apple to have done during the early days of iTunes.

Just because you select a list of reasons why Apple are not evil does not mean they are not evil in other ways.

Re:History repeats?

[Anonymous Coward]

> Apple doesn't hide rootkits in their software or media files.

Nor are they a content company like sony is.

> Apple doesn't actively prohibit "rooting" of their devices.

Yeah, steve just loves those jailbreaks right? Its not like the appstore tries to prevent this or anything.

> Apple doesn't pursue the iOS "hacker" community with legal threats, DMCA takedown notices, etc.

Apple tried very hard to prosecute people who develops and performs jailbreaks but where shot down by the courts. They also issue dmca takedown notices to any hacker community who would have the balls to inform people how to install or virtualize osx on a pc (Which is a 100% pure drm stye lockdown as a modern mac IS a high spec pc) regardless of wether they want to buy the software.

> Apple doesn't embrace DRM every day, and in every way

Osx is locked using drm to prevent it running in a virtual enviroment (Which really sucks for developers), and iPod is most certainly an attempt of a locked in device that uses both drm and propriatary formats to faux competitive mp3 players. Only the competition forced them to abandon this strategy.

> Apple doesn't infest its products with an OS (Windows 7) that has DRM from the driver-level up.

Ehh..What do you mean? And how does that compare to sony anyway???

> Now, let's compare the above to Sony... ....

Re:History repeats?

[Anonymous Coward]

http://gizmodo.com/303171/apple-says-unlocked-iphones-will-brick-after-software-update-+-what-does-it-mean

That story from 2007 is not a threat, it's a warning that users can wipe out data on their jail broken phones and possibly not get it back.

http://news.cnet.com/apple-iphone-jailbreaking-violates-our-copyright/

Apple's responding to a complaint the EFF made. There's no Apple equivalent of GeoHot.

http://tech.slashdot.org/story/05/08/01/0421248/Mac-OS-X-Intel-Kernel-Uses-DRM

You're 1 for 3. The ppl who spent mod points on this post didn't read the stories that were linked to.

Re:History repeats?

[macs4all]

Apple doesn't hide rootkits in their software or media files.

Maybe not. But they were summoned to the US Senate to answer questions on privacy concerns over what they track & why they track it unencrypted.

Google, who is responsible for Android, was also called to those hearings. Apple sent a vice-president in charge of software development. Google sent a lobbyist. Apple voluntarily has already taken steps, and has promised to take further steps, to reduce both the amount of "tracking data", and to encrypt what data the user's phone does store. What has Google done/promised (I honestly don't know on that one)? But don't let facts available for nearly two months stop your rant.

Apple doesn't actively prohibit "rooting" of their devices.

I think you need to read the last 2 lines about possibly denying sevice on this page.

Yeah, EULAs always sound terrible. But point to me one instance of Apple actually doing that. [Crickets]

Apple doesn't pursue the iOS "hacker" community with legal threats, DMCA takedown notices, etc.

It has put the mechanisms in place to do so in the future though.

Again, the potential of doing it; but obviously Apple is just putting that in as a guard against an unforseeable "worst-case-scenario" threat. And again, please show me a single instance of Apple actually making good on any sabre-rattling. And didn't it get settled nearly a year ago that "Jailbreaking" was NOT illegal? Do you see Apple actively fighting that with signed bootloaders, security fuses, etc, like some Android Device manufacturers? So, your point, again?

Apple doesn't embrace DRM every day, and in every way (they DO have to put up with SOME DRM due to pressures from "content providers"; but it is obvious they chafe against it).

Apple dropped DRM from iTunes about 2 years ago. It could be argued that they bowed to pressure from their user base after the Sony rootkit and CD DRM fuss. I have not come across a DRMed CD for some years now because of the stink DRM caused.

ANYTHING "can be argued". But at least Apple's CEO published an Open Letter publicly decrying DRM. Has Sony? Howabout Google?

Apple doesn't infest its products with an OS (Windows 7) that has DRM from the driver-level up.

I'm mainly a Linux guy, I'm still using XP for some stuff but haven't played with Windows 7 much beyond setting up some laptops for colleagues - therefore I'm no expert on it. However, I am not aware of any restrictions on Windows 7 that stop you running non-DRMed formats on it exactly as you can do on previous iterations of Windows. I am led to believe that it provides a *platform* for DRM, again probably bowing to the same pressures from the RIAA that you said it was perfectly okay for Apple to have done during the early days of iTunes.

When Apple was starting out with iTunes, NO ONE would have signed up without DRM, and you (and everybody else) knows it. Even when iTunes had DRM on music, it was the weakest DRM possible. Individual songs weren't DRMed, per se; only Playlists were copy-restricted. NOTHING (but trust) prevented the user from deleting the Playlist, and recreating it, thus garnering another seven (then five) copies of a particular song. And let's not forget that iTunes also allows creating an Audi

Re:History repeats?

[joh]

Just because you select a list of reasons why Apple are not evil does not mean they are not evil in other ways.

He's still right. Apple is very good at protecting their business and has a very clear vision how things should work and an unbending will to see it through, but I can't see anything genuinely evil here. In fact lots of things Apple does are rather considerate and cautios. iTunes has DRM but still you can install the apps and music you bought on all iPads and iPhones and iPods you may own. Same with the Mac App Store: You have more than one Mac? Buy once, install on all. They don't give your data to the newspaper publishers, they use random IDs for iAD instead of Device-IDs without anyone asking them to do that. They don't code their iOS apps in a way to fail on jailbroken devices. They may go after people who try to attack them, but they quite surely respect their users and customers.

And even if the file system encryption in iOS is less than perfect at least there is encryption, other than with Android which has none at all.

Re:History repeats?

[Mysteray]

Will Apple start issuing lawsuits and court orders left and right to try and stop this? And if so will it distract people from Sony's recent actions along those lines?

I doubt it. ElcomSoft's products are favorites of law enforcement and Apple employs some crypto people who know exactly what they're doing with the product's design.

Law enforcement raids journalists' houses and confiscates their computers for Apple, Apple leaves room for law enforcement to buy software from Russians to use against Americans.

Re:History repeats?

[macs4all]

Mods? You mean -5 DISinformative, didn't you? To wit:

Apple doesn't actively prohibit "rooting" of their devices.

http://gizmodo.com/303171/apple-says-unlocked-iphones-will-brick-after-software-update-+-what-does-it-mean

From the linked article:

"But first, the bricking. Was this done on purpose? Lam doesn't think so. Jacqui at Ars believes that the firmware was completed weeks ago, and the bricking is unintentional."

Apple doesn't pursue the iOS "hacker" community with legal threats, DMCA takedown notices, etc.

http://news.cnet.com/apple-iphone-jailbreaking-violates-our-copyright/

Partially true. Apple did say this, and a Federal Court disagreed. Apple however, didn't appeal the decision, and unlike many Android device manufacturers, has not done an end-run around that decision by putting "fuses" in their microcontrollers, signed bootloaders, etc.

So, it seems that Apple had one opinion, and the Feds had another, but in the end, Apple respected the process. It sure seems like those other manufacturers are simply taking a disingenuous advantage of the fact that the lawsuit didn't name them, specifically, and that Android users (and curiously, the EFF) seem to be disinterested in pursuing the issue. Wonder why? Could it be that the EFF has an Anti-Apple bias? Nah, couldn't be!

Apple doesn't infest its products with an OS (Windows 7) that has DRM from the driver-level up.

http://tech.slashdot.org/story/05/08/01/0421248/Mac-OS-X-Intel-Kernel-Uses-DRM

Wow! Old story much?!? How long did you have to search for that one!?!

If you look at the article, you will see that that referred to the DEVELOPER PREVIEW PLATFORMS when Apple did the Intel Switch. The TPR protection did NOT make it into the actual RELEASE CODE. Obviously, Apple had a pretty strong interest in keeping their very-restricted Beta release OS protected. Let's see what that actually ended up being in the RELEASE code. A simple deleteable file and deletable kernel extension that says "Please Don't Steal OS X". Wow. Some DRM! This article refers to TPR on OS X as "The Myth That Won't Die." And of course, the very existence of Hackintoshes kinda belies strong TPM protection, doesn't it?

As I said: DISinformative. But his post is modded +5 Informative, and mine will be punish-downmodded, of course.

Re:History repeats?

[Anonymous Coward]

Apple doesn't hide rootkits in their software or media files.

Maybe not. But they were summoned to the US Senate to answer questions on privacy concerns over what they track & why they track it unencrypted.

Google, who is responsible for Android, was also called to those hearings. Apple sent a vice-president in charge of software development. Google sent a lobbyist. Apple voluntarily has already taken steps, and has promised to take further steps, to reduce both the amount of "tracking data", and to encrypt what data the user's phone does store. What has Google done/promised (I honestly don't know on that one)? But don't let facts available for nearly two months stop your rant.

...

Umm, so Apple treats your privacy slightly better than Google does.

Not a very high standard, now is that?

(Yeah, this will piss off all the brainless Googlebots. GOOD!!!!!)

Re:History repeats?

[Roogna]

Osx is locked using drm to prevent it running in a virtual enviroment (Which really sucks for developers)

It is? You mean the single file "/Volumes/Mac OS X Install DVD/System/Library/CoreServices/ServerVersion.plist" that has to exist before Parallels or VMWare will consent to installing MacOS X in a VM? The file that VirtualBox last I checked didn't care about at all? While Apple actively declares in their EULA that MacOS X (The client version, the server version EULA contains no such specific requirement) can not be installed in a VM, the actual prevention of it is being done purely on the VM side in my experience. Now mind you, they do require it to be on a VM on "Apple Branded Hardware", though again I've seen nothing specific that forces that beyond a expectation of honesty from their users.

Now in my personal experience, while working on kernel extensions as a developer, I've had on and off again luck installing OSX in VM's. As Apple's motherboards aren't exactly stock off the shelf boards. So at points the VM software hasn't exactly provided a bug free experience, but that's not really Apple's fault, they write their OS for hardware they control, it's purely up to the VM authors to provide an environment that emulates the hardware appropriately. This is true of Windows as well, I would -love- to see Microsoft provide a update to DirectX that allows it to be easily virtualized by the VM makers. But at the end of the day, Microsoft writes their own OS to existing hardware, not tailored to the VM makers virtualized hardware. I'm assuming the investment isn't worth the cost for either OS vendor.

Re:History repeats?

[Anonymous Coward]

Uh, you're quoting some story from Sep 24, 2007?

That's hardly relevant now. The reason it could brick the phone was because the jail breaking process modified the phone in such a way that when it was flashed with the new OS version, it could brick. It's actually the jail break that caused the problem not Apple.

Re:History repeats?

[macs4all]

> Apple doesn't hide rootkits in their software or media files.

Nor are they a content company like sony is.

Are you actually DEFENDING Sony's rootkits HERE, on Slashdot?!? Wow! No wonder you posted AC!!!

> Apple doesn't actively prohibit "rooting" of their devices.

Yeah, steve just loves those jailbreaks right? Its not like the appstore tries to prevent this or anything.

Huh? Citation, please!

> Apple doesn't pursue the iOS "hacker" community with legal threats, DMCA takedown notices, etc.

Apple tried very hard to prosecute people who develops and performs jailbreaks but where shot down by the courts. They also issue dmca takedown notices to any hacker community who would have the balls to inform people how to install or virtualize osx on a pc (Which is a 100% pure drm stye lockdown as a modern mac IS a high spec pc) regardless of wether they want to buy the software.

First, Apple had one opinion, the EFF had another. The Feds sided with the EFF. However, since then, Apple hasn't tried to do an end-run around that decision, like many Android Device manufacturers. No "fuses" in microcontrollers. No encrypted bootloaders. In short, no REAL effort to stop Jailbreaking. In the end, Apple respected the adversarial process. Doesn't make them evil. At all. In fact, quite the opposite.

As far as their prohibition against virtualizing OS X: As Apple has stated many, many, many times, they are a HARDWARE company. That is unabashedly they claim to make their money. Not from the sale of OS X. So, their prohibition against virtualizing OS X on non-Apple hardware is exactly in concert with their prohibition against installing it directly on non-Apple hardware. Their OS. Their rules. Doesn't make them evil, though. Just protecting their primary revenue stream, which is the sale of HARDWARE.

Besides, as pointed out in this article, it is quite possible to install OS X on, for example VMWare running under Windows 7, just like it is quite simple to install OS X on any number of hardware-compatible non-Apple computers. Apple says "Please". It does NOT run around like the Artist Now Again Known as Prince, (or the widow of Frank Zappa!), filing DMCA takedown notices of Hackintosh websites, or articles like the one above regarding installing OS X (illegally) on VMWare Server on Windows 7, let alone prosecute anyone who attempts to do so. Illegally.

> Apple doesn't embrace DRM every day, and in every way

Osx is locked using drm to prevent it running in a virtual enviroment (Which really sucks for developers),

No it isn't. See above.

and iPod is most certainly an attempt of a locked in device that uses both drm and propriatary formats to faux competitive mp3 players. Only the competition forced them to abandon this strategy.

Anyone can CLAIM anything without proof. But I DO know that NOBODY forces Steve Jobs to do ANYTHING. And least of all, write an Open Letter decrying DRM, like this.

> Apple doesn't infest its products with an OS (Windows 7) that has DRM from the driver-level up.

Ehh..What do you mean? And how does that compare to sony anyway???

> Now, let's compare the above to Sony... ....

How does it compare to Sony? Sony COULD install Linux on its machines (Apple doesn't count; because they have created their own OS). But instead, they have embraced Vista, and then Windows 7. I can't find the article now, but both have so much DRM that, even after Vista shipped (which was LONG after there was a "driver stable" version available for developers) ATi couldn't even write a damned video card driver! I guess

Re:History repeats?

[Anonymous Coward]

Looks like Steve Jobs let you out of his bedroom tonight!

Re:History repeats?

[pandrijeczko]

Google, who is responsible for Android, was also called to those hearings.

I did not say Google are not evil, I said Apple are evil.

Yeah, EULAs always sound terrible.

But it's in there - therefore Apple CAN legally use it if they want to.

Again, the potential of doing it; but obviously Apple is just putting that in as a guard against an unforseeable "worst-case-scenario" threat.

Again, it's in there. Therefore they can use it if they choose to do so.

Now, let's compare that with Sony, where it took the DoJ rattling its sabre for them to stop putting rootkits on their audio CDs.

DRM disappeared on CDs completely - because the record companies had to bow to company pressures.

Media companies do not want anyone to own anything because they want a regular payment, rental model. Apple facilitated that by allowing DRMed music to be sold through iTunes - yes, it made the record companies sign on but Apple made a huge amount of money from it - that's basically saying they were "in league with the devil".

They changed the DRM model because Sony's stupid rootkit fiasco brought it to the public attention, it became very unpopular and Apple had to backtrack. Period.

Oh, one final point. Do you not find it more than coincidence that Apple removed DRM from music downloads about the same time Amazon started offering DRM-free music. Yet Amazon are much smaller than Apple, wield less corporate power as a consequence, yet have never been *forced* to offer DRMed music. Explain that one.

Name three.

I did - please read my previous post again if you can't see them.

Re:History repeats?

[Bing Tsher E]

As I said: DISinformative. But his post is modded +5 Informative, and mine will be punish-downmodded, of course.

Actually, the opposite is the case.

This is apple.slashdot.org, not the main domain. I wonder if they will ever disclose how much Apple paid to lease the subdomain.

Re:History repeats?

[Bing Tsher E]

(Apple doesn't count; because they have created their own OS).

Not really. They tried to create their own modern OS in the late 90's. Finally after spending many millions on the project, they gave up and allowed themselves to be taken over by NeXT instead. Then they slapped their gui-paint layer on top of UNIX like some fat chick going to the disco slaps pasty makeup on.

Apple's developers don't seem to have the skill-set needed to create a robust multi-tasking OS. They concentrate more on 'style.' One-button mice (yeah, yeah, we know that was in the past.) They're a company of marketers, where trademark-buzz like 'Quicktime' and 'Altivec' are the trump cards.

Re:History repeats?

[tehcyder]

> Apple doesn't hide rootkits in their software or media files.

Nor are they a content company like sony is.

Are you actually DEFENDING Sony's rootkits HERE, on Slashdot?!? Wow! No wonder you posted AC!!!

No, he was just saying that you can't congratulate Apple on not doing something that they couldn't do anyway, in the same way that you couldn't sensibly praise Google for not using WMDs on Martian babies (yet).

Re:History repeats?

[intheshelter]

Shut up with the Evil Company scare tactics already. They are a company, they are trying to make money, serve customers AND protect their brand. Put those all in the same bowl, mix well, and then tell me if some compromises aren't necessary?

And I would also make the assertion that not only "Evilcorps" are hacked, but charities, squeaky clean companies, and little saintly grey haired grandmas are hacked. Apple/Sony/etc. aren't hacked because they are evil, they are hacked because they exist at all.

Re:History repeats?

[brit74]

> "This is precisely what happens when you turn yourself into an "evil" company like Sony did and Apple are a long way through the process of doing".
This will happen regardless of whether you are an "evil" company or not. The biggest factor seems to be how big your userbase is.

Re:History repeats?

[macs4all]

As I said: DISinformative. But his post is modded +5 Informative, and mine will be punish-downmodded, of course.

Actually, the opposite is the case.

This is apple.slashdot.org, not the main domain. I wonder if they will ever disclose how much Apple paid to lease the subdomain.

Oh, I see... Now SLASHDOT is in on the CONSPIRACY!

LOL!

If that were the case, why have I seen the score on my original comment steadily go DOWN from 2 to 0 over the course of the past several hours?!?

Better put another layer on that tinfoil hat! The mind-control rays are OBVIOUSLY still leaking in...

Re:History repeats?

[macs4all]

Google, who is responsible for Android, was also called to those hearings.

I did not say Google are not evil, I said Apple are evil.

I see. The enemy of my enemy is my friend, right? So, how does that address the valid point I made?

Yeah, EULAs always sound terrible.

But it's in there - therefore Apple CAN legally use it if they want to.

I heard your speculation the first time; no need to repeat it. However, I still challenge you to find a single instance of Apple exercising that right. Like all large companies, Apple has a legal department. A LOT of the time, companies let things go into a contract or EULA just to shut up their OWN legal team, with no actual intention of ever enforcing the language. And yes, that's what I am saying is what happened, here. And besides, the EFF case pretty much nullifies that language, anyway, doesn't it? So now what are you saying that "Apple could do"?

Again, the potential of doing it; but obviously Apple is just putting that in as a guard against an unforseeable "worst-case-scenario" threat.

Again, it's in there. Therefore they can use it if they choose to do so.

No they can't; per the EFF case. And I pointed that out, both in my original reply to your response to my original comment, and in this further reply, too.

Too bad, just like before, you aren't letting long-settled facts mitigate your rant. You do realize, of course, that that is a sign of mental illness...

Now, let's compare that with Sony, where it took the DoJ rattling its sabre for them to stop putting rootkits on their audio CDs.

DRM disappeared on CDs completely - because the record companies had to bow to company pressures.

WTF are you SMOKING, and can I have some, please?!?

The record companies had to bow to... WHAT?!? What "company" are you talking about?!? Or are you talking about "The Company" (as in the CIA), LOL?!?

The DoJ (actually, it was the DHS) made it CRYSTAL CLEAR to Sony that the user's computers WERE NOT THEIRS to install rootkits (or anything else) on. It wasn't "industry pressures", it was the threat of CRIMINAL PROSECUTION and GOVERNMENT REGULATION that moved them. That, and pressure from retailiers, who were getting sick and tired of handling more and more RETURNS for media that SIMPLY WOULD NOT PLAY in many devices.

But, my original comments still stand: Steve Jobs called for an end to DRM. And NOBODY forced him to do THAT!

Media companies do not want anyone to own anything because they want a regular payment, rental model. Apple facilitated that by allowing DRMed music to be sold through iTunes - yes, it made the record companies sign on but Apple made a huge amount of money from it - that's basically saying they were "in league with the devil".

Once again, iTunes is NOT, repeat NOT, a major PROFIT stream for Apple. This asinine meme simply HAS to die, along with your other ridiculous claim: ZOMG! the OS X Kernel is DRM'ed...

But again, you have demonstrated that even when the facts are presented in rebuttal, you simply argue on and on and on.

They changed the DRM model because Sony's stupid rootkit fiasco brought it to the public attention, it became very unpopular and Apple had to backtrack. Period.

Oh, one final point. Do you not find it more than coincidence that Apple removed DRM from music downloads about the same time Amazon started offering DRM-free music. Yet Amazon are much smaller than Apple, wield less corporate power as a consequence, yet have never been *forced* to offer DRMed music. Explain that one.

I agree that that gave A

Re:History repeats?

[macs4all]

Shut up with the Evil Company scare tactics already. They are a company, they are trying to make money, serve customers AND protect their brand. Put those all in the same bowl, mix well, and then tell me if some compromises aren't necessary?

And I would also make the assertion that not only "Evilcorps" are hacked, but charities, squeaky clean companies, and little saintly grey haired grandmas are hacked. Apple/Sony/etc. aren't hacked because they are evil, they are hacked because they exist at all.

THANK YOU!

That is the most concise, insightful comment I have EVER read on the topic of Apple == The Evil One(tm)!

Mod parent +100 Insightful!!!

Re:History repeats?

[macs4all]

(Apple doesn't count; because they have created their own OS).

Not really. They tried to create their own modern OS in the late 90's. Finally after spending many millions on the project, they gave up and allowed themselves to be taken over by NeXT instead. Then they slapped their gui-paint layer on top of UNIX like some fat chick going to the disco slaps pasty makeup on.

Since NeXTStep was already a GUI-based BSD/Mach "UNIX", what you REALLY mean is that Apple applied some cold-cream, wiped off the NeXT makeup, and THEN slapped on Mac makeup, LOL!

While I admit that that was the original plan, things didn't exactly work out that way... At least Apple was willing to accept that they couldn't realize their overly-ambitious Rhapsody/Copland "Red Box, Blue Box, Yellow Box" OS. But even then, they were able to back-port much of that development back into MacOS 8 and 9, and even OS X (what do you think "Classic" mode was?). So, not nearly as much of that work was wasted as one would initially think.

As for being taken over by NeXT, that meme started because of so many NeXTStep/OpenStep engineers that were subsequently hired by Apple to work on the Rhapsody/NeXTStep integration that was to become OS X. But the simple fact of the matter is, Apple wrote the check, not NeXT.

Apple's developers don't seem to have the skill-set needed to create a robust multi-tasking OS. They concentrate more on 'style.'

No. They already had that in the form of A/UX, But it wasn't really suited for a consumer-grade OS. What the issue REALLY was that, Apple didn't have TIME to finish what they had started, and the intended project was frankly too ambitious for ANYONE to complete in a reasonable timeframe. At least Apple was smart enough to recognize that, and act accordingly.

One-button mice (yeah, yeah, we know that was in the past.) They're a company of marketers, where trademark-buzz like 'Quicktime' and 'Altivec' are the trump cards.

QuickTime was a groundbreaking suite of APIs (and they had to call it SOMETHNG), which was then shamelessly subsequently ripped off by Microsoft (with the help of Intel). Altivec is a Motorola (Freescale) trademark, not Apple's. In fact, Apple always referred to Altivec as the "Velocity Engine".

What a shock...

[WaffleMonster]

What thou doest encrypt thou can decrypt. Unless the encryption keys are not also stored on the device...sigh....

Meh

[mark-t]

Wake me up when somebody makes a free tool that does this.

Why does encryption never work?

[benwiggy]

Can someone explain the incongruity between these two statements:

"Don't worry, your data is encrypted with 256-bit RSA."
"Computer experts have cracked the encryption."

So why doesn't the fantastic mathematically complex encyption ever work? Why should I trust https? Or any other encrypted transmission?

Re:Why does encryption never work?

[0123456]

So why doesn't the fantastic mathematically complex encyption ever work? Why should I trust https? Or any other encrypted transmission?

Encryption does work: the flaw is normally in the key handling.

There's a fundamental incompatibility between security and convenience: people encrypt the data on their phone with 256-bit AES using a password of 'password' and are surprised that it can be broken. Or they rely on the phone to encrypt their data with a key that is... stored on the phone.

Re:Why does encryption never work?

[teslafreak]

Because the only other option is just never to communicate information. All encryption can be undone given enough time, processing power, and a big enough sample of the data. The critical thing is just keeping up with the changning tactics and standards.

Re:Why does encryption never work?

[Anonymous Coward]

because they didn't crack it at all.

they did the next best thing which is bruteforcing.
although, in this case it seems they can actually extract the encryption keys to bruteforce them somewhere else. something that shouldn't be possible in good encryption.

Re:Why does encryption never work?

[tacarat]

Good encryption requires a good "key". Forget password, think passphrase.
Encryption is great when it's somebody intercepting your messages or data, but not so useful when they have access to an endpoint.
The effectiveness of a good lock is severely reduced if you can't remove the keys from it. Most hardware like this has a copy that can be gotten at by the diligent. It's how bluray ended up losing it's DRM.

Oh, and this.

Re:Why does encryption never work?

[h4rr4r]

They are liars. This tool just does a brute force attack against a backup of the device, then once the key is found it can be used against the actual device. If you have a simple password this might work, if not too bad for them.

The only lessons here are always use long passwords and "security" companies are often 1 shade off of scammers. Even simple phrases like "And its fleece was white as snow" makes a decent passphrase due to length, changing it to "And) its( fleece* was6 white5 as4 snow3" makes it even better and still easy to remember. Just a phrase and a pattern. Sure random is even better, but most users won't bother to even use a simple phrase.

Re:Why does encryption never work?

[Bryan3000000]

Well, the flaws are always implementation details. Implementation details are usually botched in mobile devices, for convenience of the designer and (perhaps) because of hardware limitations, and in web applications, for the sake of interoperability and usability. And stupidness. Don't forget the stupid.

But, if you use a known good implementation (as much as it can be known, but pretty good with some FOSS) yourself (not implemented by a web service, but by you on your machine), then it's much less likely to be vulnerable, because the convenient and intentional weaknesses tend to be eliminated.

Re:Why does encryption never work?

[sphantom]

The encryption itself is solid. What falls most of the time is the specific implementation. Say for example I made the choice to encrypt my hard drive but didn't use an already baked system like Ubuntu's home drive encryption. Instead I decided to do it by hand and code my own pre-boot initramfs to automatically handle decryption by hashing some hardware specific identifier from the bios. Except that since I'm not a security expert, I made some foolish coding error which allowed the hash to be intercepted or easily guessed. Then some hacker comes along, figures it out and now has full access to my encrypted data.

In this case the encryption itself is sound, and wasn't cracked, instead my shotty coding and/or lack of solid security knowledge was exploited. 9 times out of 10 this seems to be the case when encryption is defeated (brute forcing aside of course).

To answer your question though, why should you trust HTTPS? I'd say that you can never be 100% sure, but HTTPS has been around long enough to have been well tested by by people who rely on it being solid (banks, etc) that you're probably pretty safe. Rest assured that if HTTPS's implementation of encryption were cracked, it'd be news, and you'd know (I assume).

Re:Why does encryption never work?

[Barefoot Monkey]

RSA is usually 1024 bits or more. 256-bit sounds great if you're used to talking about AES encryption or other similar symmetric algorithms, but it's pretty small for an RSA key. I'm not an expert on cryptology (I haven't even read TFA yet so don't trust anything I say), but this looks like it was an easy target.

Re:Why does encryption never work?

[pandrijeczko]

Just to be clear on this.

The encryption algorithms are publicly documented for methods like RSA, Bluefish or any of the other countless ones - that's the point behind them being used the world over.

But knowing *HOW* the encryption is done still doesn't get you in because you still need to get or work out the encryption key that's being used.

Re:Why does encryption never work?

[jgtg32a]

Standard != Implementation

The idea behind it is rock solid, but the engineering aspect is a bit tricky.

Re:Why does encryption never work?

[0123456]

Even simple phrases like "And its fleece was white as snow" makes a decent passphrase due to length, changing it to "And) its( fleece* was6 white5 as4 snow3" makes it even better and still easy to remember.

And you're going to type that in every time you use your phone?

Coming up with a good passphrase is much easier than convincing people to go to the trouble of using one.

Re:Why does encryption never work?

[GCsoftware]

They ARE talking about AES. No one uses asymmetric encryption for large amounts of data, due to its slow speed.

Re:Why does encryption never work?

[Corwyn_123]

The thing about encryption is, it's the timeliness of data.

Anyone relying on encryption to store any data for any long periods of time are confused. Any encryption system, no matter how complex, can he defeated, given time, resources, and perhaps some skulduggery.

Look at WWII and the German Enigma machine. It was no more than a computer, and very hard to crack, in fact, it couldn't be cracked on the basis of the encrypted information itself. But it did it's job, messages were secure for the length of time that they needed to be, and even if it was decrypted after the fact, it didn't matter. It took the Allied forces stealing an Enigma device and code book to actually crack Enigma encrypted messages.

The same goes for anything, it's timeliness of information. If you encrypt something long term, and someone gets ahold of it, and they want it bad enough, and have the resources at their disposal, they will in time, get at that information.

Bottom line is 2 fold actually, timeliness of information and the fact that locks only keep honest people honest.

Re:Why does encryption never work?

[rvw14]

Even better, just speak into the phone and say, "My voice is my password".

Re:Why does encryption never work?

[betterunixthanunix]

Computer experts have cracked the encryption

Can you please point out the experts who have cracked RSA, DSA, DH, ElGamal, or ECC? Oh, right, the math has not been cracked, the only things we hear about are:

1. Specific implementations being attacked, due to bugs or poorly thought out optimizations (i.e. that lead to side channel attacks).
2. Proprietary crypto being cracked; why anyone would be using proprietary crypto in this day and age is a mystery to me, but people continue to do it.

Also, nobody speaks of 256 bit RSA in this century; the recommended key size for use with a 128 bit block cipher is 3072 bits when I last checked.

Re:Why does encryption never work?

[Anonymous Coward]

Damn, now I have to change my passphrase.

Re:Why does encryption never work?

[BitZtream]

You don't do drive encryption with asymmetric encryption, not if you actually want to use your data at any reasonable rate.

You generate a large key for symmetric encryption, then encrypt that key using asymmetric encryption.

Browsers for instance only use RSA for the initial key exchange, and then fall back to using AES or whatever is supported by both ends. Your https sessions use RSA for about 80 bytes of data exchange before the web server actually starts communicating with the client, your GET / request is sent using symmetric encryption, as is the response that comes back.

Re:Why does encryption never work?

[PRMan]

Yes, because that is uncrackable unless you can convince a woman go to dinner with a nerd, which we all know would never happen in the real world...

Re:Why does encryption never work?

[Barefoot Monkey]

Naturally. As I mentioned, I hadn't read the article when I wrote that and was responding directly to the parent poster's question:

Can someone explain the incongruity between these two statements:

"Don't worry, your data is encrypted with 256-bit RSA."
"Computer experts have cracked the encryption."

So why doesn't the fantastic mathematically complex encyption ever work? Why should I trust https? Or any other encrypted transmission?

There's no incongruity between the statements because a simple 256-bit RSA is not a great way to encrypt data.

Re:Why does encryption never work?

[iluvcapra]

Also, nobody speaks of 256 bit RSA in this century; the recommended key size for use with a 128 bit block cipher is 3072 bits when I last checked.

You only need a key size that big if you're doing asymmetric keys -- see Schneier and ridiculous key lengths. The encryption on these phones is symmetric, and the reason it's so easy to crack is the 256 bit keys are in fact selected from a very restricted space: they just take four numeric digits from the phone entry and then maybe hash them to get better bit coverage.

Re:Why does encryption never work?

[GCsoftware]

My bad, didn't get that you were replying to that.

And yes, 256-bit RSA is trivially decrypted, has been for quite a while.

Re:Why does encryption never work?

[betterunixthanunix]

Read the part of my post that you quoted, and you'll see that I did not say anything that contradicts what you or Schneier said. When using a 128 bit block cipher, the recommended size for your asymmetric keys is 3072 bits for non-ECC algorithms (e.g. RSA). That is not a ridiculously long key size, given the state of the art attacks on the RSA problem, nor does it exclude the smaller symmetric key size. I was responding to a statement about "256 bit RSA," which is ridiculously short.

Re:Why does encryption never work?

[mjwx]

Can someone explain the incongruity between these two statements:

"Don't worry, your data is encrypted with 256-bit RSA."
"Computer experts have cracked the encryption."

So why doesn't the fantastic mathematically complex encyption ever work? Why should I trust https? Or any other encrypted transmission?

Because encryption cannot get around having physical access to the device. Even being on the same network (subnet) makes things measurably easier as most OS's don't do anything about a brute force attack.

Once you've got physical access, you can easily use brute force to crack encryption, your only limitation is time. Reading the article, they have physical access to the devices they are cracking. Considering that ElcomSoft makes tools for forensics not attackers it makes sense that you'd have physical access.

Encryption does work, as network security but not as physical security. My WPA key on my home wireless network is there to stop people who are locked outside my house, it does nothing inside as someone can walk up to the modem and use a blue cable.

Re:Why does encryption never work?

[Anonymous Coward]

Can someone explain the incongruity between these two statements: "Don't worry, your data is encrypted with 256-bit RSA." "Computer experts have cracked the encryption."

So why doesn't the fantastic mathematically complex encyption ever work? Why should I trust https? Or any other encrypted transmission?

You shouldn't.

"Mathematical cryptography is usually not the weakest link in a security chain" -- wikipedia

"It is insufficient to protect ourselves with laws; we need to protect ourselves with mathematics." -- well known quote

I believe the author later recanted/revised this statement, something along the lines that mathematics is insufficient as well.

in short:

http://xkcd.com/538/

2011

[geekoid]

Year of the Mac Attack.

Re:2011

[thestudio_bob]

Um.. this is iPhone, not Mac. Unless you meant "Year of Apple Attack".

Re:2011

[geekoid]

I know, but Mac Attack sounds better.

Re:2011

[joh]

As always here: "This isn't true, you know." -- "Yeah, I know, but it sounds better this way."

Re:2011

[Anonymous Coward]

lol.. wow, just wow. thestudio_bob and joh, you guys need to get a sense of humour you ridiculous nerds. Lighten up a bit, go get laid. Original quote = funny. You = fucking retarded.

Re:2011

[aztracker1]

Yeah but Year of the Bic Mac Attack is awesome... While the "Big Apple Attack" could land you in Guantanimo...

Re:2011

[TheVelvetFlamebait]

Apple

It's spelled S O N Y.

Re:2011

[bipedalhominid]

Well, I have had a Big Mac Attack or 2.

Re:2011

[Anonymous Coward]

Year of the Mac Attack.

You definitely need the Mac Defender!

Sweet

[taxtropel]

Way to go ElcomSoft! Good to see hackers sticking it to the once hacker-originated Apple Computers Inc. Sad to see that Apple Computers has become another catholic church style entity.

Re:Sweet

[Anonymous Coward]

-1 Fucking Retard

Re:Sweet

[The Dawn Of Time]

What does that even mean?

Re:Sweet

[macs4all]

Way to go ElcomSoft! Good to see hackers sticking it to the once hacker-originated Apple Computers Inc. Sad to see that Apple Computers has become another catholic church style entity.

Wow! Up your meds, dude!

Regardless of your platform choice, are you REALLY lauding the efforts of hackers whose efforts will not hurt Apple, but rather only the unfortunate users of their products?

What about the people who have been handed an iPhone/iPad by their employer? Do they deserved to be hacked, too?

Perhaps its time for you to head to the nearest psychologist/psychiatrist. What you are experiencing is commonly referred to "Misdirected Anger", and is usually a sign of some OTHER significant "perceived wrong" you have suffered.

Or perhaps, you're just an arrogant dick.

Re:Sweet

[Anonymous Coward]

That Macs now molest young boys?

Re:Sweet

[Anonymous Coward]

Do you survive on Steve's cum alone, or does He let you swallow His shit or piss as well? =)

Principle

[iluvcapra]

It seems like this would work on any phone, in principle. If you're using a 4-digit numeric password to protect your phone, any kind of phone, yeah, somebody's eventually going to crack it in a non-end-of-the-universe timeframe, if they get unattended access to it, and you don't remote-wipe it.

Use an alphanumeric password to protect your phone. Also, it's got a ton of your stuff on it, never leave it unattended for extended periods of time, never give it to people you don't trust. A cellphone is a very personal frob and no amount of engineering is going to make it safe from hacking, modulo the sensitivity of the data contained therein -- even if you pick a 20 char, completely random password, nefarious folk can still dust the screen for fingerprints, or surreptitiously videotape you unlocking your phone...

Re:Principle

[Anonymous Coward]

Entirely not what this is about at all.

Re:Principle

[kybred]

If you're using a 4-digit numeric password to protect your phone, any kind of phone, yeah, somebody's eventually going to crack it in a non-end-of-the-universe timeframe, if they get unattended access to it, and you don't remote-wipe it.

Unless you limit the number of failed attempts (and then brick/erase the device), or have an increasing delay after each failed attempt.

Re:Principle

[joh]

It seems like this would work on any phone, in principle. If you're using a 4-digit numeric password to protect your phone, any kind of phone, yeah, somebody's eventually going to crack it in a non-end-of-the-universe timeframe, if they get unattended access to it, and you don't remote-wipe it.

Well, on most phones (like Android ones) you don't need to go that far. The password ist just for protecting you against someone using the phone, but since the file system isn't encrypted at all on most phones, you can just dump the data and be done with it.

Re:Principle

[iluvcapra]

If you can circumvent the crypto hardware and the tool has raw access to the storage, it can try passphrases willy-nilly and any such limits won't be applied.

Re:Principle

[Anonymous Coward]

While iTunes will prompt you for the PIN/passphrase, I'm pretty sure Linux doesn't give a shit and will just mount the device. There you go, free for the reading.

Re:Principle

[Vintermann]

> nefarious folk can still dust the screen for fingerprints,

I think that lipid-repellent surface of those screens is going to make this impractical. One thing Apple did right (though I hear they don't last forever).

Re:Principle

[Agret]

It seems like this would work on any phone, in principle. If you're using a 4-digit numeric password to protect your phone, any kind of phone, yeah, somebody's eventually going to crack it in a non-end-of-the-universe timeframe

On Android if you get your code wrong a certain numbers of times it will require you to log back into your google account to prove ownership. While a useful feature by design, it's incredibly frustrating if it happens when you are in an area with no data coverage (or roaming) and you can't get back into your phone.

SO what!

[kurt555gs]

If you wanted security and the ability to control what your phone is doing, and who has access, and if you delete something it's really deleted and actually know what programs (apps) are actually doing then go find a Nokia N900.

Otherwise, you are a consumer to be culled, and controlled, and not a customer to be sold on features where you are in control.

Sheep have won.

Re:SO what!

[NotAGoodNickname]

This may be flamebait but its the truth. Unless the platform is truly open you have no control. Security it out the window because it cannot be independently audited.

Use a decent password and you're ok

[jmichaelg]

From their FAQ:

Only relatively short and simple passwords can be recovered in a reasonable time.

Re:Use a decent password and you're ok

[macs4all]

From their FAQ:

Only relatively short and simple passwords can be recovered in a reasonable time.

But I thought that Bruce Schneier said that complex passwords were not any safer than short ones.

[Ducks]

Re:Use a decent password and you're ok

[Anonymous Coward]

'Ducks' is a terrible password.

Re:Use a decent password and you're ok

[BitZtream]

As is typical with people that think they 'know about security and encryption', you read one part of Schneier's statement and completely neglected the 'why' behind it.

Go read the rest of his paper, then come back. By the rest of it, I mean that it doesn't end after the first paragraph.

IN SOVIET RUSSIA

[Jeremiah Cornelius]

iPhone Cracks YOU!

Re:IN SOVIET RUSSIA

[tripleevenfall]

When Appil Computering tells me only $100 per month, most premium mobile package.... I jump in it!

$320 Brutus

[HTH NE1]

The application is called the ElcomSoft Phone Password Breaker and costs around $320 for the Professional edition.

So this is not going to be another way to get your own apps onto the iPhone without jailbreaking, but rather reducing to a $320 barrier and sufficient period of time of your not having possession of your iPhone modulo the weakness of your passcode to your plausible deniability that someone has planted something on or used your iPhone for nefarious purposes without your knowledge.

Remember, the answer to the question "Has this item ever left your sight?" is always "Of course it has." The question is to establish your liability for the contents therein.

Re:iPhone Anal Security Gloryhole

[Anonymous Coward]

Sounds like you're upset about Steve Jobs NOT violating your asshole.

They aren't first to have this

[erroneus]

You can bet that US and other law enforcement have probably been given the keys already. After all, how else would those [unconstitutional] mobile phone searches of US citizens used during US border crossings be able to work so easily and efficiently?

Re:They aren't first to have this

[Anonymous Coward]

They just search blackberries?

Re:They aren't first to have this

[Mysteray]

Simple, they use ElcomSoft. The iPhone4 is fairly new right?

They didn't crack the crypto, just the security

[StandardCell]

Folks have a hell of a time understanding the difference between security and cryptography, and the misleading sensationalist headlines don't help.

Cryptography is merely the study of hiding and unhiding information. It doesn't secure information. Security is about securing information from unauthorized access. These guys attacked the security of the device, probably through the protocol or through insecure hardware.

If the crypto itself (probably AES-256) had been broken, the NSA would have had some big problems on their hands due to the fact that the same crypto is used in the publicly-available Suite B algorithms.

Phone _hardware_ or the backup images?

[GCsoftware]

From my reading of their FAQ, it seems that this tool can be used to decrypt the encrypted backup images that iTunes takes when syncing the phone, not the phones themselves.

Am I wrong? If it's the backup images, then I see the potential attack vector as slightly less serious as an iPhone is usually a lot easier to lose / have stolen from you than the machine you sync it with.

If you compromise physical access...

[Anubis IV]

...security is already compromised. We've known this forever. This new method requires 40 minutes of physical access to the phone. Either your phone has already been stolen, in which case they have all the time in the world to try number codes until it opens up for them, or it's been taken by the police, in which case you can probably be compelled to provide the codes necessary to access the device. Either way, this doesn't change too much. And if either of those concerns you as being too risky, why were you using a mobile phone to keep sensitive information in the first place, instead of something designed specifically to hold confidential information?

mkay

[Anonymous Coward]

Since when did a brute force dictionary attack become encryption breaking?

exponential back off?

[MetalOne]

Why does the software permit repeated rapid login attempts? Why isn't there some sort of exponential back off time between retries?

Re:exponential back off?

[joh]

Well, maybe because there is a setting that just wipes the phone after 10 failed attempts.

Re:exponential back off?

[Mysteray]

The idea is that you would obtain a backup or image the data with a backdoor interface, then use this software to guess the password.

Re:exponential back off?

[tftp]

maybe because there is a setting that just wipes the phone after 10 failed attempts

May I borrow your locked iPhone for a minute?

Re:exponential back off?

[Cimexus]

Uh ... there is? At least on my iPhone there is. After the 5th attempt it makes you wait increasingly long between each further attempt. By the time you're up to 8 or 9 attempts you're waiting hours. On the 10th or 11th, it wipes the phone completely.

SSL 2, weak ciphers, renegotiation, foreign CAs

[tepples]

Rest assured that if HTTPS's implementation of encryption were cracked, it'd be news, and you'd know (I assume).

SSL 2 has been cracked. Weak ciphers used in SSL 3 and later have been cracked. SSL renegotiation has been cracked. Root certificates owned by governments whose interests are not aligned with those of the United States and western Europe have been included in major web browsers' default repositories. And yes, they were all news.

Re:SSL 2, weak ciphers, renegotiation, foreign CAs

[Anonymous Coward]

What weak cyphers were cracked? Or are you referring to "brute forced" which is kind of not cracked. Cracked means there is a flaw in the design of the algorithm.

Similarly, Apple's encryption was not cracked. The passphrase to the key was brute forced. That's night and day difference.

Renegotiation was not "cracked". Renegotiation worked as intended - it is the software that used renegotiation that failed to view the two streams as separate connections, as it should!

CA is a known issue and it has everything to do with convenience, not cryptographic weakness.

Therefore I question your understanding of the facts and what "cracked" means.

Re:SSL 2, weak ciphers, renegotiation, foreign CAs

[Mysteray]

Renegotiation was not "cracked". Renegotiation worked as intended - it is the software that used renegotiation that failed to view the two streams as separate connections, as it should!

Except that renegotiation was developed by the very same people at Netscape and for the same specific purpose that it got used for: changing crypto parameters and client certificate authentication after the HTTP request had been made.

And the value of this is ... nil?

[BitZtream]

Unless you encrypt your backups and forget your password or your backups are stolen, its pretty much pointless.

I really don't see the point in encrypting my backups because well, if someone can get to my backups, they'd be far better off just taking the source data off my laptop.

Seriously, by the time someone can get to your backups, they have a larger more important device at their finger tips ... you know, the device that the iPhone got the data from in the first place, just use the source.

This is basically like being proud that you can decompile a windows app ... and ignoring the fact that you already have the source code since you wrote the app in the first place.

Re:And the value of this is ... nil?

[Eivind]

That depends on how you do backups, I guess ?

I do off-site backups by rsyncing to a TB-disc in the basement of a co-worker. (and he does his off-site backups by rsyncing to a disc in my basement)

This gives us both reasonable security against possibilities like flooding, fire, burglars or lightning-strikes that could all potentially destroy both my laptop, and all in-house backups at the same time.

By using encfs for the backup, I preserve the property of only needing to sync changed files, but at the same time keep reasonable privacy.

Yes, a lost pass-phrase would mean a worthless backup, but this being a secondary backup, that's acceptable. (I'd lose the data if my house burnt down AND I forgot the password at the same time)

Re:And the value of this is ... nil?

[djrogers]

The real advantage to encrypting your iOS backups is that when you do iTunes will then back up WEP/WPA passwords, mail passwords, and possibly some other sensitive stuff I've never noticed before. For obvious reasons these are normally left out of the unencrypted backup, so encrypting makes the restoration process much smoother.

TFA, TFA...

[Anonymous Coward]

Looks like TFA didn't read TFA.
Or misunderstood it big time. All of the comments are also about their OLD TOOLS which are related to brute forcing and analysing the BACKUPS and have nothing to do with this hardware encryption getting cracked.
If you read the blog post they say there that there is some data that's not included in the backup that you can access with the hardware encryption keys.
Also they're saying they don't want this ending up in the "wrong hands" and will only offer it to governments and such.

A system is only as secure as

[tepples]

Apple's encryption was not cracked. The passphrase to the key was brute forced.

Or maybe it was the fact that Apple's passphrase implementation allowed trying more than three passphrases in three minutes, or more than 24 passphrases in 24 hours.

Renegotiation worked as intended

A system is only as secure as its deployed implementations. If every widely used implementation of TLS fails to treat a renegotiation as a FIN, then TLS fails to treat a renegotiation as a FIN.

I question your understanding of the facts and what "cracked" means.

We have run into Layne's Law of Debate, and useful discussion can't proceed until we get our definitions straight. A cipher is only one step in a complete cryptosystem. If you intend the word "crack" to apply only to a dramatic reduction in the effort needed to brute-force a cipher, what word do you prefer for breaking parts of the system other than the cipher?

Re:A system is only as secure as

[CheerfulMacFanboy]

Apple's encryption was not cracked. The passphrase to the key was brute forced.

Or maybe it was the fact that Apple's passphrase implementation allowed trying more than three passphrases in three minutes, or more than 24 passphrases in 24 hours.

Or you actually need to jailbreak the iPhone and then run the brute force program bypassing Apple's passphrase blocking implementation. http://www.h-online.com/security/news/item/ElcomSoft-cracks-iOS-encryption-system-1250526.html

Re:The DMCA give's you the right to hack your phon

[binford2k]

And it also gives you the right to use an apostrophe correctly! Hint: you're not!

Your comparing Apples to Apple

[Anonymous Coward]

"Don't worry, your data is encrypted with 256-bit RSA." - Marketing Department of Encryption Tool Provider

"Computer experts have cracked the encryption." - 'Journalism 101' Headline to generate ..... 4. Profit

Encryption is not designed to prevent anyone from learning the clear text of the data
Encryption is designed to make the level of effort required to obtain the clear text greater than its value

It might be 'worth it' to take my laptop if it is left unattended in a busy food court
But it would not be worth the effort if I locked it to a table and let the security guard play Asteroids on it while I was gone.

 

too many fails and wipe

[Anonymous Coward]

most enterprise iphone deployments will be set to wipe after x key failures - does this get by that?

Those russians

[Anonymous Coward]

we should've nuked them when we had the chance

.Re:generating keys

[Anonymous Coward]

There are at least two ways to provide sufficient entropy for generating a key: one uses a piece of hardware (based on something such as a small piece of radioactive material) to generate random bits; the other uses something like the mouse, and asks the user to wobble the mouse for a while to get its random bits.

You can stop holding your breath now :)

Worst Article Ever

[onefineline]

N/T

Misuse of encryption

[Bert64]

I have an iphone, and several other phones (blackberry, android etc)...
And correct me if i'm wrong, but when i power on the devices they boot up, and then automatically start talking to the network and retrieving email etc...

Surely then, even if the data stored on the phones built in flash is encrypted, the key to that encryption must also be on the phone somewhere in order for it to boot on its own, otherwise it would require the key be entered in order to boot at all.

Surely then, given that the encryption key must be stored somewhere on the device, its only a matter of having the necessary skills (or easy to follow instructions) in order to work out where that key is stored and how to use it to unlock the data.

The key lock on the screen is irrelevant, as the phone has already booted and is working in the background.

So you basically have security through obscurity.. And you can bet that there are nefarious groups out there who have already worked out how to extract unencrypted data from all of the major phones.

Apple should....

[hesaigo999ca]

Apple should just offer the means to view in regular format your stuff on your iphone in order to do easy backups....drag and drop from your device into a windows folder in order to have more control over the file system. Heck, the only reason why i would consider this tool, is to make sure my backups are properly made, that itunes has to be the worst piece of crap software i have ever used.....this whole thing with trying to manage your allowed devices vs. trying to limit who will replicate the data (if at all)....is really a pain in the backside. I get it for mp3s, but why cant i just be able to see my notes or my documents that are NOT mp3s in order to just drag and drop which i want to copy over, they are my notes after all......

Unless someone has a better system with their backups for their iphone that i am not aware of which they could share with me,
i guess i will be one of their first client in north amercia for their new tool....

limited

[LoganDzwon]

Article is misleading... "This includes historical information such as geolocation data" unless they are talking about your photos, there really isn't any geo data. "browsing history, call history, text messages" are not encrypted on iOS4. "emails, usernames, and passwords." These actually are all encrypted. So this tool lets you brute force a passcode so you can get the e-mails stored on the phone. Usernames are there, but what they are for is hashed in way you can't really map it back to what it's for. The passwords are hashed using an method which I don't know of anyone having broken yet.

The Friendly Article is wrong

[xylog]

Based on the information in the Elcomsoft Phone Password Breaker FAQ the article makes some mis-statements. The article states the software allows you : '... to recover data and perform forensics on devices." but according to the FAQ the software does not operate on the device itself but rather on backups:
Q: So, what is it all about?
A: Phone Password Breaker takes care of password-protected iPhone, iPod Touch and iPad backups.
The article also states: "What ElcomSoft did was to create a toolkit that allows for the extraction of the encryption keys from such a device." but again according to the FAQ you cannot recover encryption keys from the device. As stated above the software only works on backups. In fact they state at the very top of the FAQ: Q: Will your product jailbreak my iPhone, unlock it from the carrier, remove passcode lock, or reset a SIM card PIN code? A: Sorry, no way. This also debunks the various posts claiming that this attacks the iphone unlock password. According to the FAQ, the software performs a tailored brute force attack on iphone and blackberry backups which have a different password than the device unlock password.

This is a troll?

[Daetrin]

Seriously mods? Are you perhaps unaware of the whole recent Geohot thing and Sony's response to it? And how the hacker community _seems_ to have responded to that? Or is it somehow being a troll to wonder if Apple, when confronted with a very similar situation will make a similar decision and be faced with a similar response?