LMAX Exchange
In the last week, a high profile bug known as “Heartbleed” was revealed in the OpenSSL software widely used to encrypt secure web sessions. A fix for it was available pretty quickly, but the main cause for concern was the risk that the secret keys that underpin the SSL certificate system may have been stolen from affected sites. Rather than try and explain what heartbleed was/is I’ll point you at the clearest explanation I’ve come across here.
The LMAX Exchange trading platform was not affected by the Heartbleed bug, but along with other recent high profile attacks and vulnerabilities (for example the Apple SSL bug) it’s been a good time to take a look at LMAX Exchange’s security standards, and some ways we are continuously improving security behind the scenes.
Heartbleed was a good test of our ability to respond. Within hours of the announcement hitting the wires we were auditing our entire range of SSL-encrypted external systems. Although none of our exchange and trading systems were affected we did uncover an issue with an internal corporate mail system, which required a slightly home made patch, as we were not prepared to wait for the vendor to provide one.
So, a quick recap of recent security related changes to the platform.
EV Certificates
Firstly, we have now deployed “EV” — extended validation — certificates across all customer facing web systems. EV certificates mean that the Certificate Authority which issued them (DigiCert, in our case) has contacted LMAX Exchange and verified that we exist and that our request is genuine. You can check whether a site uses EV certificates by clicking to the left of the address bar. The thought behind this is that although SSL encrypts network traffic to protect it from interception, this isn’t much help if your encrypted data is actually going straight to an attacker who’s set up a fake site using a cheap unchecked SSL certificate.
So, look for the green padlock with LMAX Limited [GB] in the Chrome or Firefox URL bar on trade.lmaxtrader.com, testapi or the application pages.
Secure Cookies
We commission regular security and penetration tests from third parties, with the realisation that there may be things that we may occasionally overlook something unintentionally. Bugs creep in and occasionally an otherwise innocent change may have unintended changes. Regular security testing from an external company is a good backstop for this.
The most recent report highlighted one such small omission. A couple of weekends ago we made a change to force the “secure” flag on cookies. Cookies are the things that your browser presents to the LMAX Exchange webservers to prove you have logged in. They work rather like a rail season ticket; rather than having to pay for a new ticket for every journey you make, you can buy one ticket that covers 3, 6 or 12 months travel in advance. In the same way, session cookies are presented to the LMAX Exchange servers by a web browser or trading software at each request, authenticating the request without the need to type your password for every page view or market order.
These cookie files are very valuable to an attacker who could get hold of them, for instance by intercepting them from the network whilst in transit. This threat is mitigated by only sending them over encrypted SSL connections.
It’s possible that the browser could be tricked into sending the cookie over an unencrypted, plaintext HTTP connection. An adversary who could then intercept them could steal your trading session and do anything that you can do. To prevent this happening, we are now setting a “secure” flag on all cookies. This tells the client software — the browser or trading software — that the cookie must never be sent over unencrypted HTTP, only via SSL.
Looking Forward
We’re always looking for ways to improve the security we offer our customers. As we’re an agile, customer driven organisation, here’s your chance to let us know what you’d like to see next.
Three possibilities we’re looking at are “perfect forward secrecy”, two-factor authentication and a password portal. Each one is described below.
There are costs and benefits associated with all three, and we’d welcome your comments and feedback on where you’d like us to strike the balance between security, convenience and cost. If you’re strongly in favour or against here’s your chance to speak out.
Perfect Forward Secrecy
PFS is a form of SSL encryption that restricts the codes (or “ciphers”) available to secure communications with LMAX Exchange to one of a small number that have a property of particular interest.
This has been in the news recently with Twitter and Facebook both enabling PFS by default. A quick search for Twitter and PFS will give you a link to their blog post that describes their motivations for enabling this. In that post they describe the “new normal” of everything SSL wrapped and continuous improvement in security. We very much subscribe to that view. We’ve been pure HTTPS/SSL since day one, for example.
So how does PFS work? Imagine a scenario where an attacker is somehow able to intercept and read the encrypted session data from the network. Without access to the secret keys used to set up the encrypted channel at the start of a session, they would be unable to break the encryption. However, they may decide to record the encrypted data, and hope that one day they will be able to get hold of the keys used by the server and client to set up the SSL encryption session. (As it happens, the Heartbleed vulnerability described above could in principle be used to steal these secret keys, although it seems to be very difficult to accomplish). With most types of SSL encryption, when the attacker gets access to the keys they would then be able to decrypt all the stored data they’ve accumulated so far.
Perfect Forward Secrecy refers to a few specific ciphers that use a different technique to establish the encrypted session. With PFS, the keys are regenerated randomly for every new session. The practical effect of this is that an attacker with a stash of encrypted data would never be able to decipher it, because the key is not the same from session to session.
Implementing PFS would be a relatively simple change for us to make. The drawback is that some clients may not support the PFS cipher suites (although all modern web browsers do so). It might also take fractionally longer to set up the initial encrypted session — but remember that this only happens once, when you first login to LMAX Exchange. Subsequent requests and response see no increase in latency.
Two-factor Authentication
Most sites use a single “factor” to authenticate logins — a password. There are many drawbacks and pitfalls to passwords — they are easily forgotten, they can be shared, there is a temptation to
write them down with the consequent risk that they might be found by someone malicious, they need to be changed regularly, and unless software is configured to force users to pick very long, complicated strings of numbers and letters, they can be easily guessed by simple techniques.
Many organisations are adding a second authentication factor to the password, eliminating these risks. This may take the form of a code or PIN that can be sent to the user over a separate channel — often, an SMS text message. Nowadays many popular sites use this system, including Google, Facebook, GitHub, and Paypal. Other systems (favoured by some retail banks in the UK) include physical bits of hardware that generate an apparently random numerical code which changes every few minutes. Other examples are smart cards, or even biometric systems like fingerprint scanners.
Whilst these systems greatly reduce the risks of relying on a password, they have drawbacks of their own. They can be expensive and time consuming to install and operate, and they add some complexity to the customer side. (For instance, what happens if you change your phone, or lose the dongle or smart card?). None the less this is rapidly becoming part of the “new normal” for internet security, and we’re making early plans to roll this out.
Better Handling for Password Resets
If you want to reset a lost/forgotten password for your LMAX Exchange account today, you have to call our Customer Services Team who will generate a new temporary password which is then emailed to you. We have a couple of safeguards in place that mean that if someone compromises your email account they don’t get all the information on a plate to log in to your trading account.
While this works it is relatively slow and inconvenient, both for you, the customer, and for us, plus it relies on your email account for the temporary password. A chilling if interesting article on how you can get hacked via social engineering and password reset mechanisms was posted here.
We’d like to improve on that. A better solution perhaps could be to provide a password change web portal. We’d have a set of security questions and checks – for example is the connection being made from a different country or IP address from the one you normally log in from? Is this your 3rd incorrect attempt to answer the security question? If you pass those then you’d get sent to the password change page of the LMAX Exchange website.
This could be more secure as well as convenient. It would be 24×7 rather than only available during our office hours as at present. The scope for social engineering would be reduced, and more importantly would not rely on the security of your external email account.
If you have strong opinions on any of the topics in this post, please let us know directly via [email protected]. If there’s something you think we should be doing that’s not mentioned here – please let us know.