Computerbeveiliging - Hoe je bad guys buiten de deur houdt

Inloggen bij Polismap verzekeraar met 4-cijferige pincode veilig?

14-02-2024, 17:29 door Weaver, 6 reacties
Laatst werd ik door mijn verzekeringstussenpersoon op de hoogte gesteld van een nieuwe service: inzicht in mijn polis informatie via een app en webapplicatie. Inloggen gaat middels het mail adres dat bij de tussenpersoon bekend is en een 4-cijferige pincode die zelf te kiezen is.

De tussenpersoon zegt dat er niets aan de hand is aangezien er na 3 foutieve pogingen het mailadres geblokkeerd zou worden.

Nu ben ik zeker geen CS expert maar iets zegt mij dat dit niet de soort beveiliging is die je voor de bescherming van dergelijke informatie zou verwachten.

Wat is jullie kijk hierop?
Reacties (6)
14-02-2024, 17:51 door MathFox
Zo op het eerste gehoor klinkt het als "onvoldoende beveiliging". Tegenwoordig wordt een wachtwoord van minstens acht (willekeurig te kiezen) tekens aangeraden om toegang tot normale persoonsgegevens te beschermen. Als het via de app/webapp ook mogelijk is om financiële zaken aan te passen dan zou ik een of andere vorm van twee factor authenticatie verwachten.
14-02-2024, 18:57 door Anoniem
Tijd om een andere tussenpersoon te zoeken.
14-02-2024, 19:55 door Anoniem
Door Anoniem: Tijd om een andere tussenpersoon te zoeken.

Tijd voor een andere verzekeringsmaatschappij.
15-02-2024, 00:43 door Erik van Straten
Door Weaver: De tussenpersoon zegt dat er niets aan de hand is aangezien er na 3 foutieve pogingen het mailadres geblokkeerd zou worden.
Een nieuw account en dan zo'n vraag: het klinkt alsof je zelf een verzekeraar, tussenpersoon of student cybersecurity bent. Anyway, laat ik eens filosoferen (als je student bent steek je er mogelijk iets van op ;-)

Om te beginnen, lees dit: https://www.security.nl/posting/829288/Franse+huizensite+Pap_fr+krijgt+boete+voor+plaintext+opslag+wachtwoorden.

Daarna moet je snappen dat het nauwelijks tot niet mogelijk is om een eenweg-afgeleide van een pincode te berekenen die niet weer omgezet kan worden in de oorspronkelijke pincode, zelfs niet met de zwaarste Argon2. Met andere woorden: wat je ook doet, wat je als afgeleide van een 4-cijferige pincode opslaat is effectief net zo toegankelijk als de plain-text versie daarvan.

Gevolg: klanten die pincodes (en/of wachtwoorden) hergebruiken lopen grote risico's - groter naarmate het totale aantal mogelijke combinaties van cijfers in de pincode (of bij het wachtwoord, de toegestane alfanumerieke en leestekens) kleiner is.

Meer info: https://tweakers.net/nieuws/217734/easypark-bij-cyberaanval-zijn-ook-gehashte-wachtwoorden-gestolen.html?showReaction=19528434#r_19528434.

Maar stel dat je zou weten dat de AP het zó druk heeft dat de kans dat jij (de inzetter van dit systeem) gepakt wordt, ongeveer nul is.

In elk geval hangt het er dan vanaf welke schade een aanvaller met toegang tot het account van een klant zou kunnen aanrichten. Als zich dat beperkt tot het inzien van een polis, zonder dat daar al te veel risicovolle persoonsgegevens op te vinden zijn (vooral van het type dat phishing zouden kunnen vereenvoudigen, zoals geboortedatum, telefoonnummer en/of een ander e-mailadres dan waar de klant mee inlogt), dan is het risico voor klanten relatief klein, en dus ook het motief voor de meeste aanvallers (tenzij zij uit zijn op afpersing en/of het toebrengen van imagoschade, maar dan moeten zij wel véél accounts kunnen hacken).

In dat geval (laag risico voor klanten): als het dan écht zo is dat het het account, gekoppeld aan het e-mailadres van de klant, voor onbeperkte tijd wordt geblokkeerd, lijkt het mij niet meteen onredelijk {1} - mits elke pincode willekeurig gegenereerd wordt door de server, en de klant, na een "pincode-vergeten" redding, een nieuwe door de server gegenereerde random pincode krijgt (zodat een brute-force aanvaller opnieuw moet beginnen). Echter, als de aanvaller een pincode toevallig toch weet te raden, en de klant die pincode hergebruikt (in die gevallen dat servers dat toestaan), speelt het eerdergenoemde risico voor de klant (e-mailadres + pincode gelekt).

{1} De pincode van een bankpas bestaat ook maar uit 4 cijfers, maar die pas moet je (sinds er een chip in zit, de oude magneetstrip kon eevoudig gekopieerd worden) wel in handen hebben - een extra authenticatie-factor dus.

Nb. indien de klant de pincode zelf mag verzinnen, bestaat deze in mogelijk meer dan de helft van de gevallen (gokje) uit de 4 cijfers van de postcode van de klant. Daarna vaak een deel van de geboortedatum, dus uit "dd-mm-eejj" (voorbeeld: 31-12-1999) bijvoorbeeld "ddmm" of "mmjj". M.i. is, in dit geval, de "raadkans" door een aanvaller onacceptabel groot.

