Door Anoniem: Door Anoniem: Door Anoniem: vwb "plaintext":
Dan "staan" die wachtwoorden van jouw nog steeds niet "plaintext" in de backup zoals je claimde. want dan zou je ze zonder extra hulpmiddelen letterlijk moeten kunnen lezen in het bestand logins.json .
Dat is wat plaintext betekent.
Of nu big endian, little endian, UTF-8, base64, rot13 of wat dan ook gebruikt wordt, maakt niet uit. De beveiliging van je e-mail wachtwoorden in Thunderbird is vergelijkbaar met de beveiliging van plaintext. Er is geen secret die het veilig maakt. De beveiliging is gelijkwaardig aan plain text.
Ik geef wel toe dat je er een hoofdwachtwoord op kunt zetten. Ik vind dat zelf lastig.
Nog een keer opnieuw (je ongelijk toegeven is moeilijk):
Plaintext is niet beveiligd. Zo'n wachtwoord kun je overtypen en meteen hergebruiken.
De waarden in het json-bestand kun je niet overtypen en meteen gebruiken. Daar moet jij of thunderbird een extra decryptie voor uitvoeren.
Als je een "secret" wilt gebruiken, dan is dat het "hoofdwachtwoord", wat je dan wel elke keer zelf moeten intypen, Want "secret". Ook voor Thunderbird.
Hoe lastig je dat ook vindt.
Maar je kunt natuurlijk altijd je eigen mailsoftware schrijven, helemaal op je eigen voorkeuren afgestemd. Dan heb je dit soort ongemakken niet. 0:-)
Ook kan het hoofdwachtwoord gestolen worden door malware terwijl je het intikt.
In theorie kan dat met elke toetsaanslag. Ook als je andere wachtwoorden overtypt van bv je papieren wachtwoordkluis. Dat zijn ook toetsaanslagen. ;-)
Maar als je bij het terugzetten van een (thunderbird) backup op een schone installatie al last van malware hebt, dan heb je heel andere problemen, in een heel andere orde van grootte.
Exact did "plain text is niet beveiligd"
We hebben het niet over de sterkte van enige beveiliging we hebben het over je claim van plaintext opslag. Anders moeten we het ook gaan hebben over ciphers en nog meer voor deze claim compleet overbodige informatie. Dan kan je net zo goed je gehele opsec er bij betrekken wat again niks te maken heeft met de plaintekst claim. En iets zegt me gezien je dingen zegt als UTF8 wat geen versleuteling is maar encoding (wat dus wel heel veel uitmaakt omtrent je nieuwe argument voering) dat je daar weinig verstand van hebt. Dus iets neerzetten als TLS_AES_256_GCM_SHA384 of Elliptic Curve Ephemeral Diffie-Hellman gaan we niks mee opschieten. Maar als je het over de complete opsec wilt hebben dan komt dat wel weer om de hoek kijken.
De malware argumentatie is ook niet relevant die kunnen ook copy pastes onderscheppen vanuit keymanagers als je niet aanvullende maatregelen hebt getroffen zoals memory protection. Zodra jij malware op het systeem hebt staan die een privilege escalation heeft veroorzaakt dan helpt niks je. En ik bewijfel tenzeerste dat je beschikt over EDR/SIEM koppeling en een killswitch protocol.
Dat je een hoofdwachwoord ofwel secret lastig vind ja dat kan, dat vinden de meeste daarom dat het ook geen verplicht iets *helaas* is. Maar dan waar gaat de hele discussie over als je beveiligen zelf lastig vind.
Je vind dat de beveiliging niet up to par is maar je weigert dus zelf je beveiliging op te schroeven. Of zoals jij het stelt je hebt een inbraak werende deur (bestaat niet btw dat heet vertragende) en inplaats van de picking en slijptol vertragend slot en sleutel(hoofdwachtwoord met AES 256) kies je ervoor alleen een AXA fiets slot en universele sleutel op te zetten omdat je geen zin hebt die sleutel constant mee te sjeulen en dus in je slot laat.
Wat denk je dat de meeste hier doen die gebruiken een keymanager met een hoofdwachtwoord *los* van hun mail applicatie ofwel MUA. Je typt je hoofdwachtwoord in je keymanager de applicatie runt voor x seconden zonder herverificatie en je geeft opdracht voor het vullen van de hoofdwachtwoord gekoppeld aan applicatie veld in de MUA. En dat is basis beveiliging nog niet te hebben over FIDO2, een losse TOTP, app password / OAuth2 wat je op enterprise niveau zult zien voor toegang tot je MUA. Maar voor de meeste is dat allemaal overkill zelfs een hoofdwachtwoord is voor de meeste overkill maar als je echt wilt hebben over opsec en geen vals gevoel van veiligheid dan werk je met zero trust architecture (ZTA)
Je zegt "mijn mailserver" bedoel je je eigen of bedoel je een licentie, seat voor gebruik van een provider MTA op hun domein. Als het je eigen beheerder server is dan ga ik me nog meer zorgen maken om je data gezien wat je allemaal brabbelt over beveiliging.
Want voor de meeste in het vak is de minste zorg wel wat de MUA zelf lokaal doet want iemand met lokale toegang heeft reeds toegang verkregen is door het gros van je beveiliging heen en dan houdt je reguliere opsec op dan moet je vertrouwen op reactive alerts. De MTA is waar je je mee bezig zou moeten houden hoe veiliig is het transport van de MTA naar de MUA. Hoe is je POP3 ingesteld heb je Implicit of opertunistic TLS of nog erger connect je via poort 110. Want als je je transport al niet in orde hebt maakt het ook geen donder meer uit als het wel plain text was lokaal *wat het dus klaarblijkelijk al niet is*
Dus theoretisch plain text wachtwoord opslag oh dat is wel je minste zorg als het om mailserver infra en gekoppelde opslag gaat. De meeste hier snappen dat die proberen je dat ook uit te leggen maar je kronkelt om de discussie heen en verzeker je je houd hier niemand voor de gek daarmee door wild termen te gaan noemen.
En had je gesteld van *ik denk* dat er plaintext wordt gebruikt dan was de discussie nog gevoerd maar wel andere toon van de meeste hier. Nu is het erger want weet je wat ik en denk meeste hier van balen? De valse claim is geindexeerd omdat je het als onderwerp hebt neergezet en die data vervuld dus nu ook de zoekmachines.
We doen niet aan aannames in de IT we lopen stappenplannen af escalatie routes, we onderzoeken we analyseren, we auditen data we maken PoC's we vragen kennisgroepen we vragen leveranciers *voor* we een claim of conclusie de wereld in helpen. Daarom hebben we ook zaken als responsible disclossure.
Want dat is de volgende discussie die we eigenlijk zouden moeten voeren als je gelijk had *wat je niet hebt* Waarom zou je dit op een willekeurig forum posten je eigen opsec notabene in gevaar brengen in plaats van de leverancier benaderen voor controle en patching voor het een probleem zou worden. Nogmaal hypothetisch want er was nul risico qua threat landscape maar voor the sake of the argument benader ik het alsof het zo wel is. Los van of je wel of niet gelijk had gehad absoluut niet slim en zelfs gevaarlijk.
Die sht zien we helaas nu constant terug in de vorm van AI assisted reports en tooling. Ergste nog is dat zelfs gerenomeerde partijen in die valkuil trappen. Ik had drie weken geleden een partij die tijdens een attack in the wild een ongecontroleerde fix de wereld in hielp wegens paniek en duizenden server beheerders een hart aanval bezorgde met het ongefundeerde advies dat de systemen gewiped moesten worden wegens infectie.
Uiteindelijk bleek het detectie script stuk te zijn en veilige sessie informatie van zichzelf als kwaadaardig te zien.
05/04/26 08:50AM CST: Updated the detection script further to remove additional false positives.
05/01/26 11:52AM CST: An updated version of the detection script has been added. This addresses scenarios where false positives were being detected.
05/01/26 08:05AM CST: Temporarily removed the current detection script while we confirm a new version
https://support.cpanel.net/hc/en-us/articles/40073787579671-Security-CVE-2026-41940-cPanel-WHM-WP2-Security-Update-04-28-2026Duizenden servers als gevolg gingen op zwart toegang van eindgebruikers tijdelijk weggehaald bij providers omdat een detectie script en advies van een gerenomeerde partij zei dat het mis was en beheerders die beter hadden moeten weten blindelings het advies volgde in plaats een redteam simulatie uit te voeren of de detectie wel goed werkte. Want een goede ITer die vertrouwd niet eens blindelings op het advies van zijn leveranciers want uiteindelijk ben jij aansprakelijk, verantwoordelijk voor de acties niet die leverancier. "Never Trust always Verify" geldt dan ook niet enkel voor security maar alle aspecten in de IT zelfs tot je eigen kennis.
Bovenstaande is een schoolvoorbeeld van het gevaar wat er gebeurt als je niet goed analyseert voor je claims de wereld in helpt met consequenties er aan verbonden. Hoe eerder je die les leert en belangrijker ervan leert hoe minder schade je jezelf en andere bezorgt.
Laatste wat ik hier over heb gezegd want als het kwartje nu nog niet is gevallen waarom het vanaf begin flawed logic was dan is verdere argumentering nutteloos en als het wel is gevallen dan is de argumentatie klaar.
