Enterprise-wachtwoordmanager Passwordstate is getroffen door supply chain attack

Passwordstate, een wachtwoordmanager voor bedrijven, is getroffen door een supply chain attack. De aanvallers zaten ongeveer 28 uur lang in de leveringsketen van de software, maar hoeveel van de meer dan 29.000 klanten getroffen zijn, is niet bekend.

Onder andere het Deense securitybedrijf CSIS Group schrijft over de aanval. De aanvallers braken in bij de systemen van ontwikkelaar ClickStudios en plaatsten daar een software-update voor de self-hosted-wachtwoordmanager. Die vervalste update bevatte een aangepaste versie van 'Moserware.SecretSplitter.dll', met een 'Loader' aan boord die contact zocht met een server die in handen was van de aanvallers. Daar zou de malware de payload ophalen, maar het is onbekend wat daarin zou zitten; CSIS heeft die niet kunnen bemachtigen omdat de server al offline is.

ClickStudios heeft een onbekend aantal klanten per e-mail op de hoogte gebracht en treedt naar buiten met een publiekelijk bericht. In dat bericht stelt het dat de malware onder andere gebruikersnamen, wachtwoorden en een lijst van draaiende processen naar de server van de aanvallers zou sturen. Ook staat er in het bericht dat het 'erop lijkt dat zeer weinig klanten getroffen zijn, hoewel daar met nieuwe informatie verandering in kan komen'. De aanvallers zouden niet bij ClickStudios binnengekomen zijn met behulp van gestolen of zwakke wachtwoorden.

Het Australische bedrijf komt met een hotfix om het geïnfecteerde bestand te vervangen. Ook raadt het aan om alle wachtwoorden te vervangen bij aan het internet blootgestelde systemen, interne infrastructuur en alle wachtwoorden die in Passwordstate opgeslagen staan.

Reacties (105)

[japie06]

Zeer verontrustend bericht. Het is belangrijk dat mensen ook 2FA gebruiken voor hun meest belangrijke diensten (email, cloud, bank, digid etc).

Ik ben (nog steeds) een groot voorstander van password managers, maar het blijft niet 100% veilig. Je zult echt meer beveiliging moeten hebben dan alleen een wachtwoord.

[IStealYourGun]

Volgens mij is deze oplossing eerder gericht op situaties waar geen persoonlijk wachtwoord mogelijk is zoals root wachtwoorden, sql accounts, service accounts,... Voor veel van die situaties bestaan er passwordless alternatieven (certificates, gmsa, pgp,...) maar dan moet de applicatie dat wel ondersteunen en dat gebeurt nog veel te weinig.

Gmsa is volgens mij ondertussen +10 jaar oud en toch zie je dat weinig applicaties dat ondersteunen.

[ro4sho]

Ik vraag me altijd af hoe imap beter beveiligd kan worden. 2fa is vaak niet standaard geïmplementeerd. Hoe denk jij daarover?

[Jeroen]

Misschien VPN

[ro4sho]

Ik bedoel meer dat veel website hosters toegang tot e-mail via standaard IMAP of POP geven.
Als ik bijvoorbeeld mijn e-mail box op mijn telefoon wil openen dan moet ik IMAP of POP gebruiken. Er is nog geen standaard om daar een VPN of 2FA voor te gebruiken naar mijn weten.

[Jeroen]

Ik dacht meer aan de context van een bedrijfsnetwerk inderdaad. Voor persoonlijk gebruik weet ik niet of er aanbieders zijn die het zo doen, maar misschien is dat niche genoeg om zelf te moeten hosten. Aanbieders met 2FA voor email zijn er natuurlijk wel met webmail.

[fendt]

Eens. Maar even een vraag als leek op dit gebied: is een dergelijke hack te wel voorkomen met 2FA?

[japie06]

Als ik het artikel goed begrijp hebben de aanvallers wel de daadwerkelijke opgeslagen wachtwoorden kunnen bemachtigen. Maar als je emailaccount 2FA heeft, zouden de aanvallers daar niet in kunnen loggen.

Misschien wel een les voor sommige. Aangezien sommige wachtwoordmanagers ook een 2FA functie (TOTP) hebben voor externe websites. Of als je de backupcodes in dezelfde kluis opslaat, kunnen aanvallers als nog in je account komen.

[Het.Draakje]

