Wow if you made 6.72 in interest on $20 in a year, I’d like to put some money in your sock too.
Eam:
I put a 20 in my sock last year, and now I have a 26-dollar-and-seventy-two-cent bill. Stupid compound interest.
Todd Derscheid on February 7, 2007 08:16 AM
Did you ever see the online bank ING Direct password system? They had images that made up a numeric keyboard. The image names changed on every refresh. So you mouse clicked your numeric password and the image names were stored in a comma-delimited string form var. I assume that the image names corresponidng to each number were stored in a session hash table which would then be used to verify the password.
When you clicked on each number you’d see a password textbox add a * to it. The javascript was just adding an ‘A’ everytime to give the user an indication that the click had been registered.
As Evan pointed out, there is a processor and public/private key encryption going on.
One thing he didn’t emphasize that is important, is that the private key never leaves the card. The host computer may send a message or hash of a message to the fob to be encrypted, but the private bit is never visible outside. Because of this, without the fob plugged in, you can’t send properly encrypted messages, which means the attacker has to do the dirty work RIGHT THERE AND THEN. (Annoying but somewhat common exception: if the fob was used to encrypt a temporary symmetric key which is used for all further communication in this session, the attacker may be able to “keep the session alive” for later use)
I believe a “man in the middle” attack is mostly thwarted by digital certificates, to the level that you trust the issuers (I’ll use verisign as an example). Your browser knows who verisign is (contains their certificate), and can communicate securely with them to validate that your connection is encrypted DIRECTLY to the REAL jkl.com (jay-kay-ell.com). The weakness involved is related to whether you are browsing to jk1.com (jay-kay-number one.com) who verisign accidentally issued a certificate to, even though they are phishing for customers of jkl.com.
Of course, all of that doesn’t help you if you (your destination) doesn’t use https, if you “click through” the warning dialogs about “hostname does not match certificate”, or don’t type in the name of the domain you are going to by hand.
I think a compromised PC is the real vulnerability for two-factor setups at the current time.
Oh, I suppose I should have mentioned I was using jkl.com and jk1.com as examples too. I have no idea what those sites might be about, but the first thing I thought of (xyz.com) didn’t have something easily mistaken like {1,l,0,O} in it.
Aha, I thought that might be the case. Thanks evan and greenup. The smartcard information available on the web is, er, not good.
So a smartcard is a great way of Keeping Private Keys Private:
http://www.codinghorror.com/blog/archives/000501.html
security anecdote:
Friday morning, email from bove…
“As from Monday, ALL EMPLOYEES will be required to produce their electronic swipe card in order to enter the building”
“Employee electronic swipe cards will be issued on Thursday”
Great hackers take hours to breach security.
Brute hackers take 15 minutes to get into the system, of which 10 is spent on attaching security admin to a chair with scotch tape.
That does no good if the security admin cannot override things on his own. 
Why no mention of CardSpace? Instead of managing a separate username and password with each vendor who stores all my information, I can just present a certified CardSpace identity.
There’s still concern over workstation login security, but my moving beyond simple HTML form elements to a mature digital identity system, the problem of identity management seems to simplify quite a bit.