'Belgische banken hebben ssl-beveiliging niet op orde'

Een aantal Belgische banken, waaronder ING, heeft de ssl-beveiliging van zijn websites niet goed op orde, zo blijkt uit resultaten van een scan door de online tool SSL Labs. Door de soms ondermaatse ssl-implementaties bestaat het risico dat hackers sessies kunnen kapen.

SSL Labs geeft een score aan de implementatie van het ssl-protocol: een A+ betekent dat een https-website voldoende beveiligd is, terwijl een F-beoordeling wijst op kwetsbaarheden. De securityblogger Yeri Tiete is alle Belgische banken nagelopen met behulp van de tool en stelt op basis daarvan dat de websites van Bpost, BNP Paribas, HelloBank!, ING, Record Bank en Bank van Breda een slechte tot zeer slechte beoordeling kregen. Hierdoor zijn de websites potentieel onvoldoende beveiligd. Zo zijn sommige sites kwetsbaar voor de Poodle-bug, een kwetsbaarheid in het ssl 3.0-protocol.

Bpost en BNP Paribas Fortis hebben inmiddels hun ssl-configuratie op orde gebracht, maar ING, Recordbank, Hellobank en Bank van Breda zouden nog steeds slecht scoren. De belangrijkste Nederlandse banken komen overigens beter uit de test: Rabobank, Knab, ING en Triodos Bank scoren een A-, terwijl ABN Amro, ASN Bank, RegioBank, SNS Bank en Van Lanschot een B-score krijgen toegekend.

Update 13:40: ING België scoort inmiddels een A-.

Reacties (75)

[biglia]

Sommige banken willen Windows XP en Internet Explorer 6 blijven ondersteunen voor hun klanten. Vandaar dat ze niet willen upgraden.

[chaoscontrol]

Dat is onzin. je kan een goede A rating halen en nog XP (SP3) ondersteunen (ook alleen IE, de rest zal gewoon werken). Gewoon die oude SSL en TLS zooi disablen, niemand heeft dat nodig en al helemaal niemand gebruikt het meer. Dat is eerder om de smartphone uit 2003 nog te ondersteunen...

[Armin]

Dat is onzin. je kan een goede A rating halen en nog XP (SP3) ondersteunen (ook alleen IE, de rest zal gewoon werken). Gewoon die oude SSL en TLS zooi disablen, niemand heeft dat nodig en al helemaal niemand gebruikt het meer. Dat is eerder om de smartphone uit 2003 nog te ondersteunen...

Aangezien XP native geen TLS ondersteund kun je SSL echter niet uitzetten

Overigens heb je wel gelijk, dat een C-rating of lager gewoon slecht is van de bank.

Een B-rating niet. Dat is afhankelijk van de omstandigheden.

Enkele voorbeelden:
- RC4 : Er zijn nu eenmaal nog steeds bedrijfs software pakketten die bijvoorbeeld RC4 gebruiken. Denk aan bepaalde proxy en anti-virus scanners. Als bank kun je dan niet zomaar zeggen dat je RC4 gaat uitschakelen. Als je echter zorgt dat RC4 enkel gebruikt wordt bij TLS 1.0 en niet bij 1.1 en 1.2 en bovendien zorgt dat die onderaan in de cipher orde staat is er geen enkel probleem voor normale PC's die dan nooit RC4 zullen gebruiken.

Er is een flinke discussie op het forum van SSL Labs geweest hoe zwaar RC4 op dat moment zou moeten tellen. Ik en anderen opperde dat in die gevallen het geen B-rating zou moeten geven.

- Forward secrecy. Dat is ter bescherming van gestolen keys door software lekken zoals heartbleed. Echter je kunt ook hardware encryptie units nemen met load balancers. SSL Labs kan dat niet zien aan de buitenkant, en geeft dan een lager rating ook al heeft de bank het wel op orde.

