Firefox slaat wachtwoorden voortaan lokaal op met AES-encryptie

Mozilla heeft de ingebouwde wachtwoordmanager van Firefox voorzien van AES-256-CBC-encryptie voor het lokaal opslaan van wachtwoorden. Dat gebeurde tot nu toe via 3DES-CBC, maar die encryptiemethode is achterhaald.

De upgrade van de encryptie zit in Firefox 144, meldt Mozilla. Dat is de recentste versie, die dinsdag uitkwam. Alleen de lokale versleuteling verliep nog via 3DES-CBC, want het synchroniseren via het Mozilla-account gebeurt al langer via AES. De nieuwe versleuteling is veel moeilijker te kraken, wat het opslaan van wachtwoorden veiliger moet maken.

De nieuwe Firefox-versie bevat meer nieuwigheden, zoals de eerder aangekondigde functie om te werken in profielen, visueel zoeken via Google Lens en de integratie van AI-dienst Perplexity als zoekmachine in de browser.

Reacties (57)

[Grrrrrene]

Aan de ene kant is lokale opslag van wachtwoorden wel zo veilig, maar aan de andere kant is het niet heel gebruiksvriendelijk. Ik vind het heel fijn dat mijn password manager, zodra ik het installeer, van mijn wachtwoorden in de cloud gebruik kan maken. Ik heb ze dus beschikbaar op mijn telefoon, laptop, werklaptop, tablet, etc. Nu zul je waarschijnlijk kunnen verwijzen naar een mapje op je NAS die je open zet voor toegang van buitenaf, maar dat is toch minder gebruiksvriendelijk dan cloudopslag.

[PD2JK]

Wachtwoorden kunnen prima gesynchroniseerd worden naar de Mozilla cloud, werkt prima.

[R_Zwart]

Waarom zou je het dan nog lokaal willen hebben?

[PD2JK]

Professioneel gezien: Als ik geen 'ge-cache-de' kopie van die database zou hebben, zou ik in de problemen kunnen komen bij storingen. Genoeg routers, switches en hyper-visors met een webinterface welke on-prem draait.

Ja, je kunt een hotspot aanmaken met je mobiele telefoon, maar dat is verre van ideaal. Je zit dan op twee netwerken tegelijk met je laptop (wifi en koper-NIC)

[Reactie gewijzigd door PD2JK op 15 oktober 2025 12:34]

[Blizz]

Voor de veiligheid, de keus ligt bij jou.

Ik vind het nog steeds ironisch dat juist Apple de eerste was met versleutelde browserwachtwoorden en dat Google het een decennium geleden nog steeds weigerde in te bouwen en alles plaintext werd opgeslagen. Ook bij Firefox kreeg je direct toegang tot wachtwoorden als er geen master password was ingesteld.

[pnxsinned]

Ehhh? De eerste browser die dit had was dus Netscape, uitgave van 1997. Welke een encrypted WW manager had.

[Blizz]

Gezien de implementatie van Firefox zal het bij die versies van Netscape ook wel afhankelijk zijn geweest van een opt-in master password? Ik kan me overigens niet herinneren waar het precies werd opgeslagen in Firefox, maar van Chrome meen ik mij te herinneren ergens een plaintext bestand te hebben gevonden na het toevoegen van een testwachtwoord. Hoe dan ook kon je het natuurlijk ook in de browser zonder controle inzien en bij Firefox evengoed zonder dat opt-in master password.

[pnxsinned]

Het ging mij meer om het feit dat Apple niet als eerste was. Ik surf al zolang op het internet, old man.

[Blizz]

Misschien had ik de uitspraak moeten beperken tot moderne/huidige browsers. Rond of na 1997 klikte ik wel op linkjes in Netscape, maar volgens mij zijn mijn eerste wachtwoorden enkele jaren later pas bedacht.

[JayPe]

Een mapje, op je NAS, die je open zet voor toegang van buitenaf...

Klinkt ook niet heel erg veilig.

Doet Firefox die wachtwoorden niet ook synchroniseren over al je devices?

[dewfuz]

https://www.vaultwarden.net

Secret server, zelf hostable, werkt met bitwarden client/ browser plug-in.

Beter dan 'mapje' open, en persoonlijker dan iemand anders zijn computer/ cloud

[The-Source]

