Een overweging voor mij om een wachtwoordmanager als apart programma te kiezen, en niet de in de browser ingebouwde wachtwoordmanager of een webgebaseerde, was dat die in een afzonderlijk proces draait, en niet in hetzelfde proces waar websites alle ellende die die mogelijk binnen slepen in uitvoeren. Processen kunnen op moderne computers niet elkaars werkgeheugen benaderen. De wachtwoordmanager in een afzonderlijk proces onderbrengen levert daarom naar mijn idee een grotere barrière op tegen ellende die zich in websites bevindt dan de wachtwoordmanager van de browser of een webgebaseerde.

Dit zijn toch voor het grootste deel allemaal zaken die bij een losse password manager net zo goed spelen?
Dat is evengoed een geval van all-your-eggs-in-one-basket met de daaraan verbonden encryptie en backup vereisten.
Ik zie niet wat het verschil is met een losse password manager. Ofwel je spullen staan op je eigen computer, ofwel
ze staan in de cloud. Beiden hebben risico's zoals boven beschreven maar ze zijn niet echt anders dan die van een
browser wachtwoordmanager. (bedenk dat de meesten hun "losse passwordmanager" ook met een of andere browser
integratie zullen gebruiken om niet gek te worden van het zoeken, knippen en plakken van wachtwoorden)

Ik gebruik mijn brein icm de “wachtwoord vergeten” functie op websites:

Waar ik vaak inlog onthoud ik het wachtwoord.

Bij bijvoorbeeld webshops waar je zonder account niet kan bestellen genereer ik een random password door wat op het toetsenbord te rammelen. De volgende keer dat ik er wil inloggen ben ik mijn wachtwoord vergeten (en dat is dan niet eens gelogen).

Password managers vertrouw ik voor geen ene meter. Het blijft een stukje programmacode dat kwetsbaarheden kan bevatten.


Maar goed, ik heb dan ook niet veel accounts.

Dacht u dat?
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow

Zoek ook eens op: rowhammer, spectre, meltdown en zombieload.

Ik weet nog dat men riep dat WEP veilig was. Werd toch vervangen voor WPA. Werd vervangen door WPA2. Werd/wordt vervangen voor WPA3.
Zelfde geldt voor SSL. Is inmiddels ook TLS 1.3.

Niets is onbreekbaar. Misschien niet nu te kraken, maar er is vanzelf een onderzoeker die een methode vindt om iets “onkraakbaars” te kraken.

Ook voorzichtig zijn met permissies voor Android apps. Tik Tok kan bij je wachtwoorden. Gemak dient de mens, maar is daarom niet altijd veilig.

#obserwator

Nou ik weet niet wanneer jij voor het laatst met ps of taskmanager of wat je ook hebt in je systeem gekeken hebt uit
hoeveel processen je browser precies bestaat, maar je kennis lijkt me niet erg actueel.
Moderne browsers splitsen de boel al op, zowel per functionaliteit als per website (tab).

Over Ford Knox is een mooie film gemaakt. Goldfinger. Dat was pure fantasie. Tot nu toe. Over wat je niet voor mogelijk had gehouden worden ook films gemaakt. Maar altijd achteraf. Niks is veilig. Het enige wat je moet doen is iets slimmer zijn dan de rest. En dat voor jezelf houden. De mensen houden ook niet van slimmere mensen. Of het moet duidelijk om een film gaan. Dan betalen ze zelfs voor een kaartje.

Ik doelde op de bescherming die virtueel geheugen oplevert: een proces is simpelweg niet in staat om het geheugen te adresseren dat andere processen toebedeeld hebben gekregen. Het fysieke geheugen van het ene proces is afwezig in de virtuele adresruimte van het andere proces. Buffer overflows richten hun schade daarom aan binnen het proces waarin ze draaien, ze kunnen niet bij het werkgeheugen van andere processen. Als je niet weet hoe virtueel geheugen werkt kan je het opzoeken op Wikipedia.

Dat zoiets als rowhammer bestaat doet er niets aan af dat virtueel geheugen een goed concept is waar je wat aan hebt. Rowhammer vergt kwaadaardige software op je systeem. Daar kan je je tegen beschermen, inclusief het zo veel mogelijk blokkeren van JavaScript in websites.

Tegen spectre, meltdown, zombieload en andere soortgelijke processorbugs zijn al lang en breed maatregelen beschikbaar. Als je je systemen up-to-date houdt, inclusief de kernel en de processor-firmware, zou je beschermd moeten zijn tegen de bekende kwetsbaarheden. Om je systeem te controleren:
https://github.com/speed47/spectre-meltdown-checker

Dat er af en toe een dijk doorbreekt wil niet zeggen dat dijken meteen overbodig zijn, die beschermen wel degelijk. Het helpt als je het onderhoud eraan niet overslaat en niet zelf ondoordacht gaten in de dijk gaat graven.

Hier laat ik het bij, ik ga er geen welles/nietes-gekibbel van maken.

Overtuigingshysterese?

Oftewel, elk argument dat afwijkt van degenen waar jouw kennelijk onwrikbare standpunt op is gebaseerd, bij voorbaat afdoen als irrelevant, "geldt ook voor losse wachtwoordmanagers" of "ik zie niet"?

Ik heb mijn argumenten bewust genummerd, en gaf niet voor niets aan dat de perfecte oplossing niet bestaat. Als je per item aangeeft waarom dat ook voor niet door webbrowsers beheerde en opgeslagen wachtwoorden zou gelden, heb ik niet het gevoel mijn tijd verspild te hebben met het beantwoorden van jouw (? of van een andere Anoniem) vraag, en is een constructieve en op concrete argumenten gebaseerde discussie mogelijk waar anderen (ook ik) hopelijk van kunnen leren.

Cybercriminelen passen zich voortdurend aan, als wij dat niet ook (willen) doen, betekent dat winst voor hen.

@Erik van Straten,

100% mee eens met je conclusie over de huidige 'boe' tegenover 'ba' cultuur.

Als er nu reeds een cultuur wordt opgetuigd van 200 door overheden in dienst genomen gedragswetenschappers om mensen gemakkelijker over te kunnen halen tot geprefereerd soms ondoordacht gedrag, kan het niet anders dat men zo gaat reageren en wel op 'ouderwets' zelfstandig denken en dat gaat afwijzen.

