What went wrong at Tesco Bank? Tesco Bank has enlisted the help of the National Cyber Security Centre (NCSC) following the most serious cyber-attack launched against a UK bank. The attack against the supermarket giant's banking arm involved the theft of £2.5m from 9,000 customers' accounts, funds that the bank quickly reimbursed. Initially theft against 20, …
You (nor me) don't know what is running on the co-lo kit and how it's secured to make an informed statement whether this is smart or not. there is plenty of insensitive data and applications in a bank that are perfectly suited for co-lo/cloud.
""Shared" (even locked cage) is co-lo."
Yes, that's technically true, but it does mean random passers by cannot just get physical access to the kit, it also means no-one else is using that kit either.
How many banks are you aware of that actually *own* their own data centers? I'll give you a clue - none.
Why don't you look up who the customers are at the L3 DC on Leman street.
Cloud banking 'entry points' depends.
Some of the clouds (I believe IBM's can be configured so) are essentially private fibre connections between bank HQ and dedicated servers for the really top secret data. So can really be thought of as an 'external branch network'.
Although I believe there are a range of players and options available in this field.
If the data can be anonymised and crunched offline, then returned and the data de-anonymised, cloud computing can work very well.
"If the data can be anonymised and crunched offline, then returned and the data de-anonymised, cloud computing can work very well."
One of the reasons the cloud has got where it is today is that it offers many of the long-forgotten benefits of 1960s-style timesharing - e.g. timesharing/cloud customers don't own (or control) their own resources, resources are shared with other customers and the person paying the bill has to either accept that or pay extra. Sometimes lots extra.
The approach you suggest loses the flexibility of uncontrolled sharing, and the price will doubtless reflect that. It may still make commercial sense in some circumstances.
Still, cloud == hip/trendy, What could possibly
Santander online banking has a password and a PIN that you need to enter selected character/digits from - so they can't be hashing passwords either. At least they don't use email as the account identifier though.
My first direct account uses an app based 'code generator' - which doesn't seem to be TOTP/OATH. I wonder if its an established and reviewed method, or if they rolled their own solution?
I use Santander online and mobile app. Both request 8 digit customer ID (which you can persist for convenience) and full PIN, not selected characters from it. The mobile app won't allow you to set up new payments either and the online version sends a code via SMS you need to enter to create a new payment.
Not saying any of this is vastly secure but it sounds like Tesco have really let the security aspect slip, probably because it's difficult and a bit more expensive to deploy properly.
My Santander online access is a userid (can be customised) and password, which then presents you with a screen giving you a piece of information you have previously supplied to them so you can be more sure they're not a fraud site (unless it's doing some passthrough stuff) and then asks for a full 5 digit pin number.
I presume (faint hope) the banks that ask for individual character combinations from passwords / keywords have a slightly restricted list of combinations which are hashed? If my password is 10 characters long, then there are 120 different ways to choose 3 characters - it doesn't seem unrealistic to think they might have that many hashes stored for me...
Clinging to hope here!
Why not just hash each character...
But more seriously, I assume the "first third and fifth" version of pin checking if for *view* only options to statements and already assured bills and payments. When ever I need to add a new bill or account to pay into, or set a new DD, I need a new pin pad check (which is hashed etc AFAIK).
@ Greg 24: Both request 8 digit customer ID...
In one sense that must be "common knowledge" but you have just informed those who didn't know how long the customer ID is. In a small way you have just weakened your own security along with that of countless others.
I wouldn't tell anyone how many characters I use for any User ID and (more particularly) my passwords. Make hackers find that information out the hard way.
"I use Santander online and mobile app. Both request 8 digit customer ID (which you can persist for convenience) and full PIN, not selected characters from it. "
No they don't. I don't know about the mobile app, but to log in to Santander from a real computer requires the customer ID, 3 characters from your password (which actually allows strong passwords without stupid restrictive rules), and 3 digits from your 5 digit numeric PIN.
As for the main topic, this is actually an interesting problem that doesn't really have an easy solution. Only asking for a few random characters from a password is done for a very good reason - keyloggers can't steal your password if you never actually type the whole thing. But, as this incident apparently shows, this makes accounts more vulnerable to other types of attack. So the question is not so much whether it's a bad idea to do it like this, but whether it's worse than the alternatives.
Santander's login differs depending on which bank they took over that you used to be with. I locked myself out once due to their telephone banking system asking me for a field I don't have on my account.
The customer ID length being "unknown" would be very weak security by obscurity.
Storing hashes of each 3-character combination of your password (along with the necessary indexes of the characters) is pointless - it vastly reduces the attack space to brute force your password. Once you've got the first three characters, attacking another hash that re-uses 2 of your now-known characters is simple, and so on.
"but to log in to Santander from a real computer requires the customer ID, 3 characters from your password (which actually allows strong passwords without stupid restrictive rules), and 3 digits from your 5 digit numeric PIN."
My current account from a 'real' computer requires me to decline installing the trusteer crap (every time because I don't keep cookies), enter a numeric customer ID, and a full numeric PIN on a page which shows a personalised icon and phrase. I seem to have a password which I am never asked and setting up a payment recipient requires more authentication.
"(which actually allows strong passwords without stupid restrictive rules)" This is the single most annoying thing I find when creating a password on a site.
Why is that some sites will not allow the full use of different types of characters?
Just a shame that they're so lax on the phone. Having had them transfer several thousand pound between my accounts without any security info at all on the phone, and having had them add extra security of which the extra has never in 10 years been asked for, if you were going to do something to them, you'd just phone.
But the rest is true, they use 3 inputs from me plus a visual validation of picture and phrase I set online (edit: although it appears this isn't always the case depending on account type and vintage)
>they can't be hashing
Well, the PIN you use for your credit/debit card payment isn't hashed either - the PIN you enter at the ATM or PoS terminal is encrypted and sent to your card-issuer where a Hardware Security Module (HSM - designed for the secure, tamper-proof storage of security credentials) checks whether it matches the PIN it contains for your account. The HSM is also used in the originating of the PIN and mailing you its value. And, indeed. there would be limited benefit in hashing a small number of characters known to be numeric.
There is no reason in principle why HSMs could not do a "masked" match for a subset of a PIN (or indeed a password), though I don't know if they're used by online banking systems in that way.
I have seem some references to the Tesco problem involving overseas debit card payments, so whether it's directly related to use of the banking website remains to be seen.
The PIN is never stored on the mag stripe. You are confusing it with either the PAN (card number) or CVV.
The classic way of validating the PIN at the bank is having a HSM encrypt the PAN and then turning the first bytes of the result into digits. However, nowadays many are using a database with per-card data instead.
What is, however, occasionally stored on the mag stripe when doing it the classic way is a PIN offset to let you choose the PIN yourself - this is simply added (modulo 10 raised to the number of digits in the PIN, duh) to the encryption result to get the expected PIN. As should be pretty obvious, this value does not reveal anything about what the actual PIN is.
The number of combinations can be halved, if the pair are sorted by index (i.e. if you always ask for the second and fourth characters, and never for fourth and second).
But what's the maximum allowed length of password? You have to provision for that.
And what about Natwest, who ask for four characters?
Edit: And, as some points out below, the net protection from all these hashes is far less than decent encryption.
I've just realised how trivial cracking a password stored as hashed pairs would be:
Cracking any pair by brute force is a search for a two character password.(64*64 iterations?)
Once you have at least one letter, cracking every other pair is reduced to a brute force search for a single missing character.
And if you didn't salt each pair separately, and the password contains a duplicated character, then cracking is reduced to a brute force search for a single character.
Storing hashed pairs of characters offers NO security.
Calculating and storing the hashes is not impossible at all, but if the hashed values are leaked, it's also very easy to brute-force the original password.
For each 2-character hash, you need to try less than 10,000 possible combinations of 2 characters, and you only need to brute-force 8 hashes to retrieve your 15-character password. Ouch!
NS&I asked me to give a new password over the phone the other day. (I politely declined)
This is in spite of the fact that their own website states they would never ask for one.
I currently have a complaint open on the matter - not that they seem to care.
I will be soon removing what little money I do have with them!
@ Mr ChriZ
""NS&I asked me to give a new password over the phone the other day. (I politely declined)
This is in spite of the fact that their own website states they would never ask for one.
I currently have a complaint open on the matter - not that they seem to care.
I will be soon removing what little money I do have with them!""
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Me, I **HAVE** to stick with those gormless bastards - it's the only place to put my UK Pension each month - who wants devalued Quids in a former B.C.C.
At least I might become a Millionaire before I "Snuff it".
"NS&I asked me to give a new password over the phone the other day"
I'm always amused at the idiocy of the banks!
I keep getting emails from my bank, inluding a "click on the link" to get to their web site.
It's like they are trying to condition their customers to become easy fishing targets!
No thanks!
I will enter the web address myself!
Must depend on which bank's accounts Santander historically acquired.
Our historically Alliance & Leicester login needs a numeric user ID then a five-digit PIN in full.
My business login (based on Abbey National systems) needs a numeric user ID, then a password and PIN, both in full.
Both also use the picture verification thingy, but that's pretty much entirely placebo. The user IDs are not guessable, but nor are considered secure information.
Both are now Santander branded but show their provenance in a few places. In both instances though, the password and/or PIN could be (and hopefully are) hashed.
Santander 'upgraded' (NOT!) their security. Old Santander accounts require customer ID, full passcode and full registration number. Accounts opened in the last couple of years required customer ID and three random characters from the passcode and three random characters from the registration number.
So they must be storing them using reversible encryption. and to make it look like they beefed up security they just changed the front end. No changes have gone into the way the data is stored.
What do customers do when presented with three random character shite? They chose simpler passwords don't they? No point in trying to use a 20-character random generated one when they pull this crap on you.
I don't use the Santander mobile app so can't speak for that one.
The Tesco's one is worse. The three random characters required by Santander are in fields named in the HTML as x1, x2, x3 and the three characters random are annoyingly not in order either. The Tesco's site asks for the username (not email address), full password (good) but the three random characters of the security number are presented and named as x1, x2, x3, x4, x5, x6 with the three you don't have to enter greyed out.
My ex-Abbey National account also needs a full (alphanumeric and customisable) user ID along with a password and a PIN, so that firs your theory.
I do also have it tied to a moneydashboard account too but ISTR that was set up with a one-off security exchange to prove to Santander that I wanted Moneydashboard to have read-only access to my accounts.
"With cloud computing, hackers have so many more points of entry" - Sod off, absolute crock of s**t... People and Organisational culture make more of a difference to security than the platform it sits on. Odds are if you're a Project based org - i.e. get it in, once it's working, ignore it, you'll succumb to this type of attack, and in some cases, quite often. If you're more on the ball and there is a focus on operational performance (i.e. looking at what data is going out), paying for time/people to continually remediate, you'll stand a better chance of not having these instances.
Public Cloud, just like an on-premise/hosted solution will normally have it's biggest weakness in those configuring it not knowing how to configure it. That'll always leave ways in, even when done properly, they'll still be zero days. Building an architecture that is more tolerant of people mistakes, making it harder and harder for an attacker to exploit, or once exploited, get to anything meaningful is the way forward.
It's nice to see NSCS being involved here, that was only very recently setup, I'd seen their head speak at Microsoft Future Decoded, it actually looks like an organisation with the right tools/mentality for helping firms work to prevent this kind of thing happening.
Generally speaking I agree with the above; meatsacks, in one way or another, offer the easiest way in.
Look at that large attack on Sage recently. Although not sure how that ended up (or even if it has been announced) that smacked of an inside job with the arrest at Heathrow etc. With the Tesco bank (also based in Newcastle?) I speculated that an insider had been conned into doing something small and not realised the scale of the impact it could have. That was based on absolutely no knowledge whatsoever of banking security other than the POV of a consumer.
Then I read this article and thought what a piss weak login system for a brand new bank with no legacy code to accommodate.
I had an email from The Co-Operative Bank a few weeks ago saying they were having to do maintenance on their banking system (long overdue!), and when I went on to my online banking I noticed now they ask for a username. If you don't have your username (which I don't) they ask you to provide your sort code and account number or the long card number. You then provide two digits from your personal pin number which I set up, then answer the question to one of 4 questions.
They then emailed roughly around the time of the Tesco hack to say their maintenance was on hold. I thought it was coincidence, but now that you mention the pin number for Tesco works the same as the Co-Op, I wonder if the underlying systems are related?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