Zoals IStealYourGun stelt, het is een enterprise password manager. Die gebruik je niet voor jouw email-credentials maar omdat je (o.a.) de sa van je database of de unix root wilt delen. (Delen omdat je meerdere dba's hebt of omdat als je dba onder de tram ligt, dat je dan nog steeds sa toegang tot je database kunt hebben).

Ik moet de eerste database nog zien waarbij de sa via 2FA aanlogt. Hetzelfde voor een Unix server, aanloggen van root met 2FA heb ik nog niet gezien.

[jvwou123]

Je kunt ssh met 2fa doen: dit is voor bv ubuntu 16.04 geschreven maar ook op gewoon debian werkt dit nagenoeg hetzelfde: https://www.google.nl/amp...r-ssh-on-ubuntu-16-04.amp

[Cybertinus994]

Met een Unix server is triviaal om 2FA te hebben om root te worden. Zet via SSH aan dat je alleen met keys in mag loggen en niet als root (wat je hopelijk al hebt) en je hebt je 2 factors voor root toegang al. 1. De key om als normale user in te loggen 2. Het benodigde wachtwoord om root te worden (en in deze maakt het niet uit of je sudo of su gebruikt)

Daarnaast kan je ook een Yubikey configureren om daar een OTP mee in te vullen tijdens het inloggen, eventueel naast een ssh key dus.

Verder kan je ook 2FA met Duo doen, dan log je in met ssh key en daarna krijg je op je telefoon een pushbericht in de Duo app en daarin moet je de login accorderen. En alleen daarna kom je binnen.

Vele opties om 2FA te krijgen op Unix. En ja, al deze opties heb ik in de praktijk gezien

[Het.Draakje]

Tenzij ik jullie niet begrijp, het gaat niet om aanloggen met ssh.

Je logt aan op het systeem met je persoonlijke credentials. (Als het goed is kan root niet rechtstreeks aanloggen). Uiteraard is het "handig" als dat met 2fa gaat.

Vervolgens moet je iets met het systeem doen, dus su - (switch user root). Gaat dat dan vervolgens ook met 2fa? Vandaag moet ik het systeem updaten en doe ik de su - en morgen mag jij dat en doe jij de su -. Gaat dat nog bij de juiste telefoon uitkomen?

Vervolgens heb je / jouw collega's ook nog (een aantal) windows server(s) en daar moet je ook admin werkzaamheden op doen (bijv. de windows patch installeren). Remote connection vanaf een veilig workstation. Diverse gebruikers van administrators. Werkt dat ook met 2fa. En naar de juiste telefoon / yubikey?

Aanloggen op unix via persoonlijk account. su oracle. Start oracle, log aan in Oracle als sa. 2FA ? Eveneens meerdere personen, gaat dat allemaal goed?

[Zwatelaar]

Ik ben geen syteembeheerder, verre van. Dus excuses als ik de plank volledig mis sla.

Uit je verhaal maak ik op dat voor beheerszaken jij en je collega dezelfde login gebruiken. Je stelt daarbij de vraag naar welke telefoon dan de 2fa vertuurd moet worden.

Nogmaals, ik ben geen systeembeheerder, maar wordt het niet tijd dat iedereen zijn eigen login krijgt?

[Het.Draakje]

Uiteraard heeft ieder zijn eigen log-in. Maar als je het systeem moet updaten zal je toch toegang moeten hebben tot root. Of windows-administrator. Of het system-account van de database. Of de web-administrator of het applicatie account.

Je gaat geen 15 user's met rootrechten creëren op vijftig unix servers, waarvan sommige meerdere oracle databases hebben. Of persoonlijke admin op een paar honderd windows servers.

[Zwatelaar]

Waarom niet? Iedere user heeft toch ook zijn eigen login.

Maak je je keuzes op de IT-afdeling op (in)convenience. Well, there lies the problem. Dan heeft het geen nut om dan vervolgens te zeuren over de gevolgen.

Als je een systeem beheert met 15 admins, dan heb je waarschijnlijk ook een paar honderd users.
Waarom dan wel zoveel users creëren?
Of maak je dan ook maar één user per afdeling?
Naast die paar honderd users maakt die 15 admins toch ook niet zoveel uit?
Het is toch gewoon best-practice?
Of geldt dat alleen voor de simpele users (zoveel mogelijk restricties) maar niet voor de almighty-admins?

Maar ja, wat weet ik er nou van.

[Het.Draakje]

Gebruiker start een rapportage. Duurt normaal 8 uur voor het klaar is. Blijkt de verkeerde maand te zijn. Even killen, want je gaat niet wachten totdat het gereed is om daarna de juiste rapportage op te starten. (Je wilt ook geen twee rapportages draaien vanwege mogelijke dead-locks).

Rapportage: unix deamon stuurt request naar database (select accounts), de child stuurt vervolgens per account een database request voor de gegevens per account en stuurt dat naar een windows applicatie die daar een mooi rapportje van maakt (en vervolgens stuurt die unix deamon weer een nieuw child request naar de database voor het volgende account.

Unix deamon draait (uiteraard) onder zijn eigen account. Hoe ga ik dat killen. Inderdaad door ook aan te loggen onder dat account (of root). Hoe ga je de database querie killen (door gebruik van de applicatie owner of sa). Hoe ga je die windows applicatie killen (door gebruik van de applicatie owner of admin). Gooi even de print-queue leeg (Applicatie owner of admin).

Herstart even de web-site. Heb je toegang tot de web-applicatie-user nodig. Want die wil je niet onder je eigen credentials starten. Want dan kan jouw collega, en de gescripte herstart (in de nacht voor de backup) opeens jouw deamon niet meer stoppen.

Kortom allemaal situatie's waarin je vanuit een werkende shell/windows sessie even een switch moet doen naar een andere user.

Nu heb ik applicatie-owner x nodig en een half uur later heeft mijn collega het nodig. 2FA challenge naar een ander toestel?

Zo min mogelijk toegang geldt ook voor admins. Je geeft geen admin alle rechten op alle servers en databases. Je draait je applicatie's niet onder system (root) account. Maar onder hun eigen dedicated account.

[ViperXL]

Het klopt niet helemaal wat je zegt. Het "least privileges" model zou moeten worden toegepast. In Windows en volgens mij ook Linux kun je verschillende rechten aan accounts geven wat betekend dat je lang niet altijd full admin/root nodig hebt.

Ik zie heel veel binnen bedrijven dat er enkel user en admin/root is terwijl je dit echt wel kunt segmenteren.

[Het.Draakje]

Uiteraard is het mogelijk dat je in Unix rechten krijgt om een bepaalde applicatie/daemon te starten. Maar als je dat doet dan kan alleen jij of root die applicatie/daemon killen. En dat is niet gewenst.

Daarom geef je in windows mensen rechten om een bepaalde server als local admin of applicatie owner via rdp over te nemen. Of in unix een su naar een andere gebruiker te doen. En dan kan je die root of applicatie owner gewoon als non-log-on definieren.

[Zwatelaar]

Je doet enorm je best om jouw werkwijze te verdedigen.
Driekwart begrijp ik niet of kan het niet checken of dat zo is. Misschien ook niet relevant, als je het zelf maar begrijpt.
Het komt een beetje over als: het is gvd ontzettend veel werk om dat goed ingeregeld te krijgen, gaan we dus niet doen.

Mijn achtergrond, financiële systemen. Bij ons is het een doodzonde als er ook maar een simpelste handeling gedaan wordt zonder te loggen welke user dat was. Daarom bestaat er geen account die door meerdere mensen gebruikt kan worden. Omdat de vraag niet is of het een keer misgaat, maar wanneer. Dan wil je altijd terug kunnen gaan naar point-of-failure.

Mocht er bij jullie ooit een keer iets misgaan, kom je dus niet verder dan, eeuh moet wel één van die 15 mensen van IT zijn, Joost mag weten wie.

Mocht ik daar werken, zou ik om de boel wakker te schudden een database grab doen.

[Het.Draakje]

Dat wordt wel degelijk gelogd. Wij weten het wachtwoord niet. Je krijgt het password alleen via de enterprise password manager. En na afloop van jouw werkzaamheden geef je het wachtwoord vrij en wordt het password automatisch aangepast.

Inderdaad, ik werkte bij een financiële instelling. (Nu pre-pensioen).

[Reactie gewijzigd door Het.Draakje op 23 juli 2024 02:34]

[satya]

Als je het heel strict inregeld, dan maak je eens stepping stone waar je (groepen) gebruikers alleen maar via snelkoppelingen op de toegang geeft tot de plek waar ze moeten wezen, een wachwoordmanager regelt dan de aanmelding voor je die afhankelijk is van je account, in ons geval is dat Evidian, welke je zelfs op desktop nivo gebruiken kan.

Je hoeft dan alleen de toegang tot de steppingstone goed in te regelen via 2fa en vpn bijvoorbeeld, zo houd je meteen per taak (applciatief/systeemtechnisch/netwerk) je gebruikers meteen uit elkaar omdat je je beheer in compartimenten opdeeld.

In elk geval is het bij ons zo ingeregeld. Zelfs systeembeheerders kennen wachtwoorden op de systemen niet, dus kunnen ook geen taken uitvoeren die buiten hun rechten of competentie liggen.

[BugBoy]

Strikt genomen is hetgeen je in de eerste alinea schrijft geen 2FA, omdat je enkel dingen hoeft te weten. De truc van MFA is juist dat je vaak iets moet weten en iets moet hebben. Enkel al het feit dat elk systeem een root gebruiker heeft is al genoeg om je SSH access uit te zetten. Je hoeft dan enkel het wachtwoord te raden en anders moet je ook de username nog eens weten.

Ik heb helaas geen ervaring met HashiCorp Boundary. Dat lijkt eigenlijk best een aardige oplossing te zijn om toegang te geven tot verschillende systemen. Je wilt eigenlijk geen wachtwoorden hoeven te geven aan medewerkers (behalve om als "zichzelf" in te loggen) voor admin accounts. Als iemand uit dienst gaat is het niet triviaal om alle beheeraccounts te veranderen. Ben wel benieuwd of er mensen ervaring hebben met dit soort producten...

[Het.Draakje]

Ervaring met CyberArk.

Je log 'normaal' in (al dan niet met 2FA). Je logt persoonlijk aan in CyberArk (persoonlijk account) en vraag wachtwoord van root op server x. Wordt getoond of je kon (bepaalde systemen) rechtstreeks inloggen. E.e.a. wordt in CyberArk gelogd en geblokkeerd (niemand anders kan op dat moment root op die server worden). Je doet je ding. Vervolgens geef je het wachtwoord weer vrij in CyberArk. CyberArk verandert op dat moment meteen het root wachtwoord op de server. Tenzij je gebruik maakt van hard-coded wachtwoorden, die worden niet aangepast.

Anderen kunnen zien dat je een wachtwoord in gebruik hebt. Uiteraard rapportage voor het management (Piet heeft vergeten het wachtwoord vrij te geven, etc.)

Eenmaal opgezet, werkt het prima.

[fastedje]

Je kan in de sshd config gewoon toegang voor de root user uitzetten. Verder kan je ook password authentication uitzetten en een publik/private key pair gebruiken, Beter is het nog om SSH certificaten te gebruiken en specifieke princpals voor de locale users in te stellen. Je kan dan voor iemand zijn public key een cert genereren met zeer specifieke toegang met zelfs een start en eindtijd/datum.

[McBacon]

Hetzelfde voor een Unix server, aanloggen van root met 2FA heb ik nog niet gezien

Daar heb je PAM voor. Ik weet sowieso dat er een module is voor TOTP (libpam-google-authenticator) en er was er ook iets voor push notifications via Duo. Als ik het me goed herinner is er zelfs een mogelijkheid om zowel password als SSH key te vereisen; je logt dus eerst in met user+password en daarna checkt ie nog ff of de key die je doorgeeft ook klopt. PAM kan ook werken voor local logins en niet alleen remote/SSH.

Voor MySQL/MariaDB kun je ook inloggen via PAM, op dezelfde manier zou je dus 2FA kunnen regelen voor je databases. Voor SQL Server/MSSQL kun je alleen in laten loggen via het domein, waarbij de AD dan de 2FA regelt. Het standaard "sa" account zou je dan kunnen disablen, beetje hetzelfde idee als het Windows built-in Administrator account disablen (of je dat moet willen is iets anders).

Overigens kan Passwordstate ook TOTP tokens genereren, dus die secrets zijn hoogstwaarschijnlijk ook gejat als je de malicious update hebt geïnstalleerd. Verder kun je het prima privé gebruiken, het is namelijk gratis tot 5 users. Je kunt password lists privé houden, dus je eigen emailaccount (of andere private accounts) erin zetten is ook gewoon mogelijk.

[lunnie]

Password state heeft ook de mogelijkheid om private wachtwoorden op te slaan.

[ThoffeGast]

Of het wachtwoord voor je cloud based 2fa app in je password manager hebben zitten ... 🤔

[woopdiedoo]

Beetje offtopic, maar voor huis-tuin-keuken gebruik vind ik het wel een beetje ingewikkeld worden zo. TOTP beschermt je niet tegen een database breach, want de server heeft het token ook opgeslagen. Bovendien schiet je er dus niks mee op als je het token in je wachtwoordmanager opslaat, want op het moment dat je kluis succesvol doelwit wordt van malware, hebben ze beide authenticatiefactoren in een keer. Maar de tokens zul je toch echt ergens moeten backuppen, want je wilt ze niet kwijt raken. Dus ergens op papier schrijven (wat als er brand uitbreekt?), of in een andere kluis bewaren (je zult een extra wachtwoord moeten onthouden).
Als je al een wachtwoordmanager gebruikt met sterke, unieke wachtwoorden die je regelmatig wijzigt, dan klinkt 2FA met TOTP voor mij persoonlijk als een hoop gedoe om je te beschermen tegen een vrij kleine bedreiging, namelijk die van malware die lokaal je wachtwoorden uit je kluis jat. Je kunt je tegen de specifieke aanval die dit artikel noemt beschermen door je wachtwoordmanager te sandboxen (geef hem bvb geen internet toegang).

[Deedss91]

Met 2FA heb je altijd die extra stap die een gebruiker moet nemen om in te loggen. Bijvoorbeeld een nummer invoeren vanuit een authenticator app op de telefoon, of een akkoord geven via een app op de telefoon. Heb het met mijn microsoft account waarbij ik in de app op de telefoon een extra bevestiging moet aantikken, en dat werkt best goed. Dus ook al zou je wachtwoord gehackt worden in zo'n dergelijke situatie, dan kunnen hackers nog steeds niet inloggen met enkel het wachtwoord als jij 2FA gebruikt.

[Reactie gewijzigd door Deedss91 op 23 juli 2024 02:34]

[KeesAlderlieste]

tenzij ze inbreken op een pc waar de optie 'vertrouw deze browser' aan staat, dan komt de 2fa vraag niet...

[logix147]

Dat is natuurlijk niet het geval als je password manager host zoals in dit geval getroffen is.

2FA is altijd beter dan alleen met wachtwoord inloggen, ook al moet je die extra handeling uitvoeren. Het kost altijd minder tijd/geld/moeite dan als je gegevens bij ongewenste derde partijen terecht komen.

[BugBoy]

Dat vinkje zet je natuurlijk ook enkel aan op apparaten die je vertrouwt. En dan nog is het 2FA, want je hebt nog steeds twee zaken nodig. Je hebt het wachtwoord nodig en (toegang tot) de laptop/telefoon. Met 2FA wil je vooral voorkomen dat mensen toegang krijgen tot je account. Als ze al in iemands laptop zit dan ben je al ernstig gecompromitteerd.

Systemen waar beveiliging echt belangrijk is moet je die optie gewoon niet gebruiken en elke keer de overhead op de koop toe nemen. Overigens moet je je ook bedenken of alles inderdaad via een admin-account moet en of je het systeem wel goed heb ingericht. Maar soms is dat zoveel werk dat het toch maar zo gebeurd (ook niet gek).

[Mike2k]

De hack is hiermee niet te voorkomen, de gevolgen zullen wel minder zijn aangezien je met 2FA niet meer alleen met het wachtwoord kunt inloggen. Dus zelfs al heb je het wachtwoord, heb je nog steeds de 2de authenticatie methode nodig (bijvoorbeeld email, sms, etc)

[ShopHB]

E-mail is dan niet geschikt meer.... ervan uitgaande dat je die wachtwoorden ook hebt opgeslagen...

[ViperXL]

Inderdaad zoals @japie06 aangeeft zou het tegenwoordig eigenlijk een verplichting moeten zijn om een wachtwoordmanager EN 2FA te gebruiken.

Zoals @ShopHB aangeeft is email niet verstandig om meedere redenen, SMS is ook al "achterhaald" dus enkel icm een authenticator app is het "veilig".

Beveiliging is een process van meerdere lagen in zowel de technology, bedrijfsvoering en de mensen zelf.

[timoootjex]

Ik moet nog eens werk maken van al mijn 2fa sms uit te schakelen want heb die nog als backup optie.

Ik twijfel om eventueel yubikey te kopen voor mijn emails en belangrijkste accounts.
Wat denk jij over over een hardwarekey?

[Reactie gewijzigd door timoootjex op 23 juli 2024 02:34]

[ViperXL]

Hardware keys zijn in de basis goed, er zijn wat problemen geweest helemaal in het begin maar de huidige generaties zijn solide qua beveiliging. Implementatie van hardware keys in bedrijven kan soms wel een hel zijn maar het is zeker wel een goede optie.

[aadje93]

tot het email adres dan ook in die password manager staat

[CAPSLOCK2000]

Dat is zo'n vraag waarbij er een enorm gat zit tussen theorie en praktijk.
In praktijk betekent 2FA eigenlijk altijd een wachtwoord + iets anders. In theorie zegt 2fa alleen dat er twee sloten de deur zitten, niet dat een van die twee sloten een wachtwoord moet zijn. Een vingerafdruk en een pincode is ook een vorm van 2FA. Maar in praktijk zit er bijna altijd een wachtwoord bij.

In het artikel staat dat ze niet met behulp van een wachtwoord binnen zijn gekomen. De versie van 2FA die de meeste mensen uit de praktijk kennen had dan niet geholpen. Maar het principe blijft wel staan. Twee sloten is beter dan één. De aanvallers zijn binnen gekomen dus er is een beveilging verbroken. Een tweede vorm van beveiliging was beter geweest.

Maar uiteindelijk zijn inbraken nooit helemaal te voorkomen.

[haam]

Lastige is dat de meest logische plek om je recovery codes op te slaan ook de password manager is (want altijd encrypted).

Dus als ze eenmaal binnen zijn, helpt (in dat geval) 2FA ook niet

[Groningerkoek]

De hack zeer waarschijnlijk niet, maar bij 2FA heeft het uitlekken van wachtwoorden vaak een veel kleinere impact.

[L0g0ff]

Nope, als ik het zo lees zetten ze een achter deur open door die software update.

Je kunt nog zoveel sloten (2fa) op de voordeur zetten, als je achterdeur open staat heeft ben je hier niet tegen beveiligd.

[Pep7777]

Er spelen hier 2 verschillende dingen

1) De hack op de aanbieder van een password manager
2) 2FA voor jezelf

