GDPR regelgeving - bijhouden wachtwoorden door systeembeheerder

[Robert Ford]

Ik stel me een paar vragen rondom security en wachtwoordbeleid voor bedrijven

- Mag je als bedrijf wachtwoorden van gebruikers bijhouden in een database?
- Mag je een werknemer een vooraf gekozen (sterk) wachtwoord opleggen?

[crackjack]

technisch gezien is dat een serieus beveilingsprobleem: als die database of lijst met opgelegde wachtwoorden lekt, heb je een groot probleem
GDPR: ik heb hier weinig kennis van, maar ik weet dat GDPR vereist dat wachtwoorden een bepaalde complexiteit en encryptie nodig hebben.
Met die encrytie word jouw lijst of database dus nutteloos.

[johcla]

Ook naar tuchtprocedures in geval van misbruik is er een probleem: een werknemer kan ontkennen dat hij iets misdaan heeft omdat nog andere mensen zijn wachtwoord hebben en zich dus met zijn account kunnen aanmelden.

[fuserke]

Wachtwoorden mogen niet in een lijst bijgehouden worden. Niemand heeft zaken mer jou pw. Als je in een bedrijf werkt dan zijn er admin accouts om eventueel pw te resetten maar dat mag enkel met toestemming van de persoon zelf

[CCatalyst]

AVG bepaalt niets specifiek, wel bv dat niet-toegestane toegang tot persoonlijke gegevens verhinderd moet worden. Dus:

- Mag je als bedrijf wachtwoorden van gebruikers bijhouden in een database?

Nee. Enfin, toch niet in "plain text" of geëncrypteerd. Uiteraard mag je het wel one-way hashed opslaan, anders raak je nergens.

- Mag je een werknemer een vooraf gekozen (sterk) wachtwoord opleggen?

Ja als de toepassing dat vereist, maar de werknemer moet het paswoord dan bij de eerste login resetten alvorens hij toegang krijgt.

[FullHD]

Wachtwoorden mag je in principe niet versleutelen (tweewegs-encryptie) maar die moet je hashen (encryptie in één richting; je kan vanuit een hash onmogelijk het origineel terugrekenen). Hashen alleen is trouwens niet voldoende. Maar goed, dat is een aparte discussie.

Accounts en de bijhorende wachtwoorden zijn persoonlijk. Iedereen heeft een eigen account en wachtwoord dat met niemand gedeeld mag worden. Niet met administrators en ook niet met collega's (als bvb iemand met vakantie is of zo). Jij blijft namelijk verantwoordelijk voor alle acties die onder jouw account zijn uitgevoerd.

Het wordt ook afgeraden om systeemaccounts of technische accounts te gebruiken voor manuele acties. Je weet dan namelijk niet wie de actie heeft uitgevoerd. Ook elke administrator moet beschikken over een eigen account en een eigen wachtwoord. Bij voorkeur is dat zelfs niet het account dat dagdagelijks gebruikt wordt maar enkel voor die acties waarvoor de admin rechten nodig zijn. Als je daarover meer te weten wil komen: dat heet "PAM" of "Privileged Access Management".

Een admin kan eventueel een wachtwoord voor een gebruiker instellen en dat doorgeven maar dan is het de bedoeling dat dit wachtwoord door de gebruiker onmiddellijk bij het eerste gebruik wordt veranderd. Op veel systemen kan je zelfs forceren dat dit gebeurt.

Dat zijn allemaal dingen die een bedrijf dat z'n beveiliging op orde heeft heel normaal vindt. Maar dat is spijtig genoeg zeker niet overal het geval.

[CCatalyst]

hashen (encryptie in één richting; je kan vanuit een hash onmogelijk het origineel terugrekenen)

Hashing is geen encryptie he, dat is wel relevant hier. Maar je bedoelt het wel juist.

[meon]

Ik zie niet in wat wachtwoorden met de AVG te maken hebben: dit is géén persoonlijke informatie.