Inderdaad en als je secure remote wil doen.
Cloudflared tunnel met nodige WAF rules en wellicht ook nog MTLS certificaat op je devices.
Zo filter begin ik dat alleen landen op de white-list toegang mogen hebben, vervolgens wordt elke ip-range die script-kiddy acties proberen in hele ranges geblokkeerd.
En daarna moet je nog voldoen aan het MTLS certificaat voordat je op de login pagina komt. (die overigens door reverse proxy geserveerd wordt dus direct toegang tot de vaultwarden host is er niet.)
De reverse proxy zorgt er voor dat ik lokaal (wifi) en extern dezelfde FQDN kan gebruiken.

Overigens zou je ook met tailscale het kunnen werken (ik gebruik beide maar voor alleen vaultwarden sync of home assistant client heb ik geen tailscale nodig)

[Kevinns]

Vast veiliger, maar voor 99,9% van de mensen veel te complex om op te zetten en te onderhouden. Dan is een publiek gehoste oplossing een haalbaarder alternatief. Of lokaal gehost en alleen via VPN bereikbaar.

[i-chat]

Dan zet je een paar van die functies uit

Bij mij draaide vaultwarden in een docker die alleen verbonden was aan de docker van cloudflared voor de rest liet ik de beveiliging over aan cloudflared door per device 1x per 24u een 2fa tocken te vereisen om toegang te krijgen moest je dus een password én een een otp token hebben

[dewfuz]

Hier een wildcard cert (anders staan je subdomeintjes alsnog op crt.sh) en een traefik die op basis van hostname routeerd.

Dan een niet standar subdomein, Ook nog een beetje obscurity

[gigi71]

Het voordeel van een dienst als bv. Onedrive is dat je daar ook vanuit bedrijfsnetwerken vaak gewoon bij kunt. Gebruik een wachtwoordmanager die een veilige encryptie voor zijn wachtwoordbestand gebruikt (bv. aes256) en een lang, makkelijk niet standaard wachtwoord. " AllewegenleidennaarRomebehalvedewegnaaromaskoffie@10uur" is veel makkelijker (en moeilijker te kraken) dan " %24%ghEassqweC#"

[remmuz]

Dat werkt inderdaad zo. Overal dezelfde browser passwords op elk platform dat ik gebruik zonder dat ik weer een andere tool nodig heb.

[Ablaze]

Firefox slaat standaard wachtwoorden lokaal op. Maar met een Mozilla account kun je ze ook synchroniseren met andere apparaten. Dat is opt-in, zoals het zou moeten zijn.

[Jazco2nd]

Dat is juist exact wat Firefox ook doet. Het wordt opgeslagen door Firefox Sync en is overal op al je ingelogde devices beschikbaar. Net als elke andere paswoord manager wordt het ook lokaal opgeslagen.

[haam]

Ik synchroniseer pc en mobiel wel met mn NAS, maar dat werkt alleen als ik verbonden ben met het lokale netwerk (NAS heeft geen toegang tot internet) en ik handmatig een sync initieer.

Ik zie de toegevoegde waarde van online sync niet echt, anders dan 'gemak'. Maar gemak en secure geeft altijd wat spanning.

De browser dingen laten opslaan heeft alleen zin als het gesynced wordt (ergo ingelogd ben) en daar pas ik voor.

[desalniettemin]

Bitwarden extensie gebruik ik.

[nihilissimis]

Ze zjjn er rijkelijk laat mee:

The National Institute of Standards and Technology (NIST) deprecated 3DES in 2018 due to its vulnerabilities and the advancement of more secure encryption methods.

Triple DES (3DES) has been deprecated due to its insufficient security against modern attacks, with its use disallowed after December 31, 2023.

[GertMenkel]

3DES breken vereist zo'n 785GiB aan data die met dezelfde sleutel versleuteld wordt. Dat is een behoorlijke wachtwoorddatabase die je op je systeem hebt. Algoritmisch gezien heeft 3DES last van sleutelverzwakking, maar nog steeds zit het met 80-bit-beveiliging redelijk veilig in de praktijk.

Effectief zie ik eerlijk gezegd het voordeel niet zo. Tooltjes die wachtwoorddatabases ontsleutelen zijn zo oud als browserwachtwoorddatabases. Welk versleutelingsmechanisme je gebruikt, is niet zo heel relevant voor de meeste gebruikers. Het handjevol mensen dat een eigen sleutel voor de database gebruikt zal er op vooruit gaan als er een grote overheid is die een paar jaar aan rekenkracht aan hun gestolen wachtwoorddatabase besteden, maar voor de meeste mensen blijft het risico even groot.