Het eerste kan jij helemaal niks aan doen ook niet met je eigen 2FA.

Maar als je voor jezelf wel een 2de manier hebt als extra check dan is het uitlekken van een password niet gelijk een probleem. De hackers hebben dan wel een password maar niet je 2de manier van toegang.

[System]

op naar 3FA? Of is dat al een ding?

[RobIII]

MFA (multi-factor authenticatie) is al lang een ding ja.

* Iets wat je weet (wachtwoord, pin)
* iets wat je hebt (raboreader, usb stick, 2fa app, ...)
* iets wat je bent (vingerafdruk, iris, ...)
* locatie/tijd (bepaald netwerk IP bijv)

2FA is gewoon een greep van 2 uit die 4z

Maar ik zie niet hoe 3FA het anders gemaakt zou hebben dan 2FA?

[System]

ah ja op die manier.
Ik dacht eerder aan bv de klassieke 2FA code + bv een ubikey + WW

[Anoniem: 1576590]

* Iets wat je weet (wachtwoord, pin)
* iets wat je hebt (raboreader, usb stick, 2fa app, ...)
* iets wat je bent (vingerafdruk, iris, ...)
* locatie/tijd (bepaald netwerk IP bijv)

De vraag is of een wachtwoord dat ik niet ken maar mijn wachtwoordmanager voor mij "weet" en onthoudt nog wel onder de eerste categorie valt.