Als ik "W5j62rmWYBC6rDvM" weet, zelfs in combinatie met een gebruikersnaam ab123456, is dit geen persoonsgebonden, identificerende informatie.

Wachtwoorden staan ALTIJD in een database. Hier op Userbase, in Azure AD, in Active Directory, in uw SAP-omgeving, ... De vraag die je u moet stellen heeft meer met compliance en security te maken: wie kan aan dat wachtwoord en hoe wordt dit beheerd. Worden log-in-pogingen bijgehouden in een audit-logboek, net als wachtwoordresets. Is het gebruikte account privileged of niet (een 'admin'-account, een service-account, ...). Of wachtwoorden encrypted opgeslagen wordt of niet... Maakt op zich niet echt uit. Belangrijker is wie aan die info kan. Password-hashes zijn uiteraard veel veiliger dan plain text, want je neemt daarmee al het grootste risico weg uit de vergelijking.

Een werkgever of welk systeem mag je dus wel degelijk een sterk, initieel wachtwoord geven. Of je die daarna wijzigt ligt aan jezelf. De meeste systemen hanteren een "must change on first logon"-principe, dus als dat opgegeven wachtwoord niet meer correct is, dan heeft iemand anders daar reeds gebruik van gemaakt.

[DarkV]

Wachtwoorden staan ALTIJD in een database.

Ik denk dat hij eerder bedoelde als plain text (zodat iemand anders er om welke reden dan ook mee zou kunnen aanloggen).

Op zich staat dit los van de GDPR maar het is alvast NOT-DONE en zowat tegen alle regels !

[fvhbrugge]

GoCards.nl zet na succesvolle registratie je ingestelde paswoord gewoon in plain text in bevestigingsmail.

En er is geen functie om je passwoord te wijzigen..
Je kan alleen je account verwijderen.


Tja niet te begrijpen hé.

[crackjack]

Het wachwoord veranderen kan wel via https://www.gocards.nl/wachtwoord
maar dan sturen ze het terug per e-mail

Deze privacyverklaring is aangepast op 19 augustus 2012

GDPR bestond toen nog niet

[fvhbrugge]

Hopelijk heeft hun site beveiligingsupdates gekregen n'a 2012...

[Jefm]

Ik zie niet in wat wachtwoorden met de AVG te maken hebben: dit is géén persoonlijke informatie.

Als ik "W5j62rmWYBC6rDvM" weet, zelfs in combinatie met een gebruikersnaam ab123456, is dit geen persoonsgebonden, identificerende informatie.

Op plaatsen waar logging en goedkeuringen opgevolgd worden op basis van gebruikersnamen is dit zeker identificerende informatie.
Meestal kent men de gebruikersnamen van de betrokken personen uit ervaring, anders kan men deze eenvoudig opzoeken.

[meon]

Opnieuw, nu heb je het weer over andere informatie dan een 'wachtwoord', maar tijdstippen, locaties. Dat is andere metadata. Dat je iemand kan identificeren op basis van een gebruikersnaam en wachtwoord is de bedoeling hé.

Meestal kent men de gebruikersnamen van de betrokken personen uit ervaring, anders kan men deze eenvoudig opzoeken.

Ja... zo werkt dat nu eenmaal? Wat heeft dat met de AVG te maken? Blijkbaar wordt hier verwacht dat GDPR er voor zorgt dat alle informatie in alle gevallen privé is, maar dat is helemaal niet?? De AVG zorgt er vooral voor dat die gegevens voor geen andere doeleinden gebruikt mogen worden dan dat ze bedoeld zijn.

[Jefm]

Ja... zo werkt dat nu eenmaal? Wat heeft dat met de AVG te maken? Blijkbaar wordt hier verwacht dat GDPR er voor zorgt dat alle informatie in alle gevallen privé is, maar dat is helemaal niet?? De AVG zorgt er vooral voor dat die gegevens voor geen andere doeleinden gebruikt mogen worden dan dat ze bedoeld zijn.

