There are some tell-take signs that this is a cursory inspection by soemone who is not familiar with the iOS security environment.
Firstly, the statement that the passcode is only 4-digits. Not knowing that this can optionally be switched to a far longer string, and that this option can be mandated by policy in secure environment, is an indication that the author is making his inference just by looking at the GUI.
Also, whilst it's true that the passcode can be brute forced, this must be done on-device and so requires a non-trivial rig (which even then will be encumbered by the work required for each try), or a many-hour manual attack.
Well, yes and no, the fallback for TouchID must be handled in app and is not related to the pin you use to unlock the device.
Most app I've seen use the same 4 digit pin format, but nothing is stopping them to ask for a full password...
Also, there's a pretty good keychain API to handle encryption, and you shouldn't need to derive any key from any password to safely encrypt stuff...
For me, it's not really a problem with the TouchID implementation, but with each developer knowing what they are dealing with...
I think you might have read this article a bit too quickly. It's about apps using TouchID to protect access to the app on an unlocked phone, and whether that is worthwhile or a false sense of security. The passcode in question is a dropbox one that is distinct from the system-level iOS one.
A 4-digit passcode cannot be brute forced if the application is dependent upon an external service. After N bad attempts, lock the user (which I'm sure dropbox does.)
The default lockscreen passcode works the same way. After several attempts it will lock the phone and prevent further access for some time.
Brute forcing a PIN on iOS is not particularly practical in the same way brute forcing auth via a script isn't practical (so long as the system wasn't designed by idiots).
Sure, my point is just that a server-side check is immune to attack (assuming the server is not compromised.) A client-side check is subject to other exploits allowing the attacker to get around it.
Either way, you're right, it's pretty much a given that brute forcing a 4-digit passcode in iOS is far from easy, regardless of context if the developer knows what they are doing.
I think Apple could remediate this by extending the Local Authentication API into a get/set keychain-backed method.
You'd do something like [TouchID getLocalAuthFor:"uniqueIdentifier"] and success would return the secret. The app could store a one-way hashed copy of the secret to verify the correct value had been received. This would also rely on using encrypted local storage otherwise this all gets bypassed by USB access.
This would require extending the keychain on iOS to include items decryptable/retrievable only with TouchID biometric information.
... And there comes the rub: your fingerprint information is local per device and not transferred. These keychain items would only be decryptable on the same device and only as long as you don't replace your recorded fingerprints.
This may be part of why Apple is only doing a yay/nay API at the moment - because anything more starts verging into people/devs complaining they can't unlock their secrets when iCloud Keychain or device replacements are in use.
Apple is not currently transferring your TouchID biometrics between devices and I'm pretty sure this is a business they're intentionally avoiding.
Summary: The Dropbox passcode lock is only a view preventing access to the app, but does not encrypt anything. Dropbox' use of Touch ID does not improve on this and it uses a Touch ID API that only provides a yes/no answer.
> Instead, it could actually grant access to cryptographic keys. As, however, the keys would still be stored on the device (although in the keychain), this is merely a compromise, albeit one which could actually provide added value (ACL protected items are not backed up).
That's all Touch ID can do. The data stored in the keychain (with a kSecAccessControlUserPresence ACL) is encrypted with a key the secure enclave needs to provide (or it is asked to decrypt an item-specific key). So without the secure enclave agreeing, which it only does when it finds a matching fingerprint, you can't get the data. What more can you expect?
Funny enough I recently implemented touchID for my company (Mustbin).
The local authentication framework APIs only provide a place to store data. In our case we use touchID as a secure keystore for client side decryption / encryption keys, certificates, etc. If you don't have a touchID device we fall back to storing keys encrypted via passcode and also protected by the device hardware encryption (the data protection API). If someone where to hack the app to bypass the touchID window you couldn't get at the data since it is encrypted at rest.
A wierd oddity of the local authentication framework is that if the user deletes the application the keychain isn't deleted, so if you naively delete and reinstall the app you get back old keydata :(
It seems the key point of the article, obfuscated by discussions about hiding UIViews and the limits of the Touch ID API, is that the dropbox app does not encrypt the files of your dropbox account using a shared secret key. I think everyone already knows this.
It is kind of interesting that Apple has provided an authentication API via Touch ID, but no similar authentication API for non-Touch ID. So you have to roll your own if you want it to work on older devices.
Firstly, the statement that the passcode is only 4-digits. Not knowing that this can optionally be switched to a far longer string, and that this option can be mandated by policy in secure environment, is an indication that the author is making his inference just by looking at the GUI.
Also, whilst it's true that the passcode can be brute forced, this must be done on-device and so requires a non-trivial rig (which even then will be encumbered by the work required for each try), or a many-hour manual attack.
The link-bait title is another tell-tale.