Om de risico's te helpen inschatten is het daarom zinvol om de sterkte van elk van die items in de schatten, en die varieert nogal.

Vooral als je je een belangrijk aspect van elk van die items realiseert dat zelden (in één adem) genoemd wordt, en ik eerder in deze draad hier beschreef (waarbij het mij ontgaat waarom ik daar -1 voor krijg, ik ben bloedserieus).

[RobIII]

De vraag is of een wachtwoord dat ik niet ken maar mijn wachtwoordmanager voor mij "weet" en onthoudt nog wel onder de eerste categorie valt.

Zolang je een tweede (derde, ...) factor hebt is het niet heel relevant (all else being equal). STEL dat je wachtwoordmanager je wachtwoord gelekt heeft (en zoals je hier ziet gebeurt dat dus): dan kan diegene die je wachtwoord heeft nog steeds weinig omdat diegene je overige factor(en) mist. Natuurlijk is 't niet fijn als je wachtwoord(en) op straat liggen en natuurlijk hoor je ze aan te passen dan. Maar ik heb veel liever voor elke site een eigen, uniek, fatsoenlijk wachtwoord dan 1, of een handvol, wachtwoorden die ik overal gebruik. Dan maar een wachtwoordmanager.

Het punt is simpelweg dat mensen er nogal een handje van hebben om geboortedatum + naam huisdier of zoiets onnozels als wachtwoord te kiezen; dat doe je bij het (fatsoenlijk) gebruik van een wachtwoordmanager niet (meer). Al mijn wachtwoorden zien er als volgt uit: "7VPHMp7V9^qNQr5hBTboEgTsJ" - tenzij sites achterlijke beperkingen hebben van 'max. 12 tekens' en dat soort onzin - en dan nog haal ik daar dan 't maximale uit. En de crux: voor ELKE site gebruik ik een ander wachtwoord. Dat is zonder wachtwoordmanager ondoenlijk (ook niet op een velletje papier tenzij je telkens 25 random tekens wil overtypen).