Dus deze identificeerbare persoonsgegevens horen niet thuis in een database die de systeembeheerder zelf nog eens gaat aanleggen, want dan dienen ze niet voor het doeleinde waarvoor ze bedoeld zijn

[meon]

Je hebt geen relatie met je systeembeheerder, maar met je werkgever .

Je systeembeheerder werkt in opdracht van je werkgever, als organisatie, en beheert daar de systemen en heeft daar dus ook de bijhorende toegang tot data mee.

Opnieuw: de AVG gaat over vermijden van misbruik (door bijvoorbeeld bewaartijd van gegevens te bepalen, de mogelijkheden tot verspreiding, de verantwoordelijkheden, ...). Alle dingen die hier opgesomd worden vallen onder normaal gebruik van gegevens.
Als een werkgever dus in je mailbox wilt kunnen kijken spreken we eerder over briefgeheim.

Maar realistisch... systeembeheerders hebben vaak zo belachelijk veel toegang tot informatie dat je daar als eindgebruiker niet bij stilstaat. De meesten hebben geheimhoudingsclausules in hun contract, maar de meesten zijn letterlijk niet geïnteresseerd in al die informatie. Dus ja, een systeembeheerder zou je wachtwoord kunnen hebben... maar waarschijnlijk heeft ie dat niet eens nodig.

[ITnetadmin]

Soms is er ook gewoon het praktische.
Destijds in het onderwijs kregen de leerlingen pwd van 4 cijfers toegekend, als een pincode.
Die geldde zowel voor het online platform als voor de lokale login op pc.
En die konden ze niet wijzigen, en stond in lijsten zodat het secretariaat ze kon opzoeken wanneer ze, voor de zoveelste keer, hun pwd vergeten waren.

De zwaarste beveiligingsupdate die ik daarin doorvoerde, was de lijsten op donkerrood papier afdrukken (dat kopieert niet zonder sporen na te laten), te nummeren, en bij te houden welke lijst aan wie toegewezen was, want die lijsten werden al wel ns gekopieerd door lkr die wilden lesgeven ipv hun lln constant naar het secretariaat te sturen, en dan lieten ze die uiteraard nonchalant rondslingeren.

Nu is dit uiteraard van een compleet andere aard dan pwd bijhouden van werknemers.
Hoewel ik ook daar vaak de pwd van kende, ze gooiden ze bijna in je schoot als je iets moest fixen of testen op hun account.

En dan was er het incident met een onderwijs inspecteur die wenste dat ik pwd van leerkrachten doorstuurde om te kunnen controleren of de leerkracht afstandsonderwijs zijn job goed deed.


Als sysadmin *wil* ik uw pwd niet kennen; als ik in uw account wil geraken heb ik genoeg andere methodes, en aan uw persoonlijke folder op de shares kan ik zoiezo aan.


PS: lang lang geleden heb ik ooit ergens gewerkt waar we ons gewenste pwd op papier moesten invullen.

[ubremoved_2964]

lang voor de GDPR werkte ik als linux admin bij een medisch bedrijf

op een bepaald moment kwam de personeelsverantwoordelijke bij iedereen langs, en we moesten ons paswoord op een briefje schrijven, wat in een envelop ging, die dan in de kluis ging

waarom ze dat nodig hadden was altijd een raadsel

maar ik heb dat slim gecountered, ik stuurde dan een mail naar de personeelsverantwoordelijke :

kan u mij bevestigen dat ik mijn passwoord op een briefje in een envelop aan u heb overhandigd

waarop ze antwoordde: ik heb van u een envelop gekregen, maar de inhoud is mij onbekend

toen ik dat op email had, heb ik direct mijn passwoord weer aangepast

[meon]

Vanuit een systeembeheerders-perspectief zie ik eigenlijk geen enkele reden om het wachtwoord van iemand te moeten weten...
De enige keren dat zoiets nodig kan zijn als een probleem zich enkel onder zijn/haar account voordoet, en dan nog gaat dat eigenlijk altijd via screensharing.

