Banks Begin To Use RSA Keys

jnguy writes "According to the New York Times (free bacon required), banks are begining to look into using RSA keys for security. AOL has already begun offering its customers RSA keys at a premium price. Is this the future of security, and is it secure enough? How long before everyone needs to carry around 5 different RSA keys just to perform daily task?"

Banks are the problem

[Anonymous Coward]

Ever read your bank's privacy statement? They pretty much share your personal info to every 3rd party out there. Not to mention they offshore data management overseas.

Thumb drives

[Huogo]

This is the perfect use for a thumb drive, so long as the computer you're using can be trusted. I can see a problem with people keeping all their keys on a thumb drive, and using it at a net cafe or something, but the computer at the cafe could be easily set to download the keys and key log the password to each set of keys. This can only be solved by something like an external device that will let you input a challenge code, and spit out a response code to gain access to the RSA key.

Chinese Supercomputers Crack Normal Passwords

[Anonymous Coward]

The reality is that the RSA key is a godsend for protecting your accounts. Many Americans are simply unaware of the fact that the Taiwanese [geocities.com] have essentially given all the key computer technologies to mainland China [phrusa.org]. Beijing can now assemble a supercomputer based solely on the technology from Acer, a Taiwanese company with major investments in mainland China. This supercomputer can easily crack the passwords of many accounts at your bank, brokerage, etc.

The RSA will help to protect Western bank/brokerage accounts from Chinese theft. That the majority of stolen credit card numbers end up in the hands of Chinese gangs, aided and abetted by Beijing, in Southeast Asia should surprise no one.

Yes, it IS different...

[wcdw]

This sounds like SecureID cards, which are time-synched to a master server which runs the same algorithm/seed. SecureID has a long history in the IT world, and works relatively well (and, as far as I know, no one has ever hacked the algorithm).

Sounds like your device just calculates a response based on two inputs; don't know why that wouldn't be just as easy in software. (You _can't_ turn a SecureID card off, so it can't get out of synch with the server, unlike software.)

Not to say that your device isn't secure - more reverse engineering would be required to determine that - but the two approaches *are* very different.

just need a physical digit wallet

[emkman]

If we are going the route of RSA keys, we need a secure digital wallet, where one key contains all the credit cards and bank info we need. This will keep all the info just as secure but we wont need a billion different keys for all our different accounts.

Not surprised...

[4alexnyc]

Considering most of my friends in corporations already use these devices to get access to the corporate network, I'm not surprised they're looking to bring it to the general public. I is highly effective.

To answer the 5 tokens keychain question: there is a software token device also available: http://www.rsasecurity.com/node.asp?id=1313/ [rsasecurity.com]

I suppose this doesnt surprise me..

[doormat]

I use an 8 digit PIN and a RSA hardware token to log into work remotely.

We should be careful of this....

[I kan Spl]

Putting all of one's eggs into the same basket of crypto is probably a bad idea. If banks all adopt RSA as a standerd way of doing logins at ATM's and or online then there will be a major upheval if anyone cracks RSA.

RSA is based on the idea that prime numbers are very hard to find, and with some of the research that is currentl going into that field I would be very wary of using that idea as an end-all.

If banks are to adopt a universal crypto system, then perhaps AES or some form of elliptic curve crypto would be a better choice?

Re:For those who don't want to register:

[Xentropy]

A better solution is to use the archive link, which doesn't require registration:

http://www.nytimes.com/2004/12/24/technology/24onl ine.html?ex=1261544400&en=7cc80182b7687ad9&ei=5090 &partner=rssuserland [nytimes.com]