Om de risico's te helpen inschatten is het daarom zinvol om de sterkte van elk van die items in de schatten, en die varieert nogal.

De sterkte zit 'm in de combinatie van de factoren, niet zo zeer in de factoren an-sich.

Zelf vind ik de biometrische factor technisch altijd wel heel leuk en knap, maar ik kan mijn vingerafdruk of iris niet wijzigen en daar heb ik er maar een gelimiteerd aantal van Neemt niet weg dat 't een hele goeie extra factor kan zijn.

[Reactie gewijzigd door RobIII op 23 juli 2024 02:34]

[Anoniem: 1576590]

Zolang je een tweede (derde, ...) factor hebt is het niet heel relevant (all else being equal). STEL dat je wachtwoordmanager je wachtwoord gelekt heeft (en zoals je hier ziet gebeurt dat dus): dan kan diegene die je wachtwoord heeft nog steeds weinig omdat diegene je overige factor(en) mist.

Ik vrees dat dit in de praktijk vaak erg tegenvalt: in veel gevallen zijn er wachtwoord-reset procedures met zwakkere authenticatie. Vaak alleen het toegang hebben tot een mailbox, en als jouw wachtwoord daarvan gecompromitteerd is, is de ellende compleet.

En als het device waarvanaf je inlogt zelf gecompromitteerd is, bijv. via een foute wachtwoordmanager-update, heeft MFA niet veel zin meer.

Een probleem bij "enterprise" wachtwoordmanagers is dat deze gebruikt worden om systemen te beheren die, out of the box, geen MFA ondersteunen en waarvoor het toevoegen daarvan als ballast wordt gezien. En zelfs een risico vormt: een mission critical systeem niet kunnen beheren omdat een tweede factor om de een of andere reden niet beschikbaar is, is gewoon een risico.

Ik vermoed dat de kans dat een (andere dan wachtwoord-) authenticatiefactor in verkeerde handen valt in veel situaties groter is bij andere dan een sterk en goed geheim gehouden wachtwoord. Uiteindelijk leiden alle factoren tot een soort van shared secret, waarbij we (door ervaring wijs geworden) -bij wachtwoorden- een afgeleide daarvan opslaan op servers. Bijv. bij Authy (of andere TOTP apps zoals Google Authenticator) is sprake van een shared secret dat plain text op de server wordt opgeslagen, en daarmee diefstalgevoeliger is.

Dan maar een wachtwoordmanager.

Eens. Ik gebruik al jaren KeePass en moet eerlijk zeggen dat ik screenshots van Authy-achtige QR-codes daar ook in bewaar, en dat n.a.v. dit incident heroverwerg.

Het punt is simpelweg dat mensen er nogal een handje van hebben om geboortedatum + naam huisdier of zoiets onnozels als wachtwoord te kiezen;

