Online Bank Security - BROKEN !?!?!

esuhl

6_6_6 wrote: »

Is this trolling, or do I believe you really believe that ?

I believe that you are verging on trolling with your anti-bank rant and complete inability to express yourself succinctly with any clarity.

I also think that you don't know very much on the subject and, with a naive bit of Googling, and a lot of fear-mongering confusion, you thought that you'd present yourself as some kind of know-it-all expert, using poorly-written posts to conceal the fact that you don't fully understand what you're talking about.

6_6_6 wrote: »

SSL v.X is not the only weak protocol in use today. It most certainly is not all roses just because you FF 34 etc. You must be careful of spreading misinformation like that.

I never said it was. I thought the point of your tediously long waffling was specifically to highlight problems with SSLv3.

With all your argument here, it sounds like you're suggesting that the banks should do something to make their websites safe. As you well know, nothing can be 100% safe. You should be careful yourself of spreading such misinformation.

So... Are you trolling, or do you really believe that the Internet banking can be completely safe?!

6_6_6

Your post seems rather colored by emotion. I will attempt to put your comments in context. Apologies if there are a bunch of typos, I'm rushing this reply so bear with.

securityguy wrote: »

Fiddling with available cipher suites

. Calling it fiddling is somewhat disingenuous don’t you think; it’s perfectly reasonable to agree a range of cipher suites and protocols, test them, pass them to a CM team then implement them. Besides getting a little off topic, I don’t think I provided enough information for you to draw that conclusion so I wonder what underlies your assumption. The subject here is why banks are not enabling strong ciphers and up to date protocol support.

securityguy wrote: »

implications for processing performance (one of RC4's attractions over DES was that the former is very quick on standard hardware, while the latter isn't), for entropy collection (a server using RSA doesn't need to generate session keys,

Yes there are ‘implications’ for processing performance, and possibly more further reaching than you might think. If you have tested them in the real world which I am sure you have, you will know that the performance issues depend on a number of things:
On small 32-bit systems such as embedded ARM, the MAC part of GCM will be expensive, but so will SHA-384 due to the request for 64-bit computations . Perhaps there is little difference here. On PC, AES cost will dominate except on very recent PCs with AES-NI, where AES is very fast, and so is GCM. So a GCM cipher suite will usually be a better bet.
However, it takes a lot of bandwidth, or a very small CPU, to actually notice any difference. Even without AES-NI, a typical 8GB i7 IIS server has more than enough processing capacity to perform SSL at full gigabit bandwidth.
It really depends on one’s infrastructure, for instance like you have the hardware which provides AES acceleration, why would you not use it.
I would not think anybody here is saying AES based ciphers are a problem, quite the contrary why are all banks not enabling them. But by the same token, placing a strong AES cipher above a non-accelerated cipher might not give you the performance boost you had hoped for.
Again I didn’t talk about the processing implications of given ciphers since it a given that anyone who knows about this topic will obviously be aware of the basic premise, but your raise a valid operational concern. I think in general, you need to be careful not to overestimate the impact without testing your assumptions first. Premature optimisation is a classic anti pattern. You might be surprised how small a difference there is between the modern cipher suites. The right hardware should be figured out at the provisioning stage in any case and are we to say then, banks have neglected this area if they fear performance issues. This kind of implementation detail risks extending beyond the scope of the post. But what would be interesting, would be to see some metrics that justify why Bank X or Y have felt it necessary to disable TLS 1.1 and 1.2 only to make available, TLS 1.0 with RC4 and DES based ciphers. Now if they know something we don’t, i.e. TLS 1.2 with an AES based ECDHE cipher will in some way significantly harm their business, then that would be an interesting read.
On the other hand, I am aware that having super-fast session keys also has its weaknesses, since it serves to assists bluecoat implementations. Thing is, the SSL PKI technology is broken anyway because if your browser trusts one CA, it trusts all certificates issued by that CA for any web site and all bets are off, but I digress.

securityguy wrote: »

ECDH session keys are predictable if you can attack either the client's or the server's RNG), for browser compatibility (not only for fielded browsers, but for people on the other side of Blue Coat-style intercepting proxies)

The "permanent" key pairs validated by a Certificate Authority are used for identity verification, and signing the temporary keys as they are exchanged. Not for securing the session. I am not aware that Blue Coat proxies rely upon any weakness within ECDH session key management specifically. Are you conflating two separate concerns? Besides if some actor has altered the RNG, you’re pretty stuffed all round, besides you having some form of hostile within the confounds of your server space, any key generation could be made predictable and all reliant ciphers would be compromised in any case, I’m not sure what point your making in disfavour of ECDH specifically ?

