Apple could much more properly do something with embedded keys on the iPhone (and next-gen Macs), in addition to passwords, email, and KBA. I'd consider it acceptable if Apple restricted some actions to Apple client devices, if you've got an apple client device registered, at least as an option.
Twitter is unforgivable, though. They have a fucking mobile client and are pushing that hard (at the expense of their developers). They are fairly neutral and non-hated by both Apple and Google (and probably Microsoft and RIM too). They are pushing Twitter logins to services. They borged one of the best cryptographic software developers (Moxie). They have users in places like Syria where compromise of an account can lead to torture and death.
It would be so obvious to turn the Twitter mobile client into a key management app and security tool, both for Twitter and for services using Twitter login.
(Facebook could do the same, modulo some hate from Google and Apple).
To elaborate: on a PIN debit payment, for example, there are two factors - something you have (the debit card) and something you[1] know (the PIN). In the case of authorizing the purchase of an app, you obviously have physical access to the device, or else you wouldn't be able to get to the checkout screen. For an actual second factor in a MFA scheme, it would be necessary to have a _different_ device that only the user with authority to make a purchase would have access to.
One could argue that if the device is PIN-locked, this is sufficient; however, in this case, you're replacing a physical factor (having the device) with a knowledge factor (knowing the unlock code). Combined with the account password [2], you still only have one-factor auth, it's just two steps. This is like most banking logins: there's a single authentication factor - knowledge - but two different pieces of data are necessary.
Worse yet, that "mother's maiden name"-type info tends to be a) relatively easy to access as an unauthorized user and b) used to authorize password reset, thereby reducing the security of a possibly-great password down to your facebook account's privacy settings.
Suffice to say, proper MFA support when the device often used as the physical factor is part of what's being authenticated is non-trivial, and almost by definition requires additional hardware. Perhaps some sort of NFC/RFID tag that you'd keep in your wallet, or a less clumsy equivalent of an RSA keyfob (which is where TOTP came from in the first place). But the key takeaway here is that you cannot use the device being authenticated as part of the authentication scheme.
[1] and only you, I hope! otherwise there's no point. [2] or worse, not, as some have suggested for free or even paid apps
If you trust the hardware enough, I'd even accept on-device pin checking (i.e. a 4-8 digit numeric passcode), verified inside the secure element, instead of a password which went to the remote server. It would be two factor local, and one factor to the server (operations proving control of the private key).
For this all to work, you need to 1) prevent users from saving the passcode (easily enforced by the mobile OS, and pretty safe for a 4-digit passcode) and 2) protect the key using a hardware secure element, and prevent users from copying it willy-nilly. Otherwise it could become a single factor ("saved key + saved passcode", stored in the same place) very easily. Depending on your system, you may have a mandatory requirement to prevent that technically, or do it through policy, or let users do it.
It's kind of a philosophical argument at what point something becomes something you know vs. something you have, if it's just a long number.
Go ahead and steal my RSA token, and see what good it does you on its own. None, right? Not unless you bludgeoned my password out of me first.
All of the "have" factors that I've seen are, fundamentally, just a big number that's hard to get at or copy (with the exception of a physical, metal key). There's some math done on that number to generate a one-time-use code and do it in such a way that you still can't access the big number, but if an attacker were to compromise the number, then yes, that factor is broken. The theory is that the device cannot leak the number, and therefore it will only ever be known by the authenticating party. Or, more accurately, that the knowledge contained within should only ever be able to exist in two physical places (one each with the party being authenticated and the party performing the authentication).
I'm guessing we're talking about slightly different things and use-cases, but it's impractical to know that without a lot of diagramming and back-and-forth.
Biometrics are probably the best way to prove identity and control of your phone, locally. They already have a high-quality CCD. Biometrics are unpopular as something sent to remote devices for a variety of reasons, but should be much more palatable if they remain local-only.
This doesn't help at all for Apple ID, though.
http://blog.agilebits.com/2012/08/27/dropbox-two-step-authen...
That is no excuse for not providing basic TFA for users who know how important it is, however miserable the user experience may be.
Somewhat related, if anyone wants to get two factor auth working for their OS X login, instructions are at the bottom of this page:
https://code.google.com/p/google-authenticator/wiki/PamModul...
Though I can't speak to how well it works (if at all) it at least makes me hopeful someone will implement it more sensibly at a later date...