If you control the client device, it's not really suitable as a second factor in a two-factor authentication system.
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
A hardware-managed asymmetric (e.g. x509) key on device, combined with a passphrase which can't be saved to the device (and is entered by the user each time) would be two factors.
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.
I think you missed my point: phones can be stolen. If you watch me type in my passcode by looking over my shoulder on the train (knowledge factor is now compromised), then steal the thing and run off as the train is departing, then you have full access.
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.
Yeah, it's fair to say the unlock passcode on your phone is more vulnerable than a specific authentication password used during a web login. But other than length and how frequently it's exposed, it's not fundamentally different from shoulder-surfing that password and then stealing your keyfob. In both cases you can try to deactivate the account before the next login.
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.
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