Throwing Light On Elcomsoft's Analysis of Smartphone Password Managers

An anonymous reader writes "Security firm Elcomsoft analyzed 17 iOS and BlackBerry password-keeping apps and found their actual security levels well below their claimed level of protection. With additional digging, however, Glenn Fleishman at TidBITS found that Elcomsoft's criticisms rely on physical access to the apps' data stores, and, for some of the more common apps, on the user employing a short (6 characters or fewer) or numeric password. In other words, there really isn't much risk here."

Re:

[jmcvetta]

Awww dude, put your name to it! There's so much that you said that's just right, and yet so much you said that's just asininely wrong.. but who wants to debate an AC?

My scheme

[Anonymous Coward]

I just add my ss # and phone number and bam - secure unforgettable password!

Re:

[DMUTPeregrine]

Bah, that's too easy to discover! I use really secret values that nobody knows, like a secret number where the ratio of the sum of the the secret number plus one is equal to the ratio of the secret number to one. No one has ever used it, and nobody else has the mathematical genius to calculate it!

WTH

[Anonymous Coward]

Glenn Fleishman does understand that encrypted data should be safe even in the hands of the enemy? Also, totally didn't read that article.

Re:

[Anonymous Coward]

I have no idea why someone would gloss over / apologize for half-baked attempts at practical crypto, as Glenn Fleishman appears to have done here ("oh yeah, it's not really secure, did you reeeally need that?"). Does he have a horse in this race?

Re:WTH

[rtfa-troll]

I have no idea why someone would gloss over / apologize for half-baked attempts at practical crypto, as Glenn Fleishman appears to have done here ("oh yeah, it's not really secure, did you reeeally need that?"). Does he have a horse in this race?

Very good question (mods; you should be reading at -1). Having looked about a bit it seems that he has been recommending this password software, for example he recommended 1password pro [tidbits.com] which has multiple problems; doesn't use the keychain; encourages use of a PIN for security and (to quote Elcomsoft):

Thus, very fast password recovery attack is possible, requiring one MD5 computation and one AES trial decryption per password.

When you write articles on a topic you likely get advertising revenue from that, so it's possible he's also being attacked on his income. As they say, "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!" (N.B. I am not suggesting concious corruption or something).

In the end I guess I had better put it in an obXKCD which puts this better than I could [xkcd.com].

Re:

[eggboard]

I'm never sure if Slashdot commenters read the original article or the blurb.

In the article, which I wrote, I explain the precise degree of risk, who is at risk, and how to mitigate.

* Recommending software: I did not write the article about 1Password Pro; Joe Kissell did.

* I do not receive a share of advertising revenue, nor is any my writing for any of many publications based on advertising revenue. I receive a fixed fee arranged in advance. Only the publication knows whether or not advertising was justifi

Re:

[rtfa-troll]

Thanks for responding. First I'd like to apologise. I tried to make it clear that I don't think you are deliberately trying to mislead. I clearly failed. I'll say it again but more clearly. Nothing I could see in the article you wrote made me think you were acting in anything other than good faith. I think you should have written some things differently, but I do not see this as a deliberate attempt to mislead.

Now this is my understanding of the situation as it is now and why I think your publicatio

Re:

[rtfa-troll]

Sorry; one part of your comment I didn't respond to with my other post [slashdot.org]. I read your original article (considered immoral around here; I took the "rtfa-troll" tag specifically so I could claim to be trolling if someone caught me doing this). You mentioned risk mitigation; I was not convinced by your arguments and they have mostly been answered elsewhere in the comments thread. I will point to some:

There is more risk if the cracker obtains access to your actual device, but that person must have significant

Re:WTH

[binarylarry]

I think Mr Fleishmen is well aware. After all, he is a columnist for an Apple magazine and has a degree in art.

Elcomsoft has only cracked bluray, dvd, HDDVD and most other forms of commercially available encryption. They're practically noobs and probably don't even own in iPhone between them (LOLZ!).

Re:

[beelsebob]

Actually, no – encrypted data absolutely isn't safe in the hands of the enemy. Assuming that the enemy can identify what's an important message, they will eventually crack it (by brute force if necessary). That's the key to why your messages are secure on the internet – your enemies can't identify what's important and what's not.

Re:

[chrb]

As far as we know, data encrypted with a random key and modern algorithms ought to be safe in the hands of the enemy. I say as far as we know, because the NSA does not reveal exactly what they can and can't crack. There is no practical way to brute force any of the modern algorithms: 256 bits is roughly equal to the number of atoms in the universe. [zdnet.com]

