Miljoenenboete voor gebruik SHA-256, trackingcookies en delen van klantdata
De Franse privacytoezichthouder CNIL heeft een niet nader genoemd bedrijf een boete van 3,5 miljoen euro opgelegd wegens het gebruik van het SHA-256 hashing-algoritme, het zonder toestemming plaatsen van trackingcookies, het toestaan van zwakke wachtwoorden en het delen van klantgegevens met een socialmediaplatform. Het bedrijf in kwestie heeft een loyaliteitsprogramma met ruim tien miljoen leden in Frankrijk, meer dan tweehonderd duizend in België en ook duizenden leden in andere Europese landen.
Volgens CNIL heeft het bedrijf op meerdere punten de AVG overtreden. Wanneer deelnemers aan het loyaliteitsprogramma lieten weten dat ze reclame via e-mail of sms wilden ontvangen werden hun persoonlijke gegevens gedeeld met een socialmediaplatform. Het bedrijf liet deze gegevens gebruiken voor gerichte advertenties op het platform. Klanten werden echter niet ingelicht over de datadoorgifte of het doel hiervan, wat wel had gemoeten, aldus de toezichthouder. Daarnaast had het bedrijf geen data protection impact assessment (DPIA) voor deze gegevensverwerking uitgevoerd.
Het bedrijf ging ook de fout in met de regels voor de sterkte voor wachtwoorden. Die waren volgens CNIL niet robuust genoeg, waardoor gebruikers zwakke wachtwoorden konden maken. Daarnaast gebruikte het bedrijf het SHA-256-hashing-algoritme in combinatie met een salt voor de opslag van wachtwoorden. Iets dat geen veilige methode voor de opslag van wachtwoorden is, aldus de Franse toezichthouder. Inmiddels maakt het bedrijf gebruik van het Argon2-algoritme voor het hashen van wachtwoorden.
Het laatste kritiekpunt betreft het plaatsen van trackingcookies. Bij alleen het bezoeken van de website van het bedrijf werden al elf trackingcookies geplaatst, nog voordat het cookievenster met de toestemmingsvraag hiervoor was verschenen. Wanneer gebruikers trackingcookies weigerden werden de elf al geplaatste cookies niet verwijderd. Het bedrijf bleef deze cookies in strijd met wetgeving ook nog gewoon uitlezen.
En als jouw wachtwoord manager genoeg entropie toevoegt is SHA-256 geen enkel risico natuurlijk.
Een boete is dan eigenlijk wel terecht, vind ik...
Een boete intereseert ze niet die halen ze in de klant via marge wel op termijn terug. Klant verlies door PR disaster echter en ineens wordt hemel en aarde bewogen voor schare inperking.
Het probleem met deze hash functie is dat het gewoon te snel is wat het kraken van wachtwoorden te makkelijk maakt.
Een 8 karakter lang wachtwoord kan binnen een dag gekraakt worden op een (high-end) consumenten GPU.
Gebruik je bcrypt als hash methode, dan zou dat voor hetzelfde wachtwoord bijna 2000 jaar duren.
Als aanvallers de database lekken zullen ze proberen de wachtwoorden te achterhalen om die te kunnen misbruiken.
Een tragere hash methode maak dit een stuk lastiger. Ook maakt het de database een minder aantrekkelijk doelwit.
Als iedereen 32 willekeurige tekens zou gebruiken voor wachtwoord, dan is SHA-256 wel een redelijke optie.
Maar mensen kiezen helaas simpele wachtwoorden zoals "Password123!" waarvan het kraken minutenwerk is.
Ja het is onveilig in combinatie met een te korte minimumlengte, maar bcrypt is ook niet veilig met een minimumlengte van 1 of 3 chars.
De CNIL stelde vast dat de regels voor de complexiteit van gebruikersaccountwachtwoorden niet robuust genoeg waren.
Daarnaast herinnerde de beperkte commissie eraan dat de functie van SHA-256 geen veilige opslag van wachtwoorden toestond."
Voor die wachtwoordregels hebben we de ISO 27k, en als wachtwoordhash Argon2id:
https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
BCrypt is legacy en dient uitgefaseerd te worden.
Om juridische problemen te voorkomen.
De CNIL stelde vast dat de regels voor de complexiteit van gebruikersaccountwachtwoorden niet robuust genoeg waren.
Daarnaast herinnerde de beperkte commissie eraan dat de functie van SHA-256 geen veilige opslag van wachtwoorden toestond."
Voor die wachtwoordregels hebben we de ISO 27k, en als wachtwoordhash Argon2id:
https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
BCrypt is legacy en dient uitgefaseerd te worden.
+1
Als Argon2id geen optie is heeft Scrypt de voorkeur over Bcrypt.
Nieuwe NIST richtlijnen maar deze gaan niet in op password hasing algorithms best practices, maar stelt wel dat minimaal 12 character het minumum zou mogen zijn: https://pages.nist.gov/800-63-4/sp800-63b.html
Voor passwoordhashing is dit niet meer een veilige standaard. Afhankelijk van het aantal characters zijn deze wachtwoorden (te) snel te kraken. Als iedereen netjes een wachtwoord van 21 tekens en deze uniek voor elk account zou gebruiken met was het een ander verhaal.
Zie de OWASP cheatcheat voor bestpractices (hierboven vermeld)
Dit in tegenstelling tot pepper, een string die voor alle wachtwoorden wordt gebruikt en daarom geheim moet blijven,
https://en.wikipedia.org/wiki/Salt_(cryptography)
https://en.wikipedia.org/wiki/Pepper_(cryptography)
Als je het echt goed wilt doen, gebruik je salt & pepper.
Om juridische problemen te voorkomen.
Het was eigenlijk een retorische vraag en/of enigszins cynisch bedoeld, maar toch dank voor de reactie.
Juist de juridische problemen zouden ervoor moeten zorgen dat het niet meer gebeurt. Dat ze zich eens even achter de oren krabben en eerlijkere verdienmodellen zullen gaan hanteren in het belang van iedereen.
Je bent niet ingelogd 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.
(Senior) Informatie Beveiligingsadviseur - CISO Office
Ministerie van Binnenlandse Zaken en Koninkrijksrelaties
Wil jij je op strategisch niveau bezighouden met de beveiliging van informatie waar niets mee fout mag gaan? Wij geven jou volop gelegenheid om samen met deskundige collega’s te werken aan beleid, procedures, advies, risicomanagement, metrics en projecten rond informatiebeveiliging.
Wij zoeken een Junior DevOps Engineer!
Ben jij nieuwsgierig, leergierig en klaar om je te verdiepen in de wereld van DevOps? In deze functie krijg je alle ruimte om te groeien. Je werkt met de nieuwste technologieën en krijgt intensieve begeleiding van ervaren security professionals zodat je je in korte tijd kunt ontwikkelen tot een volwaardige DevOps Engineer. Je werkt in Den Haag en werkt samen met een team dat kennis, humor en uitdaging moeiteloos weet te combineren. Are you ready for a challenge?