Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
The Almighty Buck

Online Bank Security: Cover Your Assets! 85

Posted by timothy from the your-session-has-timed-out dept.
LogError writes: "Randy M. Nash writes in this article: 'Why are there so many concerns about online banking? Where is the breakdown in security? Even brick and mortar banks have internal networks that must be secured. It's my understanding that these are very well secured indeed. What happens when these security-conscious organizations move their presence to the Internet?'"
This discussion has been archived. No new comments can be posted.

Online Bank Security: Cover Your Assets! More

Online Bank Security: Cover Your Assets!

Comments Filter:

  • Keep a paper trail to be safe (Score:1)

    by Anonymous Coward
    If you are serious about maintaining the safety of your own account, keep your statements that you receive in the mail and do print-screens of your on-line transactions. At least that way you can show normal use for your account and you will have a basis to return your account to if your balance is ever screwed up / cracked. I bank on-line (with a US bank) and disputed a charge that I noticed which popped into my account. The bank was very responsive about removing the charge and investigating. They were all the more ready to take me seriously because I could show the charge was outside of my normal routine.

  • Oh the security... (Score:1)

    by Anonymous Coward
    When I signed up at my bank, it was an agreement a mile long, the basic line was, the bank is not responsible for anything. There are online banks which go to the extreme of using their own proprietary software, which allows users to connect through the Internet, but some banks only allow direct modem dialup connections through these clients. I did not and will not in the future register at my bank to get 'extra' features for my online banking account. You simply cannot trust code written by people you don't know, or haven't reviewed their work. Online banking communications and infrastructure should be fully opensourced, available so anyone could be able to scrutinize it.

  • Banks may not be the problem... (Score:1)

    by Anonymous Coward
    The banks themselves are usually fairly safe. A while back somebody came out with a portal. The idea was that you could access all your accounts at all the different banks,credit card companies whatever using one site. Well part of that was you were required to give your passwords to this one site. Guess what the portal wasn't the best at keeping things secret. Oops

    Don't forget the banks have thier own internal systems. Locally the banks didn't get hurt by Mafia boy because they had been warned. The people who weren't in the old boys club got hammered.

    OTOH you have banks with the brain power of a walnut. I know of one bank that makes it virtually impossible to change your password. You can't do it online. When you file your application for online access the person taking your application will often suggest using your mothers maiden name as a password. I think they actually teach this to people. That's real secure.

  • Comment removed based on user account deletion
  • I don't know about any other banks, but People's lets you transfer funds and other things and manage a lot of other things online.

  • And in a full-way intelligent banking system they get a Verisign Global ID certificate which allows 128 Bit security even with browsers crippled for export.

    Klaus
  • Even brick and mortar banks have internal networks that must be secured. It's my understanding that these are very well secured indeed. What happens when these security-conscious organizations move their presence to the Internet?
    Unfortunatly, these organizations don't generally keep very secure networks, at least not the smaller ones. A lot of them use Unisys servers, which while they're new enough to be atx and communicate via tcp, the interface to the machine is via their terminal editor on port 23 (Probably vt100, possibly tn3270). Combine this with communication between branches over 56k frame-relay, unencrypted, and you have the potential for sniffing large ammounts of financial data. Luckily, when this contract is up, there will be one fewer bank with such an insecure network (hint: Link encryption is your friend).

  • Why. (Score:1)

    by SEWilco ( 27983 )
    "Why are there so many concerns about online banking?"

    "Because that's where the money is."

  • What you describe doesn't sound like any online bank I have seen.

    I've personally used two systems. One was based on a java applet which generated a local key based on a one time password I got sent from the bank via snailmail. My selected password only decrypts my local key which resides on my machine, which is then used for further communication with the bank.

    The other system uses a device protected by a pin code which generates one-time passwords.

    As to reactions regarding bad press: True this is feared, but it is also hard to avoid as security problems can just as well be discovered from the outside as from the inside. The first implementation of net.banking in norway was indeed unsecure. A couple of local geeks blew the whistle and the system was taken down immidiatly.

  • I'm surprised that many people are talking about the security at the bank itself, when it's the client machines that are the most vulnerable.

    It would be completely stupid for on-line banking to be used by the vast majority of computer (especially Windows-based ones - a relative of mine had sub7 only a month after buying the machine) - the security of the client can't be guaranteed.

    This method [slashdot.org] seems an excellent way of doing things (it's not foolproof. How about installing a client on the machine that snooped the keystrokes in real-time, and then disabled the network so that the code could be used by the attacker instead?) but the thought of having insecure operating systems on the client sends shivers down my spine.

    I don't think that on-line banking should be commonplace until the security of clients is vastly improved - there's too much of a chance for passwords, IDs, credit card numbers, etc being snooped on.

  • Instead of just giving your hired [ch]rackers the full brunt of your security, start by doing that, then periodically give them chunks of information they could gain from various employees, source code, passwords, etc, *until they break it*. That way, you'll know _how_ secure your system is, not just that it is too hard for so-and-so to crack.
    --------
    Life is a race condition: your success or failure depends on whether you get the work done on time.
  • I remember that one. $250 billion was it? Aren't those jokers busy investing money again?

    I recall Rolling Stone (they weren't completely lame at that point) having an article about all the things you could do for that much money -- like take a cab ride to Jupiter...
  • I use Online Banking and like it..:-)

    If someone grabbed my password, he could just see my account, to make any transaction you need a so called TAN Number, I get them from my bank via snail-mail and you can only use one number one time, kind of shared secret. When you have used all your number you have to order new ones from your bank. This and 128-bit SSL looks like it's secure enough...;-)

    Michael
  • I was thinking more of their AppShield product, it sits infront of the web server and stops the hacks there. AppScan is cool since it's the first application focused scanner, but I've always been a fan of an active solution.

    I agree you, you need to hire good coders. But I have seem some of the best make the worst mistakes. With the time to market demands slaming them in the face everyday, the chances that they will make a mistake increces. Good coders minimize the risk, but they can't eliminate it. Perhaps the coolest thing about AppShield is that it is not based on pattern files that you need to keep updated, it just figures out your web app by parsing the HTML and then blocks all the rest. How many things out there can protect against unknow hacks? According to their web site this thing is protecting the Israeli goverment!

    Damn I sound like an advertisment, but technology like this is going to be the only thing that can save online banking and e-commerce from a hacking arms race that is out of control.
  • Some banks suck anyways, like mine...If I want online banking I have to pay $10 a month to have it. $10 a month so my account can be hax0red into and have all my account info stolen...
  • A while back somebody came out with a portal.... Well part of that was you were required to give your passwords to this one site. Guess what the portal wasn't the best at keeping things secret.
    The defect being, of course, that the portal never should have kept that information. It should have remained on the user's computer.

    How many other problems related to other issues, like privacy, would be fixed by using the same design philosophy? Consider the user-profiling used by web advertisers. The avowed purpose is to give the user ads which interest them, and avoid showing the user ads which are not of interest. Why does this require the banner-ad site to be in the loop? These preferences could be collected and managed by the user's own computer, and never sent outside it; presented with a choice between several ads, the client-side preference machine could pick the one most aligned with the historical likes of the user. It would even be possible to make something to get rid of particular ads permanently; what need does a male user have for feminine hygiene products, or female users for Viagra? If this were configured as a client-side selection apparatus, privacy would be preserved and relevance even more so.

    If this happens anywhere, it'll be in the EU. The USA allows this tracking information to be collected and sold, so there is a powerful incentive to grab it even if the model is broken in serious ways. If the sale of that information is barred and even the keeping requires subject-review procedures, the incentive to collect it is lost (it costs money to keep data). At this point it makes far more sense to shove the work and the data down to the user's machine and never touch it at the server, and the privacy problem goes away. At this point, security becomes the user's problem. Most user machines are very insecure, but hacking one web site is a lot easier than hacking hundreds or thousands of individual PCs.
    --

  • heh, looking back at my post I guess it does sorta look like that. But no, I don't. I was just so pleasantly surprised when I went to find something like this online, that I was hooked. I will admit though, finding an online (well, good one) bank that doesnt want a huge deposit or a minimum daily balance is sort of tough, there needs to be a site out there with nothing but Online Banks. Not just the 50/50 Online/Brick anf mortar mix but pur online banks. Towards the end I had a choice tween these guys and 3-4 other. To tell the truth the only reason I picked netbank was because the minimum required to open an account was (at the time, not sure now) only 50$. *shrug*

    ----------------------------------
  • The difference is that an internal network is just that: an internal network. Assuming the bank's network designers had a modicum of intelligence, the (important parts) of the internal network have no connections whatsoever into the outside world (read: terminals not secured by the bank's physical security), which means they are literally uncrackable -- from the outside. Inside jobs are a different matter, and and I would not be too surprised to find that at some places internal security consists mostly of obscurity. And of course there are tales about evil Russian hackers splicing into the banks' private cables and whatnot... there's probably a grain of truth in them, but for most part we'll never know since banks have a very large interest in keeping things hush-hush.

    Internet banking is very different. When you have a bank on the Internet, you must allow people anywhere on the Internet to manipulate those critical internals, and the system must be very, very carefully designed to allow only authenticated people to manipulate only their accounts. This is highly non-trivial, and it's only a matter of time before somebody manages to exploit a flaw. Whether we will ever hear about it is another story.

    Cheers,
    -j.

  • http://www.smartmoney.com/bestbuys/banking/index.c fm?story=ebank

  • So what bank was this? I'd be interested in checking it out to see if it fits my needs.
  • you have not come up with one single, solitary argument that stands upto any scrutiny.

    How about "My bank just made me change my PIN to a 4 number code?"

  • Most banks suffer losses each year from fraud and (more often) inside jobs. You don't here much about this, but the amounts can be substantial. Banks and their regulatory bodies generally have a sense of proportion about such things - when online banking shows material losses, you can expect that they will respond. But the losses haven't made much of a splash yet...
  • 3. browser ssl - it doesn't matter if the site's key is 128-bit; if the browser functions at 40-bit, then that's the key size used for encryption. This is a problem with all ssl-based connections. is also flawed. Most new web servers incorporate "step-up" technology, which will "pull" the client crypto up to the level of the server. FROM the IBM HTTP Server documentation:

    Stronger encryption option for financial and banking Web servers

    When designated as a financial or banking Web server, the North American edition of the HTTP Server can exploit the strong encryption capabilities in the domestic and international versions of Netscape Navigator 4.x and Microsoft Internet Explorer 4.x. To use this function, you must purchase a special digital certificate from VeriSign called a Global Server ID.

    For regular Web transactions, the Netscape and Microsoft export browsers can use 40-bit encryption only for Secure Sockets Layer (SSL) transactions. However, when the server uses a VeriSign Global Server ID for its SSL certificate, the export browsers can use stronger levels of encryption of 128-bits or greater. This enables a server with a Global Server ID to communicate at the highest SSL encryption level with both domestic and international versions of the Netscape and Microsoft browsers.

    International financial and banking customers of the HTTP Server who want to use this function must contact IBM for an export license to obtain and use

  • They rush the move onto the Web, and/or the never really seriously consider the security of it. They just hop into a business deal with the latest big-name technology company with total disregard for that companies security measures.


    Refrag

  • Hmmm... interesting. I had a friend who was in charge of setting up an internal network in a b&m bank. Once he had it set up, he figured that he, knowing everything about the system, would be able to steal a sizeable sum of money in about 20 seconds. And it would take bank security 2 seconds to catch him. So I guess it really depends on who you're dealing with.

  • Can you transfer funds and do critical banking over the internet? I just use online banking to check my balance and sometimes pay bills, so I'm not too concerned about security.. should I be?
  • Wow... do you work for them or something? Cause I'm sold...
  • ...at how bad the online security of some banks can be. The largest bank in my country (and on my continent) has at least one firewall box I know of which lets you *telnet* into it, log in as root. The clincher? IT HAS NO ROOT PASSWORD. And once you're in would be easy to get to whatever info you want because the sysadmins don't believe in secure connections. Heck, port 23 is just *fine* with them.

    And another bank here which runs it's online services on IIS had left it with all the default settings *AND* passwords! Luckily a third party IT company discovered it while doing some unrelated work and that at least has now been fixed.

    The moral of the story? I don't trust the buggers. They're bad enough with hard cash (read: thieving bastards) what makes you think you can trust them with something as temporal as a few bits and bytes on an electronic communication meduim. That's what your money ends up as...

    In my opinion, a lot of things still have to mature before I am comfortable with the idea of doing business online with a bank.

  • Actually, there is another method that banks solve some of the application level security problems. It is called a hardware security module (HSM). It performs sensitive transactions like PIN Verification, so that keys and PINS do not appear in the "clear" (unencrypted) outside of the HSM.

    There are different solutions for different problems. Don't make the mistake of thinking an outside hacker attack is the most dangerous. When you are worried about insider fraud, SSL and IPSEC are mostly useless.

  • For a brief time in college I worked for a sysadmin temp agency. They had me placed at two banks and a phone company. The Telco had the highest security of all of 'em. One bank was using an old Unisys A500, which I suppose is security through obscurity. But with each temp assigned to do weekend log dumps and backups getting the administrator password (which was a 4-character word taped to the console in the server cage) I could hardly call it secure. I just showed up, said I was the weekend operator, and they took me downstairs and gave me the serverroom doorcode, no questions asked. I coulda had the ATM upstairs spitting $20's onto the street if I had wanted to. Additionally, Having the doorcode gave me access to all the desk PC's in the back office, so I coulda pulled up plenty of personal records. As it stands all I did was play Wolfenstein3d, but still... The other bank was slightly better. They had an IBM 3090, the temps had more limited access (but still enough to do damage), but the sheer number of temps employed and the frequency at which we rotated in and out of the roster makes me think that the capcity for security breaches was fairly high. With that many people having at least partial admin access, and AFAIK no password timeout policies. The telco had various ID checks, temps were essentially tape monkeys only or had only limtied access to certain CICS jobs, and passwords were individual and your logs were spot-audited by the supervisors often. Now, if a bank can't keep its internal procedures secure, how can they expect their web transactions to?

    ----

  • This is to do with the debit card system we have in the UK. In particularly, the largest debit card type, VISA Delta.

    For those of you who are unfamiliar with this system, let us take a moment to run through the basics. Visa Delta is a system designed to enable people to use their bankcards like a credit card. The only real difference between a credit card and a Visa Delta debit card is that you have to have available funds in your account to make a purchase.

    Sounds like a good idea? It is. And it's very successful, except there's a few cracks in the foundations.

    Here is how the system works:
    You go into a retail outlet and make a purchase. You hand your Visa Delta card to the sales assistant, she swipes it, keys in the value of the goods you wish to purchase, and then you sign the authorisation slip. That's it. Purchase made.

    So what happens when the assistant swipes your card? At least 2 pieces of information are sent to your bank: your card number and the value of the goods. The bank then sets aside the required amount from your account. This process of setting aside an amount from your available balance is called "earmarking". The retail outlet then has 8 working days to follow up the earmark with a transaction, or the earmark is erased. This sets the earmarked funds as available funds again.

    So where are the cracks? Let me show you. If the retailer keys in the wrong amount after swiping the card, they just swipe again and rekey. Then, the retailer is supposed to contact the bank and cancel the first earmark. If not, the sum of both earmarks is taken from your available balance.

    "That's not so bad", you say, "It'll be cancelled in a week and a half." That may be so, but consider this scenario:

    You have £200 of available balance in your account and go to make a purchase of, say, £120. The assistant swipes the card and accidentally keys in a value of £140. Realising their mistake, the assistant reswipes and rekeys the correct value. Immediately, your bank account has been earmarked for £260 -- more than your available funds. The assitant then forgets to cancel the first earmark and you are unaware of the mistake they have made.

    The next day, you go to an ATM and your account has been frozen. You phone the bank and they tell you that the earmarked amount is greater than the available funds and that they can't do anything until a transaction comes through. Why can't they do anything? Because when the earmark information is sent to your bank, there is no way of identifying the retailer, thus disabling you from contacting them to get the earmark cancelled.

    This is an appalling flaw in the system. It could be easily exploited to disrupt thousands of Visa Delta cardholder's lives by freezing their bank accounts for 8 working days.

    So how many people know about the earmarking procedure? Surprisingly few people, which makes this evidently more disruptive as, potentially, a kind of socio-economic virus. The banks know about this and what are they doing about it? Nothing.


  • ... which I guess just re-inforces the original point.

    I must admit that I haven't tried this, and I am surprised. Such an ability is usually dependant upon the card issuer's processing parameters, and not upon those of the acquirer of the transaction (assuming that one of the major schemes isn't standing in for the transaction, and VISA may require address verification as well). One of these days I'll give it a go with my card.

    (By the by, I was also surprised about your mention of attacking the PIN PAD, and obtaining it's master key. PIN PAD's are made for one reason only, and that is to not give up this information. I have been told that the only way this information can be obtained in most cases is to carry out some "scan" of the device to literally watch the electrons as they bounce about - I am no expert, but this is what I was told. If you have time, do you remember the PIN PAD manufacturer/type - Ingenico, Intellect, Bull ...?)

  • Just out of interest I have asked Ingenico Australia for their comments on this. I've no idea if they will reply, but I am very keen to hear their side of the story.

  • Which is why you should go to http://www.wamu.com/accounts/index.html, Washington Mutual offers true free checking, no monthly minimums required, no direct deposit required, no hidden charges/fees. Yes, it's a savings and not a commercial bank like Citibank, but does your average John Doe and Jane Doe give a shit for the benefits (or negativities) of large commercial banks? I doubt it. Washington mutual will cut it for most people with what they offer... on top of what I said, free visa check cards, free PC banking (excluding bill pay, which charges some ridiculous monthly amount). Check it out, you'll see what I'm talking about.

    --

  • Oh, did I mention their assets are worth in excess of 150 billion and that they're buying out any smaller banks on the horizon too? :)

    --

  • I need an excuse for why there's so little money in my account!
  • Internet banking is just an excuse for people not to actually have to drive to the bank but increases the risks to financial institutions needlessly. Of course that will not stop everyone and their mother from doing online banking just the same because it's the "cool" thing to do.
  • There are at least a couple of hurdles to make getting any info hard 1. Most networks are switched now internally (at least with new equipment most of the time) 2. You would have to be at the router or ISP level to get anything from a dialup ISP. So it's mostly an internal matter that can be solved with upgrades and the like. Of course there's something called FDIC which will insure your deposit for up to $100,000 per account so it's not like it would hurt you anyway.
  • Yes because that's where the money is and so also all that we derive from it, ie. satisfaction security and all that money stands for in these Capitalist times. A threat to our money is a threat to all those things and more. A majority of us keep our money in the bank not for the meager interest that they offer but for the sense of safe-keeping and security and general trust.
  • I don't know about other online banking systems, but the one used by my bank isn't totally automated. Accounts sold and other informations are automaticaly updated from the internal network to the online banking network, but transactions made using the online banking have to be confirmed by an employee to go from the online banking network to the internal network. If those employees are well trained, they will probably detect suspect transactions.
  • Of course it will, we humans are built too short-sighted to avoid problems like that. As for SSL, I agree with another comment here: that might not be the big problem. Obtaining account information by listening to the network is no trivial task. It is far easier to write a program to generate card numbers, and then abuse those on the internet. Which brings me to my point: A much larger threat is poor access control / identification. (Grossly) simplified, it is not that dangerous that someone can "see" the transfer of money from my account to others. What's the problem is whether the originator of that transfer request can be identified. If you use a one-time password, for instance, it can't be used again. So what if someone reads it? Keywords in this area now are Certificates, PKI and such. This is already being used with credit card payments, and I'm sure banks could find it useful to adopt similar solutions. FYI: www.setco.org http://www.mbna.com/shopsafe/index.html
  • im 18 years old.. i work at a data processing facility for banks. currently we do all the item processing and online banking for over 20 banks in the area. so far we have had no problem with any of the online banking software. we use qUP online software. we post electronic cash letters, transactions, and much more stuff. although we arent a very big company, we have had numerous security experts coming in changing things. seems like the biggest problem i heard about was getting into the main online system from inside the work place. maybe this could still be a huge threat depending on the employees..... anyhow.. thats my little say so of this matter
  • I work for a security firm that specializes in providing penetraton testing services to financial institutions. In the last year I have seen a few dozen different e-banking applications and cracked almost all of them. The most common setup is a poorly written app running on an insecure NT system. In the rare case that the company is using a non-microsoft OS, the CGI's usually suffer from buffer overflows and the machines themselves are rarely locked down. People don't seem to realize that firewalls are designed to block access, the minute you allow connections to your web server, and connections from your web server to your mainframe backend, the firewall is already out of the picture. Considering the sheer number of ways to crack a machine through the web, whether its IIS, Netscape, or Apache, you would think more content filters would be in place for incoming traffic. If you think that internet security is bad enough, the internal networks of most of these institutions are enough to make a network admin vomit. What makes it even worse than the online banking is that there are usually dozens of modems attached directly to the mainframes and internal servers. Most of these internal machines have horrible passwords (if any at all). Just by calling a bank's phone range you can usually gain access to the financial processing system. Since these backend systems are rarely upgraded (the vendors of the financial software wont support any newer OS versions or patches), gaining root or admin access as a normal user is trivial. Before you go stashing all your cash in a safe and sleeping with a gun under your pillow, remember that these institutions are INSURED. Slowly but surely they will all come up to speed, due to mandatory audits being required by organizations such as the NCUA, CUNA, and the OCC. -spinux http://www.digitaloffense.net
  • > My last job (I left earlier this year, the
    > creative design part was over and I got bored
    > doing routine administration) was an Internet
    > Systems Engineer for a large bank/credit card
    > company/merchant processor.

    The other thing about that place was about the 20th time someone takes all the credit for your ideas, it gets old......

    > We built that system as impenetrable

    and uninterruptable

    > as we could.

    Four sources of power, clustered port redirectors for doing server farms, fully redundant hardware, etc.

    The security was give or take that one last little tweak that nobody would let us do....... Or that one last item on the checklist that was added and had to go through a change control process to be implemented.

    The actual redundantcy was to the point that it was harder to shut the the thing down than it was to keep it up. (almost like it was alive)

    > Extreme security, multi-level DMZ
    > design, black IP, major intrusion detectors,
    > dead-end fake IP subnets, quite a few traps
    > and, uh, planted 'distraction', and of course
    > 128-bit SSL.

    Hey-- I liked my planted distractions. They didn't have honey pot written all over them, but low and behold that's what they really did.

    Oh-- and can't forget intrusion detection supplied by different vendors and managed by seperate IDS specialists who completely reviewed eachother's work on a constant and continual basis. Oh-- and as far as anything for security or redundantcy goes...... if one was enough-- there was at least four. (two from two different vendors so it was redundant from both a networking and a security standpoint)

    > It's been running for almost two years now, and
    > noone has come close to hacking it. The
    > firewalls and intrusion detection
    > software usually record several

    thousand

    > attempts per day, usually just script kiddies,
    > once in a while a 'real' cracker. But nobody
    > has ever got in, and if someone did, I would
    > definitely be one of the first to know.

    Depends on who is the first to know internally-- race ya. :^)

    > We even hired some top-of-the-line, extremely
    > good professional hackers, and they were only
    > able to gleam the tiniest amount of information
    > about the topology of the network.

    Now for the question of the day. When the big name security certification companies review a site for insurance purposes, etc-- who certified that they know a damn thing about conducting pentration tests or reviewing security in the first place?

    True story: I personally completely and totally ripped SEVERAL of one company's "reports" to shreds in a document and did what I could to see to the refund of several thousand dollars to the bank. Every time we rejected their report because it was totally inaccurate, they would run another. The reports were so bad that they did not even agree with eachother! I felt bad for ripping their security analysts apart so badly, but I felt as though I had to do it-- their report was so bad that I could have composed a more accurate document when I was in Jr High less than a year after I learned what TCP/IP and ports were and still had no clue what a "slash 24" was.

    On with the rest of the story. I later ended up getting cornered into help their people understand what they did wrong and help them improve their security review process.

    I forsee someone wanting to bring up levels of experience or training so I'll just let it be known now that I am a self taught admin/security analyst/IDS/IPS type with little to no formal schooling or certification. I have lived, breathed, ate, and slept network security for over 5 VERY long years (with more 100 hour weeks than I care to think about) Granted I am probably the exception since I am under 30 and have done things from firewall QA, to VPN engineer, to banking system security person, to intrusion detection specialist. Now I am authoring from scratch enterprise wide security policy/requirement docs (posted to the intranet), aid in product selection, identify test paramenters for product security review, and make very important security decisions for a company with over 80K employees. I also gather best practice inputs and write implementation procedures and security checklists for of system/application build. Oh-- and it is a fortune 50 corporation. Oddly enough one of the few who was 99.9% mainframe up until a year ago and has skipped the 'open systems client/server' environment almost entirely)

    > The only bad thing about the bank site is that
    > the HTML coders have made one of the ugliest,
    > lamest sites I've ever seen. They sure could
    > have done a better job, but it's at least
    > usuable and extremely secure.

    Truely an example of beauty being in the eye of the beholder. I agree-- the site was/is hidious. I can't say too much about the code though since I have a different view on what a web architecture SHOULD look like. (I tend to like to put layered IDS type traps inside of application architectures though so don't mind me-- I'm a bit ahead of current best practice in that regard)

    > I use it myself, and feel safe doing so,
    > especially as I implemented a lot of the
    > security myself, very very carefully, as if I
    > made an idiot mistake I would be held
    > PERSONALLY liable.

    Yes I helped build it, and yes I helped secure it, but to this day I detest internet banking systems mere existance. I don't want or need my bank hooked into the internet, but unfornately all of them are now. I am left with only the comfort of knowing that at least this bank has used state-of-the-art technology configured to deny everything by default based on TWO sets of default deny rules on seperate products from different vendors. I take comfort in knowing that they are on completely different OS platforms for the two control points and that there is more IDS at those control points than I care to thing about. (to the tune of several gigs per day worth of logs that ARE ALL coorilated in real time for serious infractions and REVIEWED DAILY)

    > Kinda scary knowing how many billions of
    > dollars are in that bank, and it's my ass if
    > they get through. But I'd be very very
    > surprised (and very respectful of the person)
    > if anybody actually got through!

    That's what made the job fun though.

    > I don't know about other banks, but this one is
    > tight. (Sorry, I cannot disclose which bank it
    > is without written permission from them, or I'd
    > be happy and proud to tell you.)

    Good man. And no-- not a chance that I am giving that up either.

    > As far as the one bank someone was talking
    > about that didn't even use SSL - you'd better
    > find yourself a new bank - FAST!

    Actually, I'd recommend also calling the feds. They are in violation of several banking regulations.

    Now for the next person who posted:

    > I don't know why, but you sound like a total
    > cluebi.

    We won't go into what you sound like.

    > you just read 'hacking exposed' right?
    > Good network design is always good,
    > distractions are good, honeypots are good,
    > 128bit SSL, hoho, now that sounds promising.
    > You're using state of the art stuff 'eh, right.
    > I don't know any current or past commercial,
    > let alone public! software which I would trust.

    There are not any that we would trust either. You should not make assumptions like there is only one type of anything in that network.

    > For example, the world leader in firewalls,
    > yes, you know who that is, has had a remotely
    > exploitable buffer overflows in their code
    > since the very early stages of the product,
    > until today, they still don't know about it.

    I've known about it for nearly 18 months. I personally called the vendor you are talking about and talked to them about the problem when I learned of it in the underground. Once again an assumption. You ASSUME that the vendor does not know about it because they don't acknowledege it, have not published it or released a fix, etc.

    Having market share is entirely different than being the "world leader". I have worked with several firewalls. (I worked for a firewall vendor and did the configuring my vendor's firewall in the "firewall roundup" by NSTL) I know which product you are talking about find that the one you are talking about. It is basically junk relative the stuff some of the other guys are doing. I certainly would not trust it to direct internet exposure with no other control points between it and a secure bank network.

    > Oh, it's been running for almost two years now, > no incidents 'eh

    He did not say that-- he said "..... nobody
    has ever got in, and if someone did, I would
    definitely be one of the first to know. "

    There have been incidents of people hitting the honeypots. They did not get anywhere except somewhere where let's just say they have plenty of time to think about the "no good" they were up to.

    > let me tell you this darling, and you listen
    > well, if someone serious was after this system,
    > you certainly wouldn't know about it

    It helps to measure the situation before shooting your mouth off uncontrollably. For example, you just called a 6'8 280 lb guy with shoulders practically broad enough to put his arms out of BOTH windows when he drives down the street "darling"

    > Would you trust a system designed by a person
    > which has the above homepage ooze.bloomnet.com

    Trust is a relative thing. It is based on assurance.

    Let's analize it shall we.

    Relative to someone who practices in the making of assumptions rather than in the analysis of the situation as it presents itself. You don't have the kind of information you need to say any of what you have said.

    Just take the time to stop and look. Ask questions instead of assuming and flaming.

    Just incase you are wondering no-- I would not trust your skills over the guy you just flamed.

    > he clearly has obvisous mental problems.

    Once again-- another assumption.

    > I would flame some more, but I'm tired.

    Glad to see something was able to save you from the embarressment.

    A wise man once wrote: It is better for someone to think you might be a fool than to open your mouth and remove all doubt.

    Please spare us the removal of doubt factor.

  • Security not as important as you think (Score:2)

    by Anonymous Coward
    I've been involved in creating online banking software for credit unions and I don't think many people realize the security risks (or lack thereof.)
    1. First, it is not an ATM machine, there is no way to get money out. You can request a check, but it will be mailed to the address on your account and only payable to the name on the account.
    2. You can transfer money only within your member number. Unlike banks, credit unions issue you a member number and you have sub-accounts for checking and savings. Even so, most banks' internet banking only allows you to transfer between pre-arranged accounts.
    3. The main function of internet banking is to deliver statement information (i.e. account balances, check clearings, loan payoffs, etc) through the web. Since SSL is classified as munitions by the government, I like to tell people that using SSL is like having your statement delivered by an armored truck. In our case, we don't display any identifying information. So although it runs under SSL, it would be difficult to identify the account owner even if it was not SSL.
    4. Network security is an issue, but that is needed whenever a bank or credit union is connected to the internet irregardless of whether they offer home banking.
    Think about this:

    If I gave you my online banking account and password, you could do little more than see my balances and statement information.

    However, if you had my Amazon.com account, you could order thousands of dollars worth of merchandise and have them shipped anywhere in the world.

  • It depends on what you mean by online banking. I don't mind checking my account status, credit card balance, transfer funds between my bank's accounts (basically things that are internal to the bank) from online, especially since I have to go through two layers of security (site password, account PIN) and they have time limits on session inactivity, etc.

    However, I don't let other organizations do direct debiting (like for bills, etc.) nor do I check my account from just anywhere. I trust my bank's internals, but I don't trust other people with access to my money. The only people who have outside access to my account are my employers, who have permission to direct debit my paycheck (hey, if they're putting money in ...)
  • Profits: Profit measures that exceed the expected [brw.com.au]

    ...Westpac reported an operating profit after tax of $818 million for the six months to March 31 and an economic profit of $493 million...

    Strategy: Westpac's Web revolution [brw.com.au]
    ...Jeremy Gross, Westpac's group executive for information technology and operations, says applications that have been developed so far, such as internet banking and broking, are "business as usual" - existing services provided through a new distribution channel....

    Customers redesign www.westpac.com.au
    ..."With customer satisfaction of 94% already, we are aiming to set a new benchmark for what customers can expect from a financial institution online.....
    www.westpac.com.au/internet/publish.nsf/Content/WI NU+Archive+media+release+08+Sept+0 0


  • I used to build internal only LANs and WANs for banks in conjunction with companies like fiserv, EDS, online financial, etc. Their security sucks. Most were pushing hard towards all NT shops when I left, with RAS setups all over to allow people to dial in from home and from customers sites. (they liked their mortgage people to dial in and work from clients homes.) The people running the admin were clueless. I tried. My company tried. But in general we were ignored. In general bankers must be some the of the most stubborn and dense people I have ever met. And the cheapest; they just popped for a several hunderd thousand LAN or WAN setup and wouldn't spend an extra thousand or two to secure it properly with. Of course the sales people on our end were usually no help and wouldn't quote the recomended gear to try and undercut on bids ...

    All that said, the actual online services that most smallish banks use (again places like eds and fiserv) tend to be secure as hell. Still run mainframes. ibm and unisys heavy iron at most as I recall. So even if an attacker go into a branch, they would probably not get to move any money.

    Peoples records on the other hand would probably be easy pickings. Some of these places stored a LOT of scanned stuff on optical jukebox type setups that required no authentication to access. Shocked the hell out of my the first time I had to field service one.

    thus endeth my rant, back to counting electoral vote totals ... :-)

    dv
  • OK, on further thought, the Subject title of "If you build them like I do..." was a bit cocky. I deserve shit for saying something arrogant like that... :)
  • I left out that detail, it was definitely audited by several third parties.

    I and a few other people WERE/ARE held personally liable. Not for it getting hacked for any reason, but if it got hacked and it turned out to be due to negligence on our part. Such as doing or not doing something that would allow the system to be compromised. Any piece of the system implemented had to be first approved by security auditors/analysts, etc.

  • > Would you trust a system designed by a person which has the above homepage (ooze.bloomnet.com) he clearly has obvisous mental problems.

    Haha. Of course, I design a play website called "Reflective Puddle of Leaking Mental Ooze" - yep, that definitely points out my mental problems! :) (actually, there's a history to the whole ridiculous name. I needed a DNS entry to point to my IP, my friend who admins DNS for bloomnet just set up three stupid names pointing at it, out of the blue, one of them ooze, so I took it and ran with it. It's not supposed to be anything serious, I do it for fun, just enjoy it and laugh, jeez. :)

    Oh fuck, remotely exploitable buffer overflows! Oh shit, the world is going to end! I've never heard of a non-remotely exploitable overflow. AS typical wannabe security guy, they always freak out about buffer overflows. Sure, they are a theoretical weakness, but come on, the chances of overflowing a buffer with obnoxious code and then actually getting the CPU's intruction pointer to execute them with an authorized user ID is just about impossible. The web server account itself does not have enough power to get into anything, it can't even modify files. Gimme a break, is that the best you can come up with. Typical skript kiddie trick.

    Oh, yah, 128-bit SSL is bad. Actually, it's not the greatest possible, but it's the best you're going to get without requiring every user to install some proprietary bit of code on every machine, whether NT, Mac, Linux, whatever. It encrypts it hard enough that it's not going to get cracked before the mandatory password expiration kicks in. Beyond that, what are you going to do besides "wow, User A transfered X dollars from account Y to account Z" Yippee. Boring...

    But hey, it was funny. Good flame. I liked it. :)

  • Buffer Overrun, don't ya mean "Remotely exploitable buffer overrun". See my previous message for more on those...

    Certificates? Sure, I've been to a lot of classes and read a lot of books, but certificates? Give me a break, I respect them no more than you do.

    Banks will like me better? Wow! I can't wait, I'd just love to cut my hair short again and start wearing a suit again for half the money.

    All I was pointing out is that Internet Banking can be done, securely. To the point that your biggest weakness is social engineering.

    Good people are rare, I dunno where I rank, but I know that if you think that buffer overflows are the scariest thing out there, then...

    Ack! I've responded to two flames. I know what that is gonna get me, this is going to be most entertaining. I wonder how long until it digresses into spelling flames and Nazi comparisons? :)

    Let the games begin :)

  • What exactly are you trying to say? Come up with a magically non-existent solution? All I did was reply that the 40-bit problem doesn't have to be a problem if the SysAdmin is clued enough to make the webserver only talk to full 128-bit browsers. I didn't say it was a magic fix that makes all your problems go away, did I?

    You've said in other posts (Yes, you, your points are redundant and identifiable, even if you are posting as an AC) the same point about system admins who know this or that are rare. What exactly are you trying to say. If you have a good point, say it. Just saying "Pretty much everybody is a moron" is just restating the obvious.

    Why does what I said piss you off so much? Maybe cut back on the methamphetamines a bit!

  • Generally funds transfer is only between your own accounts. The Bill Paying features are a bit of a weak link, if someone grabbed your password, they could set up a one-shot (or if they were stupid, a multi-shot) bill payment to whomever. By the time you got your statement, it'd probably be too late. However, a good bank will confirm with you any new bill paying additions over a certain amount (Anywhere from $500 to $5000).
  • While I can't speak for most large banks, a lot of smaller financial institutions such as credit unions tend to outsource their online banking and even their security....in fact, a government regulation was just passed by the NCUA (Nat'l Credit Union Association) that REQUIRES them to use high encryption, firewalls, and intrusion detection or they lose government backing. They are being audited for compliancy. (and these auditors are no joke, we got the same audit the CU's did)

    The company I work for is an ISP/Mail/Web hosting for credit unions exlusively, and provide them with the services they don't have the expertise to maintain...anything from encrypted online banking and bill pay, to firewalled internet access and email services.

    While I can't divulge exact information for very obvious reasons, they're quite secure, barring a hack at the CU itself. (Someone walks up to a station at an office where some dumb teller didn't lock his/her terminal) The host with all customer info actually sits at the CU, behind our network and two firewalls. A hit to their website hits one server, and if they log in to online banking, it proxies to an SSL server that can ONLY be hit from the web server, which in turn communicates with the datahost at the CU. To actually get customer data, 3 extremely hardened servers and 2 firewalls would need to be compromised. It's not even worth the effort. We don't even see the customer information, as the encryption/decryption take place at the user and CU ends. We've had security audits and penetration tests up the ass (no pun) and have yet to be compromised. Not to mention everything is logged and monitored both onsite and off.

    I imagine most banks have a similar setup, though the larger ones utilize their own networks. But to sum up, I guarantee you that your cash is safe...federal regulations require it. If a bank thought their setup was a risk to their network integrity, they wouldn't offer the service...it's just not worth it to them to lose the federal insurance.

  • In the industry in general.. it's not that sysadmins do not 'know' how to do things securely.. it's that they don't know how to properly justify the time spent doing security to their higher-ups.

    I'm willing to bet that this is the #1 reason. And who's fault is it? It's BOTH the sysadmins fault and the company's fault.

    The Sr. Sysadmin should be able to, in no uncertain terms, explain to the company the importace and *COST JUSTIFICATION* of proper security, and should also perform proper security audits, and instruct his staff accordingly.

    In cases where there is no overall system designer, and some Jr. guy runs the show... that's the fault of the company.

    And yeah.. I'm kind of saying that the most important factor (or at least, an equally important factor) about systems administrations is not simply technical knowhow, but procedural knowhow.. knowing how to do your job, which is more than just technical.

    Saying 'most sysadmins don't know much about security' has nothing to do with the issue.

    "Poor policy" is a better one...

  • From the replies, apparently some people don't recognize the quotation attributed to the famous bank robber Willie Sutton [banking.com] (wrongly attributed, until he stole it).
  • I have had this happen to me (US Banks and Visa Debit operate same way), mostly at restaurants. Sometimes the restaurant cancels the transaction, and all is well - however, on certain occasions BOTH transactions went through, and I only later noticed it after I got my statement and balanced my checkbook. I was then able to call my bank and contest the transaction - in all cases I was found correct.

    It gets more difficult if the transactions aren't entered for the same amounts, but you can usually spot the time stamps on the statement.

    The bad part on all of this (both the earmarking and double transaction entry) is the fact that the money is out of your bank, and you don't know it until your next statement (and balancing - you do balance, right?). Hopefully, you didn't overdraw by writing other checks or bills, thinking you had one amount, when you really had a bit less (this is where living month-to-month is a bad thing - which I why I always keep a buffer of several hundred dollars in my account).

    Of course, there are upsides to everything - I have several transactions still "pending" from several years that didn't hit my bank account. IOW, I went someplace, purchased something, they earmarked it - then never completed the transaction! Free stuff! Several hundred dollars worth from many different places (most out of state). I keep 'em on the books just in case, though...

    I support the EFF [eff.org] - do you?
  • ... this doesn't require a PIN, just a number and an expiry date.

    bzzz.. actually you don't even need the expiry date. Just enter any date after today's date and it will work fine - try it - go to amazon, put in your credit card number and 12/00 and it will work just fine.
  • it was an ingenico pin pad. We had a bet with them that we could do it but they never paid up :) But as I said, the NAB system does it all with software and you can read the key out of a file on the harddrive.
  • Here's how at least one bank in Finland [merita.fi] does it.

    You don't get to choose a password. You are assigned a customer ID code and a sheet of one-time PIN numbers. Upon logging into the system, you must give both the customer ID code and the next PIN number in sequence, after which that particular PIN ceases to be valid and you must use the next number on the sheet. This way, even though someone listened in on your keyboard, they can not benefit from knowing your PIN code, since it is never the same.

    The same applies when making transfers: on the same sheet with your PIN numbers are a bunch of other PIN numbers which are used for validation. When you tell the system to proceed with your transfer, the computer will query you for a particular PIN number ("please give PIN F") to which you must answer correctly. When you finally run out of PINs, they'll send you a new sheet.

    Of course, this whole thing requires that you keep your Customer ID code and your PIN sheet totally separate - and that you keep the PINs secure. But then again, that is what you have to do with your credit card, anyway =).

    Of course, the site is protected by 128 bit SSL and the works - so I feel pretty confident about the whole online banking idea.

    Compare that to WestPac [westpac.com.au] in Australia, which I've had had the privilege to be acquainted with during the past weeks: single password, which is 6 CHARACTERS AT MAXIMUM and may NOT contain any punctuation marks... And if someone grabs your connection, they can do whatever you want with your account... Eww.

    Disclaimer: I am just a customer to these two banks, nothing more.
  • Thank you, I was going to make that point myself. Please mod that man up!

    Anyway, Ob. Topic:

    So the FDIC presumably (so add salt to taste) has standards that a bank has to be audited to -- somehting like iso 9001 I'd imagine -- concerning data firewalling, air gaps, and the like. I think any 3 out of 10 slashdotters could draft pretty reasonable guidelines.

    The problem is x-fold (don't know how many I can come up with) as I see it:
    1) The bank has no interest in being any more secure than it needs to be, as long as it is insurable. I'd imagine premiums are flat-rate, and you don't get a cut if you are over-secure. Security costs money.
    2) If the FDIC needs to up premiums 'cause too many banks are insecure, it is easier to pass these costs on to customers than to deal with them. All credit cards (and checks for banks) accept that their system is dead-easy to defraud, but that it is cheaper to accept some loss (passed on to customers as fees) than to fix the system. Apparently you need at least $10000 on a check before the signature is verified.

    So relying on insurance means that banks can basically turn their insecurity into a systematic cost that everybody else has to pay. It seems to me that the FDIC should reevaluate whether it insures on-line transactions too, at least without very strict security audits.
  • Unfortunately it will probably take a very big and extremely publicized crack of one of these online banks (with possibly tons of personal information stolen) before these banks do anything about it. It is appalling that some of them aren't even using SSL!

  • The answer.. YES! I use NetBank.Com [netbank.com] and love them. I've used em now for about, ohh, 8 months or so and never once had a problem. Their fees are lower then ones you'd find at a brick-and-mortar branch AND their lowest-level no minimum balance checking accounts INCLUDES INTEREST! How many banks out there do that? I havent found one. And then theres the conveinence. I can order checks, deposit slips, transfer funds, pay my bills, whatever online. And the best part is I can go downstairs in my building, take out 20$, and instantly see that 20$ taken out of my account in real time. No waiting till midnight for the bank to update their records. And here another kicker, hows 24 customer service via the phone sound? Name ONE bank that does that.All my transactions take place over the defact-o standard ssl 128bit encryption. So in short, especially if you have direct deposit, theres no better way to go then online banking!

    ----------------------------------
  • How does the customer gain access to the site? Regular passwords or soething better?
    I don't know what's behind the web interface of *my* bank, but one thing that made me trust them is that they *dont* use regular passwords. Instead it's a pain-in-the-ass-but-safe procedure with one-time passwords from an external gadget.

    The web site prompts me two four digit numbers which I enter in the device to get a six digit number back. That is the one-time password.

    Even if someone broke the ssl and sniffed a password it would do them no good, since it was already expired.
    And if I make any transaction that send money ouside my accounts, i must enter another one-timer, just in case I was stupid enough to leave my computer logged in.

    Of course the system can be broken, but I'd worry much more about CC fraud or someone copying the magnetic strip from my ATM card and somehow get my PIN. (looking over my shoulder for example)

  • Step 1: Pick a bank. Step 2: typo-squat a domain Step 3: mimic their login screen perfectly Step 4: on submit, display a standard error message and redirect them to the real thing
  • I personally have experience with a few online banks and I have only looked at Bank One once or twice and only for a few brief moments.... but if you really look deep into bank security you will find issues, for example:

    Last year I "owned" a bank in Florida (that will go un-named) through some pretty well documented issues and the lack of patching on certain servers. Their servers were not only insecure, but the software running on them was insecure. Upon reporting the issues directly to the bank's ceo via phone and then faxing documentation to their offices, they never once contacted me to thank me. I documented ONLY one security issue and how to fix it, but I said there were _many_ more issues and that they needed a security audit.

    Even to this day, they only fixed the one issue... I've documented my side in writing... It's their problem if they get hacked and someone starts stealing money from their database... Anyways, my point is that even though I detailed issues in both technical and non-technical forms.... they still did not care too much about security... Does it really take an "evil malicious cyber criminal" to wake a bank up ???

    Another issue was this recent IIS Unicode decoding issue that allows escaping of the web root onto the physical hard drive root. Major issue... many banks still exhibit the bug and I've even noticed that some banks exhibiting the but on their financial servers that talk with their databases even have full C: drives... where IIS usually stores logs. So guess what? I am not logged if I go exploit a server where it's Web-logging drive (default win nt install is C:) is full... how convenient!

    I am not a "security expert" by any means, I am more a security enthusiast. Even I have been able to see MAJOR issues with banks being online. I will _NOT_ trust any of the banks that I have visited online yet.... there are just too many damn security issues involved.

    Most banks don't even use IPSEC inside their firewall, another MAJOR issue.... Some banks run Win9x terminals, install a keylogger and log their whole damn telnet session to their server ... damn you must be an EVIL MALICIOUS HACKER!
  • The answer.. YES! I use NetBank.Com and love them.

    Ditto, except I think their money-market accounts are mythical. At least, they've lost our app twice, and their tech-support's response to notifying them of this is to send us a boilerplate How To Open A Moneymarket message. Our trust is eroding slightly. It's not as if they've lost our money or anything, though.

  • I'm sorry, but you evidently haven't the slightest clue what you are talking about. I've been working with security people for some time now, and know a fair bit myself. In fact, tomorrow afternoon, looking at my diary, I have to go to a meeting to discuss the live penetration test a client has requested on his network. So, let's go through a few of these "facts" of yours, shall we?

    There are several issues that make online banks easy targets:

    The only issue that makes them targets is that they have lots of money. They are not easy however...

    1. Extreme conservitism - Oftentimes, their internal systems are quite old. While this tends to make their systems quite stable, it also means that they are generally insecure.

    Are you living in the 1990's? I don't know of a single bank in the UK that has systems that are in use that are not on sale today. You see, this was this little "Y2K" bug that they had to get rid of, so they had to throw out the old, bring in the new. My cash machine down the road runs Windows NT 4.0. Are you saying they should be on W2K? I don't think you undrestand that there are real advantages to running code a few years out of date - it's been audited. Clever that isn't it?

    2. Sensitivity to bad press - online banking systems, when compromised, are often hushed up quickly, due to the fact that the publicity will scare clients away.

    Firstly, to hush something like that up is illegal at least in the UK. Secondly, they will own upto it - they want to catch the bastards. A few years ago a few banks got hit by dudes with some EMP blasters, and were blackmailed for a total of £400 million. They hushed it up for a few months, then went to Special Branch. They learnt their lesson that time - now, within a few minutes they will be on the phone. The more we go through this, I'm convinced you're living in 1994 or something.

    3. browser ssl - it doesn't matter if the site's key is 128-bit; if the browser functions at 40-bit, then that's the key size used for encryption. This is a problem with all ssl-based connections.

    Yeah, this post is definitely out of a timewarp. How many people do you know with browsers that only have 40-bit crypto? You need to tell them to upgrade. How many banks do you know that will accept 40-bit crypto? None. In fact, my on-line banking service loads a Java applet that runs it's own crypto on top of SSL. Go figure.

    4. user passwords - people in general are dumb about choosing passwords. They often choose easy to guess passwords. It doesn't matter what security mechinisms you have in place; if a password can be compromised, the cracker has access.

    My bank requires me to know the full sort code and account number, a security PIN just for access to that system, and then there are around half a dozen "authentication challenges" along the lines of "First school attended" etc. If you get any of these wrong more than 3 times in a row, the account is locked out, and I then have to phone them up to get it unlocked. The statement "if a password can be compromised, the cracker has access" also betrays your complete and total lack of experience in the security field as well. You have based your whole argument on that sentence without taking into account how big the word "if" is at the start. How exactly are you going to compromise this password then? Brute force the website? I think they might notice. Use 'phf' to get /etc/passwd? I think they may have patched that one already...

    5. poor sysadmin training - this is the plague of the industry. Most sysadmins don't know much of anything about security. The one's that do are rare.

    I wonder if that's why they have something called a "recruitment procedure" that makes sure the admins do know what they are doing. I wonder if that's why the banks spend thousands on training programs for them. I wonder if just possibly those admins have slightly more of a clue than you do.

    In your arguments as to why on-line banking is a "joke", you have not come up with one single, solitary argument that stands upto any scrutiny. For you to start mouthing off about security would be a bit like me mouthing off about baseball. I think I know the basics, and I've read some stuff written years ago about it, but in actual fact, I haven't really got much of a clue.

    Think and then post!
  • KlomDark: I use it myself, and feel safe doing so, especially as I implemented a lot of the security myself, very very carefully, as if I made an idiot mistake I would be held PERSONALLY liable. Kinda scary knowing how many billions of dollars are in that bank, and it's my ass if they get through. But I'd be very very surprised (and very respectful of the person) if anybody actually got through!

    So you are telling us a bank trusted you as one individual to secure their systems which they put on the internet without audit by a trusted third party?

    I have two problems with this:
    1) The financial regulators would not approve this business, as it has not been audited 2) No-one in this dear green world is personally liable for the security of banking systems. We are talking about corporate security here, not firewalling some guys @home account.

    The rest of your comment sounds believable, but I'm sorry ... I don't swallow that bit.

    As someone who has been involved in the regulatory hurdles involved in putting a financial site live in the developed world, I cannot accept some bank took your word for anything: they need to get it approved by the government.

  • I have to take issue with some of your points: There are several issues that make online banks easy targets: 1. Extreme conservitism - Oftentimes, their internal systems are quite old. While this tends to make their systems quite stable, it also means that they are generally insecure.

    In actual fact, you will find most banks Core Banking Systems i.e. the bits that actually process banking transactions, whether online or offline, are extremely secure, and running on legacy mainframe platforms.

    They do exactly the same thing as they have always done (i.e. move money about), and thus are not usually subject to massive development projects, or huge leaps in technology. Because they don't have to. Online banking merely provides another interface to the core systems, and unfortunately it is the interfaces which are providing easy targets for malicious users.
    This happens because:
    a: The core system is written in something like COBOL or mainframe assembler, by 40 year old programmers who resist change and have many years of experience, using strong development methodologies
    b: The whizzy new web front-end was written by a group of 20 year old graduates who are shit-hot tech-wise, but lacking any discipline, and the whole development is being driven by eager managers who have to commit to the Bank's marketing department ("we wanna go oline NOW!!")

    I have years of personal experience of working with Banking systems (as one of those un-disciplined twenty-somethings :-) and until strong web-development methodologies are implemented, including bomb-proof testing, this problem will continue.

    Your comment:
    3. browser ssl - it doesn't matter if the site's key is 128-bit; if the browser functions at 40-bit, then that's the key size used for encryption. This is a problem with all ssl-based connections.
    is also flawed. Most new web servers incorporate "step-up" technology, which will "pull" the client crypto up to the level of the server (don't ask me how ... I'm no Bruce Scheiner! [counterpane.com])

    Online Banking is a joke (Score:3) by trog on Wednesday November 08, @12:14PM JST (#25) (User #6564 Info) There are several issues that make online banks easy targets: 1. Extreme conservitism - Oftentimes, their internal systems are quite old. While this tends to make their systems quite stable, it also means that they are generally insecure. 2. Sensitivity to bad press - online banking systems, when compromised, are often hushed up quickly, due to the fact that the publicity will scare clients away. 3. browser ssl - it doesn't matter if the site's key is 128-bit; if the browser functions at 40-bit, then that's the key size used for encryption. This is a problem with all ssl-based connections. 4. user passwords - people in general are dumb about choosing passwords. They often choose easy to guess passwords. It doesn't matter what security mechinisms you have in place; if a password can be compromised, the cracker has access.
    Yes, but you can develop screening algorithms, which will force the user to use a god password. And if I find a bank with the old "answer this dumb-ass question to reset your password" option, then I'll walk away.

    5. poor sysadmin training - this is the plague of the industry. Most sysadmins don't know much of anything about security. The one's that do are rare.
    Exactly! Online banking systems need two things: 1) penetration testing, and 2) more penetration testing to ensure the site is *still* secure.

    Unfortunately most institutions (not just banks) have an initial pen-test done to satisfy the financial regulators (as in the UK), and then presume their site will remain secure for ever!!

    Anyway: enough rambling!
    As I said earlier, most of this comes down to Bank development teams not testing their interfaces thoroughly. This can be proven by the timings of most security breaches: in the UK, it's almost always after a new code upgrade went in!!

    See Here [theregister.co.uk] and here [theregister.co.uk] for some gory details!

  • We built that system as impenetrable as we could. Extreme security, multi-level DMZ design, black IP, major intrusion detectors, dead-end fake IP subnets, quite a few traps and, uh, planted 'distraction', and of course 128-bit SSL. It's been running for almost two years now, and noone has come close to hacking it. The firewalls and intrusion detection software usually record several attempts per day, usually just script kiddies, once in a while a 'real' cracker. But nobody has ever got in, and if someone did, I would definitely be one of the first to know.

    I was also involved recently in siging-off the architecture for a large UK-based website that offered financial services (but not online banking), and was in a similar situation:
    I could easily sign-off the platform, but refused to sign-off the application (aka website).

    You can build the best DMZ-oriented architecture in the world, but if the code looks like swiss cheese there's nothing the architecture/dmz/ids/firewalls can do to help you.

    Needless to say the site went live anyway: the business "accepted the risk" .... sigh


  • Unfortunately for the customer, the fantastic on-line deals will cease when the shareholders start wanting returns on their investments (and I mean the corporate shareholders, not the day traders).

    Most business models for the online banks work as follows:
    Get customers to sign-up and use the services by offering interest on current accounts, little intial deposits, loss leading credit card accounts, and no/minimal banking charges

    At some point these banks will have to start repaying investors by actually making money. At the moment every single one of them is still some distance from this goal.

    They figure that if they can draw enough customers from the bricks & mortar banks, then eventually they will be able to turn a profit.

    Unfortunately (which is the reason we are discussing this!) the average banking customer enjoys the warm feeling they get from actually a) visiting their financial instituions grand palaces, and b) the feeling of cash in the hand.

    I think we may well see quite a few .com banks go under very quickly. By that I don't mean people will lose the cash in their deposit accounts, but that the banks will have to close their accounts and shift them back to the traditional outlets.

  • I worked 8 years overall in financial services systems engineering and some of the insight gained there will probably forever prevent me from dealing with banks online. For what it's worth, here's my brief analysis why online banking services are so prone to be cracked:

    Big Rewards : If a cracker succeeds the loot is probably a lot greater then after a successful MyTunafish.com hack. (in theory that is, getting the funds into posession is a whole other issue).

    DotCom Greed : In times where banks are no more measured according to their assets, but are taken upon number of customers that bank online, time to market of a system is extremely crucial. So security (the major attribute of banking online systems) gets usually put on a backburner. In fact there aren't that much really good security experts understanding client server systems accessible from everywhere and (save for the servers) with every external component being in a hostile environment. Now a bank, rather then losing a couple bucks of their stock price very often prefers to just rush the system in.

    Unsecure Interfaces : Instead of providing dedicated software a lot of online banks rely on web browsers. Thanks to those insightful 'Murican export restrictions on encryption a lot of the world still browses with 40 bit SSL encryption. Every kiddy who just purchased (or ripped off) the Little Crackpot K1dd13s Resource Shareware Kit is able to crack such communications online (or nearly so).

    Amount of components :A C/S systems security is as week as it's weekest component. The complexity of system security climbs exponential with every additional component introduced. Due to the lack of qualified people in the field Joe Dork (recently certified MCSE) is suddenly in charge of Unix Systems security without having a clue of course.

    There's a variety of more reasons, but those are probably the most important.

    The banks on the other hand don't really have to bother since they have that very powerfull tool putting you always into the role of the idiot: The Contract, Service Agreement or the TOS. Did you read it ? Did you find the part where it states that No matter what happens, it's ALWAYS the customers fault (possibly followed by) unless you can provide proof for gross negligence by the bank (Good Luck).

    Banks have a huge interest to get you to bank electonically. An electronic customer is the teller, the datatypist and the bank building in person. The cost savings are amazing. As long however those greed-freaks in conservative suits push the entire risk into my general direction I happily invite them to shove their service agreements up their rectums...

  • I developed a credit card processing gateway in Australia...

    Reading this post, I started off appalled. Than I realized they were talking about credit card numbers, not PINS. The credit card data is semi-public information, and there are a number of people that have a legitimate need to see credit card data with our current system. The requirements to protect credit card information are comparatively recent (people only started worrying about carbon copies in the late 80's). This has worked OK, until the internet started connecting everything.

    Wrong or right, the credit card system relies upon weak authorization systems (what you have, not what you know or what you are). This means they have a high rate of fraud, which is factored into the system costs. Given today's point of view, I'm not surprised that they found a lot of weaknesses. Start with the first and worst credit card problem, which QuantamG did not event think to criticize: the authentication data is public (kind of like the US designing the Social Security Number without a check-digit). If they used some additional data (like a PIN), many of the issues he complains about would be moot (you could find customer lists, but not really commit fraud). The whole credit card was designed around this principle.

    Perhaps ironically, Australia has some of the best requirements for POS security when it comes to PIN, the AS-2805 standard. This covers both physical and logical security for POS terminals that handles PINS (often called PINpads). Since AS-2805 was so stringent, Australia ended up with some of the most secure (and most expensive) PINpads around. The PIN encryption was single-DES based, but so was everyone else. Since anything on the magnetic stripe was considered public data, the POS requirements did not spend any effort trying to keep it secret. They only added message integrity protection in the early 90's. A great deal of time and effort was spent on key management (still a major issue today, even with public keys).

    An Aside: I worked for a company that used to sell some of the most secure PINpads around. We left the business, because among other reasons, security as a feature did not sell (we found superior usability and security were not worth a $5 premium for a $200 product in the USA!).

    Canada (Interact) started out with good security requirements, but kept on relaxing them requirements so the influential members could buy cheaper, and less secure PINpads. I think Interact gave up on their original PINpad security requirements about the time we left the business. Australia, unless they have caved since, was one of the few places that required all PINpads to be at the highest level of security. We never sold POS terminals there, because the market was too small to justify the expense of implementing AS-2805 routines into our product.


  • You jumped in before I had a chance ...

    It has been interesting following the posts regarding the safety of online banking - I guess this is where the technical ability and interest of most of the "posters" lies - but ATM/POS systems are far less secure. For the most part they depend on technology that is over 15 years old - the mention of the single length DES key is a good example; it will remain in widespread use until the Euro-Mastercard-Visa mandates require triple-DES encryption next year.

    However, I think the important point that this raises is that banking is not, nor has it ever really been, that secure. The simple fact is that most banks accept the loss - they know they will be de-frauded/robbed of money, no matter what measures they introduce. (To paraphrase another post "they knew it was insecure, and yet they did it anyway".)

    Whilst this offends techies to their deepest of deep-bits, in the end it is not our decision, it is up to the people who hold the purse-strings - I guess this is what actuaries get the big bucks for. (Fraud detection systems are all the rage now; note that the majority of these catch transactions after they are completed, not online. Hotcard the card involved, and issue a new one - this is how they work.)

    Banks know that the vast majority of people don't have the cabability to crack them wide open - if they did, there are far easier ways than some of those that I have seen mentioned today. Who cares about SSL when, for example, there is an ATM/POS transaction type specific to "mail/telephone" orders ... this doesn't require a PIN, just a number and an expiry date. Anyone can do it. Online shopping and e-commerce is basically just piggy-backing on this transaction type when it hits the back-end "core" systems, or when it is carried out by a VISA/EURO cardholder.

    Banks are service providers, consumers demand a service, and as a defensive measure, banks will provide it. The profit in doing it is worth more than the loss from fraud. Not all downtown bricks and mortar banks are secured like the American Fort Knox, remember, it's just not worth it.

    Further, limits exist on most credit/debit cards, you can't do 1/1.2 million dollar transactions - on most cards. You have to keep going back, in which case, as fraud detection improves, you'll find that your transactions are noticed much sooner each time. Fraud detection is neural net based, nowadays.
    (And by the way, derision for the security employed by the Australian banking system is not really justified. I have been consulting worldwide in the electronic banking industry for the last three years (and worked for 6 years in Australia prior to that), and the ATM/POS network there is, at the very least, consistent with those utilised elsewhere. I'm sure it won't take long for internet banking there to exceed international standards either.)
    At the end of the day, locks really do only keep honest people honest.

  • Online banking it too convenient. That's one of the things that makes it insecure. With online banking I can check my account information, transfer funds, pay bill, even buy and sell stocks, from any computer on the Internet. That's the problem. If I can do it, so can somebody else with my account name and password. Would you use an ATM if all you had to so was walk up to it and enter a name and password, with no other proof of identity? I wouldn't. Online banking will not be really really secure until smart cards are used to show proof of identity (or at least proof of possession). That said, I would use online banking no problem if my bank would assume liability for any intrusions that take place. Credit card companies already do this. I haven't heard of a bank that has given the same assurance.
  • I also bank exclusively online and I've had no problems. I am morally opposed to paying banking service fees ($25 in one month - no thank you!) so I switched! My new bank has no brick-and-mortar buildings - any time I have problems or unusual requests I call the telephone banking line and they help me. I know this sounds like a commercial, but its really much easier. I always use 128-bit encryption, and this eases my mind. I am eternally grateful I live in Canada where you can debit coast to coast without any headaches, and our banks (even my cheesy online bank) are super stable.

  • Re:Online Banking is a joke (Score:3)

    by KlomDark ( 6370 ) on Tuesday November 07, 2000 @06:25PM (#640752) Homepage Journal
    > 3. browser ssl - it doesn't matter if the site's key is 128-bit; if the browser functions at 40-bit, then that's the key size used for encryption. This is a problem with all ssl-based connections.

    If it's a half-way intelligent banking system, they'll have the system set up to ONLY accept 128-bit browsers. If you can hit your bank with an old version of 40-bit Netscape, time to bail!

  • For what it's worth... (Score:3)

    by atubbs ( 72643 ) on Tuesday November 07, 2000 @06:04PM (#640753)
    I bank online, and I'm relatively confident about it, but I don't pretend that I'm safe. Bank One seemed to think that by requiring 128-bit encryption, their security needs would be taken care of. I don't know much about the internals beyond that, but my guess would be that any sort of security issues that come about are going to be a result of people exploiting some code quirk, rather than decoding encryption on the fly.

    No matter how careful they are, sooner or later somebody is either going to find or stumble upon some back hole into the system, whether it's some nasty SQL that's output that's displayed to the user or just a random glitch.

  • Re:Regarding sysadmins and security (Score:3)

    by doctor_oktagon ( 157579 ) on Tuesday November 07, 2000 @08:51PM (#640754)
    The Sr. Sysadmin should be able to, in no uncertain terms, explain to the company the importace and *COST JUSTIFICATION* of proper security, and should also perform proper security audits, and instruct his staff accordingly.

    In a regulated organisation like a bank, it is most definitely NOT the sys admins (whether senior or otherwise) who should be doing this: it's the Security Manager .

    While I fully agree the sys admins should all be security minded , this should be backed up by clear directives (policies/standards) written/approved by a security manager, who has the time and the high-level clout to act.

  • It's the application stupid! (Score:4)

    by silvexis ( 65549 ) on Tuesday November 07, 2000 @08:45PM (#640755) Homepage
    I see all this talk about 128 bit SSL, the best IDS, the best firewall, etc... All Worthless against a good Application hack. Take a study by the ICSA, "Out of 5000 hacks, 2/3 were at the application layer"! Hell, take a study of all the financial sites out there to have gotten hacked. Go further and look at all the high profile sites that have been hacked recently and you will see one thing in common - the hack targeted the web app. No network security device can prevent a web application layer attack.

    Just spent a fortune on that cool network IDS system? Great, well guess what, SSL renders it useless because you can't watch encrypted traffic! So now the hacker is hacking securely as they come right through your firewall on port 443 and just mucks with your web site while you have no clue what's happening.

    It's an accepted fact that all code has bugs, your web site is based on code, it has bugs, and it's only a matter of time until the hacker finds a way to exploit them, and most of the time you won't even know.

    The problem requires a new approach, you need an web application layer IDS, and this is not entirely a easy thing to do. You have to be able to understand the application in real time and process the SSL transactions yourself, in essence you end up with a very smart (and hopefully fast) reverse proxy. There is only one company out there (www.sanctuminc.com [sanctuminc.com]) that's doing anything at all to solve this problem and they are worth checking out if you are really serious about locking down your web site.

    Until the banking world grasps the real problems of application security, sites will continue to get hacked and defaced. Go ahead, hide behind your firewall, your SSL, your IDS, I'm going to come in, right past all of it, and rip your web application to shreds while you watch your firewall and IDS logs - and see nothing.

  • If you build them like I do... (Score:5)

    by KlomDark ( 6370 ) on Tuesday November 07, 2000 @06:23PM (#640756) Homepage Journal
    My last job (I left earlier this year, the creative design part was over and I got bored doing routine administration) was an Internet Systems Engineer for a large bank/credit card company/merchant processor.

    We built that system as impenetrable as we could. Extreme security, multi-level DMZ design, black IP, major intrusion detectors, dead-end fake IP subnets, quite a few traps and, uh, planted 'distraction', and of course 128-bit SSL. It's been running for almost two years now, and noone has come close to hacking it. The firewalls and intrusion detection software usually record several attempts per day, usually just script kiddies, once in a while a 'real' cracker. But nobody has ever got in, and if someone did, I would definitely be one of the first to know.

    We even hired some top-of-the-line, extremely good professional hackers, and they were only able to gleam the tiniest amount of information about the topology of the network.

    The only bad thing about the bank site is that the HTML coders have made one of the ugliest, lamest sites I've ever seen. They sure could have done a better job, but it's at least usuable and extremely secure.

    I use it myself, and feel safe doing so, especially as I implemented a lot of the security myself, very very carefully, as if I made an idiot mistake I would be held PERSONALLY liable. Kinda scary knowing how many billions of dollars are in that bank, and it's my ass if they get through. But I'd be very very surprised (and very respectful of the person) if anybody actually got through!

    I don't know about other banks, but this one is tight. (Sorry, I cannot disclose which bank it is without written permission from them, or I'd be happy and proud to tell you.)

    As far as the one bank someone was talking about that didn't even use SSL - you'd better find yourself a new bank - FAST!

  • Online Banking is a joke (Score:5)

    by trog ( 6564 ) on Tuesday November 07, 2000 @06:14PM (#640757)
    There are several issues that make online banks easy targets:

    1. Extreme conservitism - Oftentimes, their internal systems are quite old. While this tends to make their systems quite stable, it also means that they are generally insecure.

    2. Sensitivity to bad press - online banking systems, when compromised, are often hushed up quickly, due to the fact that the publicity will scare clients away.

    3. browser ssl - it doesn't matter if the site's key is 128-bit; if the browser functions at 40-bit, then that's the key size used for encryption. This is a problem with all ssl-based connections.

    4. user passwords - people in general are dumb about choosing passwords. They often choose easy to guess passwords. It doesn't matter what security mechinisms you have in place; if a password can be compromised, the cracker has access.

    5. poor sysadmin training - this is the plague of the industry. Most sysadmins don't know much of anything about security. The one's that do are rare.

  • The Myth of Bank Security (Score:5)

    by QuantumG ( 50515 ) <qg@biodome.org> on Tuesday November 07, 2000 @07:28PM (#640758) Homepage Journal
    I developed a credit card processing gateway in Australia. We dealt with ANZ, Commonwealth, Westpac, St. George, National (NAB) and a number of overseas banks. The security of the ATM/EFTPOS network left us flabergastered. Your average corner store receives a device called a "pin pad".. This is the thing you type your pin number into. It connects to a 2400 baud modem which runs into a standard phone line. A place like us who does thousands of transactions a day (and places like Coles and Woolworths) connect their modems to a "secure" line that is essentially a normal telephone line that goes through different switches. This is called a tran$end line (yes, the $ is intention). Either way, your modem dails out to a remote computer that is connected to the X.25 network. Software in the pin pad generates an x.25 packet with the card details (tracks on the swipe card and the pin number) encrypted with a 56 bit DES key which is set up by the bank when they issue the pin pad to you (a shared secret). The packet is passed blindly onto the x.25 network and the receiving bank does switching to people like visa for credit card purchases or they handle the packet themselves. SWIFT transactions are done the same way. When you are doing online banking, instead of plugging the pin pad directly into the modem, you plug the pin pad into one serial port on your computer and the modem into another serial port. You then run client software on your computer (NT only) which fills in the blank fields of the packet, hands it off to the pin pad to be encrypted and then passes it off to the modem to be sent. Out of curiousity we started reverse engineering the format to the pin pad messages. Essentially it's an ASCII'd version of the x.25 packet with a request byte at the start. Using a plain text attack we were able to recover the DES key from the pin pad and encrypt the packets ourself. It was only after we set up the NAB system that we learned how futile this was. The NAB system uses an NT box (they supply the box) which has no hardware encryption device. The encryption is done by the PC and the DES key is stored in a file on the hard drive. The NAB system is totally insecure. They preinstall PC anywhere on the computer and then dialup to the PC over the tran$end network. Yes, that's right, search bugtraq and you will find an outstanding bug, "PC anywhere passwords passed in the clear". Anyone monitoring your phoneline can see the password and at 2400 baud that is very easy to do. Not that it really matters anyway because they NT box we received from them had not even had any service packs installed. The reason: "we don't run any database or web servers so we don't need the upgrades which these are mainly for fixing". When we asked them where they stored the transaction logs they replied: "in an access database" on the harddrive. I was shocked to find that this included credit card numbers (all the other systems XXX out the middle digits). The commonwealth bank was the securest system I saw. Your web server SSH's to their gateway using an RSA key for authenticity. But perhaps the scariest part of all this is that the entire Australian banking system is outsourced to third parties. This results in the bank having absolutely no idea what they have to do to set up a new client and the rebound of calls from third parties to the banks and back. The bank will give you account numbers which you type into the software and it won't work. So you'll call the vendor and they say "oh.. you just have to add a zero" that doesn't work, so you call back and they say "ahh.. actually you need to convert it to hex and add as many zero's to the end to make it 16 digits then convert it back to decimal" you do that and it doesn't fit in the field anymore and after some head scratching they say "drop the last digit on the decimal representation" and you do and it works. This is scary. Many times we rang up the banks and said we had to change contact details and get new pin pads for our clients and the first few times they demanded that we get written authorization from the client. We quickly learnt that when we call the banks we should claim to be from the client company and they never asked for authorization. Social engineering at its finest. It is strange. You get the feeling talking to banks in Australia that you are talking to public servants - even though all the banks are publically owned. You could tell them anything. Ask anyone who has worked in credit card processing and you will hear stories. We once charged a million dollars to the bosses credit card then charged back 1.2 million then rang up the bank and asked them to reverse it. And this is all done by entering fields into a web page that has ASP as the backend and is protected with code like 'if Request.Form("password") = "sekret55" then'.. We built a pretty secure system in the end but we didn't have much to work with and frankly I still don't trust credit card processing, especially people like Amazon who keep your credit card details in a database. (which BTW is illegal in Australia.. try telling your clients that).

Slashdot Top Deals

It is easier to write an incorrect program than understand a correct one.

Close