Duits bedrijf krijgt boete wegens opslaan wachtwoorden in platte tekst

Een Duitse aanbieder van een socialmediadienst heeft een boete van 20.000 euro opgelegd gekregen omdat na een datalek bleek dat de wachtwoorden ongecodeerd opgeslagen waren geweest.

Het bedrijf nam op 8 september contact op met de LfDI, de Landesbeauftragte für den Datenschutz und die Informationsfreiheit Baden-Württemberg, om een datalek te melden. Bij een aanval in juli, waren de persoonsgegevens van 330.000 gebruikers gestolen, waaronder wachtwoorden en e-mailadressen. Volgens Der Spiegel gaat het om het chatplatform Knuddels en werden 808.000 mailadressen en 1,8 miljoen gebruikersnamen ontvreemd. In totaal zou Knuddels 1,2 miljoen unieke gebruikers hebben.

Nadat Knuddels de details over de hack en zijn infrastructuur overhandigde, constateerde de databeschermingsautoriteit LfDI dat het platform de wachtwoorden van zijn gebruikers in klare tekst, dus ongecodeerd, had opgeslagen. Het bedrijf zou de wachtwoorden in platte tekst gebruiken voor een 'wachtwoordfilter' dat moest voorkomen dat deze in handen zouden komen van onbevoegden, schrijft de LfDI.

Door de wachtwoorden onveilig op te slaan, heeft het bedrijf volgens de autoriteit artikel 32, lid 1 van de AVG geschonden, dat stelt dat gegevensverwerkers passende technische maatregelen moeten nemen 'om een op het risico afgestemd beveiligingsniveau te waarborgen', waaronder via pseudonimisering en versleuteling van persoonsgegevens. Inmiddels zou de dienst maatregelen hebben genomen om zijn it-beveiligingsinfrastructuur op orde te brengen. Bij het bepalen van de hoogte van de boete is rekening gehouden met de totale kosten voor het bedrijf, die een niet nader genoemd bedrag van zes cijfers zou beslaan.

Reacties (162)

Nu is de vraag of slechte hashing algoritmes zoals md5 hetzelfde worden gezien als platte tekst, wat het in de praktijk wel is. Zo ja dan ken ik nog wel een aantal bedrijven in Nederland.

MD5 is per definitie onomkeerbaar, dus nee dat is zeker niet hetzelfde als platte tekst.
Dit los van het feit dat MD5 wel onveilig is natuurlijk, want een pre-image attack op MD5 is kinderspel.

Dat wil zeggen als de MD5 van mijn password op een of andere website staat opgeslagen als 7d0d0cc0945d76779be6a003fa98bec9 is het erg simpel om een password te vinden met die hash, maar mijn password zul je zeker niet achterhalen. En dat maakt wel uit, want op die ene site kun je dan mijn account misbruiken, maar als ik hetzelfde password ook op andere sites heb gebruikt (wat sowieso niet slim is, maar dat terzijde) kun je daar nog steeds niets mee.

Jaja, probeer dit dan maar eens:
https://hashkiller.co.uk/md5-decrypter.aspx

Bijvoorbeeld: 288116504F5E303E4BE4FF1765B81F5D

Wat @Jace / TBL klopt gewoon. Die MD5 site die jij zoekt heeft gewoon miljarden woorden/wachtwoorden omgezet naar MD5 en dat opgeslagen. Dus MD5 is onomkeerbaar enkel wel te genereren.

Het gevaar wat @Jace / TBL aanhaalt is (volgens mij) dat het mogelijk is om met een ander wachtwoord dan de zijne op zijn account in te loggen zodra de website gebruik maakt van MD5 omdat het bij MD5 mogelijk is dat er meerdere wachtwoord variaties op eenzelfde MD5 hash uitkomen. Dus dat wanneer ze op zijn account inloggen alsnog niet zijn echte wachtwoord hoeven te weten.

Dus stel:
wachtwoord1 -> abcdefghijklmnopqrstuvwxy
wachtwoord2 -> abcdefghijklmnopqrstuvwxy

Dus stel dat jouw wachtwoord wachtwoord1 is en men vindt bij een lek de hash en halen hem door die site van jou. Dan zijn ze in staat om met wachtwoord2 ook in te loggen op die site. Enkel als jij bij een andere site ook wachtwoord1 hebt maar die maken geen gebruik van MD5 zijn ze daar niet in staat in te loggen met wachtwoord2. Zodra ze een plain wachtwoord opslaan weten ze wel direct dat het "wachtwoord1" is.

Sorry hoor, als je zegt "is per definitie niet omkeerbaar" en er is een site waar je menig wachtwoord al meteen kan decrypten, dan klopt dat gewoon niet.

Het is niet "decrypten". MD5 is namelijk geen encryptie, maar hashing. Dat is per definitie een one-way functie.

Kijk, deze hash kun je bijvoorbeeld niet "decrypten": 827ccb0eea8a706c4c34a16891f84e7b
Als je die op die site invult, komt er "12345" uit, maar dat is fout. Dat was niet mijn input. Dat is een andere input die toevallig ook die hash heeft.

Als je ook nog eens een Nederlands woordenboek gebruikt om de wachtwoorden langs te leggen wordt de kans nog groter dat je het wachtwoord decrypt.

Ook dat is niet het password decrypten, maar gewoon veel pogingen doen om het password te raden (wat alleen kans van slagen heeft als je een slecht password gebruikt).

Natuurlijk zijn in principe oneindig veel strings die op die hash uitkomen, maar als je wachtwoord restricties of database restricties meeneemt zal dat in de praktijk vaak maar 1 of enkele mogelijkheden geven.

Nee, ook dan zijn er ontzagwekkend veel mogelijkheden. Als je bijvoorbeeld met 'wachtwoord of database restricties' bedoelt dat passwords hoogstens 50 tekens lang mogen zijn en alleen alfanumerieke tekens mogen bevatten (wat al een vrij debiele beperking is, maar stel) dan zijn dat 62⁵⁰ = ruim 2²⁹⁷ mogelijkheden. Dus voor een willekeurige md5 hash (van 128 bit) zijn er dan gemiddeld 2^297-128 = 2¹⁶⁹ mogelijke passwords die allemaal diezelfde hash hebben. Dat zou ik niet "enkele" noemen.

Dat het doel van md5 hashing is betekent niet dat het niet gedecrypt kan worden. Waarom denk je dat er zoveel sites zijn die letterlijk zeggen dat ze 'md5 decrypten'.

Omdat die sites waarschijnlijk dezelfde denkfout maken als jij, of omdat het woord gewoon lekker klinkt. 'Decrypten' insinueert dat er iets 'encrypted' is en dat is niet het geval. Er is geen cryptografische sleutel en geen ontsleuteling waarmee je met 100% waarschijnlijkheid het juiste wachtwoord kunt achterhalen, tenzij de password restricties op het bizarre af zijn (max 8 karakters en alleen namen van personages uit Dexters Laboratory toegestaan bijvoorbeeld).

Hoe noem jij het als je van een md5 hash weer een leesbaar paswoord maakt, iets wat volgens Jace zelfs niet kan?

Nu maak jij er een taalkundig vraagstuk van. Maar goed, ik zou het "uitvogelen" noemen.

Er is natuurlijk altijd een kans groter dan 0% dat je een password gewoon raadt.

Je kunt vanuit een hash (md5 of sha512 of wat voor hash dan ook) nooit weer een leesbaar password halen, want die informatie zit er domweg niet in. Hashen is per definitie een destructief proces. Het resultaat van een hash is betekenisloze ruis. Alleen omdat dat destructieve proces deterministisch is, krijg je bij dezelfde input, ook dezelfde ruis.

Als je een hash hebt en je weet een (let op, ik zeg een en niet het) password te vinden wat die hash oplevert, weet je niet of dat het echte password was. Want er zijn nog oneindig veel andere passwords die ook allemaal die hash opleveren.

Geprobeerd.

