Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Security IT

Phishing For Bank Info Without Any Pesky Malware 232

Emb3rz writes " brings us news of a new approach to phishing that targets online banking sites. Here's the novel part of it: it doesn't involve any of the typical attack vectors we all know and love. Instead, it uses JavaScript from a remote page to detect if you have a banking site open, and prompts you for info via popup if you do."
This discussion has been archived. No new comments can be posted.

Phishing For Bank Info Without Any Pesky Malware

Comments Filter:
  • by alain94040 (785132) * on Friday January 16, 2009 @12:06AM (#26478655) Homepage

    This is real scary. And it goes to prove that bad guys always come up with new ways to steal. I don't believe there is a technical solution to this arms race.

    Instead, I'd love to see our law enforcement friends be more pro-active and setup traps. Pose as a fake victim. Go out and seek those phishing sites. When the thieves come after your money thinking they just ripped off a stupid Internet newbie, then you can trace their activity and catch them.

    That's the best way I can think of scaring the bad guys: when they never know if their next victim might be a cop.

    -- [] -- work where geeks are their own boss

    • Re: (Score:2, Informative)

      by Anonymous Coward

      I've heard of something like this before.
      Though there's this magical thing called noscript.
      If people would stop putting law before them to prevent them from making stupid choices then we might have a more informed society.
      (I ironically didn't read TFA.)

      • by Gerzel (240421) * <brollyferret&gmail,com> on Friday January 16, 2009 @03:33AM (#26479531) Journal

        Problem is with no-script you still have to decide if you trust or not-trust the site and if that level of trust you have is worth what the site is offering.

        If the site offers a useful service which requires scripts you have to decide if it is worth the risk.

        While in most cases it is easy to tell and block only those sites you trust. Those that you don't block may also allow third party scripts to be run such as in ads on the site.

        • paranoia-plus... (Score:5, Insightful)

          by BrokenHalo (565198) on Friday January 16, 2009 @05:16AM (#26479987)
          My paranoia has led me into a practice of doing my banking in a single browser session, clearing cookies, cache and history before and after, and closing/restarting the browser when finished.

          Looks like I was right about the monsters behind the sofa after all.
          • by stranger_to_himself (1132241) on Friday January 16, 2009 @06:30AM (#26480313) Journal

            My paranoia has led me into a practice of doing my banking in a single browser session, clearing cookies, cache and history before and after, and closing/restarting the browser when finished.

            My paranoia has led me into a practice of doing my banking by going to the bank.

            • Re: (Score:2, Insightful)

              by Anonymous Coward
              SSL is far more secure than going to the bank and dealing with humans.
              Also, I have never heard of anyone dieing in a digital bank robbery.
            • Re: (Score:3, Funny)

              by SkyDude (919251)

              My paranoia has led me into a practice of doing my banking by going to the bank.

              You insensitive clod. How do you get there - in your gasoline powered, carbon-emitting, smog-making car?
              A real /.er would stay in his basement and do his banking on the internet and not risk having to interact with other humans.......

              You must be new here.

        • by DigitAl56K (805623) * on Friday January 16, 2009 @05:48AM (#26480111)

          Problem is with no-script you still have to decide if you trust or not-trust the site and if that level of trust you have is worth what the site is offering.

          That slightly over-simplifies the protection that NoScript offers. For example, even when you allow script to run NoScript still provides protection against certain types of XSS, you can use it to force cookies to be exchanged over https for certain domains, it can block some plug-in types (Java, Flash, Silverlight), it features click-jacking protection, and just a couple of days ago it even added protection against attacks on twitter [].

          So yes, you do have to make that trade-off, but even when you click "allow" you're potentially better off with NoScript installed than without it.

        • [...]While in most cases it is easy to tell and block only those sites you trust. Those that you don't block may also allow third party scripts to be run such as in ads on the site.

          as far as I know, from using noscript on firefox, I can enable java on my bank's page and it still blocks Ads and java scripts if they come from other sources. from noscript home:"The NoScript Firefox extension provides extra protection for Firefox, Flock, Seamonkey and other mozilla-based browsers: this free, open source add-on allows JavaScript, Java, Flash and other plugins to be executed only by trusted web sites of your choice (e.g. your online bank), and provides the most powerful Anti-XSS protecti

      • Re: (Score:2, Informative)

        NoScript breaks my online banking. Yeah it's a good idea and I tried to use it for a while, but I found that no matter what exceptions I gave it when it came to my bank, it refused to allow me access. Don't know why, but it kinda kills your argument if you have to turn NoScript off completely to use your online banking.
        • Re: (Score:2, Interesting)

          by indi0144 (1264518)
          Call your bank! tell em you're going to the media as in "halp-my-buntu-box-does-not-do-word" unless they fix that. Happened here on my bank, they required IE 7 and I (and other fellow local geeks) called and emailed them so now they support Opera and Firefox.
    • Police have boundaries and borders. The internet, alas, does not.
    • by blueg3 (192743) on Friday January 16, 2009 @01:37AM (#26479097)

      Well, the nature of an arms race is such that it has technological approaches.

      In this case, for example, there most certainly is a technological approach. JavaScript in one loaded tab in your browser should have no shared knowledge with other tabs in your browser. Data separation needs to be enforced at a finer level. You should also know, if you have two tabs open to different sites, which one of the two a popup is associated with.

      • AFAIK tabs are really just windows. The difference is how they're displayed by the GUI. But from a Javascript POV the tab is just another window. So if we start limiting the knowledge that javascript has over other windows then we prevent a lot of useful, legitimate things that can be done with other windows. For example: I have a few web-apps that use pop-up windows in a non-annoying way (ie: you click something to open the window that actually performs a useful task).

        At first glance I like the idea of pre

        • Re: (Score:3, Informative)

          by blueg3 (192743)

          When you're currently visiting one site, and open a new tab and go to a different site, those two open tabs should have no capacity to share information -- they should function as if they were separate browser sessions. (Obviously this isn't the same as if you clicked on something in a tab that causes another tab or window to open, as they may need to share knowledge. But then, the fact that those two tabs/windows are tied to the same context should be made apparent to the user.)

    • What about just implementing a general pop-up blocker? If something actually does pop-up, and you don't get the request that it's from such-and-such a site, you know something fishy is going on. Anyways, I think there are two problems that exist here. The primary one is user education. More aware users may be harder to con unless by a very direct fishing attack. The second would be to standardize how sites can transmit secure information. I don't mean just encryption, but perhaps have a standardized protoco
    • Re: (Score:3, Interesting)

      by retech (1228598)
      There's a simple technical solution to this:
      1. trace the phishing to their location
      2. send a missile to that location
      3. problem solved
    • I believe there is a technical solution to this attack and to other attacks. But if a technical solution does not exist, then online banking is inherently insecure and should not be used by anybody.

      In this particular case: (a) block Javascript in different tabs from seeing what sites you are visiting, and (b) all popups should be clearly labelled by the browser with what site they came from. If it's an SSL site with an extended-validation certificate, then show the company name in large writing at the top

    • by macraig (621737)

      This is precisely the sort of evolutionary cat-and-mouse game that is likely to lead to the first true artificial intelligence. It won't be some well-meaning altrustic researcher in some AI lab, it will evolve out of this cyber-warfare.

      • Both.

        With semi-apologies to certain TV shows,

        "My mother was a prototype from an AI lab and gained all the lexical parsing rules and dictionaries. My father was a real-time self modifying system born out of the cyber wars. It's the unification of both that made me possible."

    • This is real scary. And it goes to prove that bad guys always come up with new ways to steal. I don't believe there is a technical solution to this arms race.

      A good start would be for banking sites to work with Javascript turned off, and, maybe, even suggest you turn off Javascript while using online banking.

      Requiring you to turn it _ON_ is insane, but extremely common.


    • by RonTheHurler (933160) on Friday January 16, 2009 @08:04AM (#26480775)

      How about this one-

      I got a letter in the mail (usps snailmail) from Bank of America asking for a lot of personal information that was missing from my account, and that if I didn't supply that information they'd have to report me to the IRS.

      The letter was spelled correctly, had proper grammar and even had the BofA logo printed in full color. The return address was a PO box in Dallas. Nothing fishy at all.

      Problem is, I don't have a BofA account. But I'm sure a LOT of other people do.

      Phishing - it's not just an on-line phenomenon.

  • XSS (Score:5, Informative)

    by AKAImBatman (238306) * <<akaimbatman> <at> <>> on Friday January 16, 2009 @12:08AM (#26478671) Homepage Journal

    Here's the novel part of it: it doesn't involve any of the typical attack vectors we all know and love.

    A cross-site scripting attack sounds like a pretty typical attack vector to me. Javascript should not be able to "detect" if they have a banking site open. Pure and simple.

    • Re:XSS (Score:5, Insightful)

      by AKAImBatman (238306) * <<akaimbatman> <at> <>> on Friday January 16, 2009 @12:21AM (#26478737) Homepage Journal

      BTW, for those of you who are curious about this attack (and are too lazy to RTFA), this basically uses a common image set behind a protected login. e.g.

      <img src="" onerror="notLoggedInSoRefresh();" onload="hahaGotEm();">

      If you ping the blasted thing for long enough, you will be able to detect the user logging in. One pop-up later and you've stolen their info.

      Now protecting against this sort of issue is an interesting question. Ideally static resources should never be behind closed doors. But that answer is a bit of a cop-out. The next best thing is to ensure that session cookies are maintained inside the login tab ONLY and that persistent cookies are not used for auto-login.

      (Interesting question: I wonder if Chrome is vulnerable? With process isolation, this trick would require that the main Chrome process delegate the handling of session cookies. Which seems like a bad idea anyway, so I would hope they implemented the browser in a more secure manner.)

      • Wouldn't this mean they'd have to ping every bank? If I bank at, loading anything from isn't going to get them very far. Now, if they sniffed my temp folder for lock.gif or other footprints... that might work.
        • by Culture20 (968837)
          It doesn't take them any more time to "ping" the top 20 banks than it would just one. It's all done by your browser on your machine in response to a web page. It's just the difference of 20 img tags or just 1.
      • Re:XSS (Score:4, Interesting)

        by Animaether (411575) on Friday January 16, 2009 @01:22AM (#26479045) Journal

        so wait..
        as you explain it, I guess the idea is that once the user logs into the secure site, the malware script can magically access the lock.gif because the site and browser tell them that.. yup.. the user is logged in and thus should have access.

        however.. presumably, the script is not from a page that's actually -on- [].. if it was, you and the bank probably have bigger problems.

        So let's say that instead it's on [] - why would a script on a page from be allowed access to a resource - in this case 'pinging' the 'lock.gif' - *on* [] ?

        Is there any valid purpose for allowing something like that? I can understand it for non-secure sites.. from inlining content that's hosted on another domain to allowing local applications to grab data off of e.g. websites that do not provide a nice API. But for secure sites? I'm baffled.

        • Re:XSS (Score:5, Interesting)

          by AKAImBatman (238306) * <<akaimbatman> <at> <>> on Friday January 16, 2009 @01:43AM (#26479127) Homepage Journal

          So let's say that instead it's on [] - why would a script on a page from be allowed access to a resource - in this case 'pinging' the 'lock.gif' - *on* [] ?

          There's a great deal of internet history behind this one. Originally, there were no barriers what so ever. Anyone could link anything from any page. Of course, as Javascript entered the scene and grew in sophistication, this was soon realized to be a problem. In result, most browsers adopted security behaviors for the really powerful stuff like XMLHttpRequest and locked out scripting across frames.

          However, that still leaves a hole like this one. And it's not an easy hole to plug. Quite a few sites are actually structured around the idea of cross-site linking. (e.g. The HTML may be while the images come from the web server Interestingly, this sort of structure is actually a solution to the problem posed. So it's difficult to dispose of it out of hand.

          Some of the web standards are moving toward highly restrictive models for HTTPS sites. e.g. HTTPS resources can only be accessed by pages whose origin is the same HTTPS site. More likely though, I expect to see more explicit security configurations along the lines of what Flash does. Flash uses a crossdomain.xml file on the target site to broadcast if a resource can be accessed or not. This scheme allows for situations like a media server separate from the primary site, but it also allows for those cross domain accesses to be tightly restricted.

          Of course, the scheme is not without its problems. Nothing prevents an attacker from transmitting information he may have collected TO a server that he has configured with a permissive policy file. If he finds a vulnerability that allows him to collect the information in the first place, he's going to be able to make off with the info scott-free.

          In result, web security is an ongoing area of research. It's incredibly complex due to the nature and history of the web, but standards bodies are working hard to find more reliable solutions that don't negatively impact existing sites and current usage.

          • Re: (Score:3, Insightful)

            by Animaether (411575)

            "There is nothing special about secure sites. HTTPS doesn't mean "this site is super special and you should do special things with it". This same attack can be applied to non-secure sites, too." - RockMFR (1022315)

            Well that's the thing - why not? They are superspecial to my browser already.. doing its certificate check and throwing a big fat "passport check" image at me (FireFox 3) if it think something's not quite up to snuff. I don't see why a page on anything other than [] shouldn'

        • Re: (Score:3, Insightful)

          by RockMFR (1022315)
          There is nothing special about secure sites. HTTPS doesn't mean "this site is super special and you should do special things with it". This same attack can be applied to non-secure sites, too.
  • Simple Solution... (Score:5, Informative)

    by Klootzak (824076) on Friday January 16, 2009 @12:12AM (#26478691)

    Don't have multiple tabs/windows open while you're doing your online banking!!!

    Oh, and use NoScript! []

    • by Bozzio (183974)

      This, like most phishing attempts, targets users who don't know about NoScript or basic internet safety practices.

      Yelling "Install NoScript you n00bs!!1!" won't register noobs... because they're newbs.

      • by X0563511 (793323) on Friday January 16, 2009 @12:24AM (#26478757) Homepage Journal

        Once more, Darwin extends into the internet.

        Computers are tools. They do what they are told without question. The internet is made of computers. By extension, it is a tool that does exactly what it is told.

        Kind of like a handgun, and you don't (usually) let people run around with those without some kind of training.

        Also like a handgun, most tools don't care who is issuing the instructions - they just do it. That tablesaw doesn't care if it's a 2x4 or your forearm, it saws anyways.

        Yes, I'm an elitist bastard sometimes.

      • by Klootzak (824076) on Friday January 16, 2009 @12:24AM (#26478759)

        Yelling "Install NoScript you n00bs!!!" won't register noobs... because they're newbs.

        Well, I wouldn't call them n00bs firstly... and secondly, most of the technically-savvy geeks/nerds I know read Slashdot and find out new and interesting stuff from here.

        One of the best things about Slashdot is if you write something on here, ALOT of people will take notice. So if by providing solutions/information that people can read and take away to tell other non-technically-savvy individuals helps protect at least one person from being scammed, I'm more than happy to yell on Slashdot about it ;)


          Sarcasm aside, that's not going to cut it. We may be in an arms race, but we do need to try to keep up. The internet should not just be for technogeeks any more than medicine should be only for doctors. But I guess you can argue that this is like a doctor telling you to eat well, excercise regularly, and lose Windows--erm, weight.

    • by Spacejock (727523)
      I second that. I've been using noscript for years, and wouldn't browse the net without it.
    • Half my desktop or more is web. These days you
      can use the web for spreadsheets, word processing,
      email, chat, and so on.

      Closing all those windows would suck ass.

      The browser damn well ought to isolate the
      web sites 100% from each other. WTF?

      Instead, the damn thing frustrates any attempt
      at manual isolation. If I try to start a second
      instance, that one does some retarded RPC thing
      to have my other browser instance spawn the new
      window -- and then that second instance exits!

      It's not even fail safe. Crash in one win

      • Are you suggesting I shouldn't be able to cut a link from one window and paste it into another? What about legitimate cross-site scripting, like using your Facebook account to comment on Gawker Media blogs? It's not nearly so black-and-white.

    • Re: (Score:3, Interesting)

      by j01123 (1147715)

      Oh, and use NoScript! []

      Another simple change is to set dom.disable_window_open_feature.location [] to true. That should make it pretty obvious when a popup comes from source different than what it's claiming.

      • by Cato (8296)

        Thanks for the tip. At least for Firefox 3 on Linux, this is set to true by default.

  • Funny how I got a Flash ad thrown my way when I visited the link.
  • by john.picard (1440397) on Friday January 16, 2009 @12:23AM (#26478749)
    The next thing you know, they'll make up a screen scraper in JavaScript. There are several things to learn from this. For the users, one, that you should completely clear your browser (Clear Private Data or similar) before going to a banking website, two that you should NEVER open other websites (or have them open) while you're signed in to a banking website, third that when you've finished banking, you should completely clear your browser again. For the browser makers (Firefox devs reading this?), third party cookies should be disabled by default, the option to turn them on should come with stern warnings, and each website can ONLY read cookies previously set by itself. Further when an encrypted page is opened, its memory should be such that other pages cannot access any part of it. In other words, the same sandboxing approach taken to deal with other security issues, within the browser for encrypted pages.
    • by r00t (33219) on Friday January 16, 2009 @01:08AM (#26478983) Journal

      Any browser window containing content from more
      than one security context must NOT display any
      sort of lock icon, and must display a warning

      "more than one" would include an https site that
      uses some http images. It's not secure if it's
      a mix.

      • by h4rm0ny (722443)

        Oddly enough, this is something IE7 did (by displaying a very annoying mixed-content warning) but which Firefox 2 did not by default (though you could turn it on). I'm not sure about Firefox 3.
    • by Fian (136351) on Friday January 16, 2009 @01:18AM (#26479027)

      Perhaps it is time to have a dedicated banking browser? One that does not use cookies/cache data/allow more that one tab etc etc

      • Does Google's Chrome browser do something to this effect? I recall something about Chrome each webpage in an independent process, not as independent threads.

      • Re: (Score:3, Interesting)

        by failedlogic (627314)

        I try and shy away from online-Banking as much as I can. Never mind separate browser. I use a Live Linux DVD and load up my bank site from there. When I do this its boot, bank website, print if necessary, shutdown and back to Windows.

      • by OpenSourced (323149) on Friday January 16, 2009 @05:35AM (#26480055) Journal

        I, for one, have a dedicated VMWare virtual machine with Ubuntu installed, and Firefox. Firefox has NoScript installed, is set to saving no user story, and I use it only for banking. I find the setup a bit unwieldy sometimes, but is sure safer.

    • Re: (Score:3, Insightful)

      by ljubom (147499)

      It would be cool to have firefox "mode" doing exactly this. Press an "online-banking" button and a new isolated firefox session would be started with all needed restrictions and settings.

      • Re: (Score:2, Interesting)

        by fprintf (82740)

        I'd bet this is something that could be created in GreaseMonkey or otherwise developed as an add-on for Firefox. It would certainly be an effort I would contribute to as this discussion is making me paranoid.

    • Re: (Score:3, Interesting)

      by labnet (457441)

      Or you should get a one time key generator.
      My key changes every 60 seconds. Could they exploit this within that time frame. (Especially if I'm already logged on and the bank does not allow a second simultaneous login)

      • by guruevi (827432)

        If the cracker is technical enough, yes they can. Again, you would have to have a dodgy site on one site, banking on the other (porn & banking, a good combination) then as soon as the JavaScript detects that it has access to the other page, it can start 'clicking' stuff from the other website and while you're logged in transfer $ from your account elsewhere or just request the page that has your account numbers on it and send it to a server somewhere.

  • by Anonymous Coward

    This is why I use a separate Firefox profile for banking and bill paying. And I only have one tab open at a time.

  • by dmomo (256005) on Friday January 16, 2009 @12:31AM (#26478787) Homepage

    The only way I can imagine that js on one site can detect if a user is logged into another (assuming the other site is secure and I cannot post js to it) would work like this:

    Use an Asynchronous request to "curl" out to a well known page of that site and then "grep" the response for typical "you are not logged in" text. If it is not found, commence shenanigans.

    BTW, this comment kind of made me roll my eyes:

    "Klein says placing a low-profile piece of malicious JavaScript on a high-profile Website isn't difficult to do, and the malware is basically invisible to the user."

    "Klein" makes it sound like this is a walk in the park. I don't know. After the myspace worm a few years back, I think validation and filtering on those sites has gotten pretty good. Low-profile sites? Sure. High-profile sites? Not so much. I'm not saying it's not possible, but "not difficult"... maybe Klein is just conceited.

    • It's called Cross-site scripting []. Except in this case I don't think XSS exactly describes the type of attack we see here.
      • Re: (Score:3, Informative)

        by dmomo (256005)

        I agree. Most XSS attacks would require the banking site to have a vulnerability. This article implies that all one needs is a vulnerability on the first (high-profile) site.

    • by blueg3 (192743)

      It's true. There's been quite a bit of research into it, mostly at Google. While you might not be able to pick a particular high-profile site and sneak JavaScript onto it, getting your JS onto "high-profile sites" in general is not difficult.

    • What if the cookie of the target site is against a host name such as []

      The attacker would not waste their time trying to guess the (randomly generated) 094ec182f4a74bc1382206407 part.

      So when you login your logging in with a host name with a token.


  • From the friendly article: although he and his research team have not spotted full-blown attacks like this in the wild as yet

    I'm sure they will now after this.

  • I already make sure that if I'm going to visit my bank, I close my browser, start a new one, do the banking thing, then close the browser before I do anything else. While banking I don't browse other sites.

    I figured an attack like this was possible but had no idea there was a way to check other sites you are visiting via JavaScript. That seems like a very obvious security flaw. Anyone know how that is possible? Is it via standard JavaScript, or does it require a bizarre hack that happens to work on t

  • I wonder if Chrome's idea of running each tab in a separate process makes it less vulnerable to this type of attack? I suspect that it is much harder for there to be a cross tab or cross window attack via Javascript it each has its own full process.
  • I always see folks bitching and moaning that FireFox burns memory... if you leave it open all day. Why would you do that? I must open FireFox 50 times a a day, and never complain about the extra 1.5 seconds it takes to do that, at least I know I have a "fresh start".

    Often, I also delete all the cookies too, just because I am a neat freak, not due to paranoia. Maybe I get more secure sessions as a side effect.

    Anyhow, keeping your kitchen neat and clean is healthy. Maybe keeping your computer neat and c
    • by Spacejock (727523)
      For some reason, FF 3.0 freezes for about eight-ten seconds after I start it up, every single time. It's very, very irritating, and the behaviour encourages me to leave it open as much as possible. (This never happened with FF 1 or 2)

      I have a dual core cpu with gigs of ram, so it's not a hardware issue. Running another profile (with few bookmarks) on the same PC doesn't exhibit the same problem, and I can only assume it's the browser rechecking links, favicons or something else every time I start it up.
    • You might have an account, but you certainly
      aren't depending on it and getting lots of
      email through it.

  • by dinther (738910)

    Are you kidding? Internet security clowns have a very limited imagination. They go nuts on securing one aspect beyond usability while completely ignoring other areas.

    Here in NZ there is a problem with ATM machine skimmers. Criminals equip the ATM machine with camera and fake card reader and collect card and pin codes from unsuspecting users after which they raid their bank accounts.

    So everyone is worried about this now. Yet, the most popular form of electronic payment in shops in NZ is the user of a bank ca

  • From TFA: "Klein says placing a low-profile piece of malicious JavaScript on a high-profile Website isn't difficult to do, and the malware is basically invisible to the user."

    I don't see how any well-designed high-profile site wouldn't account for the possibility it might get hacked, let alone not have an automated method for undoing the damage... A simple approach would be to generate an MD5 checksum from each file (i.e. ASP, JPG, flash) and compare it to the MD5 checksums of what they're "supposed" to
  • by dnwq (910646) on Friday January 16, 2009 @01:35AM (#26479095)
    Internet Explorer has a porn^H^H^H^H privacy mode where privacy settings are locked down. Why not build an analagous 'secure mode' for Firefox or Konq. where security settings are all locked to high heaven for that browsing session only?

    That way users can both bank online securely and not have half the web break for them because they've disabled javascript.
  • Here's the novel part of it: it doesn't involve any of the typical attack vectors we all know and love. Instead, it uses JavaScript ...

    Anybody who knows the history of security vulnerabilities in browsers knows that Javascript itself is the all-time-best attack vector. If Javascript is enabled in any browser, that browser can be immediately compromised when you visit a compromised website. There are latent epidemics of Javascript zero-day vulnerabilities in all browsers.

    Want much better security in your b

  • No passwords (Score:2, Informative)

    by Haiyadragon (770036)
    Over here in the Netherlands most banks (maybe all) don't use passwords. In my case I have a card reader that will generate a code after I give it my card, PIN number and a code generated by the website. I have to do this to log in and to initiate transactions. That makes this attack pretty useless. Also, a prompt should always clearly indicate by which website it was called and it shouldn't block other tabs.
    • by LingNoi (1066278)

      Surely banking would be much safer if there was a public key for the bank and a private key for the card stored on the card. The bank would have the private bank key and public card key.

      Then you could use a card reader to create encrypted messages to send to the bank.

      Although it doesn't deal with the problem of if the bank's key gets compromised. They'd have to recall all the cards..

The trouble with doing something right the first time is that nobody appreciates how difficult it was.