Quote Originally Posted by Telok View Post
Sorry, was posting late at night and I wasn't very clear. I meant using biometrics to generate a pseudo password and then 2fa the password back to the encoding device where the biometric gets run again. My concern is these systems I see with the login & phone stored in the db where the 2fa consists of just answering the phone or a pin sent to the phone. The main issue being a stolen phone turns into the whole login from a bookmarked site, the saved password, and the 2fa id. So not the issues at the stolen db level.
The primary thing there is that having the password saved on the same phone in such a readily usable fashion effectively reduces things to one-factor authentication; the value of the second factor is verifying you have access to the associated phone independent of having access to the password (the first factor), and the password being saved on the phone means they're no longer independent.

Anyway, using biometrics has problems of its own. In addition to the issues Whoracle already mentioned, a key one is that the body is not a static thing....Just to throw out an example, I am rather certain that I would fail retina scans after my retina detachment last year; and reasonably certain that it results will have changed even after I've fully recovered from the reattachment surgery it. Admittedly an extreme case, but the point is that scenarios like this, however mild, are going to be far more onerous for anyone trying to legitimately use biometrics than for anyone trying to break them; and that's not likely to promote widespread adoption.


So this is basically comparing "don't suffer bodily accidents" vs "don't save your password on the same phone"; the latter is far more controllable.

Quote Originally Posted by Telok View Post
Also, TOPT? De-acryonim?
Time-based One Time Password, including stuff like the "pin sent to the phone" thing you mentioned.