Ik heb daar 10 passwords van mezelf ingevuld, hij vindt er nul.

Ik heb het ook geprobeerd met 10 random passwords van slechts 8 alfanumerieke karakters, ook daarvan vindt hij er nul (wat trouwens slecht is want met fatsoenlijke rainbow tables had hij die nog wel kunnen vinden).

En dat is dan nog slechts md5. Kun je nagaan als men sha256 gebruikt, of sha512 of sha3. En dan hebben we het nog niet eens over salt of hmac.

Dat hij de hash van een voor de hand liggende string als "Welkom01" kent zegt niets. Dat is zo'n algemene kreet die je zo met elke dictionary attack pakt, dat zegt niks over de zwakte van md5 maar over de zwakte van dat wachtwoord.

Hoe kom jij aan mijn wachtwoord?

Nu is de vraag of slechte hashing algoritmes zoals md5 hetzelfde worden gezien als platte tekst, wat het in de praktijk wel is.

In wetgeving zal er wel iets staan van 'adequate bescherming'. Aangezien wachtwoorden opgeslagen als MD5 hash van veel gebruikers in korte tijd via brute force verkregen kan worden zal dat waarschijnlijk niet als voldoende beschouwd worden.

Let wel op dat niet alle wachtwoorden in MD5 zo gekraakt zijn. Zo had T.net ook ooit enkel MD5, en zij konden 'slechts' de helft van alle wachtwoorden achterhalen. Nu is het enkel een kwestie van tijd voordat dit bijvoorbeeld 95% wordt, maar het is geen 100% garantie.

Implementeer liever een schema specifiek gemaakt om wachtwoorden veilig in op te slaan. PBKDF2 of nog beter, Argon2id.

[Reactie gewijzigd door The Zep Man op 22 november 2018 20:41]

Dat is een aanname. Er kan net zo goed staan 'ongecodeerd' oid.

Gelukkig waren de wetgevers in dit geval niet zo dom om zo specifieke termen te gebruiken. De letterlijke (nederlandse) tekst van artikel 32, lid 1:

Rekening houdend met de stand van de techniek, de uitvoeringskosten, alsook met de aard, de omvang, de context en de verwerkingsdoeleinden en de qua waarschijnlijkheid en ernst uiteenlopende risico's voor de rechten en vrijheden van personen, treffen de verwerkingsverantwoordelijke en de verwerker passende technische en organisatorische maatregelen om een op het risico afgestemd beveiligingsniveau te waarborgen, die, waar passend, onder meer het volgende omvatten:

a) de pseudonimisering en versleuteling van persoonsgegevens;

b) het vermogen om op permanente basis de vertrouwelijkheid, integriteit, beschikbaarheid en veerkracht van de verwerkingssystemen en diensten te garanderen;
c) het vermogen om bij een fysiek of technisch incident de beschikbaarheid van en de toegang tot de persoonsgegevens tijdig te herstellen;
d) een procedure voor het op gezette tijdstippen testen, beoordelen en evalueren van de doeltreffendheid van de technische en organisatorische maatregelen ter beveiliging van de verwerking.

Zoals je ziet staan hier nergens specifieke termen in van HOE zaken uitgevoerd moeten worden. Dat is ook niet mogelijk omdat best practices continue veranderen. Wat er staat is waar de genomen maatregelen aan moeten voldoen. Dat is veel beter. En zoals je ook ziet staat er ook dat je verplicht bent je beveiliging "op gezette tijden" te herevalueren/testen. Dus achterhaalde technieken uit bv. 2010 gebruiken in 2018 zal echt niet door de beugel kunnen.

Het is inderdaad een aanname, maar die was natuurlijk wel gewoon te controleren. De AVG mag vziw namelijk niet in landelijke wetgeving afgezwakt worden. En de link in het artikel heeft deze Nederlandse versie van de tekst:

Rekening houdend met de stand van de techniek, de uitvoeringskosten, alsook met de aard, de omvang, de context en de verwerkingsdoeleinden en de qua waarschijnlijkheid en ernst uiteenlopende risico's voor de rechten en vrijheden van personen, treffen de verwerkingsverantwoordelijke en de verwerker passende technische en organisatorische maatregelen om een op het risico afgestemd beveiligingsniveau te waarborgen, die, waar passend, onder meer het volgende omvatten:

Het is - vast expres - extreem open geformuleerd, maar moderne wachtwoordversleuteling (bijvoorbeeld via de genoemde pbkdf2 of argon2i of via bcrypt/scrypt) is natuurlijk wel iets wat algemeen beschouwd wordt als een passende technische maatregel voor de specifieke persoonsgegevens (wachtwoorden).

[Reactie gewijzigd door ACM op 22 november 2018 21:01]

Het blijft natuurlijk gewoon hashing en is te brute forcen. Een wachtwoord is eigenlijk nooit veilig op te slaan en altijd te achterhalen. Is het dan adequaat? Ik zeg niet: gebruik allemaal MD5 of SHA1 (beide relatief snel te brute forcen met moderne hardware), maar pbkdf2 kun je ook brute forcen en is, afhankelijk van hoeveel rounds je doet, een factor 4 meer werk. Met zo'n grote database als in deze hack kun je gewoon een beetje met hagel schieten en je vind vast wel een paar wachtwoorden. Ben je dan ook strafbaar want je had het nog anders moeten doen?

Het blijft natuurlijk gewoon hashing en is te brute forcen.

Als men een veilig algoritme pakt (zeg HMAC-SHA256), voldoende rounds (orde > 10^5) is PBKDF2 niet in reeele tijd (leeftijd universum), inclusief speedups, te bruteforcen. Om speedups alsnog voor te zijn is password rotation aangeraden en kan door de beveiliger worden afgedwongen.

Dit beschermt overigens nooit tegen zwakke wachtwoorden door middel van dictionary attacks

[Reactie gewijzigd door kaas-schaaf op 23 november 2018 00:16]

Uh, mijn info over PBKDF2 geeft andere getallen. Ja, meer werk dan een sha-1, maar met gpu of Asics zeker haalbaar, tenzij je je paswoorden erg lang gaat maken. Maar als je 16+ karakters als lengte gaat afdwingen dan ben je zo een reeks gebruikers kwijt.

Nou ja, met 256-bitsencryptie met een beetje redelijk wachtwoord (8 tekens of langer en een forcering dat bv niet de gebruikersnaam en sitenaam in het wachtwoord mogen voorkomen) zal een gemiddelde brute-forceaanvaller nog een aardig tijdje zoet zijn. Als je nog op 64-bits encryptie zit of slechter, dan vraag je er ook om, maar het gemiddelde botnetwerk heeft nog een flinke kluif aan het verwerken van een 256-bit encrypted wachtwoord, en ook de stevigere 128-bit encrypted wachtwoorden zijn gewoon de moeite niet waard.

Wachtwoorden worden niet ge-encrypt maar gehashed. Voor brute-forcen zijn 2 factoren van belang: lengte van het wachtwoord en de mogelijke karakters (entropie) en de snelheid waarmee je kunt hashen. Of de hash 64 bits is of 1024 bits maakt niets uit. Wat PBKDF2 (en scrypt) moeilijk maakt is de snelheid van het algoritme: je kunt ze lastiger snel berekenen. Als je SHA-2 doet (of SHA-512) ben je alsnog de klos: die doe je in hardware triviaal ook al zijn het megaveel bits.
Aangezien mensen een hekel hebben aan wachtwoord policies (16 karakters, met minimaal 7 leestekens oid) kun je aan die knop nauwelijks draaien. Blijft over de snelheid van het algoritme. Maar dat is een wapenwedloop: wat nu moeilijk is (lees: geen GPU algoritme of ASIC voor) is morgen triviaal (zie PBKDF2).

pbkdf2 kan je uiteraard brute forcen, en de rest ook. Vziw wordt pbkdf2 nog altijd als "goed genoeg als je het al gebruikt" gezien, mits je het uiteraard goed gebruikt.
Hoe kom je erbij dat pbkdf2 slechts 4x zoveel werk is? De laatste aanbeveling die ik heb gezien bevatte 10.000 iteraties (en oudere geloof ik 1000-200).

