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 The Internet IT

IE Devs Criticize Bank Security Vulnerabilities 214

Posted by Zonk from the i-tend-to-like-that-little-lock-icon dept.
mrcaseyj writes "A post on the IE blog criticizes some banks for no longer using secure connections for entire login pages and only encrypting the password as it goes back to the bank. This prevents simple password sniffing but doesn't prevent a man in the middle attack from replacing the unsecured login page with one that has disabled encryption. This is especially a problem if you are using an unencrypted wireless connection such as at a coffee shop, because hackers can easily use the airpwn package to intercept the login page and steal your password. An easy remedy for when a secure page isn't available is to enter a bad username and password which usually brings up a secure page telling you to try again. But can you really trust your money to a bank that doesn't even offer the option of a secure login page?"
This discussion has been archived. No new comments can be posted.

IE Devs Criticize Bank Security Vulnerabilities More

IE Devs Criticize Bank Security Vulnerabilities

Comments Filter:

  • Fixed it for ya! (Score:3, Funny)

    by tomhudson ( 43916 ) <barbara.hudson@b ... com minus distro> on Tuesday May 08, 2007 @08:26AM (#19035443) Journal

    "But can you really trust your money to a bank that doesn't even offer the option of a secure login page?""

    But can you really trust your money to a web browser and operating system that are the most hijacked in the world?"

    There, fixed it for you.

    • If Ford made 90% of the cars in the world, they would also likely be the most crashed car in the world. Never mind that Ford are often fixed or repaired daily, the fact that the roadways are 90% Ford tends to skew the equation

      • Re:Fixed it for ya! (Score:4, Insightful)

        by Anonymous Coward on Tuesday May 08, 2007 @10:30AM (#19037505)
        If Apache made 70% of the webservers in the world, they would also likely be the most hacked webserver in the world ... Oh wait -- they do make 70% of the webservers in the world. Your metaphor fails.

        So back to the obvious explanation: the IE team can't code for shit
        • If Apache made 70% of the webservers in the world, they would also likely be the most hacked webserver in the world ... Oh wait -- they do make 70% of the webservers in the world. Your metaphor fails.

          So back to the obvious explanation: the IE team can't code for shit

          Needs some modding up, please.

          • Re: (Score:2, Interesting)

            by ewanm89 ( 1052822 )
            Find me a bank who uses apache? None, right how about on that uses IIS?

            • Re: (Score:2)

              by AVryhof ( 142320 )
              Hmm...

              JP Morgan Chase?
              http://www.jpmorganchase.com/ [jpmorganchase.com]

              Looks like they use Apache 2.0.55

              Bank Of America, HSBC, and my own bank all seem to use Sun-ONE-Web-Server/6.1

              From what I've seen by typing Bank into Google, and Clicking on links... it looks like Sun-ONE is the most popular. I didn't see any IIS....

        • Re:Fixed it for ya! (Score:4, Informative)

          by ThinkFr33ly ( 902481 ) on Tuesday May 08, 2007 @12:17PM (#19039017)
          An, indeed, they likely are the most hacked web servers in the world. IIS 6, on the other hand, appears to be extremely secure. Whether this is a factor of market share or code quality, we don't know.

          Apache: http://secunia.com/search/?search=Apache [secunia.com]

          IIS 6: http://secunia.com/product/1438/ [secunia.com]

          The fact of the matter is that you do not have enough information to conclude that IE is more poorly coded that any other browser out there. You are coming to this conclusion based on assumptions, not based on facts.

          • Re:Fixed it for ya! (Score:4, Informative)

            by nekokoneko ( 904809 ) on Tuesday May 08, 2007 @03:19PM (#19042209)
            Mod parent down! Nice try, but your search listed the vulnerabilities for all Apache related products (httpd 1.x, httpd 2.x, Tomcat, etc), totaling 383 advisories, while listing the vulnerabilites for only a specific version of IIS (IIS 6.0), totaling 3 advisories.
            Comparing IIS 6.0 to, say, Apache 2.2, we see 3 advisories for each product. Also, the comparison fails for only comparing the number of advisories and not the severity level of each one of them. Granted, Apache 2.2 has one unpatched advisory compared to zero for IIS 6.0, but it is not nearly as clear cut and one sided as your post made it seem.

            • Re: (Score:3, Informative)

              by ThinkFr33ly ( 902481 )
              Well, I gave a link to the search results for Apache, as opposed to a specific Apache version, to allow people to compare the versions they choose. How convenient that in your comparison you chose to concentrate only on Apache 2.2, which has, by far, the fewest vulnerabilities of the Apache family.

              To compare them somewhat accurately, one should compare IIS 6 with the version of Apache that has been out a similar amount of time, and, ideally, has a similar market share.

              I guess this would mean you would compa
              • I guess this would mean you would compare IIS 6.0 to Apache 2.0. In that case, IIS 6.0 has 3, and Apache 2.0 has 33.

                Another misleading post. Secunia only lists vendor supplied or publicly listed vulnerabilities. After the disaster that was IIS 5, MS stopped making that information available and now silently patches vulnerabilities they detect in-house.

        • Re:Fixed it for ya! (Score:5, Interesting)

          by ad0gg ( 594412 ) on Tuesday May 08, 2007 @01:29PM (#19040217)
          Who says apache isn't the most hacked webserver? I highly doubt IIS is ever hacked, IIS6 which has been out for 4 years only has 3 exploits come out of which 2 were from components that aren't even installed by default and the exploit that is actually in IIS has a rating of "not critical". Apache on the other has 10% of its known security holes unpatched. It also has 10 fold more holes than IIS. I'd take an educated guess and say apache is hacked way more than IIS so your example fails.

          IIS security holes [secunia.com]
          Apache Security Holes [secunia.com]

          • People modded you as funny because they're so blinded by their hatred for Microsoft that they simply ignore data that suggests that a Microsoft product is more secure than their favorite open source product.

            If you remove the data you used to back up your statement, you can see how they would find it funny.

    • Re: (Score:3, Insightful)

      by cryptoguy ( 876410 )
      I'm no fan of IE, but firefox is equally vulnerable to this issue. It's caused by the way SSL / TLS is used by the app on the server.

      • Re: (Score:3, Interesting)

        by rblancarte ( 213492 )
        The fact is that for an IE Dev to point fingers solely at the bank is joke.

        There is a lot of blame to go around for unsecure bank transactions. In the example, we are presented w/ the whole case of user on unsecured wireless. I think the lack of security of the bank in that case is the end users - I never would do bank transactions on an unsecured network except in extreme cases.

        Granted, I do believe that banks do share some responsibility. I think they would be best served to do all of their pages as se
        • I have no problem with banking on an unencrypted network, if the whole site is https. All banks should have their whole site encrypted; plaintext ought not be an option.

          Hooray for https://mail.google.com/ [google.com]

        • Re: (Score:2)

          by jsight ( 8987 )

          There is a lot of blame to go around for unsecure bank transactions. In the example, we are presented w/ the whole case of user on unsecured wireless. I think the lack of security of the bank in that case is the end users - I never would do bank transactions on an unsecured network except in extreme cases.

          So then you never bank over the internet?

          (hint... you should treat a wired internet connection that you "control" with just as much suspicion as a wireless one)

    • I must admit, I was looking for the "potmeetkettle" tag. Given that it's not there, the first post mentioning something similar was good enough, I suppose

    • One word answer: mattress (Score:3, Funny)

      by Anonymous Coward
      Just put your money in your mattress and avoid all those newfangled bank things.

    • Security is expensive. (Score:2, Insightful)

      by Anonymous Coward
      I have worked with computer programmers who think they know how to write secure software, but don't. They know maybe one or two basic principles, and think they have it all figured out. I call this the "well no one told me" phenomenon.

      Not every IT professional wants to spend lots of his free time researching the latest means of breaking into something, and defending against the break-in. So a lot of people just don't go out of their way to find out if they really know enough to write secure software...it

      • I don't have to know how to write secure software - I just need uncrackable keys, like "09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0".

      • Re: (Score:2)

        by Kelson ( 129150 ) *
        Maybe, but putting the login page on an HTTPS site that you already have isn't a terribly expensive proposition -- especially when you consider that many of these banks used to do it that way. Someone made an effort to move the login form onto the HTTP site, change all the links, etc., which probably cost more than leaving it on the HTTPS site would have cost.
        • I just checked by going to log into my bank, and its only https ... I wonder how widespread this "http" problem really is?
    • In Brazil, we would say: "Olha o sujo falando do mal lavado...", which is something like "Look the dirty talking about the bad cleaned...".

  • Isn't this a little old? (Score:5, Informative)

    by Hoover,L Ron ( 610796 ) * on Tuesday May 08, 2007 @08:27AM (#19035463)
    Links goes to some 2 year old blog entry.

    • Re:Isn't this a little old? (Score:4, Informative)

      by Don_dumb ( 927108 ) on Tuesday May 08, 2007 @08:41AM (#19035683)
      This whole article is basically just the same two posts the same submitter (mrcaseyj) made in this article http://it.slashdot.org/article.pl?sid=07/05/07/224 7244 [slashdot.org] earlier today. Now his posts may be interesting but anyone who was actually interested in this would have seen these posts today already.
      • I figured this was important enough to warrant a front page story. Both to inform a lot of users that wouldn't read the posts to some random security article, and to get enough publicity to spur the banks into action. The banks obviously know about this problem, so only a sufficient number of complaints would be likely to get them to fix it. Also, at the time, my posts weren't modded up as much as they are now. I wanted to get the issue well above the noise floor. As far as this being a link to a two year o
    • Must be a glitch in the matrix. This content is only 10 hours old [slashdot.org].
       

  • Nevermind Just The Login Page (Score:5, Insightful)

    by garett_spencley ( 193892 ) on Tuesday May 08, 2007 @08:28AM (#19035471) Journal
    The entire session should be secured. Bank account numbers, credit card numbers, transaction histories, information about billers and automatic withdraw dates etc. are easily sniffed.

    Just because they can't get your password doesn't mean they can't get useful information about you. Sniffing out an online banking session could be a big jackpot for an identity thief.

    • Re: (Score:2)

      by ozbon ( 99708 )
      I fully agree. Once you're logged in, it should all be through https 'til you log out again. That would seem pretty simple to me, but then, I am a Bear Of Little Brain. (allegedly)

      • Re: (Score:2)

        by jc42 ( 318812 )
        Once you're logged in, it should all be through https 'til you log out again.

        Uh, you missed the main point. "Once you're logged in" isn't good enough. Unless the login page (the whole page) is sent to you securely via https, what looks to you like a login page could be sending your login info in the clear to that Man in the Middle. He'll then use the info to drain your account.

        You need to make sure that the login session itself is secured in its entirety. If security starts only "once you're logged in",

        • Re: (Score:2)

          by ozbon ( 99708 )
          Yep, sorry, my bad.

          I did mean "From the start of the login process to the end of the logout process" - I just didn't actually say that.

          Thanks for the correction!

    • Re: (Score:2)

      by Kelson ( 129150 ) *
      Generally the session itself *is* secured by SSL/TLS. The problem is that many banks have dropped that protection from the login page, meaning that a password thief can then get into your account.
    • That's kinda the point. These sites being talked about actually *do* secure the whole session. Except for the most important part: the logon form! This practice is widespread even today (chase.com, sprint.com, verizonwireless.com, just to name three I happen to use on a monthly basis).

  • Um... (Score:3, Insightful)

    by 0123456 ( 636235 ) on Tuesday May 08, 2007 @08:30AM (#19035495)
    "This is especially a problem if you are using an unencrypted wireless connection such as at a coffee shop"

    Surely anyone who logs onto their bank site from a wireless connection in a coffee shop is just asking to get owned?

    • Surely anyone who logs onto their bank site from a wireless connection in a coffee shop is just asking to get owned?
      - Not if the site is using the appropriate encryption mechanisms.

    • Re:Um... (Score:4, Insightful)

      by Anonymous Coward on Tuesday May 08, 2007 @08:43AM (#19035713)
      Surely anyone who logs onto their bank site from a wireless connection in a coffee shop is just asking to get owned?

      Why? SSL protects you from MITM attacks and provides strong encryption & authentication.

      That is exactly what SSL is for, to protect you from sniffers/spoofers between you and the website.
      • Why? SSL protects you from MITM attacks and provides strong encryption & authentication.

        when it is being used properly, which it isn't.

      • Re: (Score:2)

        by CBravo ( 35450 )
        Bzzzt, wrong. As the man in the middle, I don't have to physically be in the middle. I can be on your insecure computer which has 0 day bugs which can become 0 day exploits.

        I am not aware of any bank transaction system that is impervious to man in the middle attacks.

        Do not trust what is on your monitor because it can always be fake.

        • Re: (Score:2)

          by jareds ( 100340 )
          That's not what "man in the middle" means. It refers to being in between in between the two endpoint computers. If you've compromised an endpoint computer, that's not a MITM attack.

    • Re:Um... (Score:5, Insightful)

      by jimicus ( 737525 ) on Tuesday May 08, 2007 @09:08AM (#19036111)
      Surely anyone who logs onto their bank site from a wireless connection in a coffee shop is just asking to get owned?

      Not really - this is the whole point of SSL. If you trust both endpoints, you don't much care about what's in the middle.

      Now, if you'd said "anyone who logs into their bank site from a random Internet cafe PC is just asking to get owned", I'd agree. It wouldn't require a great deal of sophistication to install keyloggers on every PC. Or if you're rather more sophisticated, you could set up some sort of proxy which sets up a MITM with every HTTPS session, presenting a self-signed certificate for $BANK and configure the client PC's with the appropriate certificate from the proxy's root CA.

      • Re: (Score:2, Insightful)

        by Z33kPhr3k ( 1047994 )
        2 factor auth prevents key loggers, but you need your own pc and secure dns to keep it private on the road.

        BTW without secure dns, Google Apps is worthless toy for the enterprise. M$ is shaking in their boots.

    • Surely anyone who logs onto their bank site from a wireless connection in a coffee shop is just asking to get owned?

      Sure, but are they aware of this fact? I'd say about 75% of the people (random number) don't know the dangers in logging in on a wireless network.

      For anecdotal evidence, yesturday I was sitting in a hotel with two public iMac terminals. A lady sat down and right off the bat asked her husband how to "turn the Apple off", by which I think she meant "how do I switch to windows".

      People l

  • Don't trust any bank that relies on credentials (Score:5, Insightful)

    by bjourne ( 1034822 ) on Tuesday May 08, 2007 @08:30AM (#19035497) Homepage Journal
    Personally, I wouldn't trust any bank whose security system relies on user supplied credentials. Any bank that does not supply its customers with an electronic hardware-based security token is not trustworthy enough to handle my savings.

    • Re: (Score:2, Insightful)

      by SlOrbA ( 957553 )

      Man ..

      It's all software .. It's all software.

    • Re: (Score:2, Interesting)

      by popejeremy ( 878903 )
      Hardware tokens present software cyphers, and cyphers can be spoofed.

      • Re: (Score:2)

        by SEMW ( 967629 )
        Could you elaborate? I'm no encryption expert, but if you have a hardware token, which receives a new key every 30 seconds from an encrypted radio signal, hashes the key together with a unique GUID that is different for each physical token, and displayes part of the hash; the user can use the displayed hash to logon, (it would only work for him b/c the unique GUID would be unique to him); and then 30 seconds later the bank sends out a new key over radio that's encrypted partly with the 30-second-old key (s

      • Re: (Score:2)

        by hab136 ( 30884 )

        Hardware tokens present software cyphers, and cyphers can be spoofed.

        I've not heard of any working attacks against SecurID (or any other hardware token). Got any links?
    • What is wrong with software solutions? When I want to login to my bank I first need username, which is random. Then a password, which I can change. Then another password, which can be used only once. Bank sends these one-time-only passwords in a letter (100 in one letter, and a new letter is posted once they start to run out). Basicly they could provide them on a public website, because they can't be used unless you know the username and password also.

      So tell me, how could a hardware solution be more secure

    • Re: (Score:2)

      by hab136 ( 30884 )

      Personally, I wouldn't trust any bank whose security system relies on user supplied credentials. Any bank that does not supply its customers with an electronic hardware-based security token is not trustworthy enough to handle my savings.

      What US banks offer this?

  • Credit Unions (Score:5, Interesting)

    by daeg ( 828071 ) on Tuesday May 08, 2007 @08:31AM (#19035521)
    I petitioned my credit union to force SSL on the entire bank website, complete with a few dozen signers (several of them with very large accounts). Shortly after the entire website is accessible via SSL only, with any HTTP page redirecting you to the homepage (SSL). Sometimes banking with a small credit union has its advantages.

    I suggest everyone do the same.

    • Re: (Score:3, Interesting)

      by mashade ( 912744 )
      USAA's site is all https and provides an immediate redirect if you type http://www.usaa.com/ [usaa.com] for example.

      Wachovia's site is as the article describes and only gives you https after login. I wondered about it myself and so began going to the site by manually specifying https://www.wachovia.com/ [wachovia.com] -- this works and gives you SSL for the entire browsing session. You may want to type it manually every time, though it would be nice if all banks made their sites HTTPS only.

      • Re: (Score:2)

        by Qzukk ( 229616 )
        USAA's site is all https and provides an immediate redirect if you type http://www.usaa.com/ [usaa.com] for example.

        Right this second, Washington Mutual's site https://www.wamu.com/ [wamu.com] does the exact opposite, it redirects me back to http:/// [http]

        It annoys me, but not enough to withdraw my cash. I just hit log in with the fields blank to get to the SSL page and then actually log in.
        • My current credit union redirects to https automatically. Out of curiosity i also checked my last two banks - Wells Fargo seems to redirect to https as well, while US Bank doesn't appear to offer a secure login page from the http site. That one is a little annoying, as even if you leave the login blank and hit login it just pops up a dialog box and leaves you on the http site. You can just go to https, though.

          Anyone know of a website that ranks banks on their online security? Might be interesting to tak
    • Yes, sometimes it seems to me that the credit union isn't out to get you for every dime. My credit union called me the other day to tell me how I could raise my interest rate on my savings accounts. Basically it entailed opening a different kind of account and transferrring the money over. They laid out the advantages and drawbacks and let me choose.

  • bank web security practices annoy (Score:3, Interesting)

    by Gary W. Longsine ( 124661 ) on Tuesday May 08, 2007 @08:32AM (#19035533) Homepage Journal
    This same annoying tendency of banks has another artifact (it's probably not intentional). It typically prevents the user's password management scheme (like Keychain on Mac OS X and analogous 3rd party password managers for Windows) from working properly. Without a tool like this to support the effort, most people wind up using the same password for all their web logins, which exposes them to dramatically increased risk. (Bad guys can exploit this common human behavior by plucking username / password combinations from any arbitrary p0wn3d web site, and then testing them at all the banks.

  • Come on guys... (Score:5, Insightful)

    by rob1980 ( 941751 ) on Tuesday May 08, 2007 @08:35AM (#19035567)
    Published Wednesday, April 20, 2005 6:44 PM by ieblog

    Two thousand and five.
    • 2000.5? Wow! That's almost seven years ago!

      ;-)

    • And yet, this problem continues to happen regularly, even on the sites of huge corporations which should know better. For example (just from sites I use regularly), chase.com, sce.com, verizonwireless.com, sprint.com. This vulnerability is *HUGE* and it deserves to be on Slashdot. If I own a public wireless hotspot, or even if I just happen to be *using* the same wireless access point as you, I can *trivially* steal your account when you visit these sites. This article is just as relevant today.

      BTW, if

  • What me worry (Score:5, Interesting)

    by packetmon ( 977047 ) on Tuesday May 08, 2007 @08:41AM (#19035679) Homepage
    Why should I really worry about security anyway they've either thrown away my information in a dumpster or were compromised...

    Scott Trade [consumeraffairs.com]
    Verizon [consumeraffairs.com]
    Bank of America [consumeraffairs.com]
    Choicepoint [consumeraffairs.com]
    Mastercard [consumeraffairs.com]
    AT&T [consumeraffairs.com]
    Department of Edumacashun [consumeraffairs.com]
    Chase [consumeraffairs.com]

  • Great article, but (Score:3, Insightful)

    by reezle ( 239894 ) on Tuesday May 08, 2007 @08:49AM (#19035783) Homepage
    Great article, but WHICH BANKS are the problem?
    I'd love to complain to my bank if it is guilty of these lapses, but how would I know?

  • I work with insurance companies on IT issues, and if it's anything like bank -- it's the same kind of business -- they suck hard at computer security.

    Their password policies for acessing extranets, for instance, are in most cases completely insane. They impose so many arbitrary constraints (such as changing the password monthly) in the name of security, no less, that invariably passwords en up being "password1", "password2" and so on. Furthermore most of them block an account after three unsuccesful login a

  • Food for thought: The keystroke-sniffing attack gets even worse if your JS can run in the browser chrome, a feature offered by some browsers.


    I wonder how a MITM attack could do that..

  • While the article may be older than dirt, I'm glad the issue has been brought up, because many financial sites still haven't done anything about the problem. It always pisses me off when I go to my bank's or credit card companies' site and am confronted with a login prompt on an insecure page. To add insult to injury, they generally have put some sort of little lock icon next to the login fields. Oh, well great! That must mean it's secure!. I mean, surely no phishing site will think to put a lock icon

  • Mother's Maiden Name (Score:4, Insightful)

    by giafly ( 926567 ) on Tuesday May 08, 2007 @09:46AM (#19036763)
    HTTPS is the least of my worries. I'm more concerned that banks
    1. Use insecure information such as mother's maiden name as proof of id
    2. Phone me with account questions, and ask me to prove my ID, but are incapable of proving their ID
    3. Send my credit cards and PINs using normal post
    4. Don't tell me when they have done "3)" so I won't notice if the letters fail to arrive.
    5. Don't give me the choice of turning off Internet access to my account
  • Yes, I'm aware that it should be the kettle. But in this case, that wouldn't do justice to (most) banks.

    For almost all successful bank frauds here, the culprit was a trojan in the IE. Banks do hire very good people to secure their online money transfer routines (at least here, cannot vouch for the US). What fails, though, is the security on the user side.

    Faciliated by IEs way of treating plugins. To slip a plugin into the IE, all you have to do is set a few registry keys. It does not even need any user inte
    • How dare you make an informative post based on real facts? This is /.!!?!

      Also, I think TFA may be conflating MITM with phishing. I'd like to see how many frauds have been really been succesfully perpetrated using real MITM (with contact back to the bank for something otehr than static content, as opposed to plain old phishing), It's not hard to set up a phishing site with a "real" SSL cert from some dodgy issuer, I've seen LOTS of those.

      Still I'm a little baffled why MOST sites have non-SSL login pages - it
      • The number is very low. Most phishing that relies on servers under the attacker's control come as a joint attack of an attack that is based on trojans for the IE. There was an attack against banks in Turkey recently that used a bogus hosts-file, but it was SO badly written (in VB5... shudder) that I just can't take it serious compared to the other attacks there are.

        "True" MITM attacks are exceedingly rare. Because of a minmaxing reason. Unfortunately NDAs keep me from telling much more, but ponder this: A t

        • A true MITM requires you to funnel all relevant traffic through your server.

          Maybe for a "true" MITM attack. But airpwn can do a sort of partial MITM attack. When your browser sends off a request for your bank's web page over the wireless, airpwn quickly sends back a response to your computer before the real server does (because airpwn is closer and can respond quicker). As soon as your browser gets the page back, it closes the port and ignores the real bank server. When you submit the password from the fa

  • Recently I tried to purchase some clothes from Hanes.com, a company most Americans will be very familiar with.

    As it turns out, all of the forms they send to your computer are encrypted. None of the data you send them back by filling out such forms are encrypted. Account logins, billing address, shipping address, card details - they all go plain text according to Firefox. I contacted Hanes customer support twice about this, only to be told that they use "industry standard encryption". "Yes", I said, "but onl
  • Ignoring any issues IE, or any other browser for that matter, may or may not have with regards to security the developers make a fair remark. In many ways this is like offering a high street bank the best cameras and locks only to have them not used. Browsers offer methods of data encryption that help provide security, but if the bank doesn't use them it doesn't really matter what was provided, it does matter, and cause concern, that they don't use them.

    The other issue is that public wireless networks (the
  • You trust bankers at all? WTF? Bankers are the scum of the earth.

    The banking system we have just now, the world over is the single largest scam ever created[1]. And it's backed and enforced by the various governments. Most people have no idea how our money and banking system works, they still think it's backed by gold or something. What bankers do, is take your money, invest it at a healthy rate of return and then give you marginally more than the rate of inflation, if they're feeling generous, less if they

  • Banks have a much bigger problem (Score:3, Interesting)

    by cdn-programmer ( 468978 ) <terrNO@SPAMterralogic.net> on Tuesday May 08, 2007 @11:44AM (#19038543)
    Banks have a much bigger problem than this. With the amount of spyware out there and the almost total lack of understanding of what vulnerabilities this exposes, probably more than 1/3 of the passwords and account details are known by Black Hats.

    There are many ways to slip money out of accounts it isn't funny.

    Trading accounts:

    Create a series of bad trade orders. Offset these with legitimate trade orders in legitimate accounts. There are many thinly traded companies where it is easy to figure out who has the buy order and who has the sell order. All one has to do on a thinly traded company for instance is place a lowball buy order and have the victim's account buy shares at whatever price and then sell them into the lowball. This can be triggered from instance by a stop loss order. Once the shares are owned they can then be sold to another victim.

    Chequing accounts: Create fraudulent transactions by paying for goods not ordered. These goods can even be shipped to create a semblance of legitimacy. By the time any of these goods arrive and the transactions are noticed the perpetrators are long gone with their loot.

    Its quite easy to create a series of dummy companies to accomplish this. Of course, since this is e-commerce one would obtain valid certificates ahead of time.

    This is one reason that secure communications offer limited protection. A felon in Jail can always get his lawyer to register a corporation for him and these are legitimate corporations. Its just they are run by crooks. But then Enron was run by crooks too it would seem. In fact, there are a HUGE number of companies run by crooks. Lots of people invest in them.

  • I'm in the bank business (Score:3, Interesting)

    by JustAnotherReader ( 470464 ) on Tuesday May 08, 2007 @12:10PM (#19038899)
    I've spent nearly a decade as a developer for a major California bank. I can't imagine that the SEC would allow any bank website to NOT use SSL. That's the most basic layer of security. But just to let you folks know that your data is safe, here are a few of the other things we do to keep your money and data safe from harm:

    • We also ask for your zip code and make sure it matches the user info we have on file.
    • We log the IP address you came from and the time. We do this for several reasons. The most common is that if we see 3 bad log in attempts in a row we lock your account. If we see several locked accounts spawning from the same IP address then we may have someone attempting to hack passwords. If that happens emails are automatically sent and pagers start going off. We notify our security people at once when that happens.
    • The password you enter is encrypted in our database via a public private key encryption. But we never generated the private key. We can tell if your password, when passed through the public key, matches what we have in our database. But we can't tell you what your password actually is. Even we don't know. That way if somebody ever gets into our database they can't use the password information.
    • We don't allow html or javascript in a user name, password field, account name or anywhere else that the user can enter data. We don't want a simple page display to run a rogue script.
    • We have a tremendous amount of safeguards to protect your account information from attacks from inside the bank, behind the firewall. Access to different apps are limit to certain staff via LDAP. All data changes create a record of the change with data on who changed it, what application was used to change it and who was logged into that app at the time. Every bank employee from the managers to the bank tellers is fingerprinted and goes through an FBI background check. Access to data is limited to those who need access to do their jobs. Physical access to the servers is severely limited to a select few.
    • The entire server and database infrastructure of the bank is duplicated in a 2nd location hundreds of miles away from the main servers. This database is being updated in real time so if any attack (whether a hack attack or a physical attack) brings down the system we do an immediate fail over to the backup system. This fail over and fail back system is tested regularly. I've been to that location. The servers are underground in a building with thick walls and no windows.

    These really are just a few of the many many things we do to protect your data. In fact, I deleted 2 of the list items that I originally wrote about because I didn't want to give away any information that could be useful to a potential crook.

    We take security very seriously for two main reasons. First, we're liable for any losses you have due to a security breach. But more importantly, we can't afford to lose the faith of our customers. If they don't trust us they'll take their money somewhere else. The actual financial loss from an attack on our system would be minor compared to the loss of trust from our customers.

  • I had a fully encrypted account login page bookmarked and used it, and at some point in the future they add an encrypted login area sections to their non-encrypted front page. I ignored it because I preferred to use the old page I had bookmarked. Several months later I got a message after logging in that I was using an old version of the login page that would be going away soon, and to start logging in from the front page and change my bookmarks accordingly.

    I ignored it, and now, several more months later,

Slashdot Top Deals

Trap full -- please empty.

Close