Proton patcht Authenticator-bug die 2fa-secrets opsloeg in lokale logbestanden

Proton heeft een bug opgelost in de iOS-versie van zijn Authenticator-app. Deze zorgde ervoor dat de totp-secrets van gebruikers in plaintext werden vermeld in lokale logbestanden. Als gebruikers die logs handmatig deelden met anderen, hadden ze daarmee onbedoeld hun 2fa-codes uitgelekt.

De bug werd ontdekt door een Proton Authenticator-gebruiker op sociale media. Deze gebruiker had last van een andere bug in de 2fa-app, waardoor enkele 2fa-entries waren verdwenen. De gebruiker wilde daarover een bugreport indienen inclusief de logbestanden van de app. Daarbij kwam de gebruiker erachter dat de logbestanden de volledige totp-secrets bevatten in platte tekst, blijkt uit een inmiddels verwijderd Reddit-bericht.

Dergelijke totp-secrets bestaan uit een reeks cijfers en letters. Ze werken als een soort sleutel die de gebruiker toegang geven tot de 2fa-codes van een specifiek account. Gebruikers kunnen dergelijke codes handmatig toevoegen in een 2fa-app en vervolgens codes voor het gekoppelde account genereren. Het uitlekken van dergelijke secrets zou anderen dus toegang geven tot die 2fa-codes.

De bug lijkt voort te komen uit code van de Proton Authenticator-app voor iOS, merkt een andere Reddit-gebruiker op. Wanneer gebruikers een 2fa-entry aanmaken of bijwerken in de iOS-app, worden de parameters daarvan vastgelegd in de logbestanden. Onder die parameters valt ook het totp-secret.

Proton heeft het probleem inmiddels opgelost. Het bedrijf benadrukt tegenover Bleeping Computer dat de logbestanden uitsluitend lokaal worden opgeslagen op het apparaat van de gebruiker. Het was door de bug dus niet mogelijk om op afstand toegang te verkrijgen tot de totp-secrets van de Proton Authenticator-gebruiker, tenzij de gebruiker die logbestanden zelf handmatig deelde met anderen.

De bug maakt het ook mogelijk voor anderen om de secrets te bekijken als ze fysiek toegang tot het apparaat van de gebruiker hebben. Het is echter toch al mogelijk om die secrets lokaal te exporteren vanuit de app, zodat ze overgezet kunnen worden naar andere 2fa-apps. "De versleuteling van Proton biedt geen bescherming tegen compromittering van het apparaat zelf, dus u moet uw apparaat altijd beveiligen, aangezien dit buiten ons dreigingsmodel valt", aldus het bedrijf.

Proton bracht zijn Authenticator-app vorige week uit. Het betreft een alternatief voor de 2fa-apps van bedrijven als Google en Microsoft. De dienst is beschikbaar voor Android, iOS, Windows, macOS en Linux.

Proton Authenticator
Bron: Proton

Door Daan van Monsjou

Nieuwsredacteur

05-08-2025 • 12:51

64

Submitter: itsme

Reacties (64)

64
62
24
2
0
30
Wijzig sortering
Wauw. Een beetje security-minded developer weet dat je dat niet moet doen.. Geen code reviews gedaan intern?
Wellicht was het bij een eerdere fase van het ontwikkeltraject, op dat moment, een geaccepteerde change en is men vergeten deze change terug te draaien bij de release.

Een betere oplossing tijdens de realisatie van de app was geweest om een production flag te hebben. Waarbij gecheckt wordt, voordat een secret gelogged wordt, of de app in een productie omgeving draait. Dan was dit ook niet fout gegaan tijdens de release.
In testing moet je nooit toestaan wat je in productie ook niet aanvaard imho. Dat je tijdens het ontwikkelen zelf even iets doet om het debuggen te helpen, daar kan ik inkomen, maar van zodra je dit naar een hoger niveau brengt hoort dit simpelweg niet door je review te komen.
ik denk zelfs dat dit door de automated commit pipeline geflaged had moeten worden.
Uberhaupt moet dit soort code altijd worden gemarkeerd met een comment label dat je door een linter kan laten oppakken.
//NODEPLOY: Handy to quickly check if TOTP is the same on alternative software.
print( secrets );
Zo heb je ook TODO, DEBUG, TEMP, etc. Hoewel het nooit netjes is om tijdelijke code in een release te hebben, kan het wel eens noodzakelijk zijn. Een NODEPLOY tag kan ervoor zorgen dat een oplossing eerst afgedwongen wordt, in plaats van een waarschuwing.
>Het bedrijf benadrukt tegenover Bleeping Computer dat de logbestanden uitsluitend lokaal worden opgeslagen op het apparaat van de gebruiker. Het was door de bug dus niet mogelijk om op afstand toegang te verkrijgen tot de totp-secrets van de Proton Authenticator-gebruiker, tenzij de gebruiker die logbestanden zelf handmatig deelde met anderen.