Maar los daarvan: je bent normaliter niet verantwoordelijk voor slecht gekozen wachtwoorden, maar het kan zijn dat voor specifieke situaties andere eisen kunnen gelden. Die zullen dan waarschijnlijk niet vanuit de privacy-wetgeving komen.
Je zal inderdaad altijd wel een wachtwoord kunnen 'raden', zeker als je ongelimiteerde tijd hebt om ze uit te proberen en er zoveel hebt verkregen.

Je wordt wel geacht om dat raden moeilijk te maken: o.a. ervoor zorgen dat als 2 gebruikers hetzelfde wachtwoord hebben, dat je dat niet van de hash kan afleiden (dus unieke salt gebruiken) en er daarbij natuurlijk ook voor zorgen dat het uitproberen van ieder wachtwoord een relatief lange tijd kost (maar we zitten nog steeds in de sub-seconde wereld hier).

4x zoveel werk op basis van het werk aan WPA2 en de GPU/Asic implementaties hiervan. De pbkdf2 aanbeveling is ieder jaar 2x zoveel rounds (zou nu ergens rond de miljoen moeten zitten schat ik zo).

Alles is te brute-forcen als je lang genoeg hebt.
De truuk is juist het zo lang te laten duren dat het het niet waard is, en de gebruiker waarschijnlijk het wachtwoord al veranderd heeft.

Het gevaar waar je als developer tegen moet beschermen is het volgende:
De inhoud van je database zou ooit gelekt kunnen worden.
Als je dan de wachtwoorden daarin alleen maar gehashed zijn, kan een aanvaller een dictionary van eenvoudige wachtwoorden nemen, die allemaal hashen en vergelijken met de entries uit jouw database.
Omdat er onder een grote groep gebruikers altijd mensen zitten met slechte wachtwoorden, zul je op die manier een aantal wachtwoorden achterhalen.

Er is een aantal manieren om dit moeilijker te maken:
- Als je vóór het hashen eerst iets gebruiker-specifieks plakt aan het wachtwoord, bv. MD5(wachtwoord+username) moet je al de hele dictionary voor elke user opnieuw hashen.
- Als je ook een secret toevoegt, MD5(wachtwoord+username+secret) wordt het nog moeilijker. Tenzij dat secret ook uitlekt natuurlijk.
- Als je zorgt dat elke hashing stap duurder wordt, door bijvoorbeeld een paar duizend keer opnieuw te hashen, dan wordt het aanvallen van zo'n grote dataset al snel onoverkomelijk duur.

Mijn punt is: deze methodes zijn bedoeld om aanvallen op grote aantallen accounts te bemoeilijken. Als je je concentreert op 1 enkel wachtwoord en daar veel resources aan besteedt, dan kun je nagenoeg alles kraken. Maar zo'n investering voor 1 gebruiker loont alleen voor heel bijzondere personen zoals presidenten en CEO's of superrijken.

Om jezelf te beschermen kun je het beste een tool gebruiken als keepass om te zorgen voor unieke en random wachtwoorden voor elke site.

Base64 is ook een codering. Het gaat ook in Duitsland niet om de geschreven letter van de wet, maar de gedachte achter de wet.

Tja, wat is 'adequate'? Wat jij misschien acceptabel vindt hoeft een ander weer niet te vinden. 'adequate' zegt niets, dus md5 is in principe adequate, want het is niet rechtstreeks te lezen.

Adequaat is wat de toezichthouder daar van vind. Ben je als gegvensverwerker het daar niet mee eens, dan kun je nog naar een rechter stappen en dan beslist die wel of iets al dan niet adequaat is. Zeker in duitsland geef ik je in dat laatste geval weinig kans. De rechterlijke macht is daar vrij scherp op bewaking van privacy.

Het voorbeeld dat 50 % van wachtwoorden binnen 30 minuten eenvoudig te kraken zijn zal door geen enkele rechter als adequate bescherming gezien worden. Indien je een goede advocaat hebt zal die je ook vertellen dat je kansloos bent in de rechtszaal en de zaak ook niet aannemen. Alleen een onetische advocaat zal de zaak aannemen, simpelweg om er geld aan te verdienen.

Goede actie was dat destijds van Tweakers. Ik meen dat het was op het moment dat ze overgingen op een betere beveiliging en na het overzetten maar voor het wissen van de oude variant checkte of deze inderdaad zo zwak was. Ik gebruikte destijds ook nog een dom simpel wachtwoord en kreeg bij het inloggen een melding dat ze het hadden kunnen achterhalen.

Overigens is dit nog wel interessant in het originele artikel:

In minder dan een half uur bleek de helft van de versleutelde wachtwoorden eenvoudig te kraken.

Dus inderdaad 'slechts' de helft, maar ook in maar een half uur. Met wat kwade bedoelingen en extra tijd was die 50% vast nog wel flink op te krikken.

Of blowfish, die brute forcing gewoon traag maakt

MD5 mag dan exploitbaar zijn maar het is ooit gewoon een WW standaard geweest.

Ik mag hopen van niet eigenlijk, ik denk dat heel veel sites daar nog gebruik van maken. Code en logic veranderen is ook een pak moeilijker dan van platte text.

Bizar dat anno 2018 er nog steeds bedrijven zijn die wachtwoorden zo opslaan. Al ben ik bang dat dit er nog best veel zijn.

Het is niet ongebruikelijk dat zoiets jaren geleden is ingericht en men er verder niet echt meer bij stil staat... blijft erg slordig natuurlijk, maar het stellen van 'anno 2018' impliceert een beetje dat je lijkt te denken dat het ook in 2018 gemaakt is

Ik heb overigens geen idee wanneer het specifieke platform gemaakt werd, en bovendien is versleuteling van wachtwoorden al veel langer gemeengoed. De 'crypt'-functie in unix bestaat volgens wikipedia bijvoorbeeld al sinds de 3e unix-versie en die is van 1973.

Magoed, er zijn helaas wel meer die die fout maken of onderschatten hoe snel de techniek is gegaan voor het kraken van wachtwoorden.

Kan me inderdaad goed voorstellen dat dit aan het begin geprogrammeerd is en nooit meer aangeraakt is. Zolang het werkt is er geen reden om dat stuk van de code te bekijken en er zijn genoeg andere dingen om aan te werken waarschijnlijk.

Edit: ik bedoel dat dit in hun optiek geen aanpassingen nodig had. Persoonlijk vind ik het volledig verkeerd.

Tegelijkertijd zou je denken dat een website die draait om persoonlijke informatie wel een soort vast audit moment heeft waarop gekeken wordt of de beveiliging nog wel up to par is.

[Reactie gewijzigd door Heedless op 23 november 2018 09:22]

Als webdeveloper zeg ik: nee, nee, nee, driemaal nee. Als je de ganse MD5, SHA1, SHA1+salt, mcrypt (enzovoorts) hebt overgeslaan, mag je wat mij betreft best veroordeeld worden voor incompetent gedrag op de werkvloer. Als webontwikkelaar heb je anno 2018 een voorbeeldsfunctie waarbij je bewust moet omgaan met privacygevoelige/persoonsgebonden informatie. Het is eigenlijk al erg genoeg dat vele ontwikkelaars eenvoudigweg toegang hebben tot complete databases met gebruikers- of klantgerelateerde informatie. Totdat ook dit soort informatie geëncrypteerd opgeslaan wordt op databaseniveau, vind ik wel dat we dit soort informatie als "goede huisvader" moeten beheren. En dat is mijns inziens hier niet gebeurd.

Als ik zo even de som maak, is volgens deze Duitse rechtbank een account zo ongeveer tussen de 16 en 60 euro waard. 20.000 euro voor 330.000 à 1.200.000 accounts ? Die zijn er mijns inziens wel heel goedkoop vanaf gekomen...

