[SC-L] Another example of the futility of hardwareless 2 factor authentication
Consider the following attempt at el-cheapo (no hardware) authentication: It is possible to imagine an authentication scheme that wants to use something like a certificate with signing, encrypting random nonces etc., to verify that someone agrees to some transaction(s). If the certificate is on a PC, though, it gets exposed to theft. In the cert is a private key. If the system were required to contact a backend server first, passing it perhaps a cipher containing its serial number encrypted with its private key and its identity, the server could send back a (hopefully unique to that cert) decryption key that would decrypt the private key, allowing its use; the code at the PC would need to erase the cleartext private key when done. The server could check the serial number matched the identity (it would have the public key) to prevent a simple search of the server for these encrypting keys. This all seems reasonable and deals well with the environment perhaps of the 1990s. Problem today is that it is still utterly vulnerable to backdoor code on the PC which could be arranged to either listen for the decrypting key or just pluck it out of memory while the real cert was being used in cleartext. This is another demo of the difficulty of building any kind of software token that can be connected to uncontrolled environments and which can keep secrets. It may resist OFFLINE attack, but that is not the primary attack threat today for such a beast. Glenn Everhart [EMAIL PROTECTED] ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Another example of the futility of hardwareless 2 factor authentication
Consider the following attempt at el-cheapo (no hardware) authentication: [...] It is possible to imagine an authentication scheme that wants to use something like a certificate with signing, encrypting random nonces etc., to verify that someone agrees to some transaction(s). If the certificate is on a PC, though, it gets exposed to theft. There is no way to avoid this (as long as you stick to the no-hardware restriction). You can get clever with third parties and whatnot all you like, but anything the user's desktop can do with the data it has (possibly including data that is typed in by the user during operation as intended), an impostor who has the same data (lifted from disk, snooped on keystrokes, whatever) can do equally well. To defeat this, in principle, you need *something* the user's computer does not have access to. This can be as simple as the next entry on a list of nonces (sent to the user by some other means such as snailmail) all the way up to something as complex as the stuff underlying SecurID. Of course, that's not to say that simpler measures can't defeat any specific examples, such as current attacks. You can make it moderately difficult, in fact. But you can't make it impossible. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