Degenen, die dat al vanaf het begin dat wel doen, dat eigen denken dan, is de cybercrimineel.

De massa overtuigen van misleiding wordt dan ook een halstoer voor de security mensen, die weten van de hoed en de rand, nl. de onafhankelijk opererende technische IT, zoals jij.

#obserwator

Omdat inderdaad alles te kraken is heb ik mijn lijst met wachtwoorden opgeslagen in een Excelbestand met een hoofdwachtwoord, ofwel: het bestand is met wachtwoord beveiligd. Dat is mijn password manager.

Voordat iemand begint te steigeren :-) .....

De locatie van dat bestand is een offline Win XP computer die uiteraard ook geen wireless connectiviteit aan boord heeft.

Ik kan dat zo doen omdat ik nooit elders dan thuis wachtwoorden gebruik/nodig heb.

Voor bezigheden die een wachtwoord vereisen start ik dus mijn 'wachtwoordmanager' op de separate XP machine met een 13" beeldschermpje dat razendsnel is omdat het geen netwerkconnectie met alle noodzakelijke IT beveiligingen hoeft te booten, die bovendien anno 2022 volkomen waardeloos zouden zijn, want... XP.

Ik weet: het is een luxe dat ik het mij kan veroorloven om niet noodzakelijkerwijs overal en nergens over mijn wachtwoorden te moeten beschikken, maar het is maar een idee hoe het ook anders kan dan middels locale of cloudbased passwordmanagers.

Die vraag en die reactie waren van dezelfde anoniem.
Ik snap best wel dat er verschillen zijn, maar je hebt me niet overtuigd dat er significante verschillen zijn.
Of ik nou de ingebouwde password manager gebruik of een aparte, er zijn altijd wel scenario's te verzinnen waarbij
mijn wachtwoorden verloren gaan of misbruikt kunnen worden. Die scenario's zullen iets verschillend zijn, en ze worden
in jouw artikel goed beschreven, maar ik ben niet overtuigd dat het ook maar enige zin heeft om een aparte password
manager te gebruiken om risico's te verminderen.
(ik ga er vanuit dat een aparte password manager browser-integratie heeft, dwz dat ik met een enkele handeling het
bijbehorende password kan opzoeken en invullen op een website. zit dat er niet in dan valt die al af voor mij, want
iedere keer dat ik ergens moet inloggen die site opzoeken in een apart programma, password daar ophalen, en dan
plakken in het password veld dat is me ECHT teveel gedoe!)

En toen crashte de harddisk...

Ik schreef niet voor niets, en heel bewust, dat dat mijn overweging was. Ik maakte deze keuze al jaren voordat Firefox een proces per tab voor elkaar had. Toen was het ook nog zo dat Chrome/Chromium niet eens een master password ondersteunde.

Maar ik heb inderdaad niet duidelijk gemaakt waarom ik het nog steeds het vermelden waard vind. En dat is dit:

Het aparte proces van een afzonderlijke wachtwoordmanager is overzichtelijk. Hoe alle subprocessen van een browser met elkaar communiceren en of dat weer kwetsbaarheden oplevert overzie ik niet. Verder heb ik me nooit verdiept in de vraag of de ingebouwde wachtwoordmanager een eigen proces heeft of onderdeel is van het proces van een ander deel van de browser. Bij een afzonderlijke wachtwoordmanager is, zonder dat ik daar processen voor hoef te gaan bestuderen, bij voorbaat duidelijk dat de browser niet gebouwd is om die wachtwoordmanager aan te sturen (als je althans kaal het afzonderlijke programma gebruikt en geen bijbehorende add-on installeert), en ook hoe de inloggegevens worden ingevuld is duidelijk (geëmuleerde toetsaanslagen in mijn configuratie). De scheiding van en de koppelingen tussen de processen zijn daarmee duidelijk en overzichtelijk. Ik zie de eenvoud daarvan als een voordeel, ook met alle verbeteringen die er zijn gedaan aan webbrowsers sinds mijn keuze maakte.

Ik heb mijn wachtwoorden ook zoals jij met een excel bestand gemaakt maar alleen laat ik een paar karakters weg zodat
deze wachtwoorden niet direct misbruikt kunnen worden. En maak altijd lange wachtwoorden. Ik begrijp dat dit niet voor iedereen is weggelegd, maar ik bestel alleen nog bij websites waar je als gast kunt bestellen.

Je reactie toont dat je zelf voor dat gat te vangen bent.
Heb je inmiddels geconcludeerd dat je hier op een IT forum bent?

Dus:

Harddisks.... in voorrraad.
Backups.... meervoudig.
Computers, voedingen, logic boards... meerdere.

Maar dan moet je dus elke keer een wachtwoord overtypen uit dat 13" schermpje. Hoe sterk zijn die wachtwoorden dan?

Áls die aanname al zou kloppen (mede afhankelijk van wat je precies met "moderne computers" bedoelt), zijn er wel heel veel "tenzij's".

Als, onder Windows, jouw account lid is van de Administrators groep (je wel eens UAC prompts ziet), kun je sowieso vergaande privileges verkrijgen. M.i. goede uitleg vind je in de twee uitgebreide "Answers" onderaan https://security.stackexchange.com/questions/220771/why-does-windows-allow-non-parent-processes-to-read-write-the-memory-of-a-proces.