Want ja, ik kan aan je homedrive. Ik kan aan je afdelings-share. Ik kan aan je Private Channels in Teams. Ik kan aan jouw Bitlocket-geëncrypteerde lokale harde schijf. Ik kan in je mailbox. Ik kan mails sturen vanuit jouw naam. Ik kan zien welke mails je stuurt, ook al verwijder je ze meteen. Ik weet het meteen als je callofduty.exe uitvoert. Ik weet naar welke sites je gesurfd hebt.

Of beter: dat zou ik kunnen, zonder dat je daar zelf iets van merkt. En dat gebeurt vaker dan je denkt. Misschien moet ik je homedrive naar een andere server migreren. Of mislukt een backup van Teams. Of moet er een driver bijgewerkt worden op je laptop. Of moet er een phishing-campagne verwijderd worden uit je mailbox. Of moet vermeden worden dat werklaptops voor spelletjes gebruikt wordt, of om naar goksites te surfen.

Onderling onder systeembeheerders resetten we mekaars wachtwoord bijna continu. Want bij klant A vervalt die om de 45 dagen, daar om de 30, bij klant C elke 180 dagen...

Nuja, ik spreek nu wel over IT-organisaties waar duizenden gebruikers beheerd worden. Ik kan me voorstellen dat bij KMO's niet zo nauw gekeken wordt naar procedures als heel de ICT-afdeling uit "Peter van de IT" bestaat.

[ubremoved_2964]

Vanuit een systeembeheerders-perspectief zie ik eigenlijk geen enkele reden om het wachtwoord van iemand te moeten weten...
De enige keren dat zoiets nodig kan zijn als een probleem zich enkel onder zijn/haar account voordoet, en dan nog gaat dat eigenlijk altijd via screensharing.

Bij de laatste opdracht was er bij een bank de integratie tussen LDAP en cyberark, oh boy wat heb ik daar op gevloekt vanwege de vele bugs, maar er zijn genoeg oplossingen waarbij je nooit het passwoord van een admin moet kennen. Cyberark ging veel verder dan bvb een sudo, omdat het alle keystrokes logde, en een volledige video kon maken van wat iemand gedaan had.

[DarkV]

op een bepaald moment kwam de personeelsverantwoordelijke bij iedereen langs, en we moesten ons paswoord op een briefje schrijven, wat in een envelop ging, die dan in de kluis ging

Zoiets mag men gewoon niet vragen en is tegen alle regels in !

Als men ooit toegang nodig heeft tot je account (al kan men zo toch al veel zien) kan men dat resetten en dan is er een spoor van.

[ubremoved_2964]

Zoiets mag men gewoon niet vragen en is tegen alle regels in !

Als men ooit toegang nodig heeft tot je account (al kan men zo toch al veel zien) kan men dat resetten en dan is er een spoor van.

Dat was een degoutant bedrijf - de baas van IT had blijkbaar een profiel van een dame gehijacked wat dan nog op elke nieuwe PC werd uitgerold.
Omdat ik die image moest uitrollen, en ik uiteraard rondkeek wat er in de distro zat die hij had samengesteld, vond ik jpg's met info over het vrouwelijk orgasme.

De dame in kwestie zou dat nooit doen, en toen ik dit euvel aankaartte met de baas van IT, moest ik zwijgen over deze kwestie.

Hij is nadien als een gek naar de server room gelopen, heeft die browser cache gedelete in haar profiel op de NT server, en is dan een defrag begonnen in de hoop dat defragmentatie de gedelete bestanden in haar profiel zou opkuisen.

Omdat deze man mij regelmatig chanteerde had ik een shitload aan bewijzen verzameld.

In dit bedrijf is ook bijna een moord begaan en dit heeft het nieuws gehaald. Pesten was de bedrijfscultuur.