Klopt, drama. Maar als je fatsoenlijke wachtwoorden gebruikt (zoals jij), wegen de nadelen van een tweede factor dan nog wel op tegen de voordelen?

Zelf vind ik de biometrische factor technisch altijd wel heel leuk en knap, maar ik kan mijn vingerafdruk of iris niet wijzigen en daar heb ik er maar een gelimiteerd aantal van Neemt niet weg dat 't een hele goeie extra factor kan zijn.

Ik gebruik mijn pink om mijn smartphones te ontgrendelen (met als noodzakelijk alternatief een irritant lang wachtwoord) maar dat is dus 1FA.

Het probleem hier is een softwareleverancier met een onverantwoord slechte update-methode waarbij unsigned binaries worden gedistribueerd zonder integriteitscheck (zie mijn analyse hierover op security.nl).

Kortom, dit is een dramatisch incident (wel leerzaam), maar ik ben er nog niet van overtuigd dat dit de aanleiding moet zijn om overal MFA op te zetten; zonder back-up betekent het verlies (of mogelijke diefstal) van een Yubikey o.i.d. ook ellende.

[Reactie gewijzigd door Anoniem: 1576590 op 23 juli 2024 02:34]

[Webgnome]

Ik denk dat dit een wijze les is dat 'de cloud' een synoniem is voor 'somebody elses computer'. Oftewel persoonlijk zou ik NOOIT een password manager cloud dienst afnemen ( en dat doe ik dan ook niet) juist omdat het mijn wachtwoorden zijn.

[Mrloki]

Het gaat in dit geval juist om een password manager die je in een eigen omgeving kunt hosten. Deze draait dus niet in de cloud maar op je eigen server.

Dat maakt deze hack extra zuur omdat zelfs als de server niet extern bereikbaar is je kwetsbaar kunt zijn voor deze hack.

[CH4OS]

Ook al zit er 2FA op een account en bemoeilijkt dat het inloggen op het account zélf, het blijft een datalek. Afhankelijk van hoe men de data bemachtigd heeft, kan men best een kopie hebben van de database en kan men vervolgens door de database te queriën bij jouw email bijvoorbeeld, dus dan maakt het niet meer uit of je 2FA hebt of niet.

Hiermee wil ik niet het gebruik van 2FA ontkrachten of zeggen dat het niet nuttig is, dat heeft het wel degelijk! Ik zeg alleen maar dat eenmaal binnen de deuren simpelweg open zijn en 2FA dan eigenlijk ook weinig nut meer heeft. Na een datalek dien je dus ook een nieuwe TOTP token te genereren!

[RobIII]

Ook raadt het aan om alle wachtwoorden te vervangen bij aan het internet blootgestelde systemen, interne infrastructuur en alle wachtwoorden die in Passwordstate opgeslagen staan.

Ik zou eens beginnen met een andere wachtwoordmanager. Shit happens, niets is 100% veilig of waterdicht maar: you had one job. Als wachtwoordmanager: Verknal je dat: doei, next.

[Blorgg]

Ik zou eens beginnen met een andere wachtwoordmanager. Shit happens, niets is 100% veilig of waterdicht maar: you had one job. Als wachtwoordmanager: Verknal je dat: doei, next.

Begrijpelijke reactie. Maar... welke password manager ken jij die nog nooit een issue heeft gehad? Ik ken er geen een. Zeker als je kijkt naar het product dat Passwordstate is dan zijn er niet zo heel veel die hetzelfde kunnen. Ik ben zelf bekend met Secret Server, Devolutions Server en dan Passwordstate.

Dit zijn allemaal pakketten die behoorlijk verder gaan dan enkel wachtwoorden opslaan. Er zijn er nog een aantal, maar het aanbod wordt al snel dunner. Ik hoor graag van alternatieven voor dit soort pakketten waarbij je on-premise enterprise-class wachtwoordbeheer kunt doen.

Wat dit issue met Passordstate betreft. Ik draai thuis Passwordstate. Overal waar gewerkt wordt worden fouten gemaakt. Wat voor mij belangrijker is dan zo min mogelijk fouten maken, is hoe men omgaat met de gemaakte fouten. Ik kreeg het verzoek om een dir-listing van mijn Passwordstate web server directory naar hen te mailen. Daaruit bleek dat mijn Passwordstate instantie niet gecompromitteerd was. Ook kreeg ik per email een verwijzing naar Click Studio's Incident Management Advisory. Dit was allemaal voordat ik het bericht hier op Tweakers tegenkwam en voordat het bericht op CSIS group stond waar Tweakers naar verwijst. Click Studios heeft snel en open gereageerd. Wat mij betreft is dit een nette afhandeling van zaken die ik graag bij meer bedrijven zou zien.

[RobIII]

Maar... welke password manager ken jij die nog nooit een issue heeft gehad?

Geen. Zelfs mijn wachtwoordmanager van keus heeft wel eens akkefietjes gehad. Maar nog nooit dat alle wachtwoorden inzichtelijk waren. Daar zit nogal een verschil.

In dat bericht stelt het dat de malware onder andere gebruikersnamen, wachtwoorden [...] naar de server van de aanvallers zou sturen

[Reactie gewijzigd door RobIII op 23 juli 2024 02:34]

[bilbob]

KEEPASS

[Blorgg]

KEEPASS

Keepass is een prima tool en absoluut een fijn stukje software. Maar het is zeker geen enterprise password manager. Stel je eens voor dat je 100 mensen tegelijkertijd toegang wilt geven tot je Keepass file. Daar heb je iets meer voor nodig dan een dropbox share

[bilbob]

heb je helemaal gelijk in

[sweetdude]

Het is nu juist andersom, reken maar dat na deze gebeurtenis Passwordstate zijn zaken op orde gaat maken waardoor alle andere password managers nu weer lager hangend fruit worden.

Trouwens zoveel goede (vergelijkbaar of beter in prijs/kwaliteit) enterprise password managers zijn er niet. Maar als je ze weet hoor ik het graag.

[RobIII]

Het is nu juist andersom, reken maar dat na deze gebeurtenis Passwordstate zijn zaken op orde gaat maken waardoor alle andere password managers nu weer lager hangend fruit worden.

