One problem we have with more and more services moving into the cloud is to provide appropriate security. The goals for the user are simple, if a bit contradictory:
- her data must not be disclosed against her will,
-
no one else should be able to pretend to be her to others,
-
it should be easy to authenticate herself to the service, and
-
she does not want to loose anything should she forget her authentication.
The ideal solution would be a token, equipped with biometric sensors, to be your key to all your accounts, with a backup stored somewhere, which uses your DNA to authenticate you. Currently this is not feasible, and even the intermediate step of having a key storage that would do manual DNA checks is too expensive.
So we are stuck with using passwords, ungainly constructs that need almost 50 letters and/or numbers to encode a password of 256 bits strength. This can be reduced to 90 bits, or around 16 symbols, if you encode the password using a key derivation function set to 10ms, but this remains too unwieldy to remember for all but your master key.
If we could make the assumption that there is a secure storage for all our complicated passwords, then the ideal model for security would be simple: have one regular password, and a backup. The backup could only be changed with the knowledge of the current backup, and email addresses would no longer be sufficient to demonstrate your identity. One would move to this model by sending a conformation link to your email when you first enter the backup password, and publicizing the fact that you should add the back up password soon.
The closest we are currently are with two factor authentication methods that generate a recovery key, and where you can disable the confirmation channel to enforce using your recovery key. Unfortunately this does not work for Apple IDs: you always require two of account password, recovery key, and a trusted device to authenticate, and once you are authenticated you can reset the third factor. Given this weakness I’d assume that iCloud content can be accessed with with a subpoena. That the recovery key is a bit short with 14 characters or roughly 80 bits of entropy is a minor issue in comparison.