securityguy wrote: »

And you base this assertion on...?

“It bears little in the way of implementation cost both in terms of FTE and tin”, In terms of the raw implementation activity, well the question is what does enabling strong cipher support on your webserver or LB do in terms of performance. Not a lot in my experience, but of course that depends how big your user base is and your hardware, and no not 20 users, no it was more around the 4000 mark, but that’s small numbers I grant you. Secondly how long does it take to update the cipher suite on a server, as long as it takes to modify a text file and roll it out ?
I think the main implementation cost will be confined to the testing of new cipher suite setups. I read that it is quite rare that new hardware is ever needed to take on any added authentication burden of stronger cipher suites these days, especially if you don’t do anything stupid like enabling 512 bit ciphers.

securityguy wrote: »

handful, all of them using AES. But then I don't have to worry about Mrs Miggins and her obscure set top box and nor, I suspect, do you.

I was not aware of a significant use case for people logging into their banks via the TV or media box, if there is, are we saying modern TVs browsers are such that they couldn’t support AES128 CBC GCM ? Like I have previously said, my issue is with banks not supporting the latest and greatest ciphers. Legacy support will always be an issue; it’s getting that issue into perspective. I suppose the question is how far back a bank should go in terms of its HTTPS encryption support. That often becomes a business decision. Firstly you need to understand who you’re ruling out when drawing the line in sand. If it's acceptable to display a user message tell thing them the browser they are using does not support the necessary security standards required for a connection, great. However, that’s a business decision. There are other ways this can be mitigated by good design such as referring certain client types to different endpoints dedicated to service content destined for specific platforms.

securityguy wrote: »

AES256 is any more resistant to the possibility of a Heartbleed-style threat than DES56?

I have not entered into discussion around specific ciphers and which one might be slightly better than others on purpose, because there is some disagreement around what is or is not the ultimate cipher suite protection; in the main all the top modern ciphers position you much further away from today’s threats if implemented correctly, vs what banks chose to implement. Indeed that would be a discussion to be had with a cryptography expert since I am not. We rely upon empirical reviews and reading the resultant papers these experts write. I don’t think I will be looking to implement DES any time soon however, poodle is the least of your problems when considering DES ciphers. It is reasonably well known that even as far back as far as 1998 DES was proven not be a suitable cipher for use in encryption.

securityguy wrote: »

AES256 + ECDH is stronger against _implementation_ fails than anything else. Which cipher suite do you think is strongest?

As I say, this is contentious nevertheless a fun discussion to have I’m sure, but not one that needs to be had here. For the purposes of main stream HTTPS implementation within a bank, there are a number of peer reviewed guides and recommendations on the ordering and implementation. I provide a link to one such accumulation of best practice in my initial post. I’m no cryptography expert so we have to rely upon these to get the job done properly, and asking me to discuss in detail, the nuances between the top cipher suites would require me to do a lot of research far beyond the scope of my day job.

securityguy wrote: »

And how much money do you think these "HTTPS zero day fails" have cost the banks so far? My guess would be zero. Nothing. Not a penny. What's your estimate?

