Thunderbird waarschuwt gebruikers voor PGP keys die gaan verlopen
De ontwikkelaars van Thunderbird hebben een nieuw versie van het Release Channel uitgebracht die onder andere gebruikers waarschuwt als hun PGP key binnen 31 dagen verloopt. PGP keys worden gebruikt om versleuteld met anderen te mailen. PGP keys hebben als veiligheidsmaatregel standaard een verloopdatum. Dit moet de impact van een gestolen key beperken.
Thunderbird gaf voorheen pas een waarschuwing als gebruikers met een verlopen PGP key wilden mailen. Met Thunderbird 141.0 zal de e-mailclient nu proactief een duidelijke waarschuwing in het venster voor het opstellen van e-mail laten zien wanneer de key binnen 31 dagen verloopt. Volgens de ontwikkelaars maakt dit de inbox van gebruikers proactief.
Een andere nieuwe feature is de mogelijkheid om inkomende e-mailberichten direct via notificaties van het onderliggende besturingssysteem te archiveren. Het is daardoor niet meer nodig om naar Thunderbird zelf te gaan voor het archiveren van berichten. De twee features zijn beschikbaar in Thunderbird 141. Deze versie bevind zich in het Release Channel waar de meeste Thunderbird-gebruikers geen gebruik van maken.
De meeste gebruikers werken namelijk met een Thunderbird ESR-versie. ESR staat voor extended support release en betreft een versie die voornamelijk beveiligingsupdates en bugfixes ontvangt. Thunderbird blijft een bepaalde ESR-versie lange tijd ondersteunen. Grote nieuwe features worden alleen bij de overstap naar een nieuwe ESR-versie toegevoegd.
Met het Release Channel worden sneller nieuwe features aan de e-mailclient toegevoegd. Volgens het ontwikkelteam maakt op dit moment tien tot twintig procent van de Thunderbird-gebruikers gebruik van het Release Channel. Overstappen van ESR naar Release Channel vereist het downloaden van de laatstgenoemde versie en het installeren in dezelfde directory waar de ESR-versie zich in bevindt.
Zorg voor een goede backup van je secret key en revoke je hele PGP sleutel als daar aanleiding voor is. Of maak vooraf een revocation certificate aan die je bij deze backup bewaart.
Zorg voor een goede backup van je secret key en revoke je hele PGP sleutel als daar aanleiding voor is. Of maak vooraf een revocation certificate aan die je bij deze backup bewaart.
Een uitleg hierover staat in https://gnupg.org/gph/en/manual.html#AEN526.
Zelf heb ik er last van dat mijn hoofd een beetje gaat duizelen bij alle master/sub keys. Ik vind het prettig om het te begrijpen zoals het was in PGP 2.x. Een RSA sleutel voor zowel signing als encryption. Natuurlijk is MD5 wat PGP 2.x gebruikt helemaal achterhaald, maar los van de leeftijd van de software werkte het goed en eenvoudig. Er was zelfs een alternatieve versie van Disastry van PGP 2.6.3ia multi die alle algoritmes van RFC 4880 toevoegde aan PGP 2.x. Helaas is Disastry overleden bij een bergbeklimming.
De DH/DSS sleutels die er vroeger waren (vanwege patenten op RSA tot september 2000) hadden de beperking dat het ondertekenen met 1024 bit asymmetrische sleutels gebeurde. Dat was achteraf gezien onveilig. Maar het was een standaard van de VS dus daar viel niets aan te veranderen.
Met 'gpg --gen-key --expert' kan je dat oude gevoel een beetje terughalen, maar er is geen garantie dat je sleutel dan blijft werken met alle software die er ook is. Het beste is om de standaard instellingen te gebruiken net zoals iedereen.
Anoniem 17:45
Zorg voor een goede backup van je secret key en revoke je hele PGP sleutel als daar aanleiding voor is. Of maak vooraf een revocation certificate aan die je bij deze backup bewaart.
Je realiseert je dat je ook niet kunt weten _of_ die aanleiding daarvoor er is ?
Met een verloopdatum is er in elk geval een uiterste grens aan het misbruik - analoog aan TLS certs .
Verder is PGP ecosysteem natuurlijk op sterven na dood - revocation cert verspreiding is twijfelachtig .
Als je alleen maar hobbymatig met een handvol contacten werkt kun je die - als je dan twijfelf over je key - nog wel de revocation sturen .
Merk op dat ongeveer de enige groep waar PGP gebruik nog echt zichtbaar is (CERT teams) dus inderdaad werken met jaarkeys .
Logisch - ze hebben relatief veel en onvoorspelbare correspondenten , en als teamleden vervangen worden is het - hoe integer en correct die ook zijn - ook wenselijk dat die niet meer eeuwig "potentieel" de cert key zouden kunnen weten/hebben.
Met een verloopdatum is er in elk geval een uiterste grens aan het misbruik - analoog aan TLS certs .
Je computer kan al compromised zijn voordat je je PGP sleutel genereert. Of tussen het genereren van twee PGP sleutels in. Het enige zinvolle dat je zou kunnen doen is om je computer helemaal schoon te installeren, en dan een nieuwe PGP sleutel aan te maken. Maar ik herinstalleer mijn computer niet gebaseerd op de verloopdatum van mijn PGP sleutel. Zolang mijn computer werkt laat ik die zo. Als je je computer schoon installeert, vernietig je ook al het bewijs dat die besmet was.
Een verloopdatum op een encryptie sleutel is volledig arbitrair.
Binnenkort komt een nieuwe versie van GnuPG en Gpg4win. Dat zou een mooie aanleiding zijn om voor het eerst quantum proof sleutels aan te maken. Thunderbird zal wel na-ijlen omdat ze niet de broncode van GnuPG wilden gebruiken. Omdat het in C is geschreven waarschijnlijk. Ook arbitrair.
Anoniem 17:45
Met een verloopdatum is er in elk geval een uiterste grens aan het misbruik - analoog aan TLS certs .
Je computer kan al compromised zijn voordat je je PGP sleutel genereert. Of tussen het genereren van twee PGP sleutels in. Het enige zinvolle dat je zou kunnen doen is om je computer helemaal schoon te installeren, en dan een nieuwe PGP sleutel aan te maken. Maar ik herinstalleer mijn computer niet gebaseerd op de verloopdatum van mijn PGP sleutel. Zolang mijn computer werkt laat ik die zo. Als je je computer schoon installeert, vernietig je ook al het bewijs dat die besmet was.
Een verloopdatum op een encryptie sleutel is volledig arbitrair.
Dus als jij in de IT zou werken zou je admin passwords ook nooit roteren ?
Als ik in de IT zou werken dan zou ik mij aan de regels van de organisatie waarvoor ik werk houden.
Ik heb een lokaal password op mijn Xubuntu computer. Deze roteer ik niet. Deze is ook meer bedoeld om bezoekers van mijn woning uit mijn computer te houden als ik in een andere kamer ben en zit alleen maar in mijn hoofd. En het password is natuurlijk nodig voor sudo. Met een schroevendraaier kom je bij mijn data, wat de standaard instelling is voor Xubuntu bij installatie en upgrade problemen voorkomt. Met een schroevendraaier tegen mijn trommelvlies krijg je ook het password van mijn PGP sleutels.
Het roteren van passwords zorgt ervoor dat je makkelijke wachtwoorden gaat bedenken die net door het systeem komen. Daarmee ben je uiteindelijk minder veilig uit. Zo ging DigiD een leesteken verplichten. Die heb ik gedobbeld en op een random plaats toegevoegd in mijn bestaande wachtwoord. En ik heb mijn wachtwoord met een teken verkort voor het gemak dus DigiD schiet daar niet veel mee op. Het wachtwoord is alleen nog slechter te onthouden en in te voeren voor mij. Gelukkig hoeft dit bij mij maar een keer per jaar.
Natuurlijk heeft Logius een ontmoedigingsbeleid voor mensen zonder smartphone. Het moeilijker maken van het gebruik van wachtwoorden past in die strategie ;-)
Anoniem 17:45
Als ik in de IT zou werken dan zou ik mij aan de regels van de organisatie waarvoor ik werk houden.
Ah, ik bedoelde natuurlijk : als jij degene was die de beleidsregels voor de IT van jouw organisatie opstelde ...
Kortom - als je keuzes moest maken in een professionele setting (en met wat meer gebruik) in plaats van je prive account.
[..]
Het roteren van passwords zorgt ervoor dat je makkelijke wachtwoorden gaat bedenken die net door het systeem komen. Daarmee ben je uiteindelijk minder veilig uit.
Het voornaamste advies dat achterhaald is is "niet opschrijven" .
Daar zijn password managers voor - zodat je én unieke wachtwoorden per login én lang+random én enige mate van rotatie kunt doen.
[..]
Er is natuurlijk een verschil is nut/haalbaar en beste keuzes qua procedures tussen
één prive persoon, oninteressant, en werkt met een behoorlijk veilig platform + fysiek redelijk setting en
organisaties, wisselende personen, eventueel meer "interessant" etc .
Kortom - als je keuzes moest maken in een professionele setting (en met wat meer gebruik) in plaats van je prive account.
Ik heb mij er niet in verdiept. Maar een RSA Token gecombineerd met een wachtwoordzin volgens Diceware? Misschien met een Nederlandse woordenlijst?
Een RSA Token zit niet op je smartphone (die besmet kan raken vanuit bijvoorbeeld de App Store of een 0-day). En een wachtwoordzin typt makkelijker als een random reeks tekens. Ik zou niet overal een wachtwoordzin voor gebruiken. Alleen voor PGP sleutels en zo. En die cachen in het geheugen zolang je je mail programma open hebt staan.
Een RSA Token is natuurlijk een soort van rotatie gebaseerd op tijd ;-)
Je kan ook nog wachtwoorden sterker maken door een hash functie te herhalen of bits van de uitvoer weg te gooien (zoals bij crypto munten). Ik weet niet meer precies hoe deze laatste methode werkt.
Anoniem 17:45
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Netwerkspecialist
Maak jij gemeente Delft digitaal sterker met jouw kennis van netwerken? Wil jij werken met een state-of-the-art netwerk en meebouwen aan de digitale toekomst van Delft? Bij ons combineer je strategie en uitvoering: van het ontwerpen van netwerkarchitectuur tot het oplossen van complexe incidenten. Zo maak jij écht impact, niet alleen op onze organisatie, maar op heel de stad.
Subsidie
Veel IT-dienstverleners wijzen hun mkb-klanten nu op deze cybersubsidie:
Mijn Cyberweerbare Zaak
Ontdek waarom
Cybersecurity Trainer / Full Stack Developer
Ben je toe aan een nieuwe job waarmee je het verschil maakt? Wil jij je security kennis graag delen en hands-on laten zien hoe cybersecurity in de praktijk echt werkt? Werk je net als wij graag samen met enthousiaste en gedreven collega's? Bij ons geen bureaucratie maar open communicatie en een werkomgeving gericht op samenwerking.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?