You are not currently logged in. If you do not have a user account then please consider creating one and logging in before you post your comment. This will allow you to track replies to your comment, and take part in the site much more freely.

To add your comment, fill in all the boxes below and then preview it to make sure you're happy with the way that it looks.

This is the comment you were replying to, attached to the article Implementing cost effective dual factor authentication:

#2 opie (rfc 2289) and two-factor auth Posted by undefined (192.91.xx.xx) on Wed 21 Mar 2007 at 22:03 two things: - i use opie like another poster, but with palmkey (previously on a visor deluxe, now on a palm z22). - i think calling auth by only a one-time password (however it is generated, in whatever form) "two-factor auth" is a bit stretching. the downside to rfc 2289 (as implemented in opie): - a little difficult to set up (opie doesn't seem to be widely used and therefor lacks a depth/breadth of documentation; pam with its different modules and stacking is itself complex) - i've only ever seen it used in interactive shell-based protocols (ssh, telnet) presumably due to the challenge-response requirement (server issues hash, count, & seed). supposedly the cyrus sasl library has a 2289 implementation, which means servers using that library should be able to use otp, but no server seems written to display the challenge to the user. even if the server application did display a challenge, would the client know how to relay it to the user. most clients are configured to receive both the username and passphrase from the user at the same time, but the challenge is user-specific and cannot be issued until after the username is submitted. ssh & telnet work because the client just displays directly to the user whatever text is received from the server and the user has the responsibility of interpreting it and responding correctly (whether that is entering a system password, a one-time password, or entering the captha from the displayed ascii art ;-). 2289 seems to be well thought out in theory, but too different from the norm to see wide adoption. plus opie (not rfc 2289) is minorly broken from a security perspective: - incorrect answers don't decrement the password count so brute-force attacks are possible (i've heard libpam-opie should, but my installation doesn't) - user discovery is possible as repeated attempts to log into an invalid account generates random counts & seeds (where a valid account will generate the same or decreasing counts with a constant seed). freeauth gets around all this by not issuing a challenge. that's somewhat problematic as it is not clear to users what type of authentication is being used (eg "It asked for a password so i just kept entering my pin but it never accepted it.") and the time synchronization cannot be verified (it would be helpful if the server printed at login what it thought the unix epoch was). the freeauth "challenge" wouldn't even need to be displayed between the username and password as with 2289. opie could get rid of the challenge to conform with standard login mechanisms and make the user track what the hash, count, & seed are (palmkey does this as long as you don't press the "clear" button), but that would be problematic for the user. actually, this might be how the opie pam-module works in practice with a login process that ignores challenges. in custom applications, rfc 2289 and freeauth can probably both be integrated with the same difficulty, but in a system like pam (pluggable authentication modules), they deviate too far from the usual username-passphrase to be widely used. finally, i wouldn't call one-time passwords "two-factor auth" because there's really only one distinct input given by the user: the hash of time, shared secret, and pin. the pin and shared secret are not really distinct because you combine the two to get your one-time password. i store all my passwords in the keyring password manager (a palm app), which itself is password protected. so is that two factor authentication: it requires the keyring password (something i know) and the keyring database (something i have)? what if all my passwords were 32 characters long, where i memorized the first 4 characters and the remaining 28 were stored on a hardware device? rsa's securid is considered two-factor because the inputs are kept entirely distinct: your pin is unrelated to the time-based one-time password (which is so complex it necessitates a computing device, something you have). freeauth is essentially cram-md5 auth where the challenge string is not issued (because the time is assumed to be the same by both parties) and the passphrase is broken into two parts: one part remembered by the user and the other part stored on a device. but no one considers cram-md5 "two-factor" no matter how the password is stored by the user. sorry to be pedantic, but two-factor authentication is not trivial, so i hate to see it trivialized (just as most free-open-source-software advocates hate to see foss trivially refered to as "freeware", though both are practically the same from the non-programmer perspective). thanks for the freeauth article!

Inappropriate comments will be removed.

Username:

Password:

[ Advanced Login ]

Register Account