An sich zou het cool zijn als je hele databaserecord gesalt wordt op basis van je password en dat je password als hash is opgeslagen.
Dan kan zelfs de programmeur niet bij je data en wordt het pas geunlocked als jij je password invoert.

Heeft echter wel een heel aantal limitaties

Dan kan zelfs de programmeur niet bij je data

Dat is gewoon zoals het hoort, heeft niks met cool zijn te maken. Een programmeur of systeem beheerder hoort niet jouw data te kunnen inzien. Dat is voorbehouden aan jou en eventueel mensen die jij specifiek toegang geeft tot (delen van) jouw informatie. Dat moet de basis zijn van alle dataopslag.

en wordt het pas geunlocked als jij je password invoert.

Dat kan, maar dan wel zo dat de server de encrypted data naar jouw device stuurt en dat de decryptie daar plaatsvindt, niet op de server, anders staat de decrypted data alsnog op de server.

1) Hoe wil je dan server-side bewerkingen uitvoeren op je data, als enkel jou device dit kan inlezen? Als bedrijf zou ik niet al mijn code naar een web frontend willen sturen zodat dit daar reverse engineered kan worden.
2) Als geen enkele developer data kan inzien wordt het ook wel moeilijk om bugs op te sporen. Akkoord, je gaat geen wachtwoorden of credit card gegevens in logs zotten maar als er iets misloopt omdat jij ergens een speciaal teken in user input doorstuurt (en mijn code dit niet opvangt) dan zou ik niet blind willen gokken wat er misgelopen is, wachtend op het volgende incident.

Klinkt dus allemaal mooi maar is praktisch niet echt haalbaar... Bovendien wordt dit normaal ook wel allemaal geregeld in je privacy verklaring. Aan de limitaties die daar instaan hoeven devs zich ook te houden.

2) Als geen enkele developer data kan inzien wordt het ook wel moeilijk om bugs op te sporen. Akkoord, je gaat geen wachtwoorden of credit card gegevens in logs zotten maar als er iets misloopt omdat jij ergens een speciaal teken in user input doorstuurt (en mijn code dit niet opvangt) dan zou ik niet blind willen gokken wat er misgelopen is, wachtend op het volgende incident.

Ik snap je redenering hier totaal niet. Je kan toch voor je tests zelf test-data encrypten en decrypten. "Ergens een speciaal teken in de user input" missen is geen argument: je moet voor je user input immers alle tekens gewoon getest hebben. En ja, ook als unicode ondersteund voor alle talen moet dat. Hier zijn ongetwijfeld gewoon scripts en tests voor.

Disclaimer: ik ben geen webdev.

[...]
Disclaimer: ik ben geen webdev.
[/quote]
Dat was duidelijk.

Alles encrypted over lijnen sturen om enkel bewerkingen front end te laten maken zijn ook kraakgevoelig, want gaat om de encryptie zelf hoe veilig je data is. Vrij toegankelijk om maar te doen wat je wil maakt encryptie dus ook kwetsbaar. En daarna kun je alles met de database doen wat je wilt, in situatie die jij beschrijft.

Ook kan je eenvoudig weg niet alles afvangen, kijk naar ps en apple waarbij afgelopen tijd nog hele apparaten vastlopen als je verkeerde input geeft in vorm van berichten. Daarbij komt nog dat de tijd echt niet altijd is om alles te testen, dit wordt gedaan door bugs op te lossen. Een learning process, want niemand weet alles vantevoren.

[...]
Disclaimer: ik ben geen webdev.
[/quote]
Dat was duidelijk.

Alles encrypted over lijnen sturen om enkel bewerkingen front end te laten maken zijn ook kraakgevoelig, want gaat om de encryptie zelf hoe veilig je data is. Vrij toegankelijk om maar te doen wat je wil maakt encryptie dus ook kwetsbaar. En daarna kun je alles met de database doen wat je wilt, in situatie die jij beschrijft.

Ik heb werkelijk geen flauw idee wat je hier schrijft.

@GeoBeo

Het "speciale teken" was gewoon een (extreem eenvoudig) voorbeeld van onjuiste user input. Met een beetje verbeelding kan je dit wel door iets anders vervangen denk ik Bijvoorbeeld json die naar een foute class wordt gemapt omdat de frontend dit fout doorgeeft. Hoe ga je dit ooit achterhalen als alles encrypted binnenkomt?
User input validatie kan gerust op de frontend gebeuren maar in the end is het de verantwoordelijkheid van je server om alles te valideren en te zien dat de data niet corrupt is. Onmogelijk dus als alles encrypted is. Dan is je server gewoon een domme opslag van random tekens...

En zoals @DerDee al zegt: je kan onmogelijk alle combinaties van tekens testen (om dat voorbeeld dan maar te volgen). User input bestaat zelden uit 1 karakter

[Reactie gewijzigd door binair op 23 november 2018 13:33]

Er zit een verschil tussen user-data in het algemeen en een wachtwoord.

Wat mij betreft moet client-side het wachtwoord al gehashed worden, en dan over de lijn verzonden. Er zijn teveel voorbeelden waar een TLS-sessie wordt opengemaakt, zonder dat dit kan worden opgemerkt vanwege rogue trusted certificaten. Denk maar aan Diginotar of recentelijk Symantec. Een wachtwoord hoort niet verzonden te worden.

Door gebruik te maken van een client-side hash, los je ook je probleem op dat je de user-input niet kan controleren.

Wachtwoord client-side hashen? Dan stuur je over de lijn de hash zoals deze in de database staat. Dat is dan toch hetzelfde als platte tekst opslaan? Immers heb je dan je wachtwoord gereduceerd tot de hash zelf en hoeft een hacker je wachtwoord niet te kennen, want de hash zelf is dan voor de server het wachtwoord.

Idee is juist dat hashes niet gebruikt kunnen worden om mee in te loggen omdat er aan serverkant een bewerking op wordt uitgevoerd die onomkeerbaar is.

Is wel lastig zoeken naar allerecords met een bepaalde woonplaats bv etc etc

Dan is het echter wel weer nodig om constant een secret token over de lijn te sturen... of clientside alles te decrypten en in geheugen te houden.

Idd, dat is ook waarom het onhandig zou zijn.

Ik vraag me eigenlijk wel af, je kan een HTTPS website hebben, maar als je via websockets alles cleartekst verstuurt, heeft dat toch helemaal geen nut meer?

Ik ben vrij onbekend met Websockets, kan je die niet ook TLS-encrypted gebruiken?