Re:

[jhoegl]

How can something be "roughly equal" to something else? o.O

Re:

[philip.paradis]

Maybe this will help [wikipedia.org].

Re:WTH

[philip.paradis]

You have demonstrated a profound level of ignorance of the most basic elements of cryptography. May I suggest spending some quality time with Applied Cryptography [schneier.com], among other notable and readily available references in the field.

Re:

[rtfa-troll]

The entire threat model for a password safe is that your phone gets stolen. Otherwise a plaintext list of passwords would pretty much do. If the enemy never gets the data then they can never do anything with it even if it isn't encrypted. Oh, and what the others said about bruteforcing.

KeePass?

[hawguy]

This isn't one of the ones they tested, but does anyone know how safe KeePass [keepass.info] is?

I use this on my desktop and Droid, which is pretty convenient since I can share the database file between them.

Re:KeePass?

[unrtst]

KeePass [keepass.info] is also available for PocketPC, Winodws Phone 7, iPhone/iPad (multiple versions), Android, J2ME, BlackBerry, PalmOS, Linux, Max OS X, Windows 98 thought 7 + Wine + Mono, and there are libs that tie into several programming lanuages.

I read through the article, the linked PDF, and the PDF linked from the PDF to find out they didn't even test KeePass, which, AFAIK, is one of the most popular and widely available password managers out there.

I really hate it when someone claims to do a thorough test on something and states something like either "Of all the X we tested, none of them passed" or "Of all the X we tested, only one came close to passing". The former makes me think they should get off their high horse and write it themselves if it's so obvious. The latter that they're just trolling to push one product... especially when there are glaring holes in the tests.

Re:

[sapphire wyvern]

Do you have any knowledge of which iOS implementations are better? I just got my first iOS device and I'm wondering which version of KeePass to install. It would be very bad news to pick one that isn't trustworthy.

Re:

[BagOBones]

MiniKeepass for iOS is good, doesn't have built in sync but supports passing the database between apps like dropbox.

Don't know if the implementation is good. It defaults to a pin / remember password option but you can dissable that.

There are several others however only look at the ones that have updated recently. Several are in the app store but are very out dated.

MiniKeePass is the cheapest one that supports the current 2.x file format.

Re:

[sapphire wyvern]

Thanks for the advice. I'll look into it.

Re:

[Elrond, Duke of URL]

I use KeePassX, a derivative of the original KeePassX. It is also open and under the GPL. I gather that the major difference between it and the original KeePass is that its cross-platform nature is not dependent on Mono/.Net. The downside is that it does not yet support the KeePass 2.x DB format, but since I'm not using that, I don't mind.

I use KeePassX [keepassx.org] on Debian, the Windows port under Win7, and KeePassDroid [keepassdroid.com] on my phone. It all works really well. My only complaint with KeePassDroid is that it doesn't

Nested links

[Scutter]

So, the summary links to a summary, which links to a PDF of another summary, which links to a PDF of the actual study. Did we forget how the web is supposed to work?

Re:

[Anonymous Coward]

sure, page views and ads.

Re:Nested links

[definate]

Here's a direct link for everyone
“Secure Password Managers” and “Military-Grade Encryption” on Smartphones: Oh, Really? by Andrey Belenko and Dmitry Sklyarov [nyud.net]

Pretty sad though...

[sshock]

It is pretty sad though how many of the apps don't encrypt the user data at all, or it's encrypted but the master password is stored in plaintext or is encrypted with a hard-coded key. Then there's many of them using strong crypto algs but not properly (e.g., what is the point of using PBKDF2 but with only 3 iterations?)

Casted vs Thrown Illumination

[VortexCortex]

Shedding Light, Casting Light, or Bringing to Light -- but Throwing Light on something? Is this a thing? I mean, you can Throw a Switch, but Light?

That said, unless you're encrypting the datastore

However, the risk is quite low even without considering the issue of short (six or fewer characters, including letters, numbers, and punctuation) or solely numeric passwords. For starters, access to the app’s data store is required — either via an iTunes backup or an iOS device containing the app and its data — and any iOS security controls must be bypassed first. The flaws that Elcomsoft has identified cannot be exploited (as far as is currently known) over the Internet, which further limits exposure.

