News & Commentary

10:34 PM
Hilding Arrehed, <A HREF=ActivIdentity " />
Hilding Arrehed, ActivIdentity
Commentary
50%
50%

Busting Online Banking Myths

Two common misconceptions about online banking security may be holding financial institutions back from offering their customers the best services possible.

I've had the opportunity to work with a number of financial institutions around the world, helping them design and implement security solutions for their online banking systems. Along the way, I've identified two highly prevalent myths surrounding online banking security. Here, I'll explain the flawed thinking behind these myths and offer some simple solutions to their associated challenges.


Myth 1: Strong online security practices are inconvenient and create bad customer experiences.

Banks with the strongest online security are able to offer their customers more and better services than their less secure competitors, which often trump any convenience factors. For example, a bank that launched its online banking service back in 1996 began immediately enforcing strong, two-factor one-time password (OTP) token-based authentication at every login. The bank quickly reached 2.5 million online users despite the fact that access to the site required login via a challenge/response scenario. Customers recognized that this system enabled them to confidently and securely conduct all their financial business online, including executing international money transfers, making stock trades and completing mortgage applications.

Fast-forward to 2011. With all of today's advanced security technologies, you might ask how financial institutions can build online banking systems that offer functionality and sufficient security and also maintain the highest level of convenience. My suggestion is to let your customers customize their security options in the following ways:

  • At the time of log in, allow customers to choose which authentication method to use based on how they intend to use the service. For example, a password should be enough to view account status and transfer money between a customer's own accounts.
  • Empower customers to configure their own "convenience vs. security" levels. When logged in with a strong authentication method, such as OTP token or SMS text, it should be possible to reset the password mentioned above, or disable/enable that access level altogether.
  • Let customers choose to connect from their preferred device. Be quick to release mobile and tablet apps, since using the built-in Web browser in small devices is typically not an option. Embed security into your apps, but keep your security model and supported authentication devices consistent so it's clear to the user that regardless of the device or app, the same service is being accessed with the same level of security.
  • Some customers will want to get security credentials (OTP tokens, etc.) directly in a branch office, while others will want everything to be managed via phone. Tech savvy customers might want to use their mobile phones as OTP tokens. Let them choose, and don't be afraid to charge a small premium.
  • Let customers use the same security credential they use for online banking when they access other bank services such as telephone banking and customer service.
  • Do not underestimate the power of great customer support -- in multiple forms. Some customers may want to research issues and find solutions on your website, while others prefer to communicate via email or phone. Make sure to provide all of these options, and do it well.

  • Myth 2: The strongest security measures should protect initial access to all services.

    Levels of security should increase based on transactional sensitivity. For example, logging into your online account could be simply protected by password authentication, but access to money transfers should require more stringent validation and verification. Consider the following best practices for secure, risk-appropriate and cost-efficient electronic transaction signing:

  • Make it as easy as possible. Only ask for transaction signing when money is transferred to outside accounts, and allow transactions to be batched, including payments, transfers and other tasks that require signing. This prevents customers from having to go through the same electronic signing process multiple times.
  • Use a secure but risk-appropriate technology to carry out the transaction signing. Smart cards, tokens, soft tokens and SMS text messages are all good ways to provide electronic transaction signing. However, customers should only be required to have one strong security credential to log in and conduct online business with your bank -- they can choose to have multiple credentials, but this shouldn't be a requirement.
  • Make sure it's clear to the user what is being electronically signed. This is to prevent the risk of man-in-the-middle attacks. Clarity is particularly important now given recent attacks on trusted Certificate Authority providers and hacks of the session security protocol mechanisms (SSL/TLS) used by Web browsers. If transferring $500 from account 12345678 to 87654321 on December 3, for example, select a subset of this transaction data to be encrypted (electronically signed) by the customer by using a strong security credential. In the case of an OTP token, this could mean that the number 5008321312 (where 500 is the amount, 8 is the last number of the source account, 321 is the last three numbers of the destination account and 312 is the date for the transaction) was typed into the token for encryption (electronic signing). The token would then return an encrypted version of the number that, once typed into the internet bank site, can be verified by the bank's back end, the only other entity with access to the encryption key used by the token. Given a strong user awareness campaign and a user-friendly interface, this allows the user to understand what it is they are approving.
  • Store the transaction data, including the customer's electronic signature, in a secure, tamper-evident audit database for archiving purposes. It can be very useful in proving that a money transfer was correctly carried out and approved many years after it happened.

  • Every bank obviously has its own advantages, challenges and security needs. Your security solution, including authentication and money transfer approval mechanisms, needs to be specifically defined to meet those unique needs.


    Hilding Arrehed is the director of worldwide professional services at ActivIdentity , part of HID Global.

    Comment  | 
    Print  | 
    More Insights
    Comments
    Newest First  |  Oldest First  |  Threaded View
    Register for Dark Reading Newsletters
    White Papers
    Video
    Cartoon Contest
    Current Issue
    Security Operations and IT Operations: Finding the Path to Collaboration
    A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
    Flash Poll
    New Best Practices for Secure App Development
    New Best Practices for Secure App Development
    The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
    Slideshows
    Twitter Feed
    Dark Reading - Bug Report
    Bug Report
    Enterprise Vulnerabilities
    From DHS/US-CERT's National Vulnerability Database
    CVE-2017-0290
    Published: 2017-05-09
    NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

    CVE-2016-10369
    Published: 2017-05-08
    unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

    CVE-2016-8202
    Published: 2017-05-08
    A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

    CVE-2016-8209
    Published: 2017-05-08
    Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

    CVE-2017-0890
    Published: 2017-05-08
    Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.

    Dark Reading Radio
    Archived Dark Reading Radio
    In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.