Helemaal kansloos ben je als het een aanvaller lukt om een rootkit-achtige kernel-backdoor zoals mhyprot2.sys op jouw systeem te installeren (uitgebreid beschreven in https://www.trendmicro.com/en_us/research/22/h/ransomware-actor-abuses-genshin-impact-anti-cheat-driver-to-kill-antivirus.html).

Aan de andere kant doet de maker van KeePass, Dominik Reichl, veel moeite om het aanvallers met toegang tot jouw "systeem" zo lastig mogelijk te maken. Wellicht doen browsermakers dat ook, maar of en hoe goed weet ik niet.

Mijn uitgangspunt is dat als een aanvaller willekeurige code kan draaien "binnen mijn (non-admin) account", het game over is voor mij. Zolang de mogelijkheid om code uit te voeren tot "ergens" binnen mijn webbrowser beperkt blijft, lijken mijn risico's een stuk kleiner. Maar dat geldt weer niet als de aanvaller middels een exploit, misbruikmakend van een kwetsbaarheid in de browser, uit de browser kan breken.

M.i. gaat het niet zozeer om de (vaak belabberde) scheiding tussen processen die jij draait onder jouw account (zoals een tekstverwerker en een webbrowser), maar het voorkómen dat onbetrouwbare code (meestal Javascript) afkomstig van websites toegang kan krijgen tot jouw wachtwoorden indien deze binnen jouw browser-omgeving toegankelijk zijn.

M.a.w. ik ga ervan uit dat het voor aanvallers veel lastiger is om "uit de browser te breken" dan "binnen de browser kwaad te doen", hoewel ook dat eerste risico toeneemt naarmate browsers allerlei "features" krijgen waar in elk geval ik niet op zit te wachten.

Je wekt de suggestie dat ik daar de tijd niet voor neem? Uit ervaring weet ik dat veiligheid lastig is, maar het nog lastiger wordt als je veiligheid niet serieus neemt in combinatie met de recht evenredige tijd die het vraagt.
Als je handmatig password security gebruikt spendeer je daar arbitrair de benodigde tijd aan. Als je daar, om wat voor reden dan ook, moeite mee hebt moet je de procedure van karakter na karakter invoeren van wachtwoorden niet toepassen, anders ben je onverantwoord bezig, Niet alleen m.b.t. jezelf overigens...

Mijn wachtwoorden? Minimaal 16 karakters: letters (upper/lowercase) cijfers, symbolen en leestekens.

...En dat bestand bevindt zich op een on-line device? Persoonlijk vind ik dat toch griezelig.
Hoewel....
Karakters weglaten in de password phrases. Dat is iets waar ik nog niet aan had gedacht. Dat is best slim want alleen de gebruiker weet welke positie die karakters innemen in de password phrase.


Toch wel leuk dit alles. Zo zie je weer dat er altijd meerdere wegen naar Rome leiden. :-)

Oeps, laat dat nou net het enige besturingssysteem zijn dat je volgens https://mijn.overheid.nl/veiligheid/ niet meer moet gebruiken:
;-)

Serieus: de wachtwoordbeveiliging van Excel, vooral bij oudere versies - in elk geval t/m 2007 (die je mogelijk gebruikt gezien XP), is totaal waardeloos (en hufterig misleidend). Met een simpel macrootje heb je dit in een oogwenk gekraakt, ongeacht de "strekte" van het door jou gekozen wachtwoord (meestal leidt kraken tot een totaal ander wachtwoord dan jij bedacht had, maar het werkt wel; bergen "collisions" dus).

Als je geen FDE (Full Disk Encryption) hebt op die PC (en elke back-up!) bestaat het risico dat een fysieke inbreker jouw wachtwoorden achterhaalt.

Ik zou overstappen op KeePass (op die netwerkloze PC).

As je toch door wilt met Excel, zou ik de versleuteling van jouw wachtwoordbestand verwijderen (nutteloze schijnveiligheid) en FDE gebruiken (Veracrypt bijvoorbeeld). Als jouw back-up-media niet zelf versleuteld zijn, zou je te back-uppen xls bestanden kunnen versleutelen met 7-Zip in AES-256 mode.

Als je Excel wilt maar geen FDE, zou ik het Excel-bestand elke keer versleutelen met 7-Zip in AES-256 mode (dan zijn back-ups daarvan automatisch veilig versleuteld).

Echter, zonder FDE loop je wel het risico dat een aanvaller met schijftoegang onversleutelde oudere exemplaren van het Excel-bestand (en/of van tijdelijke bestanden en/of in de pagingfile) kan terugvinden en recoveren; vooral op NTFS kun je vaak onverwacht veel historische versies van bestanden in "unallocated" (niet meer aan bestanden gekoppelde) blokken terugvinden ("secure erase" programma's voor individuele bestanden zijn zelden effectief).

Met KeePass zonder FDE is de kans dat een aanvaller met schijftoegang onversleutelde wachtwoorden vindt, in tegenstelling tot bij programma's als Excel, zeer klein.

Nb. met "schijftoegang" bedoel ik dat een aanvaller de schijf uit jouw PC schroeft en als extra schijf aansluit op zijn eigen systeem, of onder een draaiende XP met een diskeditor zoals HxD aan de slag gaat.

sorry dubbel

@Erik,

Hartelijk dank voor deze waardevolle informatie.

Wat jij aanhaalt is ook wel mijn overgebleven zorg geweest. Niet dat ik er panisch en/of paranoïde van wakker lig, maar voorheen stonden alle wachtwoorden op een goed verstopte A4.
Na verloop van tijd zinde mij dat niet meer. Van het een kwam het ander. Uit mijn bescheiden voorraadje HP Compaq's (allemaal goed functionerende pre 2010 afdankertjes) koos ik er een uit tot voornoemd doel.
Hoewel ik XP boot in user-account en ik niet zo bevreesd ben voor fysiek misbruik door derden, bestaat de kans natuurlijk altijd.
Wat ik niet wist was dat de gebruikte Excel uit Office 2003... ;-) zo'n brakke password beveiliging heeft.

Ik ga toch eens zoeken of er een versie Keepass is die compatibel is met XP. Natuurlijk zou ik ook de Keepass v.2.38 op mijn Linux 19.3 machine kunnen gebruiken, maar dan ga ik weer online met mijn 'wachtwoord winkeltje' ;-)

toegevoegd 01:14 uur:

Keepass is volgens de ontwikkelaar https://keepass.info/index.html maximaal backward compatible met Win 7, maar ik ga het gewoon proberen. De XP die ik heb is 32 bit (x86) en Keepass ondersteunt 32 en 64 bit.
Ik heb er wel vertrouwen in dat het elkaar niet bijt.

De verhandelingen hierboven zijn een bevestiging van mijn eerdere uitgangspunt/vermoeden!
Voor iedere oplossing is er een scenario te bedenken waarin die niet veilig is.
Echter, veiligheid is altijd een relatief begrip, en sommige scenario's vind ik gewoon niet relevant.
"als er een fysieke inbreker bij je binnen komt kan die je bol.com wachtwoord achterhalen!"
Nou BOEIE!

En vergeet ook niet: naarmate je het allemaal beter beveiligt, neemt ook de kans toe dat je ZELF geen toegang meer hebt.
Omdat al die slimme dingetjes die je bedacht had om vreemden buiten te houden er voor zorgen dat je jezelf buitensluit.