SSL Labs zelf geeft dan ook aan dat je niet die rating letterlijk moet nemen, maar moet kijken waarom je een lagere rating krijgt. Bij echte audits wordt immers wel gekeken naar de achtergronden. Vergeet immers dat die SSL labs scan geen officiele rating tool is. Het is een PR instrument (maar wel een hele goede) van Qualys om haar eigen producten te promoten.

- Indien je wel forward secrecy gebruikt maar DHE key exchange gebruikt en tevens oude op Java gebaseerde bedrijfspakketten moeten ondersteunen kun je maximaal 1024 bit onderhandelen. Je krijgt dan een lagere rating, doch wanneer je je cipher volgorde zo configureerd kun je er voor zorgen dat enkel die oude bedrijfspakketten en Android 2.x die 1024 bit exchange krijgen, en moderne browsers bijvoorbeeld eliptical curve DHE met hoger sterkte.

- De client specificaties zijn niet up to date. Qualys weet dat, maar zoals net gezegd, omdat het geen officiele tool is maakt dat niet uit. Dit zorgt ervoor dat voor sommige clients SSL Labs de verkeerde cipher detecteert voor een client/OS en dus een verkeerde rating kan geven.

[the_stickie]

Ik ken genoeg mensen op de juiste plekken binnen sommige van de genoemde bedrijven om te kunnen stellen dat ze allemaal zeer serieus met hun it beveiliging bezig zijn. Dat is oa een gevolg van pci, dat niet enkel basisbeveiliging aanpakt, maar ook sterk inzet op processen om oa nieuwe kwetsbaarheden in alle gebruikte technologieën aan te pakken. RC4, Beast, poodle ea zijn dan ook zeker bij allemaal geevalueerd. De stelling dat financiële instellingen onwetend of lui zijn als ze de ssl labs testen niet met A afronden, zoals deze 'beveiligsonderzoeker' stelt, is dan ook sowieso onwaar.
Hij gaat met zijn analyse, het in batch runnen van een lijstje urls, dan ook straal voorbij aan bijvoorbeeld de mogelijke mitigaties voor poodle door ips systemen, de mogelijke requirements die remote clients opleggen en ook, en met name, de complexiteit van het wisselen van een paar certificaten op een online betalingsplatform.
Het feit dat de genoemde instellingen zo snel reageren, toont dan ook aan dat dit al lang en breed in de pipeline zat en dus door het schuiven in prioriteiten en de change schedule dit snel geïmplementeerd kon worden.
Wat ik niet kan ontkennen, is dat de persaandacht voor dit 'issue' de communicatie naar klanten toe soms versneld of vereenvoudigd heeft. In die zin heeft dit dan toch iets opgeleverd.

[Armin]

Het feit dat de genoemde instellingen zo snel reageren, toont dan ook aan dat dit al lang en breed in de pipeline zat en dus door het schuiven in prioriteiten en de change schedule dit snel geïmplementeerd kon worden.

Eens, maar ook dat de wijzingen vaak enorm simpel zijn. Sommige van de wijzingen zijn het verwijderen van één cipher en/of SSL3 support. Zaken die je in de scanner opeens van F naar A of op zijn minst B brengen.

Maar ook allemaal zaken die het werkelijke HTTPS verkeer meestal niet echt veiliger gemaakt hebben. Daarmee bedoel ik dat men nooit onveilig was geweest. Het is in de meeste gevallen meer een noodzakelijke PR actie, dan dat het fundamentele security was.

Let wel, het is een beetje slordig om bijvoorbeeld SSL3 aan te laten staan, maar de meeste banken zijn nooit vatbaar geweest voor POODLE omdat de achterliggende infrastructuur de noodzakelijke omgeving om een POODLE aanval op te zetten niet mogelijk maakte. Het aan laten staan is dan geen groot security risico en dus inderdaad zoals jij aangaf nooit prioriteit geweest. Nu de PR afdeling echter aan de deur klopte, heeft men het dan toch maar snel uitgezet.

