Online Bank Security - BROKEN !?!?!

6_6_6

securityguy wrote: »

I'll try again, before I give up.

There are no, repeat no, recorded incidences of an attacker using either brute force or brute force assisted by theoretical weaknesses to attack banking ciphers. None.

To say 'banking ciphers', might give the impression that ciphers in some way belong to the banks, to clarify for the reader, they are just ciphers and the banks only use them, anyone can use them.

securityguy wrote: »

When people talk about DES being crackable in a day, they're referring to the use of a lot of specialised hardware, which is expensive, bulky and hot. Even once you have broken the session key, you have exactly one banking session: you have an expired authentication cookie, the username and password and one run of whatever secondary authentication they are using. This is not a winning scheme for making money.

So are we to believe cipher ordering and deprecation guidance is nonsense, all those experts are only joking and are really paid comedians ? Please.

https://owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Only_Support_Strong_Cryptographic_Ciphers
and this
https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)#Weak_SSL.2FTLS_Ciphers.2FProtocols.2FKeys
and more
https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy
and here
https://www.google.co.uk/#q=how+easy+is+it+to+crack+TLS
and hundreds if not thousands more.

securityguy wrote: »

Therefore, worrying about cipher suites is entirely the wrong question.

Hence I can forget these fools that are pushing cipher ordering and being picky and such like. I think you are perhaps, not quite with the program.

securityguy wrote: »

3DES is performance pig, particularly on small processors, and AES is not yet universally deployed; for applications where long-term security is not a concern (Ie, I don't care if you can decrypt my banking session from today in ten years' time) RC4 is still perfectly serviceable.

The reason RC4 is not well regarded is that unlike DES and AES it hasn't been subjected to agency scrutiny, and has never been used to secure protectively marked assets.

Forgive me, I'm clearly suffering from a bout of cognitive dissonance. So these people who talk about 'weaknesses' in RC4 are scaremongering. https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weaknesses

securityguy wrote: »

however, since we now have cipher suites assured to SECRET and above by the agencies we might as well use them.

Heaven forbid a contradiction ? You try to established a ciphers 'weakness' is not an issue, yet then why should agencies be so picky, and if the reason for them being so picky is because they disagree with you and feel they do need to be careful, then why should we be any less cautious ?

Something doesn't add up here. There are so may reports highlighting various 'weakness' in ciphers, we have governments who would only work with a select few, we see plenty of guidance that suggests not using some cipher suites. there are even examples of a guy and his laptop breaking SSL using off the shelf freeware tools in real-time. Do you mean to suggest all this discussion around 'deprecating' of so called 'weak' cipher suites is unnecessary fear mongering by charlatans masquerading as experts in the field ?

securityguy wrote: »

Therefore, worrying about cipher suites is entirely the wrong question.

securityguy

As I say, I give up.

You don't even read the links you post. For example, the article you cite about RC4 goes on to say "While 3DES provides more resistant cryptography, it is also 30 times slower and more cpu intensive than RC4. For large web infrastructure, the CPU cost of replacing 3DES with RC4 is non-zero. For this reason, we recommend that administrators evaluate their traffic patterns, and make the decision of replacing RC4 with 3DES on a per-case basis."

The attack on RC4 based on key bias which your leaden sarcasm seems so pleased with is completely irrelevant to banking applications. Clue: "If the same data is encrypted a very large number of times, then an attacker can apply statistical analysis to the results and recover the encrypted text." Can you think of an occasion when in a banking application the same confidential data might be encrypted under a number of keys a large number of times? No, I can't either. I was at the conference at which the authors presented the paper (see http://www.isg.rhul.ac.uk/tls/) and took part in the discussion afterwards; I presume you weren't. I suggest you read the paper: http://www.isg.rhul.ac.uk/tls/RC4biases.pdf and stop messing about with summaries. Large means _large_ "our algorithm recovers the first 112 bytes of plaintext with a success rate of more than 50% per byte, using 2^26 sessions." Can you think of the last time you repeated the same transactions with the bank 67108864 times?

And did you even think before typing? For example, " Now why should agencies be so picky, and if the reason for them being so picky is because they disagree with you and feel they do need to be careful, then why should we be any less cautious ? "

How about, "because protecting SECRET and above assets as data at rest against government threat actors where the confidentiality has to be maintained for decades is a rather different problem to protecting data in motion whose value is at most a few hundred quid again petty fraudsters?"

They put bigger locks on the nuclear weapon store at Faslane than I have on my front door. Should I worry about this? Do you think that it's harder to nick a Eurofighter than my car? Should I invest in armed guards?

Broadwood

Getting back to basics for Joe Public.....using the Firefox add-on SSleuth, I've noted that my bank scores only 6.5/10 while Facebook scores 8.5/10 while Ebay scores 5.3/10 and Twitter scores 9.8/10.