In mijn ogen is het zwakste punt dat de je zowat op ieder site je e-mail moet ingeven om in te loggen.

Een inbreker die het "2FA" apparaatje van mijn bank vindt en zowel de pincode daarvan als mijn wachtwoord achterhaalt, kan mijn bankrekening plunderen. Dat vind ik meer dan "BOEIE". En ik maak mij beslist niet alleen zorgen over mijn bankrekening.

Welkom op security.nl, waar ook dát aspect aandacht verdient!

@Quink en andere geïnteresseerden:

KeePass
Versies 1.x van KeePass hebben geen dotNet nodig, en worden zo te zien nog onderhouden. XP staat niet meer vermeld als compatibel maar is dat waarschijnlijk wel (Dominik Reichl zal dat niet meer testen). Let op: de database daarvan is niet compatibel met die van KeePass 2.x; mocht je ooit willen uitwisselen, dan zul je waarschijnlijk moeten exporteren en importeren. Zelf heb ik nooit plug-ins gebruikt.

Als je de ingebouwde wachtwoordgenerator gebruikt (erg handig omdat je kunt instellen welke karakters gebruikt mogen worden) en de "randomness" niet vertrouwt, dan belet niets je om delen van dat wachtwoord daarbinnen te verplaatsen en/of door eigen bedenksels te vervangen (bijv. om overtikken te vereenvoudigen).

H2TestW: "wissen" van leesbare of slecht versleutelde gegevens in de "vrije ruimte" op disk
H2TestW.exe (https://www.heise.de/download/product/h2testw-50539) is gemaakt door een van de auteurs van het gerenommeerde Duitstalige tijdschrift c't (uitgeverij Heise). Het was/is bedoeld om te testen of een USB geheugenstick de beloofde opslagruimte biedt (niet de factor 1000 versus 1024, maar oplichting met minder en/of kleinere ingebouwde geheugenchips dan door de stick gemeld wordt aan het besturingssysteem: oftewel je schrijft je vakantiefoto's naar een "zwart gat").

Het werkt door eerst de vrije schijfruimte (bijna) helemaal te vullen met bestanden (van, uit m'n hoofd, 1MB of 10MB) met daarin een speciaal patroon. Daarna leest het al die bestanden en controleert het of ze exact de juiste inhoud hebben.

De lol ervan is dat je er veilig bijna alle vrije schijfruimte mee kunt overschrijven (als de schijf bijna vol is zal XP wel gaan piepen). Veilig omdat het met bestanden werkt en geen "low level disk erase" o.i.d. doet. N.b. per ongeluk gewiste bestanden kun je hierna natuurlijk niet meer "unerasen".

Het beste kun je vóóraf zoveel mogelijk tijdelijke bestanden verwijderen van je schijf (in C:\Windows\Temp\ en onder je profiel - check natuurlijk ook "hidden" bestanden), vooral die iets met Excel te maken zouden kunnen hebben. Het is ook verstandig om (tijdelijk) de swapfile/pagingfile erg klein te maken (zo mogelijk 0 bytes) vanuit de instellingen (voor "virtueel geheugen" o.i.d.).

Ik raad aan om een map C:\test\ o.i.d. te maken en het programma daarin al die bestanden te laten schrijven; zodra de test klaar is gooi je die bestanden (en desgewenst de map) gewoon weer weg (de inhoud van die bestanden blijft als "zombies" in de vrije ruimte op je schijf staan, maar dat zijn geen zombies waar cybercriminelen iets aan hebben).

Bijkomend voordeel is dat je meteen een groot deel van je schijf test op nog niet gevonden "bad blocks/bad sectors", wat bij oudere harddisks best handig zou kunnen zijn. Maak daarom eerst een back-up van de belangrijkste bestanden, want er zijn schijfcontrollers die zo "in de war kunnen raken" dat enkele bad blocks er al toe leiden dat de schijf geheel ontoegankelijk wordt (de kans hierop is zeer klein maar je zult het maar hebben).

Overigens kun je na het schrijven de test afbreken, maar voor een grondige schijftest zou ik ook 1x laten lezen.

Vergeet niet om (na het verwijderen van de testbestanden) daarna de swapfile weer in te stellen (niet dat daar veel gebruik van gemaakt zal worden op de PC van Quink - tenzij die PC extreem weinig RAM heeft).

Het is onverstandig om deze tool vaak in te zetten op media met flash-geheugen (SSD's, USB geheugensticks), omdat je dan bij elke schrijfactie de levensduur verlaagt (dat speelt niet op harddisks met draaiende schijven).

Opmerkingen m.b.t. de effectiviteit van deze manier van "wissen"
H2TestW is geen feilloze "secure erase" (voor zover zoiets in alle gevallen echt mogelijk is). Ik geef een aantal voorbeelden (deze lijst hoeft niet compleet te zijn).

Achter bestanden die niet toevallig een veelvoud van de blokgrootte van het bestandssysteem (NTFS meestal 4kB) groot zijn, kunnen meerder sectors (van meestal 512 bytes groot) zitten die nog "zombiedata' bevatten. Die sectors overschrijf je niet met H2TestW. De kans dat een aanvaller op die manier zinvolle gegevens vindt, is natuurlijk wel heel klein. En achter bestanden die eerder geschreven zijn (zoals tijdens de installatie van XP, voor zover je niet vervolgens vertrouwelijke bestanden op schijf gehad hebt en daarna XP-bestanden zijn vervangen door files uit een Service Pack), zit hooguit iets vertrouwelijks van de vorige gebruiker van die schijf.

Bij corruptie van het bestandssysteem kunnen blokken als "gealloceerd" staan geregistreerd terwijl ze aan geen enkel bestand gekoppeld zijn, ook bekend als "lost clusters". Die overschrijft H2TestW natuurlijk niet. Het is dus verstandig om vooraf een schijfcontrole uit te voeren (of chkdsk.exe te draaien met de juiste flags zodat er ook echt wordt gerepareerd). Daarna evt. gevonden bestanden met lost clusters inspecteren en hernoemen of wissen.

H2TestW overschrijft ook geen sectors die in de schijf als "bad" zijn gemarkeerd en uit "het zicht" van het besturingssysteem zijn gehaald (maar dat zijn er, normaal gesproken 0 of enkele).

Belangrijk: Media met Flash-geheugen bevat meestal een (mogelijk flinke) hoeveelheid sectors "die je niet ziet" en die worden gerouleerd met vaak beschreven virtuele sectornummers. H2TestW bereikt niet de sectors die op dat moment "uit beeld" zijn, maar later kunnen "oppoppen". Dat vergroot de kans aanzienlijk dat sectors met vertrouwelijke data later niet overschreven blijken te zijn. Sowieso zijn er bedrijven die ook "verstopte" virtuele sectors op Flash memory kunnen uitlezen (desnoods door de geheugenchips van de print los te solderen en ze dan uit te lezen).

Mijn advies is daarom om SDD's altijd en zo snel als mogelijk van FDE (Full Disk Encryption) te voorzien, en te wachten totdat dit proces helemaal klaar is, vóórdat je er vertrouwelijke informatie naar toe schrijft. Maar ook vanwege bad blocks of voor jou ontoegankelijk raken van harddisks (vaak met klik-klik geluiden bij power-up) raad ik iedereen aan om ook daarop FDE in te zetten, idem op eventuele externe (USB) back-up disks.

Algemene tip: Raspberry Pi
In plaats van een lompe energieslurpende PC met sterfgevoelige oude HDD (Hard Disk Drive) zouden mensen, die een "airgapped" wachtwoordkluis willen, ook iets als een Raspberry Pi kunnen overwegen; ook deze kun je natuurlijk FDE-en. En naar verluidt [1] kun je deze zelfs in een fysieke kluis aan de andere kant van de wereld laten zitten tijdens gebruik :-)

[1] https://github.com/fpunktk/raspi-fde

Nuttige informatie dank u wel

Je wekt de suggestie dat ik dit nog serieus moet nemen? Ik werk al meer dan 20 jaar in de informatiebeveiliging en ben best wel serieus met toegangsbeveiliging, maar dit is toch wel next level nerd. Daarnaast het overtypen van 16 of meer random karakters is nogal foutgevoelig. Ook is die 84 bits wachtwoordlengte toch echt te weinig.

Next level nerd... hm.
Morgenavond hebben wij onze maandelijkse grumpy grey old man bijeenkomst en ik ga dat stempel ter sprake te brengen. Hebben we weer wat om over te grijnzen. :-)

Zolang ik niet door de ING bank noch andere zakelijke partners die wachtwoordeisen stellen niet wordt gekapitteld met het gebruik van minimaal 16 karakters voel ik me senang. Bovendien heb ik overal waar het kan 2fa ingeschakeld.
IT Security is niet mijn werk en/of bevlogen hobby maar veronachtzamen doe ik het niet. Er is altijd baas boven baas, maar daar doe ik niet aan mee. Ik zou me aangesproken voelen door je als ik zo dwaas was het wachtwoord '123password' rond te strooien op elke website. Doe ik dat...?

Momenteel ben ik substantieel gestart met toepassing c.q. introduceren van Keepass op mijn netwerkloze Win XP computer zodat ik de hele wachtwoordhandel kan migreren vanuit het onveilige 2003 Excel mij kenbaar gemaakt via alle informatie die ik hier heb opgedaan. Daaruit is mij eveneens helder geworden dat Keepass, en dan op een netwerkvrije extra PC bijzonder veilig is voor normaal gebruik (ik ben geen medewerker van MI5) en daar laat ik het voorlopig bij.

Dank voor deze extra informatie!

Grumpy grey old man bijeenkomst? Dan zien we elkaar daar ;)