Het geeft ook mooi aan dat als security als PR instrument gezien wordt er soms veel en snel dingen bereikt kunnen worden

[sjongenelen]

je OS en de server kiezen de beste beveiliging tijdens handshake. Daarom zal niemand een connectie krijgen met verouderde beveiliging.
Wat ik niet snap is waarom het toestaan van die connecties (ook al worden die in realiteit nooit gebruikt) een beveiliging risico is. Kan iemand mij dat uitleggen?

[Reactie gewijzigd door sjongenelen op 23 juli 2024 13:36]

[Blubber]

Tsjah, je OS en de server kiezen de beste beveiliging tijdens handshake. Daarom zal niemand een connectie krijgen met verouderde beveiliging.
Wat ik niet snap is waarom het toestaan van die connecties (ook al worden die in realiteit nooit gebruikt) een beveiliging risico is. Kan iemand mij dat uitleggen?

Die POODLE aanval stelt een man in the middle in staat om een protocol downgrade te forceren.

Er zijn twee versies van POODLE, eentje zorgt ervoor dat je RC4 gaat gebruiken, oplossing is om RC4 uit te zetten, wat prima kan. Die andere forceert een downgrade van TLS1.2 naar SSL3, wat een groter probleem is, want XP met IE 6 ondersteunt geen TLS, dus SSL3 uitzetten is dan geen optie.

De details staan mij niet helemaal meer bij, maar zie de gelinkte wikipedia pagina.

[Reactie gewijzigd door Blubber op 23 juli 2024 13:36]

[R4gnax]

Die POODLE aanval stelt een man in the middle in staat om een protocol downgrade te forceren.

De protocol downgrade heeft an sich niets met POODLE te maken. POODLE zelf is een padding attack op het legacy SSL3 protocol en er wordt apart een version downgrade attack uitgevoerd om een client en server zover te krijgen dat ze over SSL3 verbinden.

Eenzelfde soort aanval kun je ook gebruik om een 'downgrade dance' uit te voeren naar TLS 1.0 wat gevoelig is voor de BEAST aanval. Aan zowel de client- als serverkant zijn er tegenmaatregelen om BEAST te bemoeilijken, maar de aanval zelf blijft principieel gezien wel werken. De enige manier om er echt vanaf te komen is TLS 1.0 verbindingen niet meer toe te staan.

Wil je dus er voor zorgen dat mensen die een beveiligde verbinding naar jouw site hebben ook echt een beveiligde verbinding hebben, dan zul je op je server niet alleen SSL3 maar ook TLS 1.0 uit moeten zetten en alleen TLS 1.1 of hoger toe staan.

[Reactie gewijzigd door R4gnax op 23 juli 2024 13:36]

[Armin]

Er zijn twee versies van POODLE, eentje zorgt ervoor dat je RC4 gaat gebruiken, oplossing is om RC4 uit te zetten, wat prima kan. Die andere forceert een downgrade van TLS1.2 naar SSL3, wat een groter probleem is, want XP met IE 6 ondersteunt geen TLS, dus SSL3 uitzetten is dan geen optie.

Niet helemaal. Er zijn twee versies van van POODLE maar dat heeft niets met RC4 te maken.

POODLE is in principe enkel van toepassing bij SSL3 en een niet-stream cipher. Ofwel 3DES CBC en AES CBC. Een moderne brower zal echter nooit SSL3 gebruiken. Maar zoals je aangeeft kan een MITM aanvaller (maar dat is moeilijk overigens) proberen een hogere TLS 1.x connectie te downgraden.

Merk daarbij op dat RC4 juist bescherming geeft. RC4 is namelijk een stream cipher en niet vatbaar voor POODLE. RC4 wordt echter gezien als zwakker, en dus niet aan te raden. Maar RC4 beschermt je dus tegen POODLE.

