Quite a few sites ask you for a “memorable question” allowing you to select one of say five. These are usually questions like “What is your favourite colour?”, “What was your favourite subject at school?” or “What was your first school’s name?”. They rarely offer an option of “I don’t believe in silly security questions.”

Unless I happen to have a sophisticated taste in colours, it’s probably not too difficult to find the answer to the above question with a few guesses (probably even fewer if you profile me a bit). Even with the slightly more personal ones, this information is often in the public domain, particularly with the trend in social networking. These types of decisions by website developers make it pointless for me to use a ’strong’ password since it is too easy to bypass.

There has recently been quite a bit of discussion about a distributed single sign-on solution called OpenID which is being supported by AOL, Google, Microsoft, Verisign and Yahoo among others. This might help to solve problems like this by having a central system which requires multi-stakeholder input to iron out security weaknesses in the first place.

PAC is an access control system which operates on (among other technologies) proximity card/tokens as identifiers for access. Almost everyone will be aware of these as they are used in most offices nowadays and are similar in use to the Oyster card. Most PAC readers are simple black boxes you present your tag to, and after checking with their controller, they grant or deny access and unlocking the door as appropriate.

The company also supplies a “PAC + PIN Reader”, a special type of device which also requests that you type in a four-digit PIN code after presenting your token to the reader. This is another level on the security ladder, the tag being “something you have” and the PIN being “something you know”. There are however two major problems with this system:

1. Each PAC token (a card or key fob in this case) has a token code which identifies it to the reader (e.g. 20184201AD). There is then a formula which uses this code (dropping the first ‘20′ bits) to generate a PIN (a hash of the token code). This means that anyone who knows your token code (i.e. anyone who has run your token past a reader, and the standard read distance of a few centimetres can I’m sure be extended with enough thought; or anyone who has access to a system on which you are registered if you happen to use multiple systems) can work out your PIN code just by using the PAC EasiNet software. This means that the PIN code is no longer ’something you know’.. it’s just a code written on the PAC token but “in ink only visible under ultraviolet light” in comparative terms. Anyone who knows this just brings a UV light and they have your PIN (i.e. using PAC EasiNet Software)
2. The communication between the PAC PIN reader and the controller appears to only send information when the PAC has been presented and the PIN has been typed correctly. If you type the PIN incorrectly, it is the keypad itself which blacklists you after three attempts but only from that keypad. This means there is no security logging of failed PIN attempts (not that this should happen in any organised attempt to subvert the system due to the first problem). I have not studied the communication in detail so it is possible this is just not visible in the software I was using, but it does seem to be handled by the reader itself.

I think PAC may be offering user-set PIN codes in newer systems. PAC do have a fingerprint reader (“something you are” on the security ladder, also known as biometrics) and a non-biometric Mifare-based smart card system which is a more secure form of RFID proximity access. Nonetheless ever releasing a system which is based on such flawed security basics is worrying.

A couple of months ago, PayPal introduced security tokens in the form of RSA SecurID key fobs, quite an interesting move I expected one of the high street banks to be implementing first. I was however pleased to now see Barclays introducing a pin pad device which will generate a similar code, although this one in conjunction with a chip-and-pin card. This has the potential of being very useful if it can be shared across all cards, although personally I would much prefer a key fob, although as I have stated before, this does suffer from the problem of carrying around many of them, but to be honest I wouldn’t be carrying around a pocket calculator either.

It would be great if banks allowed customers to define their own security levels within a certain framework. For example, I would be quite happy with slightly less security for smaller transactions, and those to payees who I have paid before, and require specific chin-and-pin + pin pad authenticated transaction when making a payment which is quite large or to a new payee. However, banks usually only do something new when they are forced, rather than to try and improve their service, so I guess I’ll be waiting for several years more for this and some XML interfaces.

How they work?

These Verisign tokens are devices that generate one-time passwords every 30 seconds using a cryptographic key known only to the token and the server. PayPal will be selling these for $5 (USD) which is frankly a ridiculously cheap price for these tokens. The suggestion on BBC’s site that PayPal should be providing them for free is interesting, but I would pay a lot more if I managed to persuade my banks to provide these. Separating the authentication from a computer by requiring the user to type the tokencode into the system will vastly improve security, although this doesn’t solve the problem outright.

The article does acknowledge a problem with man-in-the-middle attacks which are still possible as long as the malicious party is ready to use the tokencode immediately it becomes available to them. This means that someone engaged in phishing would need to run a site which persuaded you to give then the tokencode, which they then used to login into PayPal straight away. This does decrease the window of opportunity significantly however. One-time passwords in general have always suffered from race conditions, which this is not too different from.

The keyring problem..

These tokens have already been used in the corporate market for many years with RSA SecurID being one of the leaders. Similarly banks have used them for specific applications like corporate banking, stock brokerage, etc. When they wake up and realise the benefits of cutting fraud and introduce them for all customers, we are all going to have fun carrying around one of these tokens for each of our bank accounts, workplace login systems, etc. They may be getting smaller but they aren’t that small.

Sooner or later, some kind of hybrid solution needs to be found. Sharing the token ’secret key’ (the encryption key located on the token and the server) is clearly not an option, unless it’s a full private-public key infrastructure, although with codes as short as six (or in RSA SecurID special applications I believe they can be up to eight) digits long, I’m not sure how feasible that would be whilst maintaining security seeing as you don’t want your employer having the keys to your bank account, etc.

