Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security The Almighty Buck

Banks Begin To Use RSA Keys 208

Posted by timothy from the probably-a-patent-on-this-too dept.
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?"
This discussion has been archived. No new comments can be posted.

Banks Begin To Use RSA Keys More

Banks Begin To Use RSA Keys

Comments Filter:

  • Heh? This is old news (Score:5, Informative)

    by zxSpectrum ( 129457 ) on Saturday December 25, 2004 @07:38PM (#11182677) Homepage Journal
    I'm rather surprised: Several Norwegian banks have been using these RSA Hardware Tokens for a couple of years.

  • Banks are the problem (Score:3, Interesting)

    by Anonymous Coward on Saturday December 25, 2004 @07:38PM (#11182678)
    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.

    • Re:Banks are the problem (Score:5, Informative)

      by Obiwan Kenobi ( 32807 ) <evan@@@misterorange...com> on Saturday December 25, 2004 @09:43PM (#11183072) Homepage
      I call FUD. I've worked in banks (and credit unions) as a network admin for over six years, and that is some bullshit.

      Now, understand that banks will use your information any way they can in-house, manipulate numbers and deposit totals and anything else analytical so they can sell a credit card or a loan (its called cross-selling). But what they cannot do is give your information to other 3rd parties without your direct consent unless its under federal mandate and/or decree (read: court order and/or the Patriot act).

      Now this is all fine and good, but when you do something substantial with your money and/or your financial outlook (say, investing or buying a home), you open up yourself to offers from 3rd parties. You sign a document saying so.

      Now the easiest thing is, before you sign something, ask them which companies are going to be behind this new venture. Whether it be an investing house (a lot of banks will farm out investing to a subsidiary and get kickbacks on it) or mortgages (who owns this loan? Can they sell it to a 3rd party mortgage company at a later date?), you need to simply be aware.

      Feel free to google "Bank Privacy" and read up on the hometown banks and the big boys: They all pretty much say the same thing. If they are under FDIC (for banks) or NCUA (for credit unions), they all fall under the same guidelines: Your information cannot be shared unless you say so. The federal privacy statements which are mandatory to be handed out upon opening an account, etc, say the same thing.

      Offshore data management services is simply a scarier way of saying Disaster Recovery. You want your bank to keep running even if the home office (or data center) explodes, right? Then don't start bitching about them backing up data in different places.
      • 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.

      • Re:Banks are the problem (Score:4, Informative)

        by jasonditz ( 597385 ) on Saturday December 25, 2004 @11:48PM (#11183486) Homepage
        The bank I used to use actually said the exact opposite: They can share with anybody unless you specifically tell them not to.

        The thing is, every 3 months or so they send a new copy of the (slightly modified) privacy agreement and if you don't send them another letter saying don't share my info, they consider it acceptance of the 'new' policy.
      • But what they cannot do is give your information to other 3rd parties without your direct consent unless its under federal mandate and/or decree (read: court order and/or the Patriot act).

        Really? How do credit rating agencies get information about your credit card debt without you ever having explicitly told your bank the information is theirs to share? Where exactly do all those pre-approved credit offers come from?

        Offshore data management services is simply a scarier way of saying Disaster Recovery. Y

      • Now, understand that banks will use your information any way they can in-house, manipulate numbers and deposit totals and anything else analytical so they can sell a credit card or a loan (its called cross-selling). But what they cannot do is give your information to other 3rd parties without your direct consent unless its under federal mandate and/or decree (read: court order and/or the Patriot act).

        Now this is all fine and good, but when you do something substantial with your money and/or your financial

  • Article not about "RSA Keys" -- Hardware tokens (Score:5, Informative)

    by Steven Reddie ( 237450 ) on Saturday December 25, 2004 @07:41PM (#11182688)
    The article is really talking about using hardware tokens for extra security since the private data is stored on an external token and can't be stolen by viruses, trojans, or phishing scams. I don't even see RSA mentioned in the article -- there is an inset picture of an RSA SecurID but that's as close as it gets.

  • Thumb drives (Score:4, Interesting)

    by Huogo ( 544272 ) <adam@thepeacock.EULERnet minus math_god> on Saturday December 25, 2004 @07:41PM (#11182690) Homepage
    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.

    • Re:Thumb drives (Score:3, Informative)

      by jdhutchins ( 559010 )
      That's what I initally thought, but the article talks about a different kind of RSA "key". The article is about the hardware things that show a number that changes every 15sec or so, and you need that number to log in. The summary title is misleading (suprise suprise)

    • Re:Thumb drives (Score:4, Interesting)

      by dustman ( 34626 ) <dleary&ttlc,net> on Saturday December 25, 2004 @08:35PM (#11182884)
      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.

      • Re:Thumb drives (Score:5, Insightful)

        by Temporal ( 96070 ) on Saturday December 25, 2004 @11:47PM (#11183484) Journal
        I've always thought that what we really need is devices like this with an LCD display that tells you what, exactly, you are signing.

        For example, imagine paying for some goods with one of these devices vs. credit card or smart card...

        Smart card: You must trust that the card reader will not choose to use your card to sign things you didn't agree to. The reader could, for example, overcharge you, and you would have no way to know that it did until you checked your monthly statement. (And, hey, by that time, do you even remember if that item was $59 or $69?) For that matter, the reader could very easily make the charge under a different name, making it difficult to determine who committed the fraud.

        Credit card: In addition to the smart card caveats, you must trust that the entity reading your card will not distribute your credit card number to any entity whom you don't trust at any time in the future. For that matter, if you use the same credit card with multiple entities, you have no way of knowing which one leaked your number. How can you fight back? Who do you charge with fraud or neglegence? In most cases you just let them go and your credit card company covers the illegal charges, while the FBI spends massive amounts of resources in mostly fruitless efforts to track them down. Why do we use these things?

        The device I described: The LCD screen displays the question "Authorize payment of $59 to Acme Co.? Yes/No". No charge can go through without your device approving it. You only need to trust that your device will ask you to confirm any charge. And you can trust it because the manufacturer knows that if it screws up, they'll get their pants sued off.

        The only thing that could make it more secure would be to implant the device into your body so that people can't steal it. Though, it's probably better to just deal with having to revoke a cert once in awhile rather than have people cutting you open to get to your bank account. :)
    • It is an even better application for smart cards. You need a $3 card and a $10 reader. And unlike a USB key it is meant to be quickly inserted and removed without any problems.

  • This is news? (Score:5, Informative)

    by Nehle ( 784297 ) on Saturday December 25, 2004 @07:42PM (#11182693) Journal
    My bank (SEB, www.seb.se) has been using a hardware token system for years. I click the sign in button, enter my birthdate, receive two four-digit numbers, start the little device, enter my password and the two numbers and get a six-digit number that I enter in the login page and then I get logged in.
    Is this somehow different?

    Oh, and by the way, works like a charm and I feel a lot more secure than I do with static passwords

    • Yes, it IS different... (Score:5, Interesting)

      by wcdw ( 179126 ) on Saturday December 25, 2004 @07:57PM (#11182745) Homepage
      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.

      • Re:Yes, it IS different... (Score:5, Interesting)

        by wfberg ( 24378 ) on Saturday December 25, 2004 @08:26PM (#11182864)

        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:Yes, it IS different... (Score:4, Interesting)

          by dannyp ( 62358 ) on Saturday December 25, 2004 @09:08PM (#11182980)
          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
          • If you read the GPP you would have found out that CR is less prone to man-in-the-middle attacks.

            A CR system can take multiple inputs (one of which could be a hash of your transaction data)
            making the response unique to the transaction.

            SecurID uses a simple token that is not unique to the transaction and so is very vulnerable to man-in-the-middle attacks.

        • Re:Yes, it IS different... (Score:4, Interesting)

          by wcdw ( 179126 ) on Saturday December 25, 2004 @10:00PM (#11183133) Homepage
          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. ;)
          • 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

            Only if you have the seed/key which is used. It's not like I've ever worked with the things, but I would assume that there is a key used to seed the PRNG.

          • 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.

            No, not if the algorithm is properly designed; it should rely on the secrecy of the key, not the algorithm. And yes, all tokens are keyed, otherwise they would be completely interchangeable, which they're not.

            Strong passwords are still less hassle, don't sacrifice much to security concerns (if never expressed in clear text), and just aren't t
        • 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).

          The algorithm was posted to BUGTRAQ [uni-stuttgart.de] in 2000.

      • SEB uses VASCO SecureID tokens (Score:4, Informative)

        by hanssprudel ( 323035 ) on Saturday December 25, 2004 @10:10PM (#11183173)
        Since this is already being moderated up, I want to note that poster is wrong.

        The system that the grandparent describes is based on VASCO [vasco.com] "Digipass" devices, that work just like the RSA secureid tokens, only that they also support PINs and challenge/response authentication. That means that if everything is done correctly (which I can't swear to) these tokens, which SEB have been using for more than five years, are considerably more secure than the normal RSA SecureID.

        Basically (very simplified) your normal SecureID will create a checksum from a secret and the current time, so the server can verify that person logging in is holding the token at this time. The Digipass, on the other hand, creates a checksum of the secret, the time, and the challenge from the server. This verifies that the person logging in has access to the token at this time, and created a checksum for this particular log in. And the fact that it also requires a personalized PIN to access the device means that stealing it will do you little good.
        • Well, frankly, it doesn't seem like it would be that hard to figure out how to dummy the PIN entry on the front end if one had the physical device in hand.

          Then again, with the SecurID card, it's even easier. ;)

          The only real problem I see is the 'if done right' part. Conceptually it's a better solution than SecurID (no surprise, the market does usually evolve). As far as actual USE goes, it seems a little less convenient.

          (Note that I have successfully fought every effort to make me actually _carry_ a Se
      • There's not much of an algorithm to hack...

        psuedorandom number generator which maps the time uniformly over the keys....that's all. And a sufficiently long seed, of course.

  • House keys (Score:5, Insightful)

    by tepples ( 727027 ) <.tepples. .at. .gmail.com.> on Saturday December 25, 2004 @07:43PM (#11182696) Homepage Journal

    How long before everyone needs to carry around 5 different RSA keys just to perform daily task?

    How long before everyone needs to carry around 5 different physical keys? Let's see... we have the house key, the car key, the shed key, the bike key, the gun case key, the baseball card key...

    • I have a church key that I carry too.
    • Just program the "doors" with your public key, and have them "challenge-response" the private one.

    • >> How long before everyone needs to carry around 5 different RSA keys just to perform daily task?

      > How long before everyone needs to carry around 5 different physical keys? Let's see... we have the [...] gun case key

      Your daily schedule seems to include riding the fences and looking for varmits.

      Be careful for that gray rabbit that stands upright, is always chewing on a carrot, and thinks you have a Ph. D. He's a tricky one.

      No matter what you do, never ever try to dynamite him.

    • If something like this replaces physical keys, that'd be great (it would raise the bar for lockpicking... instead of petty thieves with a few sharpened hunks of metal illegitimately opening locks, you'd need cryptographers and massive amounts of computing power to do it.

      As it is now, I have 4 keys -- one for my gate, one for the door to my apartment, and one for my bike lock -- as well as two proximity cards: one to get inside my building, and one to get into work. If these could all be replaced with one R
      • If something like this replaces physical keys, that'd be great

        Yeah, because everyone wants to live in a world where they can't get into their house if the power goes out during a thunderstorm!

    • My authenticate authenticate day, 8am - 6pm (Score:5, Interesting)

      by aardwolf204 ( 630780 ) on Sunday December 26, 2004 @03:01AM (#11183888)
      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.
      • 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.

  • Old News (Score:3, Informative)

    by Ann Elk ( 668880 ) on Saturday December 25, 2004 @07:46PM (#11182706)

    Banks in Poland have been using physical security tokens for online access for a few years. Yawn...

    • Query. If they use it for online access does that mean that they read them through some stupid Win Doze, Internet Explorer, embedded ActiveX control to actually access the device?

      • No.

        The security token looks something like a small calculator. To turn it on, you must enter a PIN. During an online transaction, the web site provides a challenge number (8 digits, I think). You enter the challenge number into the token, and it provides a response (another 8 digit number). You type the response into an edit field on the web form, press "submit" (or whatever), and the transaction completes. Very easy, as long as you don't lose your security token...

  • If client can't be trusted, all bets are off! (Score:5, Insightful)

    by Ron Bennett ( 14590 ) on Saturday December 25, 2004 @07:58PM (#11182747) Homepage
    At first glance, the external token as described in the article sounds secure, but since the person only types it in once per login, phishing really isn't that much more difficult than before.

    Two ways off the top of my head a phisher can defeat this ...

    1. Grab login data in real-time from an IRC channel, etc and race to login before the code changes - for extra measure, disable the user's connection for a little while - DoS, etc.

    2. Proxy the request - that is don't try to steal the login data itself, but rather hijack their session and go to town.

    Some may think, ok "check the person's ISP (IP range, etc) too" ... sounds like that would blow #1 away, but not if the phisher then logs in via the victims machine.

    In a nutshell, if the client machine can't be trusted, all bets all off!

    Yes, tokens raise the bar, but I fear banks will use this more as an excuse to erode consumer protections for fruadulent transactions; Verify by VISA comes to mind.

    Ron
    • If a phisher grabs the login and races in, you will end up with two sessions open to the same account. If the bank sees this happens, just lock out the account as a precaution. Under most "normal" circumstances two sessions for the same account should not occur - except for possibly automated software like Quicken. For the sake of security, however, I'm sure people won't mind making sure Quicken isn't logging into your bank account when you want to manually login.

      I think this is LONG overdue. I hope

  • just need a physical digit wallet (Score:4, Interesting)

    by emkman ( 467368 ) on Saturday December 25, 2004 @07:58PM (#11182749)
    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... (Score:4, Interesting)

    by 4alexnyc ( 826658 ) on Saturday December 25, 2004 @08:02PM (#11182764)
    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.. (Score:3, Interesting)

    by doormat ( 63648 ) on Saturday December 25, 2004 @08:05PM (#11182773) Homepage Journal
    I use an 8 digit PIN and a RSA hardware token to log into work remotely.

  • Carry around 5 keys (Score:4, Insightful)

    by gspr ( 602968 ) on Saturday December 25, 2004 @08:06PM (#11182779)
    How long before everyone needs to carry around 5 different RSA keys just to perform daily task?

    It's not like a million keys are harder to carry around than one...
    • Actually, it is harder to carry a million keys around than one. There are two different kinds of hardware tokens: a SIM-based smartcard or a paired key generator. The first has very limited capacity, enough for only a few keys, and the second can't carry more than one key at a time.

  • This is new? (Score:5, Informative)

    by wfberg ( 24378 ) on Saturday December 25, 2004 @08:06PM (#11182781)
    I've been using physical tokens to log on to e-banking for years. Not only that, but tokens that are significantly more secure than securID fobs, in that they support challenge/response and using a PIN to unlock it (two-factor security, and the PIN is only used with the token so it needn't be known at all to the bank).

    In fact, most banks are now switching to keypads that you plug your existing bankcard in, so they can piggyback on the tamper-resistant chipcard that's already on there (although it's slightly less advanced than some tokens, since chipcards don't support a clock that's permanently ticking).

    Most devices are from Vasco [vasco.com] who provide a wide range of tokens (some more secure than others). They even have challenge/response tokens that don't require you to copy the challenge; they have optical sensors that can read out a code that's blipped out by flashing blocks on your screen. Way cooler devices than those RSA securIDs.
    • Challenge-response isn't inherently more secure than an auto-updating number based on time. Both are basically implementations of a pseudo-random function. With the auto-updater, the current time is essentially the challenge. And not having to type/scan in an explicit challenge is a lot more usable.
      • Challenge-response isn't inherently more secure than an auto-updating number based on time. Both are basically implementations of a pseudo-random function. With the auto-updater, the current time is essentially the challenge. And not having to type/scan in an explicit challenge is a lot more usable.

        With C/R the challenge can be extended with human-readable data; my bank required me to enter bank-account numbers I add to my e-banking address book as a challenge in my token. Other banks require the amount
  • How long before someone finds a fast way of factoring large numbers and we're all screwed?

    • How long before someone finds a fast way of factoring large numbers and we're all screwed?

      There's no direct relationship between the SecurID tokens sold by RSA and the old RSA algorithm. Actually, the latest generation of SecurID tokens use AES, however RSA still ships backlogs of the older tokens which are built around a proprietary hash.

      Like most other response-only tokens, the authentication is based not on large primes like public-key authentication but rather on a shared secret (one embedded in

  • 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
    • Don't forget that RSA's security is also based on the concept that keys are 1:1 and they aren't [abnormal.com].
    • "If banks are to adopt a universal crypto system, then perhaps AES or some form of elliptic curve crypto would be a better choice?"

      AES was not written in the US - so it is highly unlikely that US banks would adopt it as a first solution. Keep in mind the only US organization (NSA) that can truly say whether or not it is breakable will not say.
      Same goes for eliptical curves - they (NSA) will definetly say not all curves are secure - but they will not say which ones and why, but I doubt if you will see elip
  • Next thing you know - they'll start using the "internets"!
  • The distinction really should be made between RSA encryption keys used for crytopgrahic algorithms, and RSA SecureID Tokens, which are what this news item is referring to, but are different from the public/private encryption keys!

  • Customers expected to pay? (Score:5, Insightful)

    by Xentropy ( 843502 ) on Saturday December 25, 2004 @08:37PM (#11182891)
    I'm willing to admit up-front that being the victim of a security breach or some kind of fraud is distressing to the customer, but given the fact most banks (and certainly any bank I would do business with) have zero liability fraud policies nowadays, the only party for whom such a device would be saving money is the bank.

    Therefore, why are customers expected to pay $10 for these? Certainly, banks will recoup the costs somehow (through higher fees in general), but isn't the net effect of this type of technology supposed to be a savings? Isn't it the bank's responsibility (and liability) to make sure their customers' accounts are secure (assuming a reasonable amount of due diligence by said customers)? Isn't the savings in reduced fraud and security breaches supposed to outweigh the cost of the security devices? If not, why does the technology exist?

    It sounds great and all, but unless offered as a free service, I'll sit this one out.

    • Re:Customers expected to pay? (Score:5, Insightful)

      by thogard ( 43403 ) on Saturday December 25, 2004 @11:10PM (#11183371) Homepage
      I don't know about you, but I like the plausible deniability of the existing system. I fear banks that have very strong online controls because when they make mistakes, they will simply say "the computer proved it was you" and there is far less recourse. Its the same reason that I used credit cards on line and won't ever use a debit card on line. The credit card is their money, the debit card controls my money.
    • Consider it this way. Let's say the cards really cost $10 for the bank. They have basically two options.

      The first is common: make the customer pay for the card, one-time up-front. Most utilities will do this for hook-up charges, etc. as well.

      The second method is to include this in day-to-day charges. A lot of people say 'this should be part of the cost of doing business', but look at it this way. Banks aren't going to take money out of their profits to pay for something, they're going to raise your fees.
    • I'm willing to admit up-front that being the victim of a security breach or some kind of fraud is distressing to the customer, but given the fact most banks (and certainly any bank I would do business with) have zero liability fraud policies nowadays, the only party for whom such a device would be saving money is the bank.

      First, the consumer pays for every needed cost by a business. That's a fact just like we all pay when a scammer steals someone's credit card or someone gets into an auto accident and

  • Sweeden uses a similar token system (Score:3, Interesting)

    by ScottMacVicar ( 751480 ) * on Saturday December 25, 2004 @08:55PM (#11182941)
    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.
    • It's the same in Finland. I have a card with about 100 disposable passwords and when I have used most of the passes the bank sends me a new card. In my opinion this is a lot more secure method than the permanent password scheme employed by many American banks. No offense, but as can be seen from the many comments posted here already, the US banking system is not exactly the state of the art. I mean, US still uses paper checks which I find astonishing. There must be incredible amounts of work and thus expen
    • And if the cards are properly generated (i.e true random), they should be as safe as one-time pads.

      And nothing beats truly random onetime pads :) For small stuff like authentication, one time pads are feasible like this. You cannot use them to encrypt the entire transaction... bla bla for a full explanation of the various one-time pad schemes go read The Code Book by Simon Singh.

      In fact, before any of you start to comment on crypto you should at least have read that book (I know many of you have read it

  • For CC charges too (Score:3, Insightful)

    by The Cisco Kid ( 31490 ) * on Saturday December 25, 2004 @09:07PM (#11182977)
    If they *DONT* protect credit(/debit) card charges with this, its somewhat useless, since thats the simplest way for someone to suck the money out of someones account.

    If they do require charges to a credit card to be authorized by the SecureID card, it not only protects against outright stealing, but also prevents a merchant from saving your CC# and automatically rebilling you without your permission unless you jump thru their hoops to 'cancel' somne service - their only recourse is to terminate the service, which is as it should be.
  • I personally have an RSA SecurID that I use for work and I love it. I think its a really great system and it meets our authentication needs. In case you aren't familiar (or haven't read other posts), SecurID is a fob that can put on your keychain that lasts I think 5 or so years and gives you a new 6 digit token each minute. This combined with your own passphrase authenticates.

    The fob uses time-based encryption against the auth server so that it knows at a given point in time what the 6 digit number should
  • It seems like most of the rest of the civilized world has already adopted hardware tokens of some sort for online banking security, but here in the good ole USA, we're yet again behind the times.

    My fear is that each bank would adopt a different technology to implement this, and I would be keeping track of 7 different tokens right now. OTOH, that is not a bad price to pay for better security of my money and lower fees, etc. on my bank accounts.

    The reality is that, depite the big inconvenience, US bankin

  • "RSA keys" in the title is a bit misleading.. It makes it sounds like a full crypto implementation, using smart cards and all the capabilities that implies. Confusing the RSA crypto algorithm, with the SecurID card, a product made by the company RSA.

    SecurID is just a clunky authentication system using a hardware token to display numbers used for the authentication (although, they do also offer software tokens. there is nothing magical about the hardware)

    Why not go to a modern smart card system? It can
    • writes:

      "RSA keys" in the title is a bit misleading.. It makes it sounds like a full crypto implementation, using smart cards and all the capabilities that implies. Confusing the RSA crypto algorithm, with the SecurID card, a product made by the company RSA.

      A common mistake. Most of the articles [com.com] I've seen lately on the subject have not mentioned either "RSA" or "SecurID", just talking about "devices" or "tokens" or perhaps "two factor authentication".

      SecurID is just a clunky authentication system

      • Yes, at the user side there is nothing directly needed to support SecurID authentication. But, on the application server side it needs to be built into the app using RSA's API. But, since SecurID is so broadly deployed, pretty much all security related applications implement SecurID auth.

        For corporate uses, it's much easier to dictate Smart Cards, and integrate a bunch of different corporate applications - multiplying the benefit of the card.

        But, thinking about the problem a bit more.. I guess that cl

  • "Bloated" security? (Score:3, Interesting)

    by mr. methane ( 593577 ) on Saturday December 25, 2004 @11:10PM (#11183370) Journal
    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.
  • Around 5 years ago I was looking for a way to have a secure-id sort of solution without having to buy the proprietary software and hardware without any success. I even looked into building my own (I know a little about microcontrollers for the hardware device portion) but was not able to come up with any suitable algorithm. It seems like the security of our Linux systems and other systems which require authentication could really benefit from something like this.
    • Tracy Reed writes:

      Around 5 years ago I was looking for a way to have a secure-id sort of solution without having to buy the proprietary software and hardware without any success.

      The first "open" standard for authentication tokens was part of ANSI X9.9, and was broken (and subsequently retracted [webservertalk.com]) back in 1999. The old X9.9 algorithm is still available as an optional authentication method in several hardware tokens offered by competitors of RSA/SecurID.

      Have you looked at GNU SASL [gnu.org] (Simple Authenticat

  • Using RSA security tokens (of the hardware variety) is unnecessarily expensive. One-time passwords (strikelists) are cheap and proven technology. US banks should start using them--banks elsewhere already do.

  • OpenPGP (Score:4, Interesting)

    by bwbadger ( 706071 ) on Sunday December 26, 2004 @03:26AM (#11183945)

    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.

Slashdot Top Deals

Some people manage by the book, even though they don't know who wrote the book or even what book.

Close