Worryingly Paypal login only scores 4.7/10.

Obviously keeping money under the mattress is even less secure.

Don't keep all your eggs in one basket seems good advice all round.

6_6_6

Trust me I read everything. I never questioned performance of RC4.

Its worth pointing out, that paper you say you read, its summary to fix the problems with RC4 reads as follows.

For TLS, there are several possible countermeasures against our attacks. Some of these are more effective than others:

• Switch to using CBC-mode ciphersuites. This is a suitable countermeasure provided previous CBC-mode attacks such as BEAST and Lucky 13 have been patched. Many implementations of TLS 1.0 and 1.1 now do have patches against these attacks.
• Switch to using AEAD ciphersuites, such as AES-GCM. Support for AEAD ciphersuites was specified in TLS 1.2, but this version of TLS is not yet widely supported. We hope that our research will continue to spur support for TLS 1.2 in client and server implementations.
• Patch TLS's use of RC4. For example, one could discard the first output bytes of the RC4 keystream before commencing encryption/decryption. However, this would need to be carried out in every client and server implementation of TLS in a consistent manner. This solution is not practically deployable given the large base of legacy implementations and the lack of a facility to negotiate such a byte discarding procedure. Furthermore, this will not provide security against potential future improvements to our attack. Our recommendation for the long term is to avoid using RC4 in TLS and to switch to using AEAD algorithms.

You talk about one aspect of RC4s weakness, indeed there are others. You point to the number of transactions needed in one particular type of attack, its more to do with the number of HTTP requests of which there are between 800 and 1000 in an average banking session which represents only 0.001% of the amount needed in your example. But likewise that's only good news in those same lab conditions. In the real world, people don't seek to operate by the rules.

If a group manages to compromise a cipher suite in real-time then scale that attack out across the net, were talking several orders of magnitude more damage than nuclear bomb. Likewise to compare the lock on your font door with that on a nuclear bunker is a non sequitur. Looking at it another way, how long would it take for you to fit the door of a nuclear bunker on your house, vs reordering and ensuring the chosen ciphers and protocols in use and which are enabled - are the best available. Res ipsa loquitur. I think your inventing barriers, no pun intended.

I go back to my initial point made earlier in this thread, security is about minimizing the chance of any issue in the first place set against the costs of implementation. If the choice over using your font door to your house or a nuclear bunker door to protect that missile, is the difference between 10 mins and 11 mins work, for the sake of 1 minute, does it even need to be discussed. The fact is, banks are making it difficult because their management practices are antiquated. They are currently choosing to use your font door not the bunker door (so to speak), and with cyber terrorism highlighting motives for attacks reaching beyond rudimentary monetary value, is it right to advocate weak security in this day and age ?

The straw man argument over configurations which would prevent a third of a user base from connecting need to be offset against an increasingly IT iterate consumer base, better and more frequent browser updates, far greater awareness and the increasingly dangerous cyber capabilities of individuals and nations alike. To suggest today ciphers even offer a decade of future protection, is based on a decade old premise. Given Moore's law and freak side channel discoveries seemingly increasing in frequency and impact, as more and more adversaries begin turning their expertise to cracking and breaking, how long will it really take before today's technology reaches a point by which the theoretical becomes the practical. The problem is, we don't really know so why would you not seek to distance yourself and your customers as far away from risk as you possibly can.