Zo kun je 't ook zien. Waar gewerkt wordt worden fouten gemaakt. Maar als je primaire business het veilighouden van alle geheimen van je klanten is en je faalt daar in dan ben je in mijn boekje af. Als een appelboer i.p.v. een vrachtwagen heerlijk rode appeltjes opeens met een vrachtwagen tomaten komt aankakken zeg je ook niet "he, jammer, volgende keer beter". Dan ga je op zoek naar een andere appelboer want deze begrijpt geen hol van z'n business.

Trouwens zoveel goede (vergelijkbaar of beter in prijs/kwaliteit) enterprise password managers zijn er niet. Maar als je ze weet hoor ik het graag.

Meer dan keus genoeg, voor elk wat wils. Wat jij vergelijkbaar of beter vindt in prijs/kwaliteit is nogal subjectief, dus dat kan ik nooit naar jouw tevredenheid beantwoorden en ga 't daarom ook niet proberen

[Daoka]

Dan ga je op zoek naar een andere appelboer want deze begrijpt geen hol van z'n business.

Persoonlijk denk ik dat het van meer dingen zal hangen bij mij tenminste. Hoe lang werk je al met die bedrijf? Wat was er verkeerd gegaan? Hoe gaan ze het goed maken? Hoe snel kunnen dit regelen? En welke schade lijdt ik er door? Compensatie hiervoor? Hoeveel kleine en grote fouten zijn er eerder gemaakt. Wat is hun prijs/kwaliteit in vergelijking met andere? Hoeveel andere goederen komen er bij hun vandaan?

Als het een kwestie is van dat de chauffeur perongeluk de verkeerde wagen meegenomen heeft en over 2 uur staat de goede voor de deur zullen er denk ik niet zoveel zijn die het gelijk zullen opzeggen.

[4x4]

Precies dit.
Mensen hebben een wachtwoordmanager om juist dit soort geintjes te voorkomen.
Als jij als manager niet goed presteert en in dit geval gewoon keihard faalt mag je vertrekken. Zeker als het om een betaalde dienst gaat.

[Recklezz]

Begrijp ik het goed dat dit alleen een issue is als je toevallig in die 28 uur handmatig een update hebt gedaan? Dit gebeurd namelijk niet automatisch.

EDIT : klopt inderdaad na het lezen van het persbericht

[Reactie gewijzigd door Recklezz op 23 juli 2024 02:34]

[Locke_]

Dat vraag ik mij inderdaad ook af, het

Begrijp ik het goed dat dit alleen een issue is als je toevallig in die 28 uur handmatig een update hebt gedaan? Dit gebeurd namelijk niet automatisch.

Staat in de publieke notificatie:

Only customers that performed In-Place Upgrades between the times stated above are believed to be affected. Manual Upgrades of Passwordstate are not compromised.

[Recklezz]

Ja precies, dus je moet net pech hebben gehad eigenlijk als je in dat window een update hebt gedaan. Daarnaast is het nog maar de vraag of de payload door een enterprise firewall heen was gekomen.

[Steenvoorde]

Jammer dat dit gebeurd is, Passwordstate is best een mooi product met veel mogelijkheden en ze leveren prima support. Ik snap alleen niet zo goed hoe dit 28 uur online heeft kunnen staan, de integriteit van hun software zou toch de hoogste prioriteit moeten zijn lijkt me.

[ShellGhost]

Dit is echt uber zonde. Ik raadde deze vaak aan omdat het een zeer veelzijdig pakket is. De Windows only hosting was jammer.

[K-aroq]

De beste wachtwoordmanager zit nog altijd in je schedel.

[gorgi_19]

Ik heb anders best moeite om wachtwoorden van 40+ karakters voor een stuk of verschillende applicaties goed te onthouden. Helaas ben ik niet als jij begiftigd met een fotografisch geheugen

[n9iels]

Ik heb momenteel ~140 accounts in mijn password manager staan met elk een uniek wachtwoord. Ben jij in staat om daarvan alleen al een kwart te onthouden?

[System]

Hangt van de schedel af.
40 unieke en complexe wachtwoorden wordt toch lastig....

[polord1]

Wachtwoorden op papier is ws veiligste...

[Ciske]

En dan raak je opeens het papier kwijt. En nog erger: Dan kan het in iemand anders zijn/haar handen terecht komen.

[comatoast]

En nog erger: Dan kan het in iemand anders zijn/haar handen terecht komen.

Dat is exact waar het artikel over gaat, dus dat is niet "nog erger" maar eerder "precies zoals".

Online password manager services worden ook veel vaker aangevallen dan mijn papiertje, omdat er veel meer te halen valt bij zo'n service.
Een veiliger aspect aan zo'n service is dat er iemand anders verantwoordelijk is om jouw papiertje niet kwijt te raken, en als ze het alsnog kwijtraken heb je precies net zoveel pech als waneer je het zelf zou kwijtraken.

De voordelen van zo'n service houden na gebruiksvriendelijkheid heel snel op volgens mij.

[Vizzie]

Je bedoelt in handen komen van iemand anders zeg maar zoals nu gebeurd is met die wachtwoorden, gebruikersnamen en processen die draaiden op de systemen van klanten?

Papier in een kluis is zeker weten veiliger dan dit, maar heel gebruiksonvriendelijk en slecht schaalbaar over een heel bedrijf.

Een oplossing als de dienst die nu getroffen is, is iets minder veilig maar wel eindeloos veel gebruiksvriendelijker en veel beter schaalbaar.

[Webgnome]

Even kijken. Papiertje / boekje in de kast ergens in je huis met daarin je wachtwoorden keurig gesorteerd etc etc opgeschreven. Dat pak je er bij als je een wachtwoord nodig hebt. De kans DAT iemand dat boekje steelt is een stuk kleiner dan wanneer je in de cloud dat 'boekje' zou delen in welke digitale vorm dan ook. Immers zal iemand eerst bij je huis moeten inbreken en daarna ook nog eens dat boekje moeten vinden.