Als de blokkade tijdelijk is, is het ook onacceptabel, omdat er dan een langezame brute force aanval uitgevoerd kan worden (indien de aanvaller het e-mailadres van een klant kent, maar daar moet je altijd vanuit gaan).

Een ander punt is: wat gebeurt er na een blokkade (na een brute force aanval, of als de klant diens pincode is vergeten en gaat gokken)? Als de klant dan een "pincode-reset" moet uitvoeren, meestal via e-mail, dan is dat verzekerings-account sowieso niet veiliger dan de beveiling van het e-mailaccount van die klant.

Nb. ik ken mensen die, vooral bij zelden gebruikte accounts, bij inloggen altijd een wachtwoord-reset doen en dan een nieuw willekeurig lang wachtwoord invoeren - dat zij niet onthouden (het voelt niet goed, maar eigenlijk heb ik geen sterk argument hiertegen, iemand?).

Omdat je waarschijnlijk niet elke dag polissen bekijkt, zou de verzekeraar dus, in plaats met zo'n sowieso vaak vergeten pincode te rommelen, ervoor kunnen kiezen om klanten altijd via hun e-mail in te laten loggen.

Aan de ene kant bij grote voorkeur door de klant een link (met een lange cryptografische random gegenereerde identifier, zoals in {2} te zien is) te mailen waar die klant op moet klikken. Voordeel: dat voorkómt de meeste vormen van phishing (met een lijkt-op website met een (iets) afwijkende domeinnaam - omdat in dit geval de juiste domeinnaam in de link zit). Aan de andere kant is het klikken op links in mails juist iets dat andere risico's introduceert, en je mensen wellicht niet zou moeten aanleren.

{2} https://example.com/login/06614652-d06f-f5ad-99b0-22fd16546658

In elk geval hoeft de klant dan niets extra's voor toegang tot polissen te onthouden, en wordt voorkomen dat, mocht een aanvaller de e-mail adressen van veel klanten in handen krijgen, die aanvaller een pincode kiest (zoals 6294) en die uitprobeert op alle e-mail adressen.

Meer info over password-spraying: https://tweakers.net/nieuws/217782/microsoft-russische-staatshackers-hadden-toegang-tot-e-mailaccounts-managers.html?showReaction=19532960#r_19532960.

De kans is niet verwaarloosbaar dat zo'n aanval niet wordt opgemerkt, vooral niet als de aanvaller tussen pogingen door een wachtpauze van bijv. enkele minuten inlast. De kans dat jouw klant-account wordt gehacked is dan klein, maar de kans dat de aanvaller één of meer willekeurige klant-accounts hackt is groter naarmate de verzekeraar meer klanten heeft en de aanvaller daar meer e-mailadressen van kent. In elk geval om deze reden is een pincode ook vaak een slecht idee.

Helaas is het de praktijk dat, vergroot bij MFA, mensen inloggegevens vergeten en/of kwijtraken.

Als de "oplossing" daarvoor een wachtwoord- (of pincode) reset is uitsluitend via e-mail, is er al geen sprake meer van MFA. Immers, een aanvaller die toegang verkrijgt tot de inbox van de klant, kan meestal veel accounts van die klant overnemen (beveilig in elk geval jouw e-mail account zo sterk als realistisch mogelijk is - wat sowieso lastig is als bijv. een e-mail app/programma jouw IMAP-wachtwoord, of jouw browser jouw webmail-wachtwoord, "voor jou onthoudt").

Het wordt al heel een stuk veiliger als de klant, om in te loggen, na om een mail-met-link te hebben gevraagd en op die link te hebben geklikt, vervolgens óók een (server-gegenereerde) pincode moet invoeren.

Maar als een klant die pincode vergeet, hebben de klant en de verzekeraar alsnog een probleem: hoe kan de verzekeraar vaststellen dat degene die wil inloggen, echt de klant is en niet een aanvaller? Daar mag de lezer zelf een oplossing voor proberen te bedenken :-)

(Tip: https://security.nl/posting/827137).
15-02-2024, 10:17 door Weaver
Door Erik van Straten:
Door Weaver: De tussenpersoon zegt dat er niets aan de hand is aangezien er na 3 foutieve pogingen het mailadres geblokkeerd zou worden.
Een nieuw account en dan zo'n vraag: het klinkt alsof je zelf een verzekeraar, tussenpersoon of student cybersecurity bent. Anyway, laat ik eens filosoferen (als je student bent steek je er mogelijk iets van op ;-))

Haha ben oprecht gewoon een bezorgde burger en cybersecurity enthousiasteling, maar spichtigheid is altijd goed toch? ;)

Dank in elk geval voor het uitgebreide antwoord; lees voer waar ik wat mee kan.
Zal het bij mijn tussenpersoon onder de aandacht brengen, benieuwd wat ze er mee doen…
15-02-2024, 12:05 door Anoniem
Bij FBTO moet je een account activeren (aangemaakt hebben zij al voor je gedaan) wil je jouw polis ontvangen. Wil je ook nog jouw zorgpas hebben, dan moet je hun app downloaden.
Op verzoek om de polis per mail toe te sturen (dat kon echt alleen maar via de site), het account verwijderen en natuurlijk de verzekering te beëindigen (dan vergeet je dat niet) krijg je geen enkele reactie. Wel worden er gegevens van je aan OpinionBar verstrekt (toestemming?) voor deelname aan een vragenlijst hoe jij het contact ervaren hebt.

Ligt dit nu echt aan mij dat ik dit allemaal geen gang van zaken vind?
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.