Maar wat voegt het gebruik van KeePass in deze constructie toe? Het enige gevaar is er als iemand fysiek toegang zou hebben tot je air-gapped PC, die -naar ik aanneem- bij je thuis staat. Als er een kwaadwillend figuur bij deze PC kan komen, heb je sowieso een andere uitdaging.

Graag gedaan!

Als je random wachtwoorden laat genereren en deze daarna wat "opleukt", valt dat best mee.

Voorbeeld (nooit hergebruiken):
Hier heb ik voor 3-letterige woorden gekozen met steeds op het eind een hoofdletter (varieer hierop), gescheiden door grotendeels random gegenereerde karakters. Bij het invoeren van zo'n wachtwoord vanuit een "airgapped" wachtwoordmanager hoef je maar 'n keer of 4 - 5 naar het wachtwoord te kijken, en mogelijk minder zodra je "het patroon ziet".

De kans dat zo'n wachtwoord vóórkomt in een lijst (dictionary) met ooit gelekte wachtwoorden, is zeer klein (zie verderop); een dergelijk wachtwoord is namelijk maar voor een beperkt deel afhankelijk van de vaak gebrekkige creativiteit van mensen en het feit dat zij, op een moment dat zelden goed uitkomt, zo'n wachtwoord moeten verzinnen (of wijzigen t.g.v. een policy die allang begraven had moeten zijn).

Mogelijke redenen waarom veel mensen slechte wachtwoorden kiezen
Naast dat er sufferds zijn die slechte wachtwoorden kiezen omdat ze denken dat ze niets te verbergen hebben (en o.a. toegang tot hun bankrekening of subsidieaanvragen in hun naam over het hoofd zien), kiezen vermoedelijk velen slechte wachtwoorden tegen beter weten in.

Als je bijvoorbeeld "iets wilt doen via internet", zoals online een product kopen of een abonnement afsluiten, of als het gaat om de eerste werkdag van je nieuwe baan, begin je niet met nadenken over het aanmaken van accounts. Vaak moet dat dus onvoorbereid en wellicht onverwacht. En, naast irritatie over het grote aantal verplichte persoonsgegevens dat je vaak moet invullen (die, al dan niet vermeld, tig jaar zullen worden bewaard), de lengte en onbegrijpelijkheid van het privacybeleid en andere voorwaarden waar je mee moet instemmen, en mogelijke ergernis over "2FA" via SMS, moet je "ineens" en "snel graag" een wachtwoord verzinnen dat voldoet aan soms onbegrijpelijke eisen [+].

Een wachtwoord dat je, als je geen wachtwoordmanager gebruikt (of nog niet hebt), ook nog eens moet kunnen onthouden. Dat allemaal bij elkaar is niet simpel voor mensen, vooral niet op het moment dat jouw onderbuik waarschuwt dat je niet precies weet hoe, wat en waarom, maar je niet "lastig" wilt zijn en dat zeurende gevoel ("TL;DR: sign here") toch maar onderdrukt. En als je denkt "verbeter ik later wel": van uitstel komt afstel.