Voor "gewone mensen" is dit misschien niet zo'n probleem, maar voor waardevolle doelwitten zoals journalisten, activisten en wetenschappers zeker wel. Ik vind het opmerkelijk om te lezen dat een bedrijf als Proton zo een grote blunder op deze manier wegwuift.
Ze wuiven niks weg, ze beschrijven de impact en lossen het probleem op. Finito.
Ik hoop dat ze ook het probleem oplossen dat zoiets uberhaupt kon gebeuren. Dit is echt een serieuze blunder.
Legio. En ik ben ook software developer. Maar gelukkig waren daar de systeemtest, integratietest en daarna acceptance test omgevingen. Waarna de interne afdeling die verantwoordelijk was voor het product richting klant ook nog testen deed en accoord gaf. Een bug bij de klant kost 100x meer dan een bug gevonden in een systeemtest.

Maar als securityfocused bedrijf in 2025 in je shiny nieuwe authenticator-app tokens in plaintext loggen is gewoon hilarisch.
Zo'n reactie lees je nu nooit als het om Microsoft, Apple, Google etc gaat. Fouten bij underdogs worden vaak goed gepraat terwijl het net zo fout is als bij de grote bedrijven.
Gelukkig zijn er nog nooit andere grote corporaties, en beveiliging bedrijven geweest die fouten hebben gehad in software.
Zou wel verschrikkelijk zijn als meer bedrijven blijken te werken met menselijke developers en er in de toekomst ook fouten bij andere naar voren komen.
Misschien toch maar alle dev's outsourcen naar AI?
Andere bedrijven die falen worden ook afgestraft. Maar een bedrijf als proton (ik ben klant en fan) dat heel securityminded is faalt toch echt wel enorm in het hele IT proces als het lukt om in een authenticator-app in de officiele releaseversie alle tokens in plaintext te loggen naar een file. Dat is geen gewoon foutje; dat is een gebrek aan developer awareness en een gebrek aan degelijk testen. Ze falen op het gebied waar ze expert in zouden moeten zijn.
Nog iemand die het probeert goed te praten omdat Proton het lievelingetje is. Dat anderen fouten maken is geen reden om het goed te praten. Zeker niet als je bedenkt dat Proton de uitdager is die beter wil doen dan de gevestigde orde.
Denk jij dat AI dit soort fouten niet maakt?
Denk jij dat AI dit soort fouten niet maakt?
Nee. AI maakt veel fouten maar een van de parameters die wij gebruiken als we AI code laat maken is dat bepaalde gegevens nooit opgeslagen mogen worden. Een van de enorme voordelen van AI is dat ze dit soort fouten (bij juiste input) niet maken.
Niet finito. Ze gebruiken in hun reacties op hun eigen subreddit ook de argumenten:
  • "Apple's back-ups zijn al versleuteld" en
  • "als wij dan ook versleutelen is er sprake van double encryption"
als argumenten tegen end-to-end versleuteling door Proton zelf.

Notabel hierbij is dat:
  • de appdata dus niet versleuteld opgeslagen lijkt te zijn en dat
  • Apple's back-ups alleen end-to-end zijn versleuteld als je Advanced Data Protection hebt ingeschakeld, iets dat het leeuwendeel van gebruikers niet aan heeft staan.
Deze app lijkt gericht op gebruikers die minder aandacht hebben voor veiligheid, maar ik vind het plaintekst opslaan van 2FA-secrets in geen enkele situatie acceptabel.

[Reactie gewijzigd door Blizz op 5 augustus 2025 14:29]

En waar stel jij voor dat de encryption key wordt opgeslagen als je wilt dat ze ook lokaal logs gaan encrypten?
Dat ging niet over de logs, maar over de appdata zelf. Logs kun je natuurlijk plaintext opslaan zolang er geen kritische informatie in staat. Er is meer mis met hoe de app werkt of lijkt te werken. Een probleem is dat er veel onduidelijk is omdat de app net uit is, de documentatie tekortschiet (de app zelf is wel open-source, maar er is nog geen enkele technische documentatie gepubliceerd), en ze op z'n minst 'ongeïnteresseerd' reageren op het vlak van versleuteling. Van willekeurige 2FA apps snap ik dat wel, maar van Proton verwacht ik dat ze end-to-end versleuteling vereisen voor de data, voor de back-ups, voor alles wat gevoelig is of kan zijn.

Ik vind het overigens begrijpelijk dat de documentatie zo vroeg nog wat tekort kan schieten, maar het geheel laat zien dat de app eigenlijk niet release-klaar was. Niets hield ze tegen om het als beta uit te brengen of om de publieke release uit te stellen.

[Reactie gewijzigd door Blizz op 5 augustus 2025 15:14]