Ter verduidelijking: ik bedoelde dat ik mij voor kan stellen dat het in hun optiek, als slechte programmeurs, niet meer aangepast hoefde te worden, of dat ze het over het hoofd zagen omdat ze met 'belangrijkere' zaken bezig waren. Er liggen bij een grote site natuurlijk altijd genoeg dingen op de stapel die een veel zichtbaarder resultaat leveren en ik kan mij voorstellen dat die bij een slecht team voorrang krijgen boven aanpassingen waar gebruikers eigenlijk toch niks van merken (tot zo'n hack).

Als je verantwoordelijk ben voor zulke data dan hoor je de boel gewoon op orde te hebben.

[Reactie gewijzigd door Heedless op 23 november 2018 09:32]

Ik weet een website van een dokterspraktijk waar je een herhaalrecept kan aanvragen d.m.v. invullen van een simpel online formulier waarbij je de volgende zaken moet invullen: naam adres medicijn geboortedatum arts etc. En dat allemaal op een onbeveiligd http adres

Dat is geen excuus, zo'n bedrijf heeft vrijwel zeker iemand in dienst die zich met de beveiliging bezig houd en die persoon of personen zijn dus de geen die dit soort dingen in kaart moeten brengen en onmiddellijk moeten eisen dat dit aangepast wordt omdat dit echt niet langer kan zo.
De CTO of de persoon die een soort gelijke rol vervuld is eindverantwoordelijke voor dit verhaal, deze zou eventueel kunnen stellen dat dit opgelost zal worden met de volgende release bijvoorbeeld maar als dat meer dan een maand op zich laat wachten dan zou de security persoon of leider van dat team over het hoofd van de CTO naar de CEO moeten stappen en hem of haar verzoeken dit aan te pakken. Veel al is het erg handig als je dan ook de advocaat vraagt even uit te leggen wat de kosten zijn als het misgaat, ook wijzen naar hoe klanten het vertrouwen in je platform zullen verliezen etc helpt vaak goed.

Ik heb zo'n vermoeden dat dit bedrijf bestaat uit een handje vol mensen die allemaal heel erg goed hun best doen maar net te weinig weten van het geen ze aan het doen zijn om door te hebben hoe veel gevaar ze nemen door dit soort dingen niet goed te regelen.

In je eerste deel en laatste alinea spreek je jezelf natuurlijk een beetje tegen.

Veel websites hebben maar een heel klein development team (of laten het on-demand extern onderhouden) en ook lang niet altijd iemand met echt kennis van beveiliging in dienst. Al met al hadden ze het inderdaad op orde moeten hebben, maar ik verklaarde vooral dat zoiets zeer waarschijnlijk (en hopelijk, anders was het nog erger) niet in 2018 was gemaakt

De site is uit 1999. In die bijna 20 jaar had toch iemand wel kunnen bedenken dat deze manier van wachtwoorden opslaan niet zo’n goed idee is.

Wat mij betreft is de boete terecht en best wel aan de lage kant. Als je zoveel gebruikers hebt en persoonlijke informatie opslaat, dan dien je een zekere minimum investering te moeten doen in security.

Het is natuurlijk lastig dat er geen goede maatstaf is voor wat voldoende secure is, maar plain-text opslaan is erg nalatig.

[Reactie gewijzigd door Zyphrax op 23 november 2018 10:04]

Ik ben met je eens dat de boete terecht is, ik vond dat als er over 'anno 2018' wordt gesproken men moet begrijpen dat dergelijke techniek vaak zelf niet uit 2018 komt

Heel goed. Moeten ze eigenlijk bij alle sites die wachtwoorden vereisen gaan controleren of ze geen platte tekst wachtwoorden opslaan en zelf kijken of de gebruikte encryptie aan de huidige normen voldoen, zover je van normen kan spreken. In ieder geval meegaan met de tijd.

Ja, maar wat zijn de huidige normen? Zolang dat niet specifiek is vastgelegd (en wordt bijgewerkt) is het voor interpretatie vatbaar, iemand kan md5 bv ook voldoende vinden, want wie ben 'jij' om te beslissen wat de huidige norm is. Dat moet dus goed afgesproken zijn voordat men boetes kan gaan uitdelen.

[Reactie gewijzigd door SuperDre op 22 november 2018 22:55]

Wat @kaas-schaaf zegt is helemaal correct. Specifiek in de wet opschrijven wat goed genoeg is werkt niet. De wetgever is dan continue bezig om die tekst aan te passen.

Dat betekent niet dat je niet kunt achterhalen wat goed genoeg is.

Allereerst heb je als programmeur inhoudelijke kennis over beveiliging van data. Op basis van die kennis hoor je in staat te zijn om in te schatten wat goed genoeg is. Kun je dat niet dan zit je op de verkeerde plek.

Ten tweede kun je ook overleggen met andere programmeurs, binnen je eigen organisatie of ook daarbuiten. Je kunt daarbij ook denken aan het inhuren van beveiligingsexperts voor specifieke projecten.

Tenslotte heb je ook nog de mogelijkheid om te kijken naar wat toezichthouders en/of rechters zeggen. Al die uitspraken zijn publiekelijk beschikbaar. Dit is wel de meest bewerkelijke route.

En bij twijfel ga je gewoon nog één stapje verder voor de zekerheid.

Normen en waarden zijn nu eenmaal geen bits. Het is niet simpelweg 0 of 1. Er komt interpretatie bij te pas. Ben je niet bereid of in staat om daar mee om te gaan dan heb je 2 opties:

• Zoek een andere baan.
• Neem het zekere voor het onzekere en ga voor de best mogelijke beveiliging.

Je kunt daarbij ook denken aan het inhuren van beveiligingsexperts voor specifieke projecten.

Weet je hoe vaak ik het niet heb meegemaakt dat bedrijven veel geld uitgeven aan externe expertise, terwijl je er dan niet veel later achter komt dat deze experts verre van experts zijn...

Het is allemaal niet zo simpel, zelfs als programmeur kun je niet overal van op de hoogte zijn. Wat 'ik' vandaag als compleet veilig interpreteer kan morgen compleet onveilig zijn want je blijft sowieso achter de feiten aanlopen. Ieder heeft zo zijn/haar expertise, het is niet zo dat omdat je programmeur bent dus overal de technische kennis van hebt.

En zolang er niets wettelijk is vastgelegd wat er minimaal onveilig is (en ja dat betekent dus dat periodiek deze richtlijnen/wetten bijgewerkt moeten worden), kan een toezichthouder niet zomaar een boete opleggen, zelfs dus niet als er bv MD5 gebruikt is, want het is in verhouding toch een stuk veiliger dan plaintext. Dat is het probleem met deze stof, wat JIJ veilig acht kan een ander als onveilig zien, en andersom. Wie ben JIJ dus om te bepalen wat wel veilig is en niet? Door niet goed te specificeren wat bedoelt wordt als veilig kan een inspecteur die de pik heeft op een bedrijf dus zomaar een boete opleggen omdat hij vind dat ze bv minimaal quantum-based encryption moeten gebruiken..

Je hebt helemaal gelijk dat wat vandaag algemeen als veilig woord beschouwd heel snel ineens onveilig kan zijn wanneer er nieuwe exploits bekend worden. Daarom is de wetgeving ook heel duidelijk dat je beveiliging niet eenmalig mag bekijken maar dat je verplicht bent deze periodiek opnieuw tegen het licht te houden.

En jij als developer/programmeur bent juist de persoon die hoort te kunnen bepalen of een beveiligingsmethode adequaat is of niet.

Door de minimale beveiligingsmethodes telkens in de wet vast te leggen loop je per definitie altijd achter de feiten aan. Het duurt gewoon heel lang om die hele papiermolen te doorlopen. Dat moet je niet willen.

Je angst dat een inspecteur te pas en te onpas boetes kan opleggen is volledig ongegrond. De inspecteurs moeten hun beslissingen voor het opleggen van boetes ook kunnen onderbouwen binnen hun eigen organisatie. Doen ze dat niet goed dan valt dat snel genoeg op.

Voorts heeft ieder bedrijf dat een boete opgelegd krijgt altijd de optie om naar de rechter te stappen als ze het niet met de boete eens zijn.

Helemaal onjuist.
Steeds meer wetten zeker rond zeer snel veranderende technieken zo als in de ICT wereld zijn geschreven met die kennis in het achterhoofd en dus stellen zij dat er voldoende gedaan moet worden om de data goed te beveiligen.
Is md5 voldoende, als je een dienst op wil zetten waar mensen gebruik van wachtwoorden maken en jij die dus opslaat dan zul je op de hoogte van de techniek moeten zijn om bij te houden of dat wel of niet voldoende is. En als jij dan tot de ontdekking komt dat ondanks dat je dacht dat md5 goed genoeg was dat toch niet het geval is zul je je systeem moeten aanpassen om een andere encryptie methode te gebruiken. Een simpele oplossing is bij de volgende login van een gebruiker het wachtwoord opnieuw opslaan met de nieuwe hash en een flag zetten in de database om aan te geven dat deze account nu met de nieuwe hash gecontroleerd dient te worden.

Als je kijkt naar veel strengere wetgeving bijvoorbeeld de wetgeving rond gezondheidsinformatie dan is deze in alle westerse landen op de zelfde manier geschreven, afdoende beveiliging is vereist. En het is dan aan jouw om te bepalen wat afdoende is. Omdat het als het fout gaat erg vervelend kan zijn zeker als het niet afdoende blijkt te zijn zullen de meeste bedrijven een stuk veiliger werken dan ze anders zouden doen want liever een beetje extra dan een probleem in de toekomst.

Een andere oplossing is wat bijvoorbeeld in Maleisie gedaan is voor de financiele wereld. Daar is de wet heel simpel om zaken te kunnen doen in het land als een bank moeten alle systemen up to date zijn van OS tot alle gebruikte software. Komt er een nieuwe versie van Java uit dan zul je binnen 2 maanden moeten upgraden, het zelfde voor de linux kernel, drivers, en alle andere software. Je kunt je voorstellen dat dit echt een groot probleem kan zijn zeker voor wereldwijde banken die veel al 1 settlement systeem gebruiken bijvoorbeeld.
Wat dat betreft is het wat ruimer opstellen van de wet en mensen zonder harde deadlines toch dwingen om het juiste te doen een hele goede oplossing. Het is simpel weg de vraag hoe groot het gevaar is als het mis gaat.

De wet zegt in de strekking van "voldoende veilig". Dit is niet specifiek vastgelegd omdat dit niet haalbaar is bij iedere verandering de wet aan te passen. Het is aan jou om te laten zien dat dit zo is. Als je met simpele zoektermen kan vinden dat dit niet veilig is, dan moet je het ook niet gebruiken en kan je aannemen dat wetgever dit ook vind.

Ongesalte wachtwoorden met simpele MD5 (of SHA1, of SHA256 ongesalt) digests zijn al sinds de jaren '00 niet meer te aanschouwen als veilig.

Toch even een nuance daarop: SHA256 (ook zonder salt) is in de verste verte nog niet bruteforcebaar. En al helemaal niet sinds de jaren '00.

Maar weer is dat zo'n loze strekking, zonder specifieke definitie kan je alles wel als "voldoende veilig" beschouwen. Er moet dan echt in iedergeval specifiek staan wat dan zeker (op dit moment) als niet veilig beschouwd wordt. Zelfs MD5 ongesalt is in feite veiliger dan plaintext opslaan. tja, dat JIJ en 'een paar' anderen dat niet vinden doet niets af aan de vage uitspraak 'voldoende veilig', want als zeik-inspecteur kun je dan dus zelfs van een bedrijf eisen dat ze minimaal quantum-based encryption moeten toepassen omdat het anders niet 'voldoende veilig' is.
Maar daarom zeg ik dus ook dat in iedergeval het minimale gespecifieerd moet zijn, of in iedergeval specificeren (en bijwerken) wat zeker niet als veilig beschouwd kan worden.

"Het bedrijf zou de wachtwoorden in platte tekst gebruiken voor een 'wachtwoordfilter' dat moest voorkomen dat deze in handen zouden komen van onbevoegden, schrijft de LfDI."

Ik begrijp noch wil het idee erachter niet begrijpen, wat een contradictie.

"u kunt het door u gekozen wachtwoord 'xyz' niet gebruiken want gebruiker 'abc' heeft die al."
Zoiets misschien?

Ik heb het geprobeerd maar kan niet bedenken wat voor iets nuttigs zo'n wachtwoordfilter zou kunnen doen.
Checken of het complex genoeg is, een veelvoorkomend woord of hetzelfde als je vorige wachtwoord kan allemaal zonder dat het wachtwoord in plain text opgeslagen moet zijn...

Zoals ik het begrijp: een keyword filter op uitgaande mails, zodat mensen geen mails met wachtwoorden naar buiten kunnen sturen. Denk aan de klantendienst die mensen voor het gemak hun wachtwoord mailt. En ja, dat is idioot want als je gewoon alleen hashes in plaats van wachtwoorden bewaart dan kan de klantendienst dat niet doen. Maar ja, er is nu eenmaal gekozen voor plaintext passwords in de database en dan is het goedkoper om uitgaande mail te filteren op de aanwezigheid van wachtwoorden.

Of wellicht een filter op de berichten die gebruikers onderling kunnen sturen, zodat gebruikers niet verleid kunnen worden om hun wachtwoord door te sturen aan een andere gebruiker?

Zolang bedrijven de boetes betalen wordt het ingecalculeerd als bedrijfsrisico. Alleen als er sprake is van persoonlijke aanspraak/vervolging (bij nalatigheid, zoals hier het geval is) zal er een andere motivator zijn dan bedrijfsgeld om hier verandering in te brengen.

Tja, het is voor veel minder dan 20.000 op te lossen. En als je bedrijf nog veel meer geld waard is, wordt de boete dus nog hoger. Daarnaast lijdt je toch ook wel flinke imago-schade als zoiets gebeurt.

Dus ik denk dat dit soort boetes bedrijven (hopelijk) wel aan het denken zet. Voorkomen is goedkoper dan genezen in dit geval. Maar het blijft natuurlijk kwestie van kansberekenen...

Is dat wel zo? Ik speel even devil's advocate, maar simpelweg zeggen dat het niet duur kan zijn die wijziging te maken is wel een erg snelle conclusie. Voordat je het roer omgooit ga je natuurlijk eerst alles testen. Ook je gebruikers moeten allemaal hun wachtwoord wijzigen, en liggend aan hoe groot je database, zit je eventueel tegen wat downtime aan te kijken. Veel bedrijven hebben niet eens devs in dienst, maar huren een bureau in. Dan tik je iets meer af dan een uurloon van een paar devs die de troep komen opruimen. Daarna moet het nog ge-audit worden op veiligheid, ook niet goedkoop. Enkele diepe audits kunnen zo 10.000 kosten.

Als je alle wachtwoorden toch al plaintext opgeslagen hebt, dan hoeven gebruikers ook geen nieuw wachtwoord te krijgen. Je kunt als bedrijf immers voor iedere gebruiker een wachtwoordhash genereren, met elke denkbare techniek die je daarvoor zou kunnen gebruiken. Je hebt alles wat je nodig hebt: het hele wachtwoord

Als je als bedrijf niet forceert mensen hun wachtwoord te veranderen na deze lang plaintext te hebben opgeslagen, ben je wel een bijzonder soort incompetent. Als iemand een data-dump heeft van de plaintext passwords, dan kunnen ze gewoon inloggen, hoe je dit ook naderhand nog hashed.

Zoals Brainlees ook al aangeeft: Je hebt de wachtwoorden dus je hebt alle input voor je nieuwe hashes. En omdat je ze ook in plain text hebt, is het heel makkelijk te testen.

Neem van mij aan: 1 developer kan dit er makkelijk in 1 dag inbakken. Het is alleen kwestie van je inlog-flow en je registratie-flow aanpassen. Als het goed is blijven al je geautomatiseerde tests gewoon werken (tenzij je echt plain text uit de DB gaat asserten in je tests )

En denk je echt dat een bedrijf dat zijn wachtwoorden plain text opslaat uberhaupt weet wat een audit is?!? En als ze het al wel weten, laten ze hiervoor echt hun systeem niet auditten hoor.

Zie hierboven:
ItsNotRudy in 'nieuws: Duits bedrijf krijgt boete wegens opslaan wachtwoorden...

Een beetje deftig Agile team verbrand zo 100.000 euro per maand, dus 20.000 euro is niks voor een corporate level dev-team.

Je hoeft niet overal een compleet agile team tegenaan te gooien. Natuurlijk hangt het er wel een beetje vanaf hoe het bestaande systeem er uitziet, maar met een paar aanroepen naar een crypto library kom je al een heel eind. Het is natuurlijk mooi om van het slechtst mogelijke systeem naar DoD-level security te gaan, maar dat is niet nodig.

Specificaties, DBA (aanpassing dev/test/live), Tester, alle plekken kunnen aanpassen (registratie, passmailer, etc.)

Boetes geven naar gelang bedrijfsomvang/omzet zou genoeg moeten zijn...

[Reactie gewijzigd door Swerfer op 22 november 2018 20:41]

Boetes geven naar gelang bedrijfsomvang/omzet zou genoeg moeten zijn...

Met een (gepercipieerde) lage pakkans gecombineerd met dat het enkel bedrijfsgeld is en het men niet persoonlijk raakt (lage impact) zal er niets veranderen.

Bruce Schneier omschrijft het goed: data is a toxic asset. Het wordt tijd dat personeel en directie van bedrijven het ook zo gaan zien.

[Reactie gewijzigd door The Zep Man op 22 november 2018 20:53]

Tuurlijk wel.
Verantwoordelijke ontslagen (die wordt immers betaald om een verantwoordelijkheid op te nemen), zonder vergoeding en zonder referenties.

De gemiddelde tweaker zou dit dan ook als een terecht geval van "ontslag vanwege incompetentie zien".

Maar het addertje hier is dat wij - als mensen met bovengemiddelde cybersecurity-kennis - weten wat redelijke beveiliging is (en dat MD5 best wel bagger is, naar moderne maatstaven).

Nu is de belangrijkste vraag; gaat een rechter hierin mee of laat hij/zij/non-binair dat gaan want "dat wist ik ook niet"? Persoonlijk verwacht ik het tweede, gezien dat cybersecurity als iets nerderigs word gezien..

Sinds de AVG staan dit soort dingen ook juridisch nogal in de schijnwerpers.

IMO zou je geen website mogen draaien als je die basisvaardigheden niet kent. Het gaat hier niet om gebruikers, maar om de programmatuur. Draai dan een standaard pakket, zelfs dan ben je al veiliger.

Nu is de belangrijkste vraag; gaat een rechter hierin mee of laat hij/zij/non-binair dat gaan want "dat wist ik ook niet"? Persoonlijk verwacht ik het tweede, gezien dat cybersecurity als iets nerderigs word gezien..

Persoonlijk verwacht ik dat ook. Maar dat is niet de belangrijkste vraag - die vraag stellen doet weer een ander probleem aan het licht komen (zie ook al die pensioen-gerechtigden die Mark Zuckerberg vragen stelden... Zo goed als geen eentje leek ook maar een flauw benul te hebben wat 'internet' is.

Verantwoordelijke ontslagen (die wordt immers betaald om een verantwoordelijkheid op te nemen), zonder vergoeding en zonder referenties.

Die gewoon weer ergens anders aan het werk gaan. Zelfs zonder referenties lukt dat wel.

En management ontslaat niet snel management, omdat management getraind is om de schuld af te schuiven op alles behalve zichzelf.

Ben er maar al te goed van bewust
Laat ons het houden op een idealistisch momentje.

En dat laat de AVG dan ook toe

En dat is ook wat er dus gebeurd,met een maximum.

[Reactie gewijzigd door SuperDre op 22 november 2018 22:58]

Ik vraag me dan wel af wat voor amateurs de software achter die website hebben geschreven. Zelfs van een beginnende programmeur mag je toch wel verwachten dat hij genoeg verstand heeft om te snappen dat het opslaan van wachtwoorden in plain text geen goed idee is.

Terecht natuurlijk dat het bedrijf een boete heeft gekregen, want dit is gewoon onverantwoordelijk gedrag en zeker als het belangrijkste deel van je business bestaat uit een website dan lijkt het me niet minder dan logisch dat je serieus nadenkt over beveiliging.

[Reactie gewijzigd door jj71 op 22 november 2018 20:49]

Hoe dat gaat?
1) Demo-project, voor intern
2) Even snel vrijdag middag in elkaar klooien
3) Geen frameworks, lekker zelf SQL-en
4) Hoppe INSERT INTO users, hatsaflats, toch een demo-projectje
5) Code groeit
6) Login & registratie zit ergens in een lib-file waar nooit meer iemand naar kijkt
7) Ineens staat het live!

