All posts tagged "banking"

Despite assembling formidable armies of cybersecurity personnel armed with cutting-edge information security technologies, many financial institutions, healthcare facilities, and other organizations handling highly-sensitive information still utilize deficient authentication processes when interfacing with the public. While industry attention in recent years has been focused on multi-factor authentication (or the lack thereof), technological vulnerabilities, and social engineering attacks, there are several significant weaknesses in design that have not yet received adequate attention. I discuss several below with the hope that readers will take proper precautions, and that any organizations needing to implement modifications will do so; please note that all of these problems are real, and have been observed and/or tested in recent weeks: 1. Allowing people to authenticate over the phone by using ATM PIN numbers1 ATM PIN Numbers are acceptable as authentication at ATMs because the person using them to access an account must also present an ATM card – the card being something that the user physically possesses, and the PIN Number being something that the user alone knows, combining to create a basic form of multi-factor authentication. Of course, ATM PIN Numbers on their own are quite weak for authentication – typically consisting of only 4 numeric digits, and, often entered in public locations at times when others know they are being typed – but, as bank systems are typically programmed to lock accounts if a card is presented at an ATM or multiple ATMs and the wrong PIN is entered more than a few times, such security is often considered adequate; statistically speaking, the reasoning goes, someone who steals an ATM card is unlikely to be able to try enough PIN Number combinations to find a hit. (Related vulnerabilities are beyond the scope of this article.) However, the minute that people can authenticate over the phone using the same PIN Number – without presenting a physical ATM card – the level of security is dramatically reduced, as authentication relies on only a single, weak password. Locking an account after some number of incorrect attempts is also problematic in such a scenario – as such a policy would mean that anyone who knows a user’s login name and account number (which includes everyone who ever received a check from the user) can potentially lock that user out of ATMs simply by calling in multiple times and providing the wrong PIN Number. Of course, banks that allow users to authenticate with their PIN Numbers over the phone may be utilizing other forms of authentication that are invisible to the user – such as voiceprints, etc. – but, asking for a PIN Number absent the corresponding ATM card still raises questions. 2. Allowing people to enter passwords via telephone tones Obtaining account information via a standard voice-based telephone call may have been quite common in the 1990s, but, today, various systems that still provide such legacy services undermine the security of users’ accounts by allowing passwords to be entered via the touchtones corresponding with letters on the standard telephone dialing pad. Because each number from 2-9 corresponds with 3 or 4 letters, and does not distinguish between upper and lower case characters, such a login system dramatically shrinks the universe of valid passwords, and effectively allows thousands of different passwords (instead of just 1) to work for an account. If one’s password is “josephS”, for example, only “josephS” should be accepted as valid; on a touchtone based login, however, entering “LORDsir” will also grant the user access; both appear identical to the authenticator, as they are both entered as “5673747.” Never mind the fact, that, on many phones, each key emits a different tone - passwords entered via touch tones can literally be recorded by anyone within an earshot or otherwise listening in to a call. The bottom line is that allowing people to enter passwords via telephone tones can dramatically weaken the security of any information protected by those passwords. 3. Allowing multi-factor authentication to be circumvented when users login from financial institutions In order to facilitate inter-bank transfers, consolidated account reporting, and various other features that require financial institutions to communicate with one another, various systems that require multi-factor authentication when users login via the Internet do not require a second factor when another bank system logs in on behalf of a particular user. While such a policy in itself may be both acceptable and necessary in many cases, there have been situations observed in which the configuration information detailing from which systems user accounts can be accessed without a second factor is not kept up to date, or was configured overly broad to begin with; in at least one case, human users were able to circumvent a system’s second factor requirement simply by logging in from a particular network belonging to another financial institution. 4. Undermining strong authentication and other security technologies via “auto-reload” and other default-payment-source features We have already seen real-world examples in which criminals were able to steal money from people’s bank accounts by hacking into systems unrelated to those accounts, but which users had configured to automatically pay for goods and/or services using the relevant accounts. If a criminal breaches a system that is set to reload a gift card account when the balance falls below a certain amount, for example, or to utilize a certain account by default for payments, the nefarious party may be able to effectively empty out the associated bank account by performing multiple reloads and or payments, without ever being subjected to the full scope of the bank’s authentication and anti-fraud measures. 5. Providing information about passwords after unsuccessful login attempts. When someone attempting to gain access to a particular system enters an incorrect username+password combination, the system in question should not provide any information to that party other than communicating to him or her that the combination provided is not valid; yet, I have seen multiple systems, that, even in 2018, still provide the user with unnecessary details that can be exploited as part of attacks (e.g., the password is invalid (but not the username), the password contains illegal characters, etc.) 6. Providing information about prior passwords Anyone protecting any sizeable collection of sensitive information accessible to large communities of account holders via the Internet must account for the unfortunate reality that, despite the best efforts of his or her team, there will be instances in which unauthorized parties will gain access to some accounts. Yet, some bank systems, to this day, prevent users from reusing their last x number of passwords when resetting passwords, and inform the user explicitly when a new password provided on a change password form is unacceptable because it was recently used as a password. Because people tend to reuse passwords between systems, and because many organizations do not lock accounts if an authenticated user changes his or her password “too often,” employing such a strategy potentially gives criminals a way to test passwords likely to be valid on other systems without risking a repeated-failed-login lock out. Incidentally, on systems ostensibly enforcing a no-reuse-of-the-last-x-passwords policy, I have tested resetting a password x+1 times in a row with no other activity in between, and, on all of them, I was able to reset the password back to my original password – raising serious questions about the efficacy of the implementation of the policy altogether. 7. Logging unsuccessful login attempts in cleartext, and then failing to adequately protect such data While there are legitimate security reasons for storing the details of every failed login attempt, anyone doing so must consider that one common mistake that probably every computer-literate person has made at least once is entering the password to one system when logging in to another. As such, databases of failed login attempts on any heavily-used consumer-facing system almost always contain significant collections of valid username-password combinations for other systems, and, in many cases, for systems of a similar nature (e.g., the password for bank A entered when logging into bank B). Any party storing such data, therefore, must protect it; yet, I have seen more than one environment in which technical staff did not know how many copies of the relevant data existed, never mind where all such data resided or who had access to it. There are, of course, many other design issues that may be present in various login processes – but, I thought that the aforementioned seven would provide some good food for thought… 1(Yes, stylistically we write PIN Number even if the second word is, technically speaking, redundant - see Wikipedia's entry on RAS Syndrome for more details.)

All posts tagged "banking"

CyberSecurity

Warning: These 7 Common Online Banking Features Often Weaken Security

POSTS BY CATEGORY

JOIN MY NEWSLETTER