Niet dat ik tegen het gebruik van AES ben, hoor, ik vind het een mooie verbetering. Het gebruik van een oude versleutelingsmethode is alleen lang niet het probleem dat gesuggereerd wordt als je de berichtgeving van cryptografen zonder context leest.

[blackSP]

Als ik het goed interpreteer veranderd er niets qua synchronisatie. Immers: "Alleen de lokale versleuteling verliep nog via 3DES-CBC, want het synchroniseren via het Mozilla-account gebeurt al langer via AES. De nieuwe versleuteling is veel moeilijker te kraken, wat het opslaan van wachtwoorden veiliger moet maken."

Wachtwoorden worden met de oude versleuteling ook gewoon gesynchroniseerd.

Dit staat ook in de bron: https://www.firefox.com/en-US/firefox/144.0/releasenotes/

[Reactie gewijzigd door blackSP op 15 oktober 2025 08:35]

[latka]

Klinkt alsof ze tijd over hebben. Als ze die nu steken in het oplossen van de performance problemen die ze hebben zodra je Firefox onder Linux gebruikt dan doen ze iets nuttigs.

[kozue]

Performance problemen onder Linux? Ik gebruik alleen maar Linux, en alleen Firefox als browser. Ik heb dus dagelijks Firefox draaien onder Linux op meerdere systemen (desktop en werklaptop). En ik zou niet weten welke performance problemen je het over hebt. Alles werkt hier prima.

[GertMenkel]

Mozilla's eigen benchmarks laten zien dat Firefox op Linux trager is dan Firefox op Windows. Ik heb er in de praktijk niet zo'n heel groot probleem mee, maar het verschil is wel meetbaar.

Ik begrijp het ook wel, Firefox is al een kleine speler en de niche van een niche bedienen door ook nog eens op de minimale hoeveelheid Linuxgebruikers in de wereld te focussen is niet per se de moeite waard.

[kozue]

Ze zouden zich juist goed op Linux moeten richten. Firefox is onder Linux bovengemiddeld populair. Het is de default browser op de meeste distro's.

[desalniettemin]

Ik ben overgestapt naar Brave, want ik kan maar niet wennen aan de nieuwe window controls die mijn thema niet meer gebruiken en ik weet niet waarom, maar ik kan geen Netflix meer kijken met extensies aan of uit maakt geen verschil. Steeds een E100 foutcode. En ook nog steeds micro freezes tijdens live sport op Viaplay die ik met Brave niet heb.

[Reactie gewijzigd door desalniettemin op 15 oktober 2025 10:40]

[HollowGamer]

Je zou ook eens de bugreports en op kanalen als Reddit kunnen zoeken, over performance issues met Firefox en Linux. Zoiets als VA-API is nog altijd een opt-in, en nog niet voor iedereen bruikbaar.

Dat is niet alleen op Firefox een probleem, zelfde ook met Brave zoals @desalniettemin aangeeft. Ook hierin heb ik flags moeten zetten, omdat dat te forceren. Ook voor GPU-accel bij het renderen van pagina's.

[desalniettemin]

Laatste keer dat ik VA-API probeerde met Firefox toen werkte het niet. Had iets met Intel te maken of zo. Je kon dat checken en toen ik dat deed mistte er iets, maar wat dat weet ik niet meer. Maakt ook niet meer uit Brave werkt prima, want genoemde problemen heb ik met Brave niet.

[desalniettemin]

Ik weet nu wat het Firefox Netflix probleem was. Het is de Netflux extensie. Vreemd dat met Brave ik die E100 foutcode niet heb, want daarin gebruik ik ook de Netflux extensie.

[HollowGamer]

Dit is ook belangrijk, security issues hebben in mijn optiek prio.

Maar ben het ook met je eens. Firefox blijft heel langzaam, zeker op Linux. Nu ze meer AI erbij gooien, wordt het nog logger. Helaas hebben ze ook veel developers eruit gegooid, maar ze kunnen gelukkig nog wel feestjes organiseren naar verre landen om daar 'vrijheden' te vieren.

[desalniettemin]

Als je echt geen AI wil is Vivaldi de optie.

[HollowGamer]

Ik heb niets tegen AI.

Alleen bij Firefox vind ik de browser al langzaam, en nog langzamer met hun AI tools aan.

[latka]

Het is specifiek YouTube heb ik ervaren, dus ik vermoed dat het probleem vooral daar zit.

[HollowGamer]