Dat staat in schril contrast met een flatgebouw met duizenden van dat soort boekjes ( lees cloud dienst ). Als je eenmaal binnen bent is het feest.

Het grote probleem van dat soort papieren boekjes is natuurlijk dat het niet automatisch nieuwe wachtwoorden bedenkt voor je

[Reactie gewijzigd door Webgnome op 23 juli 2024 02:34]

[Ciske]

Het grote probleem van dat soort papieren boekjes is natuurlijk dat het niet automatisch nieuwe wachtwoorden bedenkt voor je

Plus het feit dat je het snel kan verliezen, of het papiertje kapot gaat.

[Webgnome]

Mijn ouders zijn gebruikers van een papieren password manager en ik kan je vertellen dat ze dat boekje in de 20 jaar dat ze het nu gebruiken nog niet één keer kwijt zijn geraakt.

p.s. Je online password manager kan ook kwijt raken..

[System]

ja ok, maar complexe wachtwoorden intypen zal je snel beu worden....
Dan maar offline password managers met papieren backup?

[neonite]

Wachtwoorden op papier zijn top, en helemaal wanneer je een dergelijk blad tegenkomt bij een mysteryguest onderzoek!

[Anoniem: 1322]

Je maakt onbewust een goed punt. Een fysieke scheiding gebruiken is een goede extra beveiligingslaag. Wachtwoorden zijn inherent zwak qua beveiliging en papier natuurlijk ook. Maar zodra je een fysieke scheiding maakt bij authenticatie (zoals gebeurd met MFA op je telefoon terwijl je op je laptop inlogt) dan wordt inbreken op het account extreem veel moeilijker.

[phizzie]

Kijk, daar kun je ook nog op uitbreiden natuurlijk. En zelfs met papier.
Met een simpele matrix kun je kleine extensies voor ieder wachtwoord toevoegen. Zou al met 1 karakter kunnen zijn, waarmee je het wachtwoord uit de wachtwoordmanager aanvult. Offline augmented passwords.

Een soortgelijk voorstel heb ik sinds de BSN lekken van de overheid, KVK en onlangs de GGD ook al eens uitgetekend; ik noem het BSN+Banaan of BSN+🍌.
Dat zou een DigiD koppelingetje zijn met een aanvulwoord/karakterreeks. Net als de eerder genoemde stores kun je daar op ieder moment zelf deze reeks of het woord wijzigen.

Moet je je BSN ergens afgeven voor een identiteitscontrole? Dan moet jij het extra gegeven (koppelwoord) meegeven. Twijfel je aan de kwaliteit van een partij qua gegevensbescherming? Dan wijzig je je koppelwoord van in dit geval van banaan naar zeester bijvoorbeeld

Elke API call na de wijziging ketst af. Je zou het zelfs nog een tijdelijk houdbaar lijstje van kunnen maken. Bijvoorbeeld: BSN+dopsleutel is geldig tot 1 juni 2021. Tegelijkertijd is BSN+4142 houdbaar tot de volgende vrijwillige wijziging.

Goedkoop te maken, veel extra veiligheid.

[Pep7777]

Ik heb het vermoeden dat geen passwords uiteindelijk het veiligste is.
Challenge response met een sleutel die je zelf bij je hebt.

En ja zover ben ik ook nog niet, ik kijk wel afentoe naar een yubi key.
Maar vind dat weer lastig omdat je er eigenlijk 2 nodig hebt voor als je er 1 kwijtraakt

[Daoka]

Niet alleen dat je die kwijt kan raken maar ook niet altijd bij je heb misschien. Ga je op visite en denk je hem niet nodig te hebben laat je die misschien wel thuis. En dan blijkt dat je toevallig net wel nodig heb. Of toevallig van de week dat me moeder vroeg of ik bij haar bol.com account wou inloggen en kijken welke de beste is van de dingen die ze uitgezocht had. Dat kan dan ook niet meer.

Ook moet wel alle apparaten het ondersteunen, programma's/apps en websites het ondersteunen. Zoals dat ik netflix kijk op mijn PS5 en me moeder op haar settopbox.

Ook zou ik graag een systeem zien waar je bepaalde codes kan overzetten naar andere keys dan. Zoals ik heb select op mijn bol account en me moeder niet. Zou ze dan toch een keer willen gebruiken zou ze kunnen inloggen zoals dat het nu ook kan.

[n9iels]

Dit is in sommige gevallen 100% waar. Zeker als de eindgebruiker niet zo technische onderlegd is en moeite heeft met het gebruiken van een password manager. Het opschrijven van goede lange wachtwoorden op een veilige plaats is dat een veel lagere drempel. Mijn ervaring is dat als iemand de password manager niet snapt dit vaak frustrerend is, met als effect dat het uiteindelijk niet gebruikt wordt

[Frogmen]

Waar mensen werken kunnen fouten gemaakt worden en met genoeg geld is iedereen te koop. Vergeet dat niet. Zeker als meer bedrijven betalen voor ransomware des te meer geld er is om mensen te kopen. Verder hebben criminelen ook een probleem op dit moment om hun geld kwijt te raken dus is er meer geld voor risico en potentiele interessante ondernemingen.
Kortom zonder verdere kennis een onderneming de schuld geven is erg kort door de bocht.
In iedere onderneming is er wel iemand die gevoelig is voor geld al is het buiten iemands eigen schuld, zieke familie of andere geldzorgen kunnen genoeg zijn om iemand over de streep te trekken.

[Rouwette]

Ik ga toch maar eens kijken om Bitwarden rs zelf te hosten, zal ook minder interessant zijn dan een passw manager.

[habbekrats]

Ik gebruik al heel lang KeePass 2 werkt overal op.

[haam]

Yep, sync tussen NAS, PC en phone (local only). Dan heb ik overal mn wachtwoorden bij me. Geen automatische updates aanstaan, ik wacht altijd een paar weken voor ik een nieuwe versie installeer.

Nooit 100%, maar voelt aardig veilig en prettig dat ik zelf in control ben