Another option is a trusted third party verification system, something that is already being tried on the Internet in general for unified logins. However, it then comes down to the question do you trust the third party. Is it wise to put all eggs in one basket?

What I suspect will happen, certainly for devices which show digits on the front, is that hybrid devices will come in which can securely store multiple secret keys which in turn work for different functionality. In the long run, it’s also quite possible that smart cards will take over in which case fully PKI infrastructure will manage the problem with a single key. The reason why these ‘tokencode’ devices are so useful is because they require no hardware interface to a PC (although some have USB interfaces) which mean they can be rolled out at minimal cost. To an extent this already happens with RSA having soft tokens for PDAs and mobile phones.

Open standards & low quantities

The one change I would like to see this industry make is for the standards to become open and for individual keys to be sold without the need to buy a huge infrastructure to go with it as this would encourage even smaller companies to adopt these which are currently priced for the corporate market. RSA has launched an SecurID appliance but the cost per user is still very large and the licensing overly complex–Charge £10-20 per token and £10 per order to deliver the keys and allow open development of the server applications. Of course, I doubt RSA will go that way as they would fear their corporate business, but sooner or later this cash cow will mature into a competitive industry. It is worth adding there are more open platforms than others, some of which are linked below.

I have also just seen the Initiative for Open Authentication which is trying to unify authentication architectures and looks promising.

Links

Verisign
RSA SecurID
Aladdin eToken
ActivIdentity

Innovation

Many small businesses process tranasactions manually or in some cases with limited support from accounting packages to ‘import’ data from online banking interfaces. Although banks are nowadays offering text messages you can request for different transaction types, I have yet to find a bank that has designed an open XML interface for customers to integrate into their own systems. This probably due to the fear of security breaches within customer systems. They should also allow customers to pre-define notifications of particular events to be sent by encrypted e-mail. We shouldn’t have to login to a bank’s website to communicate with them, especially on matters which are not sensitive or confidential. Credit Card payment processors such as Worldpay have been based on providing the ability to integrate into existing business systems from the beginning to process transactions. Having a quick and easy way for a company to request recent transaction information from the bank could dramatically reduce the administrative burden of bookkeeping for smaller businesses.

Recurring Payments

There are three key methods of making recurring payments automatically: Credit Card Continuous Authority, Standing Order and Direct Debit. Continuous Authority on Credit Cards seems to be a significant problem as it’s not always easy to cancel this other than by getting a new card issued with a new number, a major inconvenience to anyone who has provided companies with their credit card details to hold on file for this purpose as each one needs to be notified of the new details.

Standing Orders give you full control over the process as the amount is fixed, but this is also the problem as is makes it unsuitable as a method of paying any bills which vary in amount. Direct Debits cover this by allowing the supplier to vary the amount once an authority has been established, whilst giving consumers the protection of getting a transaction reversed immediately without question by their bank. This is an important safeguard.

The problem with Direct Debits is that whilst my bank may well refund me immediately if I report a problem, by the time I realise such an error has taken place, other transactions could possibly have bounced for lack of funds. It is clearly documented that billing mistakes happen and no matter how much reserve you can keep in an account, this problem remains.

The solution? Direct Debit Transaction Pre-Notification. Anyone who has worked in larger commercial buildings will be aware of fire alarm systems with the notion of a ‘pre-alarm’ which allows on-site staff to investigate any fire alarm incidents within a specified time period of a minute or two and if it is found to be a false alarm, it is possible to cancel the call prior to the fire brigade being requested to attend. The same system would work well with Direct Debits allowing users for example two working days to issue a ’stop’ on a requested payment. Some credit card companies are starting to implement something similar to this by calling or sending a text message when a card is being used under certain conditions.
An even simpler solution that would be easy to implement would be the concept of setting variables within Direct Debit mandates limiting the amounts that can be debited from an account. If your average monthly mobile bill is £40, then setting the mobile phone company’s authority to a maximum of £120 would significantly reduce the risk of any over-debiting to have negative effects on other payments. The exact figures of course will depend on everyone’s individual circumstances. Companies would need to bear these limits in mind when considering credit limits, etc. but as long as they are known by all the parties, it would be a significant improvement to the current system. If such schemes also enabled more smaller companies to use Direct Debits, I would be inclined to switch to using Direct Debits.

Invoice Payment Standard

Many companies now send invoices out electronically, and there are are various payment methods offered. It would be very useful to be able to have a standard template which is used to describe a transaction and the payment required such that those involved in paying many invoices (in businesses) can simply click “pay bill” and the bank is sent the instructions provided in the electronic document. There are electronic billing standards already, used more widely within specific professions but these are not in widescale and general use.

Authentication & Security

I am sometimes astounded by the lack of security options offered by banks for online banking customers. The practise of phishing is so prevalent and the security awareness of the average user to social engineering techniques is very weak.

The first issue is the use of passwords for authentication. This is a major security loophole. Corporate customers of banks and some share dealing systems use one-time password tokens such as SecurID for security, whilst other banks are using smartcard authentication, although this has been targetted at medium/large businesses only thus far. Barclays have announced recently they will be rolling this out to all customers which is welcome. One-time passwords do not in themselves stop fraud, although they make detection slightly easier as the window for fraud is reduced. We shall have to see if the widescale implementation of smart-card authentication is an improvement in security for users or a digital signature banks will rely on to refuse to take responsibility for fraud. Implementation is key here.

The banking industry has far to progress to catch up on the flow of information that is resulting in new ways of working.