En waar stel jij voor dat de encryption key wordt opgeslagen als je wilt dat ze ook lokaal logs gaan encrypten?
Ik had begrepen dat er tegenwoordig speciaal daarvoor afgeschermde hardware in zo ongeveer ieder mobieltje en pc zit. Versleutelde secret erin, otp code eruit.

Of de secret zit er zelfs in opgeslagen, maar ik dacht dat je hem dan niet meer kan delen met je andere apparaten.

In ieder geval zou zo een secret niet eens ontsleuteld beschikbaar moeten zijn voor de software, laat staan dat hij in de log terecht komt.
Dit is waarom je kritieke apps misschien niet in de eerste week van hun release downloadt...
Is wel gelijk een grote fout ook in deze nieuwe app.

En aangezien het juist bij deze zaken om vertrouwen, vertrouwen en vertrouwen gaat, geen beste start van Proton hiermee.


Testen is tegenwoordig sowieso een ondergeschoven kindje geworden.

Snel uitbrengen en de eerste gebruikers als live betatesters gebruiken is nu de norm.

Goedkoper maar wel met gevolgen.
Ik snap ook niet zo goed waarom ze hier niet gewoon een bètaronde van hebben gehouden. Ik begrijp best dat dat soms wel heel complex is om te beheren, bijvoorbeeld bij zoiets als Battlefield 6, maar een authenticatieapp zal geen honderden bugmeldingen per dag krijgen. Bovendien lijken mij de meeste Proton-gebruikers goed op de hoogte van wat ze gebruiken, dus ik ga er voorzichtig vanuit dat de meeste bugmeldingen degelijk zullen zijn en bruikbare informatie voor de ontwikkelaars zullen bevatten.
Ook al krijg je wel honderden bug meldingen. Lijkt mij dat je dat voor zoiets als deze app met liefde te horen krijgt?
Daar ga ik ook wel vanuit, maar ik doelde meer op het kunnen afhandelen ervan. Ik weet niet hoe groot Protons Authenticator-team is, maar stel dat er maar drie personen aan deze app werken, dan is het natuurlijk wat lastiger om honderden bugmeldingen te behandelen.
Ik snap ook niet zo goed waarom ze hier niet gewoon een bètaronde van hebben gehouden.
Dat hebben ze vast wel gedaan. Maar al je testers niet vraagt om dit specifiek te testen, is dit werkelijk makkelijk om te missen door beta's. Dit soort dingen moet je intern afvangen tijdens je system tests.
Haha, ook mijn eerste gedachte..
Maar dan inderdaad bij iedere patch. Want ook na een patch kan zoiets (suffigs) als dit gebeuren.
Suffigs? Als je voor debuggen echt plaintext wil loggen van security stuff beperk het dan tot een paar gespecificeerde accounts of zo. Dit is gewoon een blunder die niet zover had mogen komen.
Deze app werkt zonder account. Ze hadden het inderdaad op een specifiek hardware-ID kunnen doen, maar dat is ook weer zo iets. Maar het had er inderdaad niet in moeten zitten.
Of log alleen de tokens van de site(s) waarmee je test. Iets wat ervoor zorgt dat je nooit alles logt zoals nu mis ging maar met een checklijstje. Of alleen als je op een bepaald wifinetwerk zit of ... Mogelijkheden genoeg.
Je hoeft mij niet te overtuigen dat het gewoon niet handig was. :)

Deze app werkt overigens (ook) volledig offline, en een specifiek wifi-netwerk in je code opnemen lijkt me ook een beetje 'gek' om te doen voor een app als dit.

Punt is, is dat het er gewoon niet in had moeten zitten.
Dat wifinetwerk opnemen is een extra measure tijdens development om de gevolgen te beperken mocht er verderop iets misgaan bij het uitzetten van die debugcode.

De hele wifi+plaintext logging debugcode moet er sowieso uit of disabled in de uiteindelijke build als alles goed gaat.
Wanneer gebruikers een 2fa-entry aanmaken of bijwerken in de iOS-app, worden de parameters daarvan vastgelegd in de logbestanden. Onder die parameters valt ook het totp-secret.

Insert de "But why" meme.

Zelfs al zou je de specifieke logs niet meer in de debugopties zetten.. waarom komt het zoiezo in een log terecht?
Waarschijnlijk gebruikt voor debugging tijdens het testen, maar vergeten om deze feature eruit te halen in de release, denk ik dan. Wel een flinke blunder voor een 2fa app
Ik heb hem nu een paar dagen draaien onder Android en nog geen last gehad van bugs. Gebruik geen sync. Zou nog aardig zijn als de keys syncen met proton pass, die heeft al een veld voor 2FA