I wouldn't be too concerned if this were desktop PCs, but these are devices you carry around with you and may leave laying somewhere while you go to the bathroom, or have stolen. You shouldn't keep all your important passwords as plain-text in your wallet or purse... A weak password store is not much better than this.

There's a much higher chance of physical access to a portable device, especially one you carry with you everywhere in public, than there is to the desktop PC. This is why physical access is less of a concern for PCs than having it remotely exploited: You don't drag it around in public.

Physical access to the device means game over unless the data-store is strongly encrypted. Data Extraction Devices Exist [cnet.com], and police have been using them without a warrant. To my knowledge these devices don't work on iPhones, yet, but anything in plain-text or enciphered weakly would still be a concern if physical access to the device is gained.

Having a password store with a weak password is a bit alarming. If you're going to have a central point of failure in your pocket, out on your desk, in your hand on a cab, then the security of that single point of failure is very important. I know an unscrupulous cab driver who gets $50 for handing your forgotten phones over to street thugs. They pay $75 if the device hasn't been locked. The thugs actually use Faraday cages to prevent remote wipes. The point is: They're already interested in your data. It's only a matter of time until they have tools to brute force your password stores, they may have them already. With a weak password that can be brute-forced in one or two days, this is an issue that would cause me concern. That is: I'd want a stronger password and a manager that requires re-auth after standby mode is entered -- Laymen, like my brother, actually think 4-6 character pass-code is adequate to protect their bank credentials.

IMHO, the fact that they allow such weak passwords for such an important single point of failure is a serious design flaw. If a weak password is used there should be some minimal end user education, perhaps via big splash screen saying: "Your Password is Very Weak -- Do Not Store Important Passwords in this Password Store"

Re:

[jimicus]

To my knowledge these devices don't work on iPhones, yet, but anything in plain-text or enciphered weakly would still be a concern if physical access to the device is gained.

Your knowledge is wrong. The manufacturer [cellebrite.com] has a list of supported phones, and every iOS device is on there. It even claims "iOS physical extraction, decoding & real-time decryption"; which suggests that either they've found a weakness, they have a backdoor in or they're making overblown claims and it simply tries a dictionary attack.

I have no idea how much they cost, whether the manufacturer has any qualms about selling them to whoever wants to buy or if they're sufficiently widespread that someone suit

Re:

[bsane]

I have no idea how much they cost, whether the manufacturer has any qualms about selling them to whoever wants to buy or if they're sufficiently widespread that someone suitably unscrupulous could easily buy secondhand, borrow or steal one.

Like local law enforcement?

Not Surprising

[aaaaaaargh!]

I'm the maker of a password manager for non-mobile platforms and can't think of any technical reasons why a mobile app would be less secure, as long as you don't intentionally sacrifice security for performance. However, from my own surveys of my "competitors" on Linux, Windows, and OS X I can assure you that not half of the programs out there can keep the promises it makes.

One thing you might check out to evaluate such apps is whether the encryption method is made public and whether the author explains exa

No surprise

[gweihir]

In fact, I find that the more bold the security claims, the worse the actual security. Have seen this several times now. Be especially wary if somebody claims "Security is our highest priority". It means in fact: "Our security is so bad, that fixing it should be our highest priority, but it is not. We asked the PR people to fix this instead."

Most people implementing software today have no clue about security and that includes people writing security products. It is really pathetic. I think the reason is peo

One problem I see...

[rthille]

One problem I see with phone-based password managers without hardware assisted crypto is the huge difference between the CPU power on the phone and even a $3000 dedicated cracking box. One thing the PDF quantifies is the amount of CPU/GPU time it'll take to generate a key for test decryption. 1-Password (the tool I've got, but haven't started using yet due to paranoia :-) uses just a single round of MD5 to generate the key, so key generation is fast. So fast that the GPU rig can test all the passwords pos

Mobile Password Security is a Generic Problem

[jasnw]

I purchased an iPad just after the 2 came out - I'm still wondering if that was a mistake. One of the main issues I am always wrestling with is how passwords for website access are handled, or not handled is more like. Safari doesn't have a protected username/password store capability (unless you consider AutoFill to be a nice secure way to store this info on a mobile device), and the third-party stuff like 1Password can't talk to Safari because of sandbox restrictions with iOS. Why is it that strong credentials security for accessing web-based information isn't a major component of mobile OS's? For me, it's now the main reason I don't get an iPhone and will likely turn my iPad into an expensive gaming pad for my grandson. (Yeah, I'm old - bring back Big Iron.)