De tweede POODLE variant is enkel omdat twee fabrikanten (F5 en nog eentje die me even ontschoten is) een bug hadden in hun software waardoor ook TLS 1.x op hun systemen vatbaar was voor POODLE. De specifieek bescherming tegen de POODLE aanval die TLS kent, was daar namelijk uitgeschakeld. Dat is echter inmiddels een zeldzaamheid want die twee bedrijven hebben patches uitbegracht op 9 december 2014.

[sjongenelen]

Thanks!

[BCC]

Spyware forceert vaak de laagst mogelijke handshake door de hogere uit te zetten.

[sjongenelen]

Logisch; daar had ik nog niet bij stilgestaan inderdaad

[BCC]

Toen wij dat 3 jaar geleden uitzetten leverde dat al verdacht veel helpdesk calls op. De site is dood! Nee, jij hebt spyware

[sjongenelen]

Ja ik heb het op de zaak ook uitstaan(ook op basis van ssl , maar wist eigenlijk nooit precies waarom (of wat nou de precieze techniek was om zo'n sessie dus over te nemen).

[Blokker_1999]

voor IE6 heb je de oude SSL versies toch nodig had ik overlaatst nog gelezen toen ik mijn eigen SSL certificaten aan het vernieuwen was en op zoek ging naar waarom ik niet onmiddelijk een A rating had.

--edit--

IE6 ondersteund standaard alleen SSL3, IE6 heeft ondersteuning voor het eveneens verouderde TLS 1.0 aan boord, maar dit staat standaard uit. Als een gebruiker vandaag nog IE6 gebruikt, is de kans klein dat deze zomaar even de beveiligingsinstellingen van zijn/haar browser gaat aanpassen.

[Reactie gewijzigd door Blokker_1999 op 23 juli 2024 13:36]

[PolarBear]

Dat is gewoon een hele slechte keuze van een bank. Er is echt geen enkele reden meer om klanten niet zo langzamerhand te dwingen een ander OS te gaan draaien. XP is out of support, zelfs het laatste SP(3) is al 7 jaar oud.

[Ronald]

Het is meer dan een slechte zaak: Poodle is zo ernstig dat het de beveiliging van 99% + van de gebruikers zo goed als teniet doet omdat er een handvol mensen zijn die weigeren te upgraden van een niet ondersteunde browser op een niet ondersteund OS, die eveneens niet knap beveiligd kunnen zijn.

[Armin]

POODLE is helemaal niet zo ernstig. Het vereist een MITM aanval, dus zolang jij op veilige netwerken zit (thuis, op je 3G/4G van je smartphone, etc) is er niets aan de hand. En zelfs op een onveilig cafe WiFi netwerk is de POODLE aanval nog lastig uit te voeren op real-time verbindingen zoals bankverbindingen. Je moet immers iets van 256 verbindingen opzetten per te decoderen byte. Banken verbreken de verbinding reeds na één poging

Het is vooral gevaarlijk bij sites die cookies gebruiken als autenticatie. Denk aan het Tweakers forum of Google+ of GMail inlog cookies. Daar kun je soms honderden keren proberen. Bankverbindingen echter dus net bijna nooit

Ik bedoel dat niet belerend, maar enkel om de ophef/angst over POODLE een beetje te temperen.

[mzinke]

Vegeet ook de B2B sector niet. Niet alle klanten van de banken kunnen / willen snel over naar TLS 1.x De meeste banken 'dwingen' dat wel af, maar geven hun klanten enkele maanden de tijd om de zaak op orde te krijgen.

[Mistraller]

En als er nu eens een intelligente SSL offloader voor staat, die een bezoeker op verouderde ssl suite ziet binnenkomen (bv op ssl3) dan krijgt die bezoeker bv een pagina "beste bezoeker, u kunt met deze instellingen onze site niet bezoeken".
Ik verwacht niet dat ssllabs deze intelligentie zal meten en dus ten onrechte een lage score geeft.

[joppybt]

Die offloader is dan wél kwetsbaar. Een kwaadwillende persoon past die pagina dan aan naar 'Beste bezoeker, u kunt met deze instellingen onze site niet bezoeken. Ga naar rabobank.evil.com om velig verder te gaan'

[Mistraller]

Tja, maar dat is nu net niet het idee van een mitm attack. Als je zo wilt aanvallen is verzending van phishing mails volgens mij effectiever.
Ik weet ook niet of het gebruikt wordt, maar ik kan het mij voorstellen dat het omwille van bewustwording ingezet zou kunnen worden.

[Armin]

Die offloader is dan wél kwetsbaar. Een kwaadwillende persoon past die pagina dan aan naar 'Beste bezoeker, u kunt met deze instellingen onze site niet bezoeken. Ga naar rabobank.evil.com om velig verder te gaan'

Er is geen zwakheid in SSL3 die dat toestaat. De POODLE aanval laat enkel achteraf van een gesnifte sessie een cookie te kraken. Geen content-wijzigingen op de server of inbreek op het transmisie kanaal van de client naar server zelf. Dat alles blijft veilig. POODLE is geen real-time aanval.

Het idee van een redirect is dus enkel om geen logins te accepteren over SSL3, zodat bij een eventueel aanval er achteraf niets nuttigs te decoderen is.

[Armin]

Ik verwacht niet dat ssllabs deze intelligentie zal meten en dus ten onrechte een lage score geeft.

Zeer goed punt. Microsoft had bij Azure bijvoorbeeld na de POODLE zwakheid een standaard config gegeven spedciaal voor bedrijven die wel bescherming wilden, maar SSL3 nog niet konden uitzetten ivm oude clients. Zo'n site is 100% beschermt, maar krijgt wel een 'F'.

Met Apache en/of load balancers kun je ook soortgelijke constructies opzetten.

[DDX]

Beetje jammer van de ssllabs.com test is dat als je geen TLS1.1 en TLS1.2 support je meteen een B krijgt.
Servers met RHEL5, Cisco ASA5510 supporten maximaal TLS1.0

[joppybt]

Dan wordt het dus gewoon tijd die server te upgraden. Windows Server 2003 kent ook alleen TLS 1.0. Die moet dan ook maar een grade A krijgen?

[DDX]

Verschil is dat 2003 bijna end of support is, terwijl RHEL5 nog paar jaar supported is.
Geef het een A- zou ik zeggen, het is niet dat TLS1.0 opeens zwaar onveilig is.

[Reactie gewijzigd door DDX op 23 juli 2024 13:36]

[gimbal]

Valse precisie heet dat. Het krijgt nu blijkbaar een B; dat is "net geen A" waar jij met een "A-" wilt gaan doen alsof het "net wel een A" is. Wat wil je daarmee bereiken? In goed overleg kun je gewoon voorlopig genoegen nemen met een B-classificering.

[DDX]

Omdat je nu een TLS1.0 site een B, terwijl een site die SSL3 nog aan heeft staan ook een B krijgt.
Dus of TLS1.0 naar A-, of SSL3 naar C ofzo...

[Blokker_1999]

Zolang een systeem verouderde, maar nog veilige technieken gebruikt zou het een A moeten krijgen daar SSL3 (wat een beveiligingsrisico is) je "slechts" een B opleverd.

[R4gnax]

Verschil is dat 2003 bijna end of support is, terwijl RHEL5 nog paar jaar supported is.
Geef het een A- zou ik zeggen, het is niet dat TLS1.0 opeens zwaar onveilig is.

Sorry? 'Opeens' zwaar onveilig? Heb je ooit van de BEAST aanval gehoord?

De enige reden dat je TLS 1.0 nog 'veilig' kunt gebruiken is omdat browser en OS vendors extra maatregelen buiten het protocol om toegevoegd hebben om extra tegen die aanval te beschermen (of in elk geval de aanval te 'bemoeilijken'). Het protocol zelf is nog steeds lek. Er wordt dus correct de conclusie getrokken dat er een B uitrolt als er via TLS 1.0 verbonden wordt.

[Reactie gewijzigd door R4gnax op 23 juli 2024 13:36]

[Armin]

Er is ook niets inherent mis met een B.

Al mis je dus wel de protocol verbeteringen van 1.1 en de cipher verbeteringen van 1.2. Dat betekend dat de beschermingen die je via die twee zaken inherent zou krijgen, je nu expliciet in de software moet configureren. Bijvoorbeeld TLS 1.0 plus AES CBC kent een BEAST aanval tenzij de client software hier expliciet tegen beschermt. Dat doet alle moderne software, maar TLS 1.1+ is niet kwestbaar ongeacht client-trucjes.

Dus een B is dan ook terrecht. Het is een ruime voldoende mits volledig gepatched, maar je bent niet het beste jongetje/meisje van de klas.

Een website met B is echter gewoon veilig. En dus ook niet minder veilig dan een A+. Dat is iets wat mensen vaak verkeerd begrijpen bij de SSL Labs ratings. Het gaat om het aantal veiligheidsmaatregelen dat gestapeld is.

[MTDjassen]

Interessant dat er zo'n groot verschil zit tussen de Nederlandse en de Belgische sites, je zou denken dat ze van elkaar overnemen/leren. Nederlandse scores:

• Rabobank - B
• SNS - B
• ING - A-
• ABN - B
• ASN - B

Enige bank die tevens in België opereert (ING) scoort in NL het hoogst, en daar een F (!).

[Reactie gewijzigd door MTDjassen op 23 juli 2024 13:36]

[ChessSpider]

En als ik de scan doe op ING krijg ik gewoon een A-

https://www.ssllabs.com/ssltest/analyze.html?d=ing.be

[crowke]

ING heeft "toevallig" vandaag zijn systemen een upgrade gegeven.

‘De veiligheid van de online betaaltransacties is niet in het gedrang gekomen. Bovendien worden vier van de vijf veiligheidsgevoeligheden waarnaar verwezen wordt in recente persartikels (ten laatste) in de loop van deze voormiddag (maandag 16 februari, nvdr) versterkt’, zegt ING België in een reactie op het artikel.

bron: De Standaard

[Armin]

Merk verder op dat SSL Labs enkel de buitenkant kan testen. Aan de binnenkant zijn vaak nog extra veiligheidsmaatregelen.

Voorbeeld: forward secrecy. Als aan de binnenzijde de private key in hardware units zit ipv de servers is forward secrecy niet nodig want is er geen gevaar bij server-hacks dat de keys buitgemaakt zijn. Maar een externe scan kan dat niet zien. Bij een echte officiele certificatie wordt zoiets wel gezien.

Ander voorbeeld is dat de POODLE zwakheid enkel uit te buiten is als naast SSL3 nog aan een aantal andere voorwaarden voldoen is. SSL Labs controleert die andere voorwaarden niet maar geeft wel meteen een 'F'.

Als je echter een echte audit zou doen door Qualys (moederbedrijf van SSL Labs) of ander audit bedrijf kijken ze uiteraard daar wel naar.

Ik ben het er mee eens dat het een beetje slordig is, maar doorgaans is er geen gevaar voor klanten.

[crowke]

Rabobank.be krijgt nochtans A+...

[Dacuuu]

Oudere systemen ondersteunen? Erg fijn. Mag dit ten koste gaan van de veiligheid. Nee! Veiligheid is ht belangrijkste wat er is..

[mzinke]

Winst maken is het belangrijkste dat er is. Als de veiligheid niet op orde is, komt de winst in gevaar. Veiligheid an-sich is niets.

[ATS]

Nee, veiligheid is niet het belangrijkste wat er is. Werkbaarheid is ook belangrijk. Het is altijd een afweging van risico's tegen kosten en werkbaarheid. Als je echt veilig wil zijn, dan kan je beter het hele internetbankieren en apps afschaffen en uitsluitend nog overmakingen doen in persoon in een bankkantoor, waarbij je je persoonlijk komt identificeren en liefst in zo'n klein kantoortje dat de bankmedewerker je ook persoonlijk kent. Maar dat is niet werkbaar en veel te duur, en dus nemen we genoegen met minder veiligheid voor meer gemak.

[Soldaatje]

De meeste banken hebben toch wel TFA, niet dat dat een excuus is, maar het maakt het wel veiliger.
Mijn Argenta bank, heeft dat dus om in te loggen, dat nemen ze niet mee in het onderzoek.

[Reactie gewijzigd door Soldaatje op 23 juli 2024 13:36]

[Blokker_1999]

Niet noodzakelijk. Indien deze rekening houd met bijvoorbeeld het bedrag dat word overgeschreven dan is het nog relatief veilig, maar indien de TFA gewoon een tijdelijke code genereerd zonder verdere parameters van de transactie te kennen blijft het mogelijk om de transactie te onderscheppen en aan te passen.

[verstrooid_prof]

voor zover ik weet (bij Argenta Belgie ten minste):
je moet eerst een random nummer ingeven in de "digipass"
dan moet je een tweede getal ingeven dat bestaat uit een stuk van het bedrag dat je overschrijft, en een stuk van de rekeningnummer naar waar je overschrijft.
Dan pas krijg je random nummer terug dat je moet ingeven in internetbankieren. (en dat wordt dus berekend op basis van bovenstaande gegevens)

Ik spreek over DEZE digipass (bijna elke bank in belgie heeft deze, enkel de opdruk verschilt)
https://www.vasco.com/pro...igipass/digipass_810.aspx

[Blokker_1999]

Er zijn, spijtig genoeg, uitzonderingen zoals Deutsche bank en Rabobank. De 810 werd een tijd bij elke belgische grootbank gebruikt, maar KBC is sinds enkele jaren over op de 836 en maakt daarbij gebruik van de optische scanner om codes door te geven (hoewel je ook manueel codes kunt ingeven).

[Kenhas]

Bij kbc moet je het bedrag ook nog in de kaartlezer intypen om de code te genereren. Dacht wel dat het pas vanaf de huidige versie van de kaartlezer was (met barcode scanner).

Vind het wel opvallend dat je als privaat persoon nog een redelijke beveiliging hebt met de gegenereerde code maar dat KBC for Business steunt op een niet hoofdletter gevoelig paswoord tussen de 6 en 8 karakters.

[biglia]

Is ING geen Nederlandse bank? Ze hebben de slechtste beoordeling:
ING: vulnerable to POODLE attack, SSL3 (insecure), weak signature (SHA1), RC4 (insecure), no Forward Secrecy.

Ook Ogone, geen bank, maar is wel kwetsbaar:
weak signature (SHA1), RC4, vulnerable to POODLE, no Forward Secrecy

Van het lijstje moet je wel toegeven dat je van sommige banken nog nooit hebt gehoord. Het zijn vooral die banken die zwak scoren.

[YopY]

Is ING geen Nederlandse bank? Ze hebben de slechtste beoordeling:

Ja, soort van (volgens mij is het officieel een multinational), echter het probleem hier is dat het IT systeem / de websites niet allemaal centraal zijn, dwz Belgie heeft blijkbaar zijn eigen IT organisatie.

[Blokker_1999]

Dat is met vele multinationals zo. De lokale entiteite functioneren grotendeels onafhankelijk, hebben een eigen infrastructuur, eigen managment, eigen boekhouding, ...

[Helixes]

En eigen toezicht.

Natuurlijk is het aan de banken om toe te zien op de beveiliging van hun internetbankieren, en aan investors om er op toe te zien dat er geen risico's op verlies ontstaan door slechte beveiliging.

Maar volgens mij is er ook een rol voor de toezichthouder weggelegd: zij moeten het algemeen belang dienen en eisen dat het internetbankieren zoals aangeboden veilig (genoeg) is. Ik weet dat De Nederlandse Bank altijd streng heeft toegezien op het naleven van die eisen voor banken met een Nederlandse bankvergunning.

Ik kan me voorstellen dat de Nationale Bank van België, of wie dan ook het toezicht mag houden, dat in het verleden minder rigoreus heeft gedaan. Als dit artikel een aanklacht is, lijkt het me voornamelijk een aanklacht tegen dat toezicht.

[CAPSLOCK2000]

Als ze al zo slecht om gaan met SSL, hoe erg is het dan wel niet met de rest van de systemen?
SSL goed regelen is nu ook weer niet zo moeilijk. Iedere fatsoenlijke IT'er zou dat moeten kunnen.

Ook bij die banken moeten mensen werken die daar geen probleem mee hebben. Ik denk dat er ofwel verouderde "beveilings"-appliances worden gebruikt en ze geen geld krijgen voor nieuwe, ofwel dat ze van de baas niet mogen upgraden om geen XP/IE6-klanten te verliezen.

Zelfs wanneer je het zelf niet snapt is er op internet voldoende informatie te vinden om het toch goed te doen.

Als ze de makkelijke problemen al niet oplossen dan vraag ik me af hoe ze met de moeilijke problemen om gaan.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 13:36]

[Blokker_1999]

Inderdaad, begin deze maand nog enkele certificaten geïnstalleerd, viavia uitgekomen bij SSL labs en met hun rating en opmerkingen aan de slag gegaan om enkele uren later netjes een A rating te hebben.

[Anoniem: 651216]

Per toeval zit ik zowel bij ING Belgie als ING Nederland. Heb daar wat kennissen zitten, en ook na wat rondvragen lijkt het er op dat het een compleet apart concern is om het zo uit te drukken. Logisch dus dat de ratings ook verschillen. Goed? Absoluut niet, ik begin te twijfelen of ik nog wel wil e-bankieren met de Belgische tak.

Moet wel zeggen dat het gevoelsmatig wel iets veiliger voelt t.o.v. ING Nederland qua inloggen.
In Belgie heb je naast je ID + Password ook nog een random reader nog, in Nederland hoeft dit totaal niet. Simpel keyloggertje op je PC en daar gaat je rekening.

^ Ik hou rekening met de TAN-Codes in NL, maar het is ontzettend makkelijk om je mobiel nummer te ontkoppelen via de site.

[Armin]

in Nederland hoeft dit totaal niet

ING Nederland heeft bij mijn weten ook al 10+ jaar een 2e factor als authenticatie. Vroeger van die lastige TAN codes, nu bijvoorbeeld SMS. Zo log ik al jaren in tenminste

[Anoniem: 651216]

Ik heb nog steeds TAN codes als ik een overboeking wil doen hoor. (Via SMS, als dat is wat je bedoelt?)
Mijn punt qua ING Nederland is dat als je mobiel bankieren gebruikt, je via de website je mobiel kan koppelen. Maar het is ontzettend simpel om het toestel te ontkoppelen, en een andere eraan te koppelen als je eenmaal bent ingelogd in het account.

Voor gewoon inloggen op je rekening op de website voldoet het om een ID + password te verstrekken. Heb het nagevraagd, m'n vriendin heeft exact hetzelfde.

[stx]

Komt dit nu aan het licht, omdat de meeste browser makers de oude SSL certificeringen standaard zijn gaan blokkeren?

[Blokker_1999]

Nee, dit komt aan het licht omdat iemand zich afvroeg hoe goed deze sites op die test zouden scoren.

Het resultaat is evenwel enorm bedroevend en teleurstellend.