Klopt, is een fout, maar meestal komen fouten m.i. door dit soort upscaling.
Mensen kennen vast de Spike of POC code. Nou, bij vrijwel elke manager gaat het gewoon live 'het werkt toch'.

Kanttekening is natuurlijk wel dat als je het aan de programmeurs overlaat je na 3 jaar nog niks hebt omdat het niet perfect en veilig is, en je dan inmiddels drie concurrenten zoveel groter zijn dat je wel kan stoppen...

Hoe dat gaat?
1) Demo-project, voor intern
2) Even snel vrijdag middag in elkaar klooien
3) Geen frameworks, lekker zelf SQL-en
4) Hoppe INSERT INTO users, hatsaflats, toch een demo-projectje
5) Code groeit
6) Login & registratie zit ergens in een lib-file waar nooit meer iemand naar kijkt
7) Ineens staat het live!

Klopt, is een fout, maar meestal komen fouten m.i. door dit soort upscaling.

Hoe het komt dat de beveiliging bagger is, is niet relevant. Waar het om draait is DAT de beveiliging bagger is. Wat je hier aanhaalt zijn gewoon smoesjes.

Een toezichthouder of rechter heeft, volledig terecht, lak aan dit soort smoesjes.

Mensen kennen vast de Spike of POC code. Nou, bij vrijwel elke manager gaat het gewoon live 'het werkt toch'.

