Hacker News new | past | comments | ask | show | jobs | submit login

Let's be crystal-clear: All of these fail PCI compliance, because they have RC4 enabled. These sites have no business processing anything, let alone personal or financial info.

Yes, having RC4 enabled is now an instant PCI compliance fail as it has a die-die-die RFC and as a result NIST changed it, on request, to a CVE grade above a 4.0 - https://tools.ietf.org/html/rfc7465 - https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-25... - web browsers have already started turning it off.




Yeah. Worse, if RC4 being enabled was the only problem, it would be bad, but somewhat reasonable, as RC4 only recently became known to be weak. But POODLE? FREAK? TSL1.0? All the other crap? Absolutely incredible.


As an aside, bank websites don't necessarily fall in-scope for PCI.

I worked for a small credit union, and we were beholden to our state auditors, FFIEC guidance, and the like -- but PCI simply wasn't a thing we worried about.


Interesting. I know far, far less about the regulatory side than the practical side. I gather it's focused mainly on merchants, but the card providers themselves founded it?

I'm not sure what I can say except not every bank seems to share that view (although as said in other comments, quite a few banks do indeed have paleolithic systems in unexpected places, and that tends to extend to their security practices - I am not able to name any names, but I can wave in the vague general direction of things which involve VAXen, COBOL and DES-and-I-don't-mean-3DES, all of which thankfully predate me). But I'm not exactly familiar with US banking practices (thankfully): did the credit union just not issue any Visa/Mastercard/etc cards? Huh.


True, but this is because a large number of credit unions don't issue Visa / Mastercard credit cards directly; typically they do it through their banking partners (who are registered as banks as opposed to credit unions who for almost all cases are not banks), if they do it at all.


Yea, I hope PCI DSS clarifies this matter soon.


For a long time I thought PCI DSS/NVD was the culprit for all RC4 on payment sites, but luckily this was solved, I see they updated the score on 03/12/2015: https://code.google.com/p/chromium/issues/detail?id=375342#c... https://code.google.com/p/chromium/issues/detail?id=375342#c...

I usually complain when some site uses RC4 and I can't access it, but unlike the OP I don't do that via twitter (one reason is that I don't even have an account there).

I've sent 2 emails regarding the use of ONLY RC4 on payment sites in my country, and although such emails aren't always acknowledged they did get fixed after I CC-ed their PCI auditors [1] :)

[1] which you can find publicly on Visa's site at 'PCI DSS validated Member Agent Weblisting' http://www.visaeurope.com/receiving-payments/security/downlo...


It was, part of it. RC4 had a CVE score below 4 (which many interpreted as an issue they could argue around, i.e. "we need to support Windows XP!"), but BEAST had a score above 4 (auto-fail). And what was the (horrible!) recommendation people got when asking how to mitigate BEAST but still let Windows XP connect? That's right: RC4.

That excuse has gone, on two counts. RC4's now thoroughly toast, and Windows XP's unsupported - and now finds itself without any secure ciphers at all.

It's zmap time…


Lets hope that the new RC4 attacks that will hit the news in a few weeks will help also.


Not long now. I think that will mostly depend on whether they give the issues a name and a logo! <g> (Seriously though, that does seems to get people off their arses!)

You might want to get ready to change passwords for sites that have used RC4 in the past. Or, despite as much warning as anyone can give, are inexplicably still using it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: