Online Bank Security - BROKEN !?!?!

6_6_6

fiesta04 wrote: »

Completely lost on all this, hope my £72/11/6d will be safe!!


F4

Sorry, its the nature of the beast. I know it sounds like waffle to the less intelligent jo, but its the fundamentals of website security and in essence, most banks are not bothered, due to a mix of antiquated IT practices, ignorance and dead wood management. Just be aware that when assessing your next bank, perhaps you should check how secure they are after checking the APR.

Online security is important as we begin to see computing power exponentially increase at a time when cyber terrorism is beginning to become more significant than boots on the ground in global warfare.
Some might laugh it off comfortable with the misapprehension that if it all goes wrong, the bank are insured. Better to get yourself with a bank who stands a better than average chance of avoiding online compromises in the first place. I'd say it's not a question of if, but when. And better HTTPS connections only serve to distance you further from that risk. Now, over to the minority to harp on about my use of the word waffle {sighs} .

Zanderman

6_6_6 wrote: »

I know it sounds like waffle

It certainly comes across as waffle.

You may, or may not, have a point - I'm not in a position to judge, but perhaps you're trying too hard with your long posts on technical issues of security. I have not, and won't be, reading them all and I doubt many others will either.

This part of the forum isn't about technical issues, and your rather long posts aren't very readable - and so simply won't be read by most.

On technical issues I was always taught to write it so it is easily readable and likely to be read. Otherwise you don't achieve your objective - you just think you have.

Perhaps another part of the forum (the Technical thread or maybe the Rants thread?) with a short, concise link to that from here would be better?

cookie365

Zanderman wrote: »

It certainly comes across as waffle.

You may, or may not, have a point - I'm not in a position to judge, but perhaps you're trying too hard with your long posts on technical issues of security. I have not, and won't be, reading them all and I doubt many others will either.

This part of the forum isn't about technical issues, and your rather long posts aren't very readable - and so simply won't be read by most.

On technical issues I was always taught to write it so it is easily readable and likely to be read. Otherwise you don't achieve your objective - you just think you have.

Perhaps another part of the forum (the Technical thread or maybe the Rants thread?) with a short, concise link to that from here would be better?

This.

6 6 6 - this isn't meant to be negative, but constructive feedback.

You may have the technical skills, but you don't appear to have the communication skills.

Or any access to the people who matter at the banks. No customer services rep can do anything with this information, even if they understood it.

Find someone who already is trusted by the banks security teams, who has the communication skills to put complex technical detail like this into a format that both security specialists and bank execs will understand and engage with, and get that person to do your advocacy.

6_6_6

Its funny, there will always be the shills that try to argue the toss against blatant and obvious facts. I wonder how much clearer this issue can be 'explained' . I would not be surprised if they are associated in some way to the banks I'm criticizing, dead set on undermining the thread with pedantry.

I have noted this information had been forwarded to the relevant teams in several banks. Yet still we see a lack of due diligence on the part of some, perhaps we can discuss that ?

They are supposed to be banking institutions with teams that 'specialise' in this stuff, perhaps your jumping the gun a little bit.

First Direct had one of their technical people contact me by phone and we discussed the issue. I was left with the impression something was going to be done. Yet the letter I received completely side stepped everything that was discussed in an almost aѕѕ covering exercise. Within it, there were shockingly flawed considerations around the basic way their own website works with the token generator, let alone the HTTPS security.

Archi_Bald

6_6_6 wrote: »

am I the only 'techie' using MSE, I bloody hope not or where all doomed !

As has been suggested before, there is a techie board on which your campaign might receive a warmer reception than it does here.

So please do take it there.

Lokolo

6_6_6 wrote: »

It would be good if we could instead have several takes on the issue rather than the odd person say they don't get it and stamp up and down. Is there anyone else who can help out here, am I the only 'techie' using MSE, I bloody hope not or where all doomed !

No you are not. I am a techy by day. But during my MSE vists to the Budgeting and Bank accounts section I don't expect to see threads about website security.

It's as ridiculous as going to a customer service agent for FirstDirect about the issue... which you seem to have done.

cookie365