I can tell you it costs a lot! Security like any other maintenance is overall - an expensive undertaking. The problem with banks seems to be they tend to be of the opinion that you don’t do it until you have to (aka wait until it's too late), and if you must, pass the cost on to the consumer.
http://www.theguardian.com/technology/2014/apr/18/heartbleed-bug-will-cost-millions
https://konklone.com/post/why-google-is-hurrying-the-web-to-kill-sha-1
http://www.theage.com.au/it-pro/security-it/the-hidden-costs-of-the-heartbleed-security-bug-20140422-zqxp6.html

6_6_6

esuhl wrote: »

I believe that you are verging on trolling with your anti-bank rant and complete inability to express yourself succinctly with any clarity.

I also think that you don't know very much on the subject and, with a naive bit of Googling, and a lot of fear-mongering confusion, you thought that you'd present yourself as some kind of know-it-all expert, using poorly-written posts to conceal the fact that you don't fully understand what you're talking about.



I never said it was. I thought the point of your tediously long waffling was specifically to highlight problems with SSLv3.

With all your argument here, it sounds like you're suggesting that the banks should do something to make their websites safe. As you well know, nothing can be 100% safe. You should be careful yourself of spreading such misinformation.

So... Are you trolling, or do you really believe that the Internet banking can be completely safe?!

I would not look to throw stones in glass houses if i were you, since you define 'naive bit of Googling' very well with statements such as

But Firefox v34 and Chrome v39 onward disable SSLv3 by default. So, if you use those browsers (from what I can gather), you don't need to worry and can go and read some more interesting threads.

I would be more concerned with your lack of reading comprehension because whilst you seem to think I'm waffling, you clearly seem to have been able to infer somehow that I professed to be an be expert. Rather annoying that, because I go to great lengths to say i am certainly NOT an expert. And that if we evidently do find one, that actually presents a solid case for why banks don't need to implement the stronger encryption schemes, then I'm all ears.

securityguy

My point was that banks have not as yet lost a penny to attacks that leverage the vulnerabilities you're describing. They are difficult to execute (they usually require a Dolev-Yao opponent, which is strong assumption) and even harder to monetise.

The rest of your assertions have the whiff of Google to them. DES isn't broken, not remotely: 56 bit keys are too short and can be brute-forced, as can any cipher of that key length, but of ciphers of that key length DES is probably still the best that is available (ie, its 56 bits really are 56 bits). Matsui's linear cryptanalysis attack on DES is the best known, and is not remotely practical.

That is why the Triple DES variants are regarded as practically secure, and their use in a modern cipher suite is entirely reasonable. The reasons for moving away from them are more to do with performance (the round function is quite awkward to implement quickly, so 3DES is still awkward on things like phones) than any security concerns.

Referring to work about DES as "polish[ing] a turd" is just ill-informed: DES is an astoundingly good piece of work, and what we now know about the origins of the S Boxes and the resistance of the cipher to differential cryptanalysis makes that assertion if anything stronger as time goes by. When AES has resisted 40 years' attacks we can give it the same accolade.

But as I say: there is not a single account in the literature of a realist cryptographic attack on a bank, using either implementation weaknesses such as you are so excited about or frontal attacks on weak cipher suites. Not a single account. No amount of frothing about impending tides of cipher anarchy can get away from that fact.

6_6_6

securityguy wrote: »

My point was that banks have not as yet lost a penny to attacks that leverage the vulnerabilities you're describing. They are difficult to execute (they usually require a Dolev-Yao opponent, which is strong assumption) and even harder to monetise.

The rest of your assertions have the whiff of Google to them. DES isn't broken, not remotely: 56 bit keys are too short and can be brute-forced, as can any cipher of that key length, but of ciphers of that key length DES is probably still the best that is available (ie, its 56 bits really are 56 bits). Matsui's linear cryptanalysis attack on DES is the best known, and is not remotely practical.

That is why the Triple DES variants are regarded as practically secure, and their use in a modern cipher suite is entirely reasonable. The reasons for moving away from them are more to do with performance (the round function is quite awkward to implement quickly, so 3DES is still awkward on things like phones) than any security concerns.

Referring to work about DES as "polish[ing] a turd" is just ill-informed: DES is an astoundingly good piece of work, and what we now know about the origins of the S Boxes and the resistance of the cipher to differential cryptanalysis makes that assertion if anything stronger as time goes by. When AES has resisted 40 years' attacks we can give it the same accolade.

But as I say: there is not a single account in the literature of a realist cryptographic attack on a bank, using either implementation weaknesses such as you are so excited about or frontal attacks on weak cipher suites. Not a single account. No amount of frothing about impending tides of cipher anarchy can get away from that fact.

I would say though, to those that knock Google, it's an online library. You just need to be careful to qualify any sources, as you would in any case.

Well, I was always advised DES56 is compromised via brute force, I grant you 3DES not so much, and far from it. So with interest piqued I have indeed just used Google to do some digging. I'm with you on 3DES ref lack of as yet practical known weakness in its cipher. https://tools.ietf.org/html/draft-ietf-ipsec-ciph-des-expiv-01

For DES-EDE3 (3DES) , there is no known need to reject weak or complementation keys. Any weakness is obviated by the use of multiple keys.

But then it states..

However, if the first two or last two independent 64-bit keys are equal (k1 == k2 or k2 == k3), then the 3DES operation is simply the same as DES. Implementers MUST reject keys that exhibit this property.

I suppose it all depends on what class of "weaknesses" we are talking about, since there are so many parts to an encryption scheme, any one might introduce a perceived weakness that is as yet unknown, without being an expert in the field it’s hard to qualify what the experts suggest so we tend to just accept their recommendations on face value.

You sound familiar with the intricacies of the particular ciphers. If banks were to reorder and enable newer cipher suites, what would be your definition of ' doing it properly'.

6_6_6

bubieyehyeh wrote: »

I've previously tried to report similar issues to a UK bank, and was unable to get messages passed on to techies within the bank who might understand. So I know the banging your head against a brick wall feeling.

They rejected my complaint, and said I could go to the ombudmen, then the heartbleed bug hit and in fixing that they fixed the fault I had been reporting for months.

The fault which was allowing people to connect to internet banking via HTTPS using a null cipher - which provided no encryption/protection.

The same bank also had a fault in their internet banking where some "secure messages" sent while logged in failed, and then the error report including the "secure message" was send to the customers email address. The customer service person didn't think it was an important problem, but did agree they would fix it "in time".

It's very frustrating. I wonder what bank that was ? I almost missed your post amongst all the silly banter on this thread. It's hard to conceive how a null cipher might have got past review, and in a BANK?

anoncol

Archi_Bald wrote: »

You obviously don't have a convincing case, otherwise they would all bite your arm off.

BTW, notice my teflon shoulders. I won't be joining anything.

The op actually talks allot of sense actually. I was talking a few years ago about the farce called rapport.

Banks not listening does not in any way mean the op doesn't have a good case. Especially when stupid Callcentre staff won't put you through to a suitable person.

securityguy

The issue of sub-key equality in EDE mode is not a practical concern if DES is being used as a session key.

Even if an implementation ignores the need to make the obvious check (and it's an entirely obvious issue from the construction of EDE mode 3DES, not some subtle problem that was discovered later, and it's in every standards document as being required, and it's trivial to test for compliance), and even if the attacker has a way to discern that the problem has arisen on any particular connection (how?) the issue will arise once in every 2^55 random key generations. So if a bank has 1000 logins per second, the issue of a key with this bad property will arise approximately once every million years.

3DES has been known to be sound (assuming that single DES is sound up to the issue of its key length) since Campbell and Wiener's 1993 paper "DES is not a group".

6_6_6

I see the guidance is that 3DES should always be use in place of RC4 based ciphers. RC4 should be disabled. But AES should always be prioritised above 3DES.

Taking a step back, would you say banks could improve their HTTPS security implementations by changing their cipher suites and enabling the current crop of high security cipher suites.

To my mind, the suggestions made here seem sound and could act as a template implementation for the banks; https://wiki.mozilla.org/Security/Server_Side_TL
I would hope a bank would not lower themselves below an intermediate level.

In the context of a banking though, are there any suites listed that would not be recommended ?
Looking toward what Santander have implemented, they seem to gone with RC4 over 3DES.

securityguy

6_6_6 wrote: »

I see the guidance is that 3DES should always be use in place of RC4 based ciphers. RC4 should be disabled. But AES should always be prioritised above 3DES..

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. There are good practical reasons as to why such attacks are very difficult, and good practical reasons as to why they are extremely difficult to monetise. 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.

If you want to defraud banks by stealing login credentials, then there is a far, far easier way to do it: a key logger, propagated as a trojan in the manner of botnets. Any botnet agent is able to steal these credentials, which is why the banks are keen to push (weak, but that's a separate issue) technologies like Trusteer Raport. The weapon may be rubbish, but the target --- key logger infestation --- is the serious risk.

Secondly, every crypto debacle of the past decade has been about implementation, not cipher strength. No "weak" cipher has made it into the marketplace; at worst, they have proven to have effective strengths within a few bits of their nominal key length. The reason things like BEAST, Lucky 13 and so on have arisen is because implementing ciphers correctly is very, very hard, and bugs in the implementations (and by implementations I don't just mean writing code, I mean using the ciphers in practical systems like TLS) have meant that the cipher can be side-stepped. Strengthening the cipher doesn't make these attacks less serious, weakening it doesn't make them worse.

Therefore, worrying about cipher suites is entirely the wrong question. The attackers are not resourced or interested in brute-force code breaking: against session keys it simply isn't worthwhile. If they had the resources to do it, they would be better off using those resources to mine bitcoins. Attacks against key exchange protocols don't look any more fruitful, and again have the same problem of only getting one session at a time. Attacks on private keys are not even close to practical, and even if successful would be used to mount active man in the middle attacks, not to decrypt past sessions.

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. DES was never accredited in general, but in practice you could get a solution which handled protectively marked data accredited using DES; AES is accredited for SECRET and (in its 192 bit and 256 bit form) for TOP SECRET. That doesn't mean there are serious attacks on RC4, and (vide supra) doesn't mean those attacks if they existed would necessarily be a worry for banks; however, since we now have cipher suites assured to SECRET and above by the agencies we might as well use them. 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.