Er zijn verhalen dat Google bewust Firefox en adblockers het leven zuur maakt. Vroeger zei ik dat dit onzin was, tegenwoordig twijfel ik daarover.

[DoubleYouPee]

Uhm, ik gebruik al jaren verschillende profielen in firefox. Dat was toendertijd juist een van voordelen tov andere browsers

[Swindowmasher]

Ik gebruik dit ook al jaren door manueel naar about:profiles te gaan. Maar blijkbaar was het een functie die je manueel moest aanzetten die nu standaard is.

[kozue]

visueel zoeken via Google Lens en de integratie van AI-dienst Perplexity als zoekmachine in de browser.

Oh nee he, niet nog meer Google spyware en AI troep die door je strot worden geramd. Dé reden voor mij om Firefox te gebruiken is omdat het geen Google is. Chrome en Chome-gebaseerde browsers wil ik niks van hebben. Dus laat aub die Google rommel achterwege, en laat ook meteen de AI hype voor wat het is.

[rookie no. 1]

Eens, maar dan moeten we wel heel wat meer donaties aan Mozilla gaan doen ;)

[telenut]

In welke mate is dit veilig voor malware die wachtwoorden uit browsers gaat stelen?
We merken af en toe wel eens dat iemand iets installeerde dat de lokaal opgeslagen wachtwoorden uit Google Chrome en Microsoft Edge ophaalde en doorstuurde.
Als de browser ze kan lezen, dan maakt de manier van encryptie niet veel uit denk ik...

[GertMenkel]

Malware die je wachtwoorden steelt gaat 3DES niet brute-forcen, dat zou jaren duren.

De meeste mensen hebben geen eigen wachtwoord op hun profiel ingesteld, maar laten Firefox een wachtwoord genereren en daarmee worden de logins versleuteld. Afhankelijk van je platform wordt dat in een sleutelbeheermechanisme gestopt (credential manager op Windows, Keychain op Mac, etc.).

Malware dumpt dat wachtwoord en gebruikt dat om de wachtwoorddatabase van je browser te ontsleutelen. Dat wordt door je besturingssysteem moeilijk gemaakt, maar aangezien wachtwoorddatabases nog steeds worden gestolen, is het duidelijk niet onmogelijk.

Bij Firefox kun je wel je eigen sleutel kiezen overigens. Daar zal malware middels een keylogger achter moeten komen.

[KorporaalTimmer]

Als je alle apparaten van Apple hebt en daarnaast een fatsoenlijke Windows 11 computer met originele drivers en licenties; is de iCloud sleutelhanger dan aan te raden, of af te raden? Ik heb het gevoel dat deze altijd werkt maar ik kan niet terugvinden of men deze wel eens kraakt zoals je bij andere managers regelmatig hoort. Het is voor ons belangrijk dat het altijd en overal werkt en het meest veilig is. Toch een andere zoeken dan?

[aikebah]

Het is voor ons belangrijk dat het altijd en overal werkt en het meest veilig is.

Het meest veilig is iets dat niet altijd en overal werkt, dat is nu net de crux in de trade-off gebruikersgemak versus security.

[Scriptkid]

Ik denk dat iedereen hier het allerbelangrijkste vergeet,

Door het gebruik van AES256 en hoger is deze methode van opslaan meteen beschermd tegen harvest now en decrypt later met quantum ,

AES is een van de weinige encrypties die Quantum safe is voor de komende jaren aangezien een quantum computer met 25 miljoen pysieke qbits er nogsteeds langer over doet dan het universum oud is om het te kraken.

En de quantum tijdlijn begint heel kort te worden 2027 is de eerste deadline en zouden alle developers alle non quantum encrypties zoals RSA en EC uit moeten hebben gefaseerd in hun software en overgestapt zijn naar quantum safe zoals AES want in 2027 komen de eerste Quantum SAAS oplossingen beschikbaar in cloud.

Van 2030 - 2035 Heb je een overgangs periode van actief uitfaseren van software die nog niet quantum safe is. Dit is de groote risico zone waar harvest now decrypt later van toepassing zal gaan zijn omdat je tegen 2030 SAAS met genoeg qbits zult krijgen om het ook daadwerkelijk toe te passen.

Hoelang duurt het per encryptie type to decode met quantum:
https://quantum.microsoft...ools/quantum-cryptography

Quantum Timelines en deadline voor implementatie change en bedrijfs risico:
https://www.microsoft.com...8558e6b8f2ccca03e54cb6ac7

[Reactie gewijzigd door Scriptkid op 15 oktober 2025 12:01]