[+] Als een wachtwoord een hoofdletter, een kleine letter, een cijfer en een ander teken moet bevatten, vooral als lange wachtwoorden niet zijn toegestaan, maak je het aanvallers een stuk eenvoudiger dan als zo'n wachtwoord die verschillende soorten karakters mag bevatten. Oftewel, omdat er sukkels zijn die "qqqqq" als wachtwoord kiezen, worden verstandige mensen gedwongen om onnodig langere wachtwoorden te gebruiken. Onnodig, want sukkels kunnen bij zo'n regel nog steeds onveilige wachtwoorden kiezen (zoals "Qq11!", allemaal aan de linkerkant van een toetsenbord).


Want? Onder welke omstandigheden?

Een wachtwoord met een "entropie" van 84 bits of meer is totaal zinloos bij bijvoorbeeld Excel <= 2007, maar heeft ook niet heel veel zin bij de meeste webaccounts. Het is m.i. véél belangrijker om voor elk webaccount een uniek wachtwoord (voor jezelf, maar dat waarschijnlijk ook nooit door een ander is gebruikt en daarna is gelekt) te kiezen.

Belangrijk: laat je niet op het verkeerde been zetten door "wachtwoordsterkte-indicators"! Vaak geven zij aan dat bijvoorbeeld "Welkom01!" of "Qwerty123!" een sterk wachtwoord is, wat qua aantal bits en het gebruik van soorten karakters wellicht klopt. Maar als zo'n wachtwoord bovenaan lijsten met veel gebruikte wachtwoorden en/of in handleidingen als default wachtwoord staat, is jouw account snel gecompromitteerd.

Zie bijv. https://en.wikipedia.org/wiki/Wikipedia:10,000_most_common_passwords voor veel gebruikte wachtwoorden. Maar realiseer je ook dat er veel langere lijsten bestaan! Een wachtwoord dat niet in die lijst vóórkomt, is dus niet per definitie veilig. Bovendien worden dit soort lijsten zo'n beetje elke dag langer.

Risico's bij wachtwoorden - geschatte volgorde van hoog naar laag
Een aantal risico's bij wachtwoorden ("ww") bij webaccounts van gebruikers, in de door mij geschatte gemiddelde volgorde van hoog naar laag (de kans is, in een aantal gevallen, sterk afhankelijk van de betrokkene):

1) Ww invoeren op een nepwebsite (phishing)
2) Combinatie van 1 en 3
3) Ww hergebruiken (meerdere accounts)
4) Combinatie van 3 en 5
5) Staat (hoog) in lijsten met (vaak) gelekte ww
6) Combinatie van 3 en 7
7) Te raden ww (geboortedatum zoals "3-Sep-92", deel van e-mailadres "rump@Gmai" of iets als "VeesBoek", mits niet vallend onder -groter- risico 5)
8) Te kort ww (niet risico 5)


Ik raad ze af, maar het risico van een kort doch waarschijnlijk uniek wachtwoord zoals "~f6&R" (versus "12345" dat door velen wordt gebruikt) is waarschijnlijk klein omdat:

- "naïef brute forcen" (het proberen van alle mogelijke karaktercombinaties met variërende -meestal toenemende- wachtwoordlengte) geniddeld veel langer duurt dan andere soorten aanvallen, en dit dus waarschijnlijk zelden of nooit gebeurt (bij een wachtwoord van 5 karakters met elk 80 mogelijkheden moet een aanvaller gemiddeld (80^5)/2 = 1.638.400.000 pogingen doen, dat is veel meer dan de langste wachtwoordlijst);

- "credential stuffing attacks" (aanvallers gokken op hergebruik van een wachtwoord op andere sites, risico 3) zinloos zijn (mits de gebruiker voor zichzelf unieke wachtwoorden gebruikt);

- "smart brute forcen" (gebruikmaken van dictionaries, risico 5) waarschijnlijk ook niet werkt.

Probleem: zonder zelf in de meest recente dictionaries te duiken, weet je mogelijk niet hoe "uniek" jouw korte wachtwoord is. Daarom is het verstandig om zoveel mogelijk redelijk lange en daardoor hoogstwaarschijnlijk unieke wachtwoorden te kiezen.

Sterke wachtwoorden
Wachtwoorden met zoveel mogelijk "bits entropie", mits zij niet vóórkomen in dictionaries (de kans daarop is klein bij lange en zoveel mogelijk random gegenereerde ww), zijn vooral belangrijker naarmate toegang (potentieel) interessanter is voor aanvallers (niet alleen cybercriminelen, ook boze exen, concullega's e.d.), vooral als:

a) Jij VIP/BN'er/influencer/"bovengeniddeld financieel vermogend" bent, en zo niet, als de hoeveelheid "lagerhangend fruit" klein is of afneemt [*];

b) Het om accounts gaat waarmee andere accounts van jou benaderd kunnen worden, zoals jouw e-mail account (als een aanvaller daar toegang tot heeft, kan deze op andere accounts van jou wachtwoord-resets uitvoeren en zo ook daarop inloggen) en bijvoorbeeld iCloud accounts;

c) Het om "objecten" gaat die offline kunnen worden aangevallen en waarvoor géén beschermende maatregelen zoals (tijdelijke) account-lockout of automatisch wissen mogelijk zijn;

d) Het om online accounts gaat zonder (tijdelijke) account-lockout.

[*] Zodra meer websites MFA en/of passkeys gaan ondersteunen, zullen aanvallers zich aanvankelijk concentreren op websites met "oude" password-only accounts.

Denk bij c) aan wachtwoordkluizen (d.w.z. de database van een wachtwoordmanager), wachtwoorden voor andere versleutelde bestanden (zoals mogelijk encrypted zip-files en bestanden met private keys) en wachtwoorden voor FDE (Full Disk Encryption; in een aantal gevallen kunnen TPM-chips wel voor een blokkade van het gebruikte wachtwoord zorgen, maar soms valt ook dat weer te omzeilen). Denk ook aan portable devices zoals tablets en smartphones - indien geen "wissen" is ingesteld na n foute unlockpogingen.

Denk bij d) in elk geval aan wachtwoorden voor beheeraccounts (populair onder aanvallers) waarop vaak geen "account lockout" is geconfigureerd, zoals servers, IoT-devices en/of netwerkapparaten (waaronder modems/routers).