Ben allang blij dat ik bij twello/authy weg kan.
Ja same. Op dag 1 weg bij Microsoft Authenticator. Die begon teveel tabjes te krijgen die niets met OTP te maken had
Ik begreep ergens dat je niet je entries mee kon nemen vanuit de MS-Authenticator naar Proton. Heb je ze opnieuw aangemaakt?
Nee dat kan niet inderdaad. Alles opnieuw aangemaakt
Ben allang blij dat ik bij twello/authy weg kan.
Ja alleen nou weer alles met de hand opnieuw aanmaken, daarom zit ik nog bij Authy. :P
was ook niet blij, maar viel uiteindelijk reuze mee om de boel om te zetten. Kan nu in iedergeval makkelijker overstappen als ik alsnog een andere app wil gebruiken en zat er toch aan te komen
Ik zit op 43 codes, jij? :P

Maar ik moet het ook maar gewoon eens doen en stoppen met excuses maken, want daarna heb je weer de volledige vrijheid inderdaad. Desnoods beginnen met 5 en morgen weer 5 etc.
Bij mij viel het mee, stuk of 15. Niet alles in 1 keer gedaan.
Maar hoe langer je wacht hoe groter het probleem
Mijn probleem meer is een redelijk simpele mappenstructuur die ik nu heb in mijn huidige 2FA app. Ik heb net zoals jij tientallen OTP codes die ik heb verdeeld in mail, social, gaming etc. anders wordt het een zooitje. Zie verder ook nog weinig features die ik nuttig vind t.o.v. mijn huidige app. Ik ben fan van Proton en hun diensten maar wat mij betreft hoeft deze app ook niet per se.
Ook ik doe aan monnikenwerk van authy naar proton. Zelf doe ik het op de computer-desktop en een sync naar android en iphone. Daarbij valt het mij op dat veel hosts verschillend om gaan met het opnieuw authenticeren:
Sommige sites laten je de mfa uit zetten en daarna weer aan. (jammer maar even geen mfa is geen ramp)
Sommige sites laten de qr-code met de originele authenticator key zien. (iets om over na te denken)
Sommige sites laten je netjes een nieuwe maken waarna de oude wordt ge-deactiveert. (netjes)
Sommige sites geven ook aan dat de lopende/active sites/machines moeten her initialiseren.

Bedenk dan dat twillo (van authy) en ook microsoft aangeven dat een export van deze master-keys niet kan wegens security uitdagingen, iets waar ik wel in kan komen.
Dank voor je reactie!

Ik ga ze sowieso opnieuw aanmaken, omdat ik dan zeker weet dat een datalek bij Authy mij niet blijft achtervolgen, anders kan ik net zo goed deze situatie aanhouden.
Ik gebruik hem nu ook en aantal dagen, so far so good. Goede motivatie om eindelijk bij Authy weg te gaan.
Ik heb nog wel meer problemen bemerkt:

- Als ik een search doe, dan worden de codes voor de gevonden resultaten niet bijgewerkt. Blijven dus in de search "eeuwig" op de gevonden waarde staan.

- Als ik vanuit de Google Authenticator via QR-codes keys importeer dan komen die dubbel in de Proton Authenticator te staan (van iPhone naar iPad, en omgekeerd).

De andere problemen, niet kunnen inloggen en log bestanden met keys, heb ik ook gezien.

Dat laat bij mij bepaald geen goede indruk achter: vertrouwen komt te voet, maar gaat te paard.
Prachtig, iedereen van de week
Gelijk alles overgezet
Heeft mij luiheid mij toch weer beschermd.
Mijn grote vraag is of en hoe deze lek via de log eventueel op andere platformen te zien is en/of is aangetroffen. Zijn er tweakers die zo ver hebben gekeken?
Ik heb een ander probleem met de Authenticator-app. Geïnstalleerd op m'n iPhone en gekoppeld aan mijn Proton account. Op de PC synct hij prima, echter als ik de app ook installeer op m'n iPad, kan ik iet syncen. Na het inlogscherm kom ik weer op een leeg authenticator-app scherm uit.
Is bekend bij Proton. Heb daar zelf ook last van en een bugreport voor ingediend. Ze zijn ermee bezig, maar weten niet wanneer het verholpen is.
Werkt als workaround het uitzetten van iCloud Sync voor de app?
Dank je! Is er ergens een linkje naar het report, waar ik kan zien wat de status is?
Bij mij was het met sync tussen android en de pc dat de pc niet de nieuwe keys zag tot ze werd afgesloten en opnieuw wordt opgestart. Van android naar iphone heb ik niet getest.

Uiteindelijk ga ik er voor het gemak van uit dat de sync gewoon niet wild is en niet per-se elke 5 minuten wil bijwerken en ook niet bij elk gebruik de sync controleerd. In dit geval wel zo handig/netjes en ook verklaarbaar. Het aantal keys zal na de eerste opzet niet snel groeien.


Om te kunnen reageren moet je ingelogd zijn