[GertMenkel]

3DES is toch niet extra kwetsbaar voor quantumaanvallen? Voor zover ik weet is dat vooral een probleem voor asymmetrische cryptografie. Ik zie een paper dat aangeeft dat je met keying option 2 (een zwakke doch veelgebruikte implementatie van 3DES) "maar" 1000 qubits nodig hebt om de aanval realistisch gezien uit te voeren, maar zelfs dan heb je daar meerdere quantumcomputers van die grootte voor nodig en aardig wat tijd. Tegen veiligere sleutelmethodes voor 3DES is zelfs een quantumcomputer niet opgewassen, dat moet je met de "gewone" brute-force doen totdat quantumcomputers van een duizend of meer qubits betaalbaar worden. Voor de onderzoekers die de aanval naar minder dan 1000 qubits hebben weten te reduceren, lijkt niet een machine beschikbaar te zijn geweest om hun theorie op te valideren.

[Reactie gewijzigd door GertMenkel op 15 oktober 2025 12:26]

[Scriptkid]

maar dat is het ding,

in 2030 zijn die er als SAAS dat is juist de timeline clock die nu de nood bel ringt om allemaal wakker te worden en nu te acteren.

[trick2011]

je verwisseld dingen.

symmetrische encryptie ((3)DES, AES, PRESENT) en hash functies (SHA, keccak, Whirlpool) zijn gewoon veilig voor quantum omdat deze gestoeld zijn op NP harde problemen die niet op te lossen zijn met een quantum compter. (of in ieder geval, deze oplossingsmethoden zijn nog niet bedacht of getest)

Asymetrische encryptie (rsa en elliptic curves) maken gebruik van NP harde problemen die wel op te lossen zijn met behulp van quantum computers: factoriseren en discrete logaritme probleem.

[Scriptkid]

Daar zijn anders op Inet veel sources het niet mee eens

A 10 million qubit quantum computer could break 3DES in a fraction of a second by using Shor's algorithm, though the exact time is theoretical. This is because the number of qubits required for this attack is less than 10 million, and quantum computers are capable of performing complex calculations on massive datasets simultaneously, with a potential to solve the encryption problem very quickly once the necessary number of stable, error-corrected qubits are available.

Our findings
show that the 3DES with keying option 2, the most widely
employed variant of 3DES, can be attacked with a circuit depth of
approximately 267 and less than a thousand qubits. This is close
to the 264 value suggested by NIST for the depth achievable
sequentially by a single quantum computer in a decade. Our
technique can be further sped up parallelizing the approach onto
multiple devices, pointing to the practicality of cryptanalyzing
3DES in such a scenario

https://re.public.polimi....9a579512e5/2024219323.pdf

[Reactie gewijzigd door Scriptkid op 15 oktober 2025 13:16]

[GertMenkel]

10 miljoen daadwerkelijke qubits? Het zal vast komen, maar nog niet in 2030. We zitten nu op een theoretische 6000 maar de mensen die vermoeden dat ze er 6000 hebben weten te maken, hebben er nog niet mee kunnen rekenen. Al die qubits tegelijkertijd in correcte superpositie houden is nogal een uitdaging. Het is niet alsof je zes machines van 1000 qubits kan pakken om 6000 qubits te produceren, het spul moet wel op quantumniveau samenwerken.

Met een miljoen qubits heb je ook AES ook al wel opgelost, dus dan beschermt deze stap helemaal nergens tegen. Gelukkig kun je bij AES de sleutel langer maken om quantumcomputers te verslaan (bij DES ook wel, maar dan krijg je wat, 9DES? met dubbel zoveel bits veiligheid? pak dan gewoon AES-512).

Het soort mensen dat over tien jaar toegang heeft tot zo'n machine, kunnen je vandaag van straat plukken, in een kelder douwen, en je stroomschokken geven tot je je browserwachtwoord opgeeft. 3DES is een risico voor dingen als VPN's en grootschalig internetverkeer, maar voor de rest zitten we nog wel eventjes goed.

[Scriptkid]

Geen idee waar je die data vandaan haalt maar met 25k qbits duurt het nogsteeds oneindig voor aes.

Zoals je kunt zien in de source die ik deel zijn de timeliness enorm naar voren geschoven.

Wil je wel geloven maar kom dan eens met actuele sources. Nu is het jouw woord tegen sources van Microsoft.

[GertMenkel]