Als je daar als programmeur aan meewerkt kun je juridisch een probleem krijgen. Je kunt dan namenlijk persoonlijk mede-aansprakelijk gesteld worden. De aansprakelijkheid houdt niet op bij "het bedrijf" of "de manager".

Het zijn geen smoesjes, het is een verklaring hoe het zover komt. Boete e.d. vind ik ook zeer terecht.

Volledig mee eens

Soms kom je gewoon heel gekke dingen tegen. We hebben hier software waarmee de personeelsadministratie en de uurroosters van de werknemers wordt beheerd. De huidige versie is nog in VB6 geschreven. Omdat het toch wat te oud werd is de leverancier een hele tijd geleden begonnen aan een nieuwe versie met de front end in Silverlight, ondanks dat Microsoft toen de end of life datum al had aangekondigd.

Verbaast het je dat de wachtwoorden als plain text opgeslagen zijn als dergelijke keuzes gemaakt worden? Soms zijn bedrijven heel slecht in wat ze doen en hebben ze geluk dat er een afzetmarktje is voor hen.
Jammer genoeg kunnen we die leverancier niet gewoon buitengooien...

Hier staat niet eens dat het EOL is: https://www.microsoft.com/silverlight/default

Het kan erger. Als je bij cu2 (jeweetwel, die Facebook uit 1992) je wachtwoord wilt resetten, dan krijg je gewoon plaintext je wachtwoord per email toegestuurd

Het kan erger. Als je bij cu2 (jeweetwel, die Facebook uit 1992) je wachtwoord wilt resetten, dan krijg je gewoon plaintext je wachtwoord per email toegestuurd

Yup. Ik heb het de laatste jaren ook nog wel eens voorbij zien komen bij vooral de kleinere webwinkels.
Maar als ik me goed herinner was ook een grotere keten als Kruidvat hier een jaar of 5 geleden nog schuldig aan.

Nog leuker zijn de bedrijven die behulpzaam het nieuwe wachtwoord dat je zelf gekozen hebt, daarnaast ook nog als reminder per mail doorsturen. Dan kun je het net gelekte wachtwoord door een nieuw vervangen, enkel om er achter te komen dat het ... weer gelekt is. Bonus punten als die mails ook nog eens over een niet-versleutelde verbinding verstuurd worden.


Maar goed; voor mij spant de kroon nog steeds de afdeling Wiskunde & Informatica van de Technische Universiteit Eindhoven. Zij sturen naar alumni periodiek e-mail reminders uit met de vraag of de NAW gegevens die ze beheren nog kloppen. Dat doen ze via een mail-merge met een bulk nieuwsbrief-provider die op die manier ook alle gegevens te zien krijgt. En deze provider zet alles ook nog eens en plain public met "bekijk een live versie hier" open op het internet.

[Reactie gewijzigd door R4gnax op 22 november 2018 22:06]