Belangrijk: ga er niet zomaar vanuit dat elke website of andere server effectieve account-lockout toepast, en als ze dat vandaag doen, dit morgen ook nog zo is. Account-lockout kent ook veel nadelen, waaronder boze gebruikers die de helpdesk benaderen omdat ze niet begrijpen waarom ze niet in kunnen loggen (voor hun eigen bestwil omdat er op dat moment een aanval gaande is). Zie https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks voor een overzicht van de afwegingen.

Nb. Of account-lockout geldt voor bijvoorbeeld een webaccount, kun je zelf eenvoudig testen door een aantal keren een onjuist wachtwoord in te voeren. Maar nogmaals, instellingen kunnen "zonder notificatie" in de toekomst veranderen.

Conclusie
Een wachtwoordmanager kan je helpen om veilige wachtwoorden te genereren. Niet zozeer omdat "brute force" een risico zou vormen, maar vooral om wachtwoorden zo uniek mogelijk te maken. Hoe langer het random gegenereerde wachtwoord en hoe groter de toegestane karakterset, hoe enorm veel kleiner de kans dat zo'n wachtwoord in (door aanvallers gebruikte) dictionaries vóórkomt. Bovendien hoef je, dankzij een wachtwoordmanager, deze complexe wachtwoorden niet zelf te onthouden.

Belangrijk is wel dat je minstens één up-to-date back-up (op een veilige plaats) van de database hebt, voor het geval er iets mis gaat met het origineel. Omdat zo'n database fatsoenlijk versleuteld is (mits je daar een lang en niet te raden wachtwoord voor gebruikt dat je wel zelf onthoudt), zou het geen probleem moeten zijn als het origineel of een back-up van zo'n versleutelde database in verkeerde handen valt.

Essentieel is dat je dat "master password" nooit vergeet; doe je dat wel dan is de kans is zeer groot dat je nooit meer toegang krijgt tot jouw opgeslagen wachtwoorden (er horen geen backdoors te zijn). Voor velen zal het daarom verstandig zijn om dat "master password" ergens op te schrijven, maar niet onder de titel "wachtwoorden" op een papiertje in je portemonnee of smartphonehoesje (je moet natuurlijk wel onthouden waar je dat kunt vinden, voor anderen onbegrijpelijke hints kunnen daar wellicht bij helpen).

Ik weet dat wat voor de een goed werkt niet per se voor iedereen goed werkt, maar dit is wat ik doe, voor wie het aanspreekt:

Ik gebruik als "master password" een wachtzin. Ik doe niet moeilijk over hoofd- en kleine letters, cijfers, leestekens etc. Meer entropie kan je simpelweg met een langere zin bereiken, en die kan dan helemaal in kleine letters zijn. Dan hoef je nergens SHIFT in te drukken en kan je het simpel houden voor zowel je geheugen voor woorden als voor je motorische geheugen, dat je bij het intypen gebruikt.

Maar ik gebruik geen zin van bestaande woorden, ik gebruik onzinwoorden die wel goed uit te spreken zijn. Bijvoorbeeld (zuig ik ter plekke uit mijn duim): "zemakotief medebraza nekadidi berzwop". Ik heb gemerkt dat ik zoiets, omdat ik het kan uitspreken, na een oefenperiode ook uitstekend kan onthouden. Dergelijke woorden staan gegarandeerd in geen enkele woordenlijst. Dat maakt zo'n wachtzin weer een (niet gering) slagje moeilijker te kraken dan een met woorden die wel in woordenlijsten voorkomen.

Maar meteen ken ik zoiets natuurlijk niet uit mijn hoofd, ik moet een poosje oefenen. Daarom schrijf ik het op een klein papiertje dat ik piepklein opgevouw tot iets wat een klein propje lijkt, en dat woont onderin in dat piepkleine zakje (ik heb een keer gelezen dat het voor condooms bedoeld is) van de spijkerbroek die ik aan heb. In de periode dat ik de wachtzin nog niet kan dromen kan ik hem zo altijd even opzoeken op momenten dat ik hem even niet weet. Als ik zo'n papiertje verlies (wat nooit gebeurd is) kan de vinder, als die al aandacht aan een minuscuul propje papier besteedt, misschien wel raden dat het een wachtzin is maar hoogstwaarschijnlijk niet van wie of waarvoor. Als ik de wachtzin inmiddels wel kan dromen vernietig ik het papiertje.

Behalve op dat papiertje sla ik het ook ergens digitaal op, versleuteld met een wachtzin die ik al wel goed ken.

Mijn partner gebruikt ook een wachtoordmanager en we vertrouwen elkaar. Omdat het kan gebeuren dat een van ons overlijdt en de ander bij al onze spullen en accounts moet kunnen hebben we allebei een eigen wachtwoorddatabase waarin we de hoofdwachtwoorden van de ander bewaren. Dat dient meteen als een extra backup. Merk op dat we niet elkaars wachtwoorddatabases hebben maar alleen elkaars hoofdwachtwoorden bewaren, inclusief die waarmee we op de pc van de ander kunnen aanloggen.

Dat verhaal heb ik al ZOOOO vaak gezien! "verzin een wachtzin".
Nou, als ik vandaag onder druk van "je moet je wachtwoord aanpassen!" een wachtzin verzin en die niet de rest van de dag meerdere malen moet intypen (omdat een ingetypt wachtwoord bijv enige tijd niet opnieuw ingevoerd hoeft te worden, zoals bij een master password) dan weet ik een week later ECHT NIET MEER welke grappige wachtzin ik gekozen had.

Jij misschien wel, maar je komt er nog wel achter als je wat ouder wordt. Vroeger kon ik zonder mankeren al die grappig bedachte namen van programma's en websites oprakelen indien nodig, maar dat lukt me nu echt niet meer. Ja Firefox of grep dat weet ik wel, maar als ineens iemand me vraagt "hoe heet dat opensource programma voor...." dan moet ik dat eerst googlen en als ik het dan zie staan weet ik het weer.

Aan het begin van deze thread werd gesproken over password managers en het risico van knippen/plakken via het clipboard, en de extra handeling die dit vereist.