(Link created by the NY Times Link Generator: http://nytimes.blogspace.com/genlink [blogspace.com] )

Re:Yes, it IS different...

[wfberg]

Sounds like your device just calculates a response based on two inputs; don't know why that wouldn't be just as easy in software. (You _can't_ turn a SecureID card off, so it can't get out of synch with the server, unlike software.)

Not to say that your device isn't secure - more reverse engineering would be required to determine that - but the two approaches *are* very different.


The approaches are different mostly in the way that securID can't do challenge/response. Note that most hardware tokens that can do challenge/response also use a hardware clock.

The immideately obvious benefit of challenge/response is that it offers far better protection against replay attacks - securID numbers are valid for 10 seconds, whereas a parallel login session using C/R will use a different challenge (in fact, the resolution is worse than 10 seconds since the server will usually accept the previous and next number as well, in order to resync to correct for clock drift).

Also, some e-banking authentication schemes require you to enter both a challenge AND the amount (or recipient's bankaccountnumber) you're transferring; this prevents malware on your PC (or a man-in-the-middle) altering the amount without you detecting it. This is obviously impossible to do with a non-C/R scheme like SecurID.

Example; when I add an account number to my e-banking site's address book, I'm asked for the response to a challenge that's clearly and human-readably derived from the bankaccount# (1 number is dropped) - so malware can't change the acount#s I add to my address book.

In my mind, even devices without a hardware clock that can do C/R are preferable to securID schemes that do have a clock but no C/R.

Also note that tokens that do C/R usually need to be unlocked with a PIN before use (they already come with a keypad, so why not?) - this means you get two-factor authentication basically for free, and the PIN only needs to be checked by the token itself, so it's not stored on the server, not even in a hashed form (which is trivial to brute force for 4/5 digit codes anyway).

While securID might be very well accepted in the IT world, and is easy to roll out, it's certainly not the most secure or well thought-out authentication method by a long shot. And they're damn expensive given how simple their design is! Just a clock and an LCD that shows the hash of the current_date/time_rounded_to_the_closest_10_second s and its secret key..

Re:Thumb drives

[dustman]

This is the perfect use for a thumb drive, so long as the computer you're using can be trusted.

Although the article talks about a different technology, one of the core features of the technology you are talking about is that the computer does not, in fact, need to be trusted.

Basically, the computer asks the hardware device to encrypt or decrypt some data. The device stores the key internally and never reveals it.

It is a core concept of devices such as this that it is impossible to retrieve the key. The chips are designed such that they never reveal the key through the "official" interface (the encode/decode thing), and they're made so that taking the chip apart destroys the key.

Sweeden uses a similar token system

[ScottMacVicar]

A friend who is studying in sweeden at the moment has basically a scratch card with 40 numbers on it, when she goes to login she enters her username, password and then scratches off a panel to get a 8 digit numeric token to enter.
When she has used about 30/40 the bank send out a new card.

Its a whole lot cheaper than handing out SecureID devices to customers and i'm really suprised that most banks dont have this already, its the size of a credit card and fits nicely in a wallet.

Re:Yes, it IS different...

[dannyp]

Most SecurID implementations will only authenticate a specific token code once within its validity window. A replay attack (even within the time validity window) will fail after the first good authentication.

There are still man-in-the-middle vulnerabilities, but no worse than with a challenge-response

Re:Yes, it IS different...

[wcdw]

One point I wanted to add is that although SecureID may be well accepted in the IT world, it is _NOT_ that easy to roll-out. Or wasn't, the last time I had to play games in that world, anyway; it HAS been a while.

Note that I never claimed that it was the most *secure* solution, and yes, the lack of challenge/response does limit it's usefulness.

However, if I can reverse engineer the bank's device and discover the algorithm in use, it becomes worse than useless, in that instills a false sense of security.

Strong passwords are still less hassle, don't sacrifice much to security concerns (if never expressed in clear text), and just aren't that freaking hard to create. Pre-shared keys are even better, depending on how strong they are, and how they're distributed. And how well keys are guarded/revoked-if-stolen. ;)

Re:You don't need multiple tokens!!

[confusion]

I admin'd an ace server for a long time, in an org that had multiple groups running them. It is true that you can use an RSA token on many ace domains - buuut the problem is largely organizational. Even within the same company, it was sometimes hard to get the seed files back and forth.

Each customer will need to provide their seed file to each new back. *IF* banks were able to settle on all using the same technology (RSA/ACE), most certainly all of them would have different policies on pins, etc, rendering it a pretty confusing thing for customers. Don't underestimate the problems that would cause.

Jerry
http://www.syslog.org/ [syslog.org]

"Bloated" security?

[mr. methane]

RSA dongles seem like a step in the right direction, but it sure is a pain. Just for my work, I need to carry one RSA dongle, two "swipe cards", and remember (best guess) seven passwords, have a list of codes, lock combinations, and several plain old keys. It's a pain.

Biometrics - thumbprints and the like - seem like the best alternative, but the few examples I've used so far have been very finicky, and mostly used as a second layer of authentication with an access card or code.

One thing that is going to make this move quickly is the financial incentive - a few million per month in credit fraud, and some congressman getting ID theft is a pretty strong incentive to be creative.

Re:Banks are the problem

[sirshannon]

As the grandparent post said, banks can and do share with pretty much whomever they want. And when you agree to their privacy policy, you gave them the express consent. My bank's privacy policy (which was mailed to me recently and is sitting on my desk) says "We do not sell information about our current or former customers and do not disclose such information to third parties, except as permitted by law." That's right, if they can legally get away with it, they will do it, according to their policy.

My authenticate authenticate day, 8am - 6pm

[aardwolf204]

I know its probably too late for anyone to see this, but here's what my typical day looks like:

Wake up. Power on computer, wash up while booting. authenticate with windows. Launch Outlook, authenticate with Exchange server. Hibernate computer. Grab cell phone, wallet, keys, etc.. Leave apartment, authenticate with locks on apartment door. Walk to car, authenticate with car door locks. Get in car. authenticate with ignition. Drive to work. authenticate with cell phone, call voice mail, authenticate with voicemail, hit speakerphone and listen to messages. Lock phone. Park at work, lock car.

authenticate with front door at work. Greet co-workers. Sit down at desk, turn on monitors, authenticate with computer. Launch Outlook, authenticate with Exchange. Call voice mail from work phone, authenticate with voicemail. Listen to messages, hang up.

Terminal Service to Exchange server, authenticate with server. Launch MMC, check event logs, Exchange logs, IIS logs, backup logs. Check performance monitor. Launch Exchange Anti-Virus. authenticate with Anti-Virus program. Check logs. Minimize terminal service session with Exchange server.

Terminal service to SQL server, authenticate with server. Launch MMC, check event logs, SQL logs, IIS logs, backup logs. Check performance monitor. Minimize terminal service session with SQL server.

Launch firefox, browse to sharepoint, authenticate, read messages. Browse to gmail, authenticate, read messages. Browse to online bank, authenticate, check balance. Browse to credit card, authenticate, check balance. Browse to photography community message board, authenticate, check private messages. Browse to Slashdot, authenticate, check headlines.

Get call from manager, talk about project. Browse to file repository, authenticate, download requirements document. Browse to print server, authenticate, print requirements document. Write notes on project, browse to project worksite, authenticate, upload file.

Get call from user, walk user through troubleshooting steps, walk user through remote assistance request steps. Launch messenger, authenticate, receive remote assistance request. Initiate connection with VPN server, authenticate. Launch remote assistance application, connect to remote user, authenticate. Troubleshoot problem. Maximize Exchange server terminal service window. authenticate with locked screen saver. Open MMC, reset user password. Disconnect from remote assistance request.

Browse to network share, authenticate, copy backup files to removable hard disk. Logoff from terminal service sessions and local machine. Grab hard disk and leave office. Lock office door. authenticate with car door, authenticate with ignition, drive home. authenticate with apartment door, turn on computer, authenticate, launch outlook, authenticate with Exchange, read messages. Grab bike and leave house. authenticate with front door. Ride bike to gym. Lock bike in parking lot. Work out. Leave gym, authenticate with bike lock. Ride home. authenticate with mailbox, get mail, lock mailbox. authenticate with front door.

Its now 6:00 and I've authenticated with something or another 40 times. My day is only half over. I carry 8 keys in my pocket, and about 40 different passwords in my head. I am constantly locking and unlocking various things. My case may be a bit more extreme being a system administrator but trust me you do this too, and its probably just as bad. This was just a quick summary, I'm sure I left off about 100 other authentications. Welcome to Earth.

OpenPGP

[bwbadger]

I'd like to be able to use just the one key for all the secure sites I go to.

... and I'd like that to be my OpenPGP key.

Surely it must be possible for me to give my public key to a bank (or whatever) and have them authenticate me using that key. e.g. by them sending out a hash, having me sign it using my private key, and then having them check that the signature is good.

Re:My authenticate authenticate day, 8am - 6pm

[St. Vitus]

Walk to car, authenticate with car door locks.

I would argue that this is authorization, not authentication. Two very different things. The car doesn't care who you are. From the car's viewpoint, you have the key, you are authorized to access the inside of the car.