6_6_6 wrote: »

I wonder how much clearer this issue can be 'explained' without resorting to such far reaching abstractions it no longer reflects the issue at hand.

Well, you're clearly going to have to figure out the answer, or find somebody with the skills to do so!

MPH80

The short version for everyone:

Banks aren't supporting the latest methods of communication between your browsers and the website.

There are various issues that have been found with all older versions of communication which make the communication insecure in different ways. Suffice to say that it still takes significant effort on the part of someone wanting to hack into the communication but there is weakness there.

It's the equivalent of having an old style key lock on your front door - it's vulnerable to bumping and various other techniques to get through it. Sure - it's secure to someone just trying the handle - but a determined person can get past it.

The OP cannot get hold of anyone at the banks who would listen so is warning you all.

However, there is nothing that we, at our end, can do to protect ourselves from these issues as they have to be fixed at the server end.

We can - however - request the change to be made.

6_6_6

Archi_Bald wrote: »

As has been suggested before, there is a techie board on which your campaign might receive a warmer reception than it does here.

So please do take it there.

I have put a link to this thread on that board. I assume its up to the moderators to merge this over there or see some value in exposing this in situ and leaving the link from the Techie bored in play. I'm not precious either way, my key take away needs to be some technical review coupled to some banking process review and suggestions around why they might not be taking the security element as seriously as they should. Meanwhile people get to know about the debacle and get to put some consideration to this element of poor banking and put security on the radar.

securityguy

6_6_6 wrote: »

How is poor website security not a convincing case ? Are you conceding that all companies operate within the best interests of their customers, always listening, always understanding ?

The Poodle SSLv3 attack allows, under some fairly rigorous circumstances, the theft of authentication cookies.

It doesn't affect the most modern browsers (because they largely refuse to downgrade to SSL 3.0) but it also requires a strong attacker, who is not only able to intercept traffic (say, a rogue wireless access point) but is also able to convince a user to visit a malicious website while simultaneously being logged in to their bank. An attacker who manages this --- and reports of POODLE in the wild are rare --- will be able to do what, exactly? They won't have access to passwords, either one-time or standard, because POODLE doesn't give them this: all they'll be able to do is to pretend to be you, logged in to your bank, for however long it is that the cookie is valid.

They won't be able to shift any money outside your own accounts, assuming that your bank is even vaguely competent, because not only will they not be able to perform the two-factor authentication that is almost universal for setting up new payments, they won't even be able to present the password that is required to make payments to existing recipients. Some banks permit movement between accounts in your name without a password: they could do this (so they could transfer money between your current and deposit accounts: so what?)

So an attacker who can (a) cause you to send on average 256 https requests per byte of the authentication cookie and (b) intercept the traffic so generated will be able to get what amounts to read-only access to your banking. This is much, much more serious for non-banking sites because if the authentication cookie controls more significant access without additional layers, bad stuff can happen (although again, it's a strong attacker, and again, there's no reports of real world exploits). But for banks? Meh.

If you're worried, your solution is easy: just use a post-Dec2014 web browser. The banks are making a commercial decision; cutting off IE6 isn't practical because large numbers of corporate desktops run it, and in exchange for not !!!!ing off lots of people who do their banking in the lunch break, they take on a risk which is very small.

There is very, very little evidence that attackers are getting money from banks using subtle cryptographic attacks on protocol weaknesses. The banks won't tell us, but there aren't accounts appearing in newspapers which plausibly make the claim either. The two factor on setting up new payments pretty much stops it being monetised, and making attacks that require substantial resources for the sole pleasure of reading other people's bank statements doesn't make much economic sense (criminals, as opposed to security researchers, are nothing if not economically rational).

"there is nothing that we, at our end, can do to protect ourselves" is simply not true. Chrome 40 et seq don't support SSL3. There you go: worried? There's your solution.

There is a variant of the POODLE attack possible on TLS1.0, which is much harder to mitigate as a client. However, it's also much easier to fix and much rarer: it impacts sites which use F5 load balancers, and no-one is doing that who isn't serious. F5 issued a fix, and (the word is) it's largely been applied.