Keepass gebruikt daarom Two-Channel Auto-Type Obfuscation (TCATO) als maatregel tegen de meeste keyloggers en om met 1 click de credentials in te kunnen laten voeren (https://keepass.info/help/v2/autotype_obfuscation.html).

M.b.t. het vertrouwen wat je in een wachtwoordmanager kunt stellen, kan voor Keepass i.i.g. gezegd worden dat het in het kader van het EU-FOSSA project van de Europese Commissie is geaudit.

Je hoeft natuurlijk niet het hele password te Copy & Pasten, laat bv de laatste 3 tekens achterwege en typ die zelf in. Dat gaat nog steeds vrij snel, en keyloggers en clipboardsniffers kunnen er op deze manier niks mee. Ik doe dit al vanaf 2009, heb nog nooit passwordmanagers nodig gehad.

Een late reactie, sorry daarvoor!

Als je het niet vervelend vindt om veel toetsen in te tikken (vooral lastig met dikke vingers op kleine smartphones), is dat natuurlijk helemaal prima.

Klopt, maar aan "entropie" heb je niets als de wachtzin bestaat uit de voornamen van jouw vier kinderen (met "-" als scheidingsteken) en een aanvaller dat raadt. Daarmee bedoel ik niet dat jij dit zo hebt aangepakt, maar vaak kiezen mensen woorden die zij makkelijk kunnen onthouden - die ook anderen weten of te weten kunnen komen (daar wil ik voor waarschuwen). Als je willekeurige woorden uit een boek of krantenartikel haalt (bij voorkeur dat jou niet interesseert), en je die goed kunt onthouden, lijkt mij dat prima.

Inderdaad, alhoewel als je willekeurig woorden uit een voldoende grote woordenschat kiest, de kans dat een aanvaller zo'n wachtzin "raadt" (brute-forcet), al gauw klein wordt.

Als je echt willekeurig 4 woorden kiest uit een woordenschat van 1000 woorden, moet (als ik me niet vergis) een brute-force-aanvaller gemiddeld de helft van 1000^4 (dus 500 miljard) pogingen doen - mits die aanvaller weet dat jij zo'n wachtwoord hebt gekozen, welke woordenschat je gebruikte en welke scheidingstekens (of geen) je koos. Als een aanvaller dat weet en vermoedt dat er "voldoende te halen valt", zou 500 miljard wel eens te weinig kunnen zijn voor het kraken van een met bijv. AES versleuteld bestand - indien daarbij geen gebruik gemaakt is van Argon2 of PBKDF2 o.i.d.

Toelichting op Argon2 en andere KDF's
De meeste wachtwoorden zijn ongeschikt om als encryptiesleutel te worden gebruikt: ze hebben niet allemaal dezelfde lengte, en de bytes, die voor de codering van de karakters worden gebruikt, zullen een sterke bias hebben (d.w.z. bovengemiddeld vaak vóórkomen) voor de ASCII-codes van 'a' - 'z', 'A - Z', '0' - '9', gevolgd door de codes van een aantal leestekens.

En binnen die reeksen zullen 'e', 'E', '1' en '!' mogelijk het vaakst vóórkomen (dus daar zullen aanvallers vaak mee beginnen; als ik goed tel zie ik 6x de letter 'e' in "zemakotief medebraza nekadidi berzwop", zijn er 15 klinkers en ontbreken 'q', 'x' en 'y' - desalniettemin bijten aanvallers hier waarschijnlijk hun tanden op stuk :-)


Middels een "Key Derivation Function", een algoritme dat bijv. uit een MD5 hashfunctie kan bestaan, worden beide problemen opgelost: het resultaat heeft een vaste lengte (in bits) en bias hoort ondetecteerbaar te zijn (d.w.z. de sleutel zou niet van random te onderscheiden moeten zijn).

Een KDF wordt dus gebruikt om de encryptiesleutel [*] af te leiden uit jouw wachtwoord. Hoewel het gebruik van MD5 voor elke toepassing wordt afgeraden (om vergissingen te voorkómen), is -indien toch MD5 wordt gebruikt- het voordeel voor brute-forcers niet dat MD5 gekraakt is, maar dat alle reguliere cryptografische hashfuncties (waaronder MD5 maar ook SHA-3) bloedsnel zijn op moderne hardware.

Daarom zijn KDF's zoals Argon2 ontworpen: die functies zijn opzettelijk traag gemaakt door hen veel CPU-performance en/of veel geheugen te laten verbruiken.

Nb. in plaats van het wachtwoord te brute-forcen, kan een aanvaller ook proberen om de feitelijke encryptiesleutel te brute-forcen. Omdat dit in de praktijk vaak veel lastiger is, wordt meestal het wachtwoord (de input van de KDF) aangevallen; vertragende KDF's maken brute-forcen lastiger bij langere wachtwoorden (en zijn niet te omzeilen, anders dan de feitelijke encryptiesleutel te brute-forcen - wat meestal kansloos is).

[*] Vaak is het nog ingewikkelder en wordt de feitelijke encryptiesleutel (voor het versleutelen van het bestand) met een tussensleutel versleuteld. Bijvoorbeeld Bitlocker gebruikt iets dergelijks waardoor meer dan één wachtwoord gebruikt kan worden. Je krijgt dan iets als volgt (wachtwoord = ww, tussensleutel = ts, encryptiesleutel = es, versleutelde es = ves):
Merk op dat naast het met es versleulde deel van het bestand (of de disk), ves1 t/m ves(n) toegankelijk moeten zijn (deze zijn welliswaar versleuteld, maar met andere sleutels dan es). Het aanvalsoppervlak wordt hiermee vergroot, maar in de praktijk zal het "gewone" user-wachtwoord (niet een lange random rescue code) meestal het zwakst zijn.

Actuele versies van KeePass v2.x gebruiken een Argon2-variant als KDF, maar ik weet niet sinds wanneer dit zo is, noch of een ouder protocol automatisch in de database geüpdated wordt. Bovendien, uit https://keepass.info/help/base/security.html:
Het is dus niet altijd eenvoudig te achterhalen welke maatregelen tegen brute-force op jouw wachtwoorddatabase van toepassing zijn.

Een afweging maken tussen enerzijds "vergeetrisico" (ook als gevolg van hersenschade) en "overlijdensrisico" en anderzijds "lek- en misbruikrisico", en passende maatregelen nemen, is verstandig. Ik moet bekennen dat ik nog onvoldoende maatregelen heb genomen om nabestaanden (ook bij hersenbeschadiging o.i.d.) op weg te helpen.