Een informaticafaculteit die dat zo doet, verdient het eigenlijk om zonder verdere waarschuwing aan de schandpaal genageld te worden. Heb je al uitleg en screenshots aan de autoriteit persoonsgegevens gestuurd? https://www.autoriteitper...klacht-indienen-bij-de-ap

Heb je al uitleg en screenshots aan de autoriteit persoonsgegevens gestuurd?

Dat is al gebeurd ja. En ik weet van anderen dat ik niet de enige ben die er actie op ondernomen heeft. Schandalig, niet?

330.000 gebruikers gestolen, waaronder wachtwoorden en e-mailadressen en dan maar 20k als straf

Mag toch hopen dat buiten de boete er ook wat koppen rollen binnen de organisatie..

[Reactie gewijzigd door HKLM_ op 22 november 2018 20:37]

ja, maar als ik het goed heb gelezen, hebben ze wel heel veel geïnvesteerd om het nu wel goed te beveiligen. En met dat laatste heeft men rekening gehouden toen men de hoogte van de boete heeft beslist. Nu het zijn sowieso vijgen na Pasen maar soit.

Volgende keer als ik te hard rijd, zeg ik wel tegen het CJB: "Yo, ik ga een elektrische fiets aanschaffen zodat ik niet meer te hard rijd naar mijn werk. Dus dan kan die boete ook weg!"

Het is in mijn opinie dus echt op het randje van totale onzin. De AVG is juist ingesteld om bedrijven te stoppen met deze waanzin van slecht beveiligen, niet een verkapte subsidie.

goh, je kan perfect aanhalen bij de politierechter dat je je auto hebt weggedaan en je jezelf een fiets hebt gekocht. Kans is groot dat de boete een pak minder wordt. (althans in België).

Waarom je zegt dat het een verkapte subsidie is, dat is me helemaal een raadsel. Ze hebben de boete gedaan + een cijfer met 6 nulletjes geïnvesteerd om het in te de toekomst te voorkomen. En in dit geval twee vliegen in 1 klap.

Ze hadden idd dat geld incl de investering ook allemaal als boete kunnen vorderen. Maar dan was de investering achteraf mss ook de moeite niet meer waard.

Ik besef zelf goed genoeg dat het allemaal op het randje is maar ik vind dit een beter oplossing (imho). Maar ik heb liever dat ze dat geld gwn investeren in beter dan gwn als boete en dan iets en niets investeren in beveiliging.

Bij mijn weten gaat dat niet op in Nederland, en persoonlijk vind ik het ook raar dat je iemand wilt straffen en dan een deel omzet in een gift.

Het gaat mij meer om het precedent dat ze scheppen, je maakt een fout en dan een boete. Al word een deel ervan kwijtgescholden omdat ze investeren in een fout die ze al wisten dat werd gemaakt. En daar ben ik persoonlijk tegen, ze verdienen de complete boete want ze hebben ook riant verdiend aan het uitstellen van de investering (wellicht zelfs meer dan de verminderde boete was...). Het zou mij verbazen als ze niet wisten dat ze fout zaten. Al is verkapte subsidie dan wellicht overtrokken van mijn kant.

Daarnaast is het net als met "het kopen van een fiets" voorbeeld, wie checkt of je het ook echt gebruikt?

[Reactie gewijzigd door Nicael op 22 november 2018 22:20]

De bedoeling van een straf (in dit geval dus een boete) is dat het niet weer gebeurt (globaal) . Dat is letterlijk hoe onze hele maatschappij werkt. Als je bijvoorbeeld goed gedrag in de gevangenis vertoont mag je vaak eerder weg.

Verder zit er een grote kans dat ze het daadwerkelijk niet wisten. Zoals @ACM hierboven al heeft genoemd kan het best zijn dat dat systeem 5 of 10 jaar geleden is ontworpen en in de ICT heeft men vaak de neiging om ergens niet aan te komen als het werkt
Ook ben ik het niet helemaal met je eens omtrent het controleren. Dit is gewoon een kwestie van implementeren en z'n gang laten gaan.

[Reactie gewijzigd door goedt op 22 november 2018 23:21]

Dat de strafmaat mede afhankelijk is van de houding en acties van een verdachte/dader is de normaalste zaak van de wereld. Niet alleen in dit geval maar ook veel breder.

Zelfs in moordzaken is het zo dat indien een dader berouw toont en meewerkt aan de waarheidsvinding er lagere straffen worden gegeven dan wanneer een dadar met een grote grijns de familie van het slachtoffer in de rechtszaal uitlacht. Dat zijn voorbeelden van verzachtende of verzwarende omstandigheden.

gift.. nergens is dit een gift. De rechtbank, noch een oranisatie heeft geld gegeven aan dat bedrijf om dat te bewerkstelligen.

Ik heb het trouwens even opgezocht, deze werkwijze wordt ook in Nederland gehanteerd :-).
Wat ben je met een complete boete, als daarna blijkt dat ze niet genoeg geld meer kunnen investeren om dit wel volledig te beveiligen. Iedereen heeft recht , of zou dat toch ergens moeten hebben, op een rechtspraak en / of straf in overeenstemming met het gedrag dat getoond wordt.

wat betreft de aankoop (en verkoop had ik in mijn voorbeeld gezegd) ga je wel met de nodige papieren moeten komen meestal. Zal hier wel niet anders geweest zijn.

[Reactie gewijzigd door Yoshi op 23 november 2018 12:58]

Op een electrische fiets (of zelfs gewone fiets) kun je ook een boete krijgen voor te hard rijden, die snelheidsborden gelden voor al het verkeer, niet alleen auto's.

En toch is het vreemde in NL dat een automobilist dan zwaarder bekeurd wordt dan een fietser...

Wat betreft snelheidsovertredingen is een boete voor te hard rijden met een fiets net zo hoog als met een auto..

Hmmm... Klaarblijkelijk niet: https://www.quest.nl/arti...ijgen-voor-te-hard-rijden

Kijk, mooie ontwikkeling. Mogen ze hier ook wel mee beginnen.

Nu is het vaak zoiets van: foei, niet meer doen hè. Maar daar leren bedrijven blijkbaar niet genoeg van...

Heeft Duitsland de AVG geschonden? Dat is toch gek, want dat is toch Nederlands?

Lijkt me eerder de GDPR dan.

De AVG (Algemene Verordening Gegevensbescherming) is alleen maar de nederlandse naam voor de GDPR (General Data Protection Regulation) in de EU. Het is dus hetzelfde, alleen de naam vertaald naar het nederlands.

Wel gek om het een eigen naam te geven. Een directe vertaling kan ik nog begrijpen, zoals met European Union and Europese Unie. Maar een compleet andere naam voor iets is toch een beetje gek.

Is toch een directe vertaling?

General = Algemene
Data Protection = Gegevensbescherming
Regulation = Verordering

Sorry, ik bedoelde meer iets vinden waardoor de GDPR afkorting in stand blijft, net zoals bij EU.

B.v. Generieke Data Protectie Regulering

Die vergelijking klopt ook niet, in Frankrijk is het niet EU, maar UE.

En hier in Paraguay worden de V.S. altijd afgekort met E.E.U.U.

Estados Unidos, daarvan zou je verwachten dat het afgekort word tot E.U., maar dat botst dan weer met een andere gangbare afkorting voor Europa.

Zoiets kan ook spelen in Duitsland en dat men daarom voor een (geheel) andere afkorting kiest.

Het is een Europese wet waarvan de officiële naam in het Nederlands AVG luidt. Je kunt natuurlijk zeggen, het is een Duits bedrijf dus dan noem ik het Datenschutz-Grundverordnung maar het gaat om één en dezelfde wet in Duitsland en Nederland. GDPR is wat de Engelstaligen zeggen.

Is GDPR ook niet waarvan men in alle andere landen ter wereld spreekt waar niet 1 van de andere Europese talen gesproken wordt?

B.v. in Japan en China.