De aanval in het paper dat je linkt gebruikt Grover's algorithm en dat werkt net zo goed op AES als op 3DES. De bron die je aanhaalt is een theoretische kwetsbaarheid die theoretisch uitvoerbaar is op hardware over tien jaar als je drie ordegroottes negeert ("close" aldus NIST), deze is niet geverifieerd door de aanval daadwerkelijk aan te voeren. Dat algoritme vereist ook dat een van de praktische problemen met Grover's Algorithm wordt opgelost, namelijk dat het enige tijd stabiel blijft draaien wat op quantumhardware heel lastig is, en dat is nu net waarom aanvallen op AES niet heel praktisch zijn.

Dit paper berekent dat AES aan te vallen is met Grover's algorithm met zo'n 3000-7000 qubits. Toch wordt AES als quantum-resistent gezien. De getallen die ze noemen komen in ordegrootte aardig overeen met de getallen uit het paper over 3DES dat je linkte (tabel 2 gaat over machten van 2, niet het aantal gates zelf).

Op zich is dat ook logisch: net als DES is AES een symmetrisch versleutelingsalgoritme en die zijn nu eenmaal van nature quantum-resistent vergeleken met veel van hun assymmetrische tegenhangers. De realistische aanvallen gebeuren dan ook vooral op gebieden als SSL en TLS, waar men assymmetrisch de symmetrische sleutel uitwisselt. Je hoeft AES niet te doorbreken met superdure supercomplexe quantumcomputers als je de Diffie-Helman key exchange kunt doorbreken met relatief eenvoudige, relatief goedkope quantumcomputers, en hetzelfde geldt voor veel DH-alternatieven.

Mij is door de quantumcomputer-industrie verteld dat we in 2025 al de eerste quantumaanvallen zouden zien, dus ik blijf sceptisch. De eerste commerciële, massageproduceerde quantumcomputer is mij in 2012 beloofd maar ik zie ze nog nergens te koop. Als je genoeg betaalt kun je op Microsoft's chips met 8 qubits berekeningen uitvoeren in de cloud, maar daar zit je toch een paar ordegroottes onder de goedkoopste aanval zelfs tegen DES. De theorie blijft zich doorontwikkelen, helemaal nu eenvoudige circuits te testen zijn door mensen die niet in een topuniversiteit werken, maar tot nu toe is de groei van het commerciële aanbod gestaag en laat de praktijk nog op zich wachten.

Ik heb ook geen bronnen van Microsoft gezien?

[Scriptkid]

Ik heb ook geen bronnen van Microsoft gezien?

Die heb ik je in de eerste post gegeven

[GertMenkel]

Ah, ik dacht dat je andere bronnen had gelinkt. Deze twee zijn namelijk niet zo heel relevant?

De inschattingstool van Microsoft zegt niks over 3DES. Ik heb geprobeerd om de inschattingstool 3DES te laten plotten via het AI ding, maar het AI ding zei dat hij dat niet kon en vertelde me om zichzelf te bezoeken om die inschatting te maken. Laten we hopen dat Microsoft hun quantumspul betrouwbaarder kan maken dan hun AI-spul

De parameters die de tool wel laat zien, namelijk het tijdverschil voor het doorbreken van asymmetrische cryptografie (RSA, elliptische curves) tegenover symmetrische cryptografie (AES, DES), laten zien dat die laatste categorie niet vatbaar is voor aanvallen door quantumalgoritmes.

De andere link is vooral een marketingcampagne voor hun recent gestarte project om RSA en EC uit te faseren binnen hun eigen infrastructuur. Waar er concrete informatie wordt genoemd, spreekt men dan ook over asymmetrische cryptografie, zoals bij TLS 1.3 in de context van key exchanges (waar noch 3DES noch AES voor gebruikt worden). Op zich mooi dat ze net met een proof of concept zijn gestart om over tien jaar aan het door NIST-opgestelde risicoprofiel te voldoen, maar weinig relevant voor het doorbreken van symmetrische cryptografie of de duizenden verbonden qubits die je daarvoor nodig hebt.

Ik zie eerlijk waar niet wat deze bronnen met het nieuwsartikel te maken hebben.

[ewoutw]

Hoe verhoud de WW kluis van FireFox zich tot betaalde diensten als proton. last pass, keeper, enz.

Uiteindelijk staat het in de cloud versleuteld en moet je maar hopen dat ze niet gesloten en gekraakt worden?
De betaalde diensten bieden meschien ook extra opties.... maar puur voor wachtwoorden? Weet iemand dat?