Whilst some seem to dismiss any risk (as of today's date) as being purely consigned to lab conditions, do we really have to say why that's a bad stance on security?

I think the bottom line comes down to the intrinsic problem with banks, and one which has always been the case. They are not known to work in an agile way and quickly follow the latest developments. IT is has never been or formed part of their core business. By continuing to neglect IT in this way they put us all at risk, and for nothing.

Banks need to take security more seriously these days. HTTPS is no longer just a tick in the box. Ok, it might not be as simple as just changing a cipher in the servers config, due to load balancers which have only hardware accelerated support for a limited set of ciphers purchased in an age when they didn't see the kind of infiltration that we see today. Deep inspection IDS based on RSA that will not work any longer if the server uses (EC)DH key exchanges to provide forward security. But that's the nature of the beast. Its not our fault they have built inflexible monolithic rods for there own backs by way of bureaucracy, lets face it, if they stopped giving out such big bonuses to CEOs, I do believe they would be able to have this issue resolved within the month.

Almost every other week we see a new headline 'Cryptographers Demonstrate New Crack For Common Web Encryption', I just wonder when the next one reads "Cryptographers Demonstrate New Crack Against TLS v1.0 RC4 ', irresponsible banks using the questionable cipher by the name of RC4, have left millions at risk of this new found weakness, a cipher that has been known to be suboptimal for years." bla bla bla.. game over.

Dropping old ciphers, especially those with known problems, is always the best plan. Ordering ciphers from strongest to weakest is also part and parcel of securing HTTPS correctly, because there is such a thing as a weak cipher. Just because we don't see a practical attack based on our current understanding doesn't mean there wont be one tomorrow, and if we already know some ciphers are stronger than others, why do we still see banks limiting their implementations to TLS 1.0 at best based on 3DES or RC4 or worse. When we are up to TLS 1.2 and have ciphers such as AES-GCM that give you encryption and authentication all in one, ephemeral perfect forward secrecy should also be enabled. AES is hardware accelerated on most systems these days which provides benefits for clients to, such as mobile users. But being a two edged sword hardware assistance might also introduce back doors.

ChopperST

6_6_6

Broadwood wrote: »

Getting back to basics for Joe Public.....using the Firefox add-on SSleuth, I've noted that my bank scores only 6.5/10 while Facebook scores 8.5/10 while Ebay scores 5.3/10 and Twitter scores 9.8/10.

Worryingly Paypal login only scores 4.7/10.

Obviously keeping money under the mattress is even less secure.

Don't keep all your eggs in one basket seems good advice all round.

Indeed this only serves to highlight the absurdity of the banks refusing to configure HTTPS as well as they could.

Problem is so far I have only seen a few banks which even enable modern encryption standards. So choose your baskets carefully and may SSleuth be your guide.

joe134

6_6_6 wrote: »

Interesting. http://www.youtube.com/watch?v=0SgGMj3Mf88&t=3m14s

OOPS, Sorry, thought I picked Banking Thread, not Techie.Good reading though, BUT, what is the object of the OP.? To put the wind up everyone, or, just to prove a pointless point, which is buried deep in the data.? I will still use Rapport, regardless of eula,NOT because I want to but, because it's a catch 22 situation, according to this and my money is in the Bankssss,which, are all insecure according to OP's Data,(which I cannot do anything about,) not , IBM.et.al

6_6_6

joe134 wrote: »

OOPS, Sorry, thought I picked Banking Thread, not Techie.Good reading though, BUT, what is the object of the OP.? To put the wind up everyone, or, just to prove a pointless point, which is buried deep in the data.? I will still use Rapport, regardless of eula,NOT because I want to but, because it's a catch 22 situation, according to this and my money is in the Bankssss,which, are all insecure according to OP's Data,(which I cannot do anything about,) not , IBM.et.al

I read that as "Worrying about security is pointless because I can’t do anything about it, and not using Rapport is a two edged sword because if it don’t, I might not be covered in the event of a security breach if my banks small print has such a clause"

I would say you can help. Every movement has to start somewhere; just the act of hundreds if not thousands of people writing to the bank asking them what they are playing at, could spark them into positive action. In essence, help the matter gain traction.

It is after all, only advice and it gives those that prefer to know about such risks the opportunity to do so and act accordingly.

Raising the issue of bank security to the foreground is within everyone's interests, putting this issue in front of the banks can only serve to raise awareness and we hope they might sit up and take action.

As for Rapport, yes it’s a problem, and one more people would do well to know about. There are many reports that expose the sales driven vested interests behind Rapport and how over hyped it is. Their argument being it’s better than nothing.

Its self-serving nature becomes transparent when you’re enlightened about its purely sales driven agenda.

I do think it’s important to dispel this myth that if bank X has this shiny protection tool, then we assume because bank Y hasn’t got it they are insecure.

A bank with a misguided notion of security, offering Rapport in a bid to reinforce a false sense of security and care for your wellbeing needs to be exposed, when all they really hope to do is compete with the next bank on feature count.

If only becomes catch 22 as I say, if you find in the small print that the bank would seek to dismiss any claims due to not using their tool, despite ostensibly presenting Rapport as an option. I honestly don’t believe they would get away without being slammed for unfair contractual terms in any case, but as you infer, would you be willing to take the risk. Hopefully this issue can receive the attention it deserves and banks can be taken to task.

joe134

6_6_6 wrote: »

I read that as "Worrying about security is pointless because I can’t do anything about it, and not using Rapport is a two edged sword because if it don’t, I might not be covered in the event of a security breach if my banks small print has such a clause"

I would say you can help. Every movement has to start somewhere; just the act of hundreds if not thousands of people writing to the bank asking them what they are playing at, could spark them into positive action. In essence, help the matter gain traction.

It is after all, only advice and it gives those that prefer to know about such risks the opportunity to do so and act accordingly.

Raising the issue of bank security to the foreground is within everyone's interests, putting this issue in front of the banks can only serve to raise awareness and we hope they might sit up and take action.

As for Rapport, yes it’s a problem, and one more people would do well to know about. There are many reports that expose the sales driven vested interests behind Rapport and how over hyped it is. Their argument being it’s better than nothing.

Its self-serving nature becomes transparent when you’re enlightened about its purely sales driven agenda.

I do think it’s important to dispel this myth that if bank X has this shiny protection tool, then we assume because bank Y hasn’t got it they are insecure.

A bank with a misguided notion of security, offering Rapport in a bid to reinforce a false sense of security and care for your wellbeing needs to be exposed, when all they really hope to do is compete with the next bank on feature count.

If only becomes catch 22 as I say, if you find in the small print that the bank would seek to dismiss any claims due to not using their tool, despite ostensibly presenting Rapport as an option. I honestly don’t believe they would get away without being slammed for unfair contractual terms in any case, but as you infer, would you be willing to take the risk. Hopefully this issue can receive the attention it deserves and banks can be taken to task.

Most Apps from Banks are less secure than Proper login details, YET, Banks promote them all the time, on Tablets and I- phones, which, to my knowledge don't support Rapport, so they are actually diluting security even more.I never bank with Apps.You cannot cover everything, just, adhere to the rules set by them, and hope nothing goes wrong, if it does, they should compensate, which they are trying to get out of via Rapport.etc.changing the onus on the user.As for IBM getting full use of your PC,and ALL files on it, I have my doubts," perhaps"files used when using Rapport, on Secured sites, by them, tagged by the users choice..YES?? bit vague that one, needs more clarification? As I type, my weekly Rapport has popped up, 3 cookie grabs, 2 wrong urls, protected, all Banks,it's doing it's job.with no detriment to my machine;
I trust no one, but take the view, better safe than sorry.If one has money, you have to spread it, £85k rule, so, you cannot ,badger every Bank, thats the job of FCA. Not only that, but, the Gov are trying to gain Access to all files held on all Pcs via ISP s', so your data is compromised anyway, is now;;;;
Do you suggest a DATA DAWN >?????

6_6_6

joe134 wrote: »

Rapport has popped up, 3 cookie grabs, 2 wrong urls, protected, all Banks,it's doing it's job.with no detriment to my machine;

Whats worse, the Illusion of Security or the Delusion of Control ?

Besides Trusteer Rapport being flawed and most often causing system instability, it actually introduces a wider attack surface and more possible weaknesses in your system that can leave you more vulnerable than not installing it at all.

Some people are of the opinion that malware coders aren't aware of Trusteer Rapport, I jest not. Quite the contrary, some infections are counting on you having it installed to open pathways under the noses of various good quality anti virus scanners, which Trusteer Rapport as been known to adversely affect since it runs in kernel mode with holes.

Is it not strange how Trusteer Rapport seems to be the only option banks steer you toward and support, when there is such controversy over its poorly designed and bug laden code base. Few people call out venture-backed companies with well-known people on the management team. Follow the money and you will see why banks insist on peddling scare-ware tactics to persuade people to use this app.

The underlying point here is Trusteer Rapport promotes a false sense of security. In short, trusting this product to do the job it claims to do only puts you at risk.
If the banks ever do try to say they wont cover you in the event of a system hack if you opt out of using Trusteer Rapport, then this gets tricky and forms part of the debate over what constitutes neglagnce on your part - under the terms of the Payment Services Regulations 2009.
But this type of self preservation over customer care possibly underlies the reasoning behind the lackadaisical approach to HTTPS connectivity and security in general.

They cover their own a$$, yours, not so much.

If they / you really care about security, then MitB (think virus on your PC) attacks could be better prevented by using what they call sandbox execution applications, these create a fence around all your activity, all your actions become ephemeral and can be rolled back any time you feel like you might have been compromised.

So for example, download portable Firefox and launch it within the 'sandbox'. When you close your browser, any changes are discarded so even if you did encounter a website which could hijack your browser in some way, it can be undone as soon as you close the application . See here for more explanations: http://www.sandboxie.com

A virtual machine (VM) is another option, this is an application that runs a computer in a computer so to speak. Consider this application when you want to have the benefit of a sandbox, but for your entire computer: http://www.shadowdefender.com/

Another option is to have an operating system (OS) on a USB key. You plug in your USB key, turn on your computer and it boots the OS from the USB key instead of your hard drive. Within there you might install a browser and use that for your dedicated access to your secure sites. An OS such as https://tails.boum.org is a good choice it has a number of apps already installed and it is very secure, but don't forget to enabling persistence if you plan on saving bookmarks etc https://tails.boum.org/doc/first_steps/persistence/index.en.html. Another good thing about this is its portable so you can take it and plug it into almost any PC.

Always verify your downloaded file signature, because HAVOK and other such man in the middle attack software exists ! The last thing you want is agency back doors in what you thought was original software!

BUT to be clear, these measures do NOT protect you from a poor HTTPS connection. Where localized vulnerabilities are not the issue. Again to re-iterate this needs to be addressed by the banks.