sumatra pdf reader gebruiken???

Nah, GrapheneOS heeft een goede apk als PDF-lezer, die is zowel opmde play store als github beschikbaar.
https://play.google.com/store/apps/details?id=app.grapheneos.pdfviewer.play&hl=en
https://github.com/GrapheneOS/PdfViewer/releases
Aannemend dat men een Android-apparaat gebruikt.
Daarnaast is het gebruik van webmail aan te raden ipv.neen cliënt op het apparaat zelf.
Gebruik de volgende app voor E-Mail notificaties van Protonmail:
https://f-droid.org/en/packages/dev.lbeernaert.youhavemail/
Werkt zonder GSF.
MuPDF is ook wel aardig. https://f-droid.org/en/packages/com.artifex.mupdf.mini.app/
Als het om desktop gaat zou ik iets van Okular, LibreOffice of Document Viewer (Gnome Poject) gebruiken.
Iets anders kan ik niet aanraden.
Vergeet niet te doneren (vrijwillig) aan deze projecten aangezien ze non-profit zijn, daarmee houdt men zulke projecten in stand.

fake news
oftewel een onzinbericht af te leiden uit zinnen zoals bijvoorbeeld:
Als je de inhoud van een PDF bestand niet kunt bekijken, is dat bestand niet geopend...

Die code krijg je alleen als je inlogt op een website waar je een account hebt.

Volgens mij begrijpen de mensen hierboven niet hoe de aanval werkt. Je kan de PDF wel 100x sanitizen, het gaat erom dat er een phishing link in zit die mensen bezoeken.

Fout 1: Openen van PDF attachment.
Fout 2: Bezoeken van de URL in de PDF.
Fout 3: Inloggen op de nep website.

Mochten de slachtoffers Passkeys of een Fido2/U2F key gebruiken dan waren ze 'veilig'.

Dat is inderdaad een geldig argument, ikzelf (anoniem van 16:24) bedoelde het meer als antwoord op anoniem van 15:42, maar negeerde daarbij het nieuws artikel zelf, dat schept inderdaad een misconceptie, mijn excuses daarvoor, u heeft gelijk.

Je ziet wel de inhoud van het PDF-bestand. Die ziet eruit als een foutmelding dat je pas toegang tot het document krijgt als je inlogt via Proton. De wachtwoord-prompt van een PDF-lezer is niet gekoppeld aan een Proton-account, dat is niet wat je hier ziet. Wat je ziet is de inhoud van het document. Misleidende inhoud, maar dat is wel degelijk het document, de inhoud van de PDF.

Je verspreidt dus zelf fake news. En als je vindt dat het dat een te zware term is voor jouw vergissing, ga er dan zelf niet meteen met gestrekt been in met fake news-beschuldigingen, want vergissingen maken, door jou en anderen, hoort gewoon tot de mogelijkheden, dat overkomt iedereen.

Dat gaat als volgt. Jij vult je inloggegevens op die fake Proton-inlogpagina in. Wat je daar invult wordt direct doorgesluisd naar de echte Proton-inlogpagina, voor Proton ziet het eruit alsof jij inlogt. Ik weet niet hoe de ondersteunde 2FA-apps precies werken, maar als er iets buiten de webinterface om rechtstreeks met zo'n app wordt uitgewisseld dan gebeurt dat gewoon; en interacties met de webinterface, zoals een code intypen die de app laat zien, worden door de fake site van en naar de echte doorgegeven. Het resultaat is dat als jij je inloghandelingen hebt doorlopen de aanvaller een inlogsessie op jouw Proton-account heeft, want jij hebt zonder er erg in te hebben alles wat die aanvaller moet weten aan hem doorgegeven.

Proton ondersteunt ook U2F, zie ik, en dat bevat bescherming hiertegen, dus ik neem aan dat deze aanval daar niet mee werkt. Met de grondige afkeer die veel mensen op de een of andere manier hebben van gespecialiseerde authenticatie-apparaatjes neem ik aan dat dat een minderheid van de Proton-gebruikers zal zijn, en dat er veel meer een authenticatie-app zullen gebruiken.

Het klopt echt wel. De pdf zal hier gewoon geopend zijn en de inhoud van de pdf is de tekst dat de pdf versleuteld is, met een link naar een phishing pagina om de echte inhoud te kunnen lezen.


En dat account heb je ook. Zoals je boven in de eerste zin kunnen lezen, gaat het om mensen met een Proton of een Google account. Mensen zijn vaak dom en vragen zich blijkbaar niet af hoe een kennid een document in jouw Proton of Google account kan plaatsen en proberen dan blijkbaar op hun eigen account in te loggen om die pdf te lezen. (Via een phishing pagina)

Er wordt waarschijnljjk bedoeld wanneer je het bestand probeert te openen... En ooit gehoord van authenticators? Die genereren constant nieuwe codes, daar is geen inlog poging voor nodig.

Daarom is het juist goed om dit 'fake news' te noemen.
Je moet niet gaan denken wat er bedoeld wordt, maar gewoon lezen wat er beweerd wordt.

Los daarvan moet je voor het inloggen bij bijvoorbeeld Google een inlognaam en wachtwoord geven.
Daarna kun je een 2FA SMS-bericht krijgen als je 2FA ingeschakeld hebt.
Dus als je zomaar een SMS met een code krijgt zonder dat je je daarvoor je inlognaam en wachtwoord gegeven hebt, kunnen ze nog niet bij je Google account. Wat het risico dus is van 2FA per SMS ontgaat mij.

Het risico hier is elke vorm van zwakke 2FA - die niets wezenlijks toevoegt aan een sterk wachtwoord.

Het probleem is dat teveel mensen niet op domeinnamen van websites letten, of niet weten hoe je die moet interpreteren, of niet weten dat de domeinnaam die zij zien niet van de (in het bericht en in de webpagina) gesuggereerde eigenaar (met logo's en dergelijke) is.

De kracht van webauthn (passkeys en FIDO2 hardware keys) zit hem erin dat software voorkómt dat je kunt inloggen als de domeinnaam onjuist is. Maar zowel passkeys als FIDO2 hardware keys kennen ook een reeks nadelen.

Diezelfde kracht (sterke i.p.v. zwakke 2FA) heb je ook als je een wachtwoordmanager gebruikt die checkt of je de juiste (domeinnaam van de) website geopend hebt (zoals ik beschreef in https://www.security.nl/posting/840236/Veilig+inloggen). Wachtwoordmanagers zijn ook beslist niet probleemloos en risicoloos, maar ze zijn (vooral onder Android, iOS en iPadOS) erg handig en je logt er erg snel mee in.

Bijv. inloggen op https://www.security.nl op mijn Android smartphone met KeePassDX gaat als volgt, met die site geopend in elke gewenste (mits geïnstalleerde) browser, na rechts bovenaan de pagina op Inloggen te hebben gedrukt (user-ID en wachtwoord zélf invoeren kan dan overigens ook nog):

1) Druk (in de pop-up) op "Sign in with KeePassDX";

2) Druk op de bestandsnaam voor de gewenste wachtwoorddatabase;

3) Bied je 2FA (niet helemaal want er is een wachtwoord als alternatief, maar dit kost veel minder tijd) vingerafdruk of gezichtsscan aan om het wachtwoord voor de wachtwoorddatabase vrij te geven;

4) Bevestig dat je met het getoonde security.nl-account wilt inloggen. Beide velden worden vervolgens automatisch ingevuld.

Druk ten slotte zelf op "Inloggen".

Dit is allemaal zó gepiept, zonder het schermtoetsenbord aan te hoeven raken. Met als enorm voordelen dat (a) de wachtwoordmanager uitsluitend inloggegevens voor security.nl voorstelt als je de website met die domeinnaam geopend hebt, en (b) een ijzersterk wachtwoord wordt gebruikt dat je niet zelf hoeft te onthouden, en (c) dat je de inloggegevens niet meer zélf, foutloos, hoeft in te tikken.

Je hebt natuurlijk niets aan passkeys, hardware keys en wachtwoordmanagers bij websites die nieuw zijn voor jou (in de zin dat je er nog géén account hebt en ze niet in de database van jouw wachtwoordmanager, passkey of hardware key staan), zoals voor een webshop die je zojuist met een zoekmachine hebt gevonden (zie bijv. https://www.security.nl/posting/851829/Bedrock+webshop%3A+echt+of+nep%3F). Om bij dat soort sites redelijkerwijs nep van echt te kunnen onderscheiden, blijft een fatsoenlijk certificaat essentieel.

Dat is dus een van de problemen dat iets gemakkelijk wordt gemaakt met alle risico's vandien.
Als ik een SMS-tekstbericht met een code krijg om ergens in te loggen _zonder_ dat ik daarvoor een inlognaam en wachtwoord heb ingevuld, is er geen probleem want dan weet ik dat er iets niet klopt.

Ja. Maar daar gaat het in het redactie-artikel toch niet over, of kijk ik ergens overheen?

In het artikel wordt het een aan het ander gekoppeld door adviezen als:

Punt is dat als je een e-mail krijgt met een PDF bijlage, je dan eerst leest van wie en wat die daarover schrijft, en dan pas die bijlage opent. Als je dan een melding krijgt dat je moet inloggen (waarbij? en hoe?) weet je dat er iets niet klopt.
Als je daarna een SMS-tekstbericht met een code krijgt (wat alleen maar kan als je telefoonnummer daarvoor is geregisteerd) is er natuurlijk al van alles misgegaan wat niet direct aan 2FA ligt maar aan andere zaken, bijvoorbeeld een wachtwoordmanager die inlognaam en wachtwoord heeft gegeven voor een website waar dat niet zou moeten?

Je snapt er niets van (of wilt er niets van snappen).

Zoals te lezen valt in deze PDF: https://www.accessnow.org/publication/russian-phishing-technical-brief vindt de aanval plaats als volgt.

Het potentiële slachtoffer heeft een Proton- of een Google account, "extra beveiligd" met een OTP (One Time Password, verzonden via SMS of gegenereerd door een TOTP (eerste T voor Time van Time-based) "Authenticator" app).

Dat potentiële slachtoffer ontvangt een PDF die meldt dat de volledige PDF bijvoorbeeld op Proton Drive staat. Als de ontvanger op de link klikt, opent bijvoorbeeld (ik heb vóór elke punt in de volgende link een extra punt ingevoegd om onbedoeld openen te voorkómen):

    https://account..protondrive..online   (fake)

Die (nep-) site lijkt als twee druppels water op

    https://account.proton.me    (echt)

Een slachtoffer dat zich niet realiseert dat het bij de eerstgenoemde URL om een nepsite (AitM = Attacker in the Middle) gaat, zal diens Proton user-ID en wachtwoord invoeren + op "Sign in" drukken. Dit is de situatie:

Zodra het slachtoffer op "Sign in" drukt, zal code in de website https://account..protondrive..online met de gegevens van het slachtoffer inloggen op https://account.proton.me. Met die primaire inloggegevens van het slachtoffer logt code op de nepsite onmiddelijk in op de échte website.

Wat er vervolgens gebeurt hangt af van de inlogmogelijkheden op de echte website (ik heb geen Proton account, dus ik weet het niet precies wat daar moet of mag):

1) User-ID + wachtwoord volstaan. De AitM is nu ingelogd op de echte website als zijnde het slachtoffer.

2) Het slachtoffer heeft ooit SMS-2FA geconfigureerd op de echte website, waarvoor zijn of haar telefoonnummer op de echte website moest worden geregistreerd. Om nu in te kunnen loggen is dus een OTP vereist. De echte website toont nu een nieuw scherm waarop om het OTP wordt gevraagd; de nepwebsite toont een kopie van dit scherm aan het slachtoffer. Ondertussen genereert de echte website een willekeurig getal (meestal 4 of 6 cijfers) en stuurt dat in een SMS naar het slachtoffer. Zodra het slachtoffer het OTP heeft ingevoerd op de nepsite, stuurt de nepsite dat door naar de echte website. De AitM is nu ingelogd op de echte website als zijnde het slachtoffer.

3) Het slachtoffer heeft ooit TOTP geconfigureerd op de echte website. Daarbij heeft zij of hij een QR-code gescand met daarin een "shared secret" (een groot willekeurig getal gegenereerd door de echte website). Om nu in te kunnen loggen is dus een TOTP vereist. De echte website toont nu een nieuw scherm waarop om het TOTP wordt gevraagd; de nepwebsite toont een kopie van dit scherm aan het slachtoffer. Het slachtoffer opent diens Authenticator app en leest het zes-cijferige getal uit voor de echte website en voert dat in (op de nepsite). De nepsite stuurt dat getal door naar de echte website. De AitM is nu ingelogd op de echte website als zijnde het slachtoffer.

4) Het slachtoffer gebruikt Webauthn (*) of een wachtwoordmanager die (net als Webauthn) de domeinnaam verifieert. De aanval faalt dan, omdat er geen inloggegevens voor de nepsite bekend zijn (in https://security.nl/posting/840236 beschrijf ik, onder meer, het veilige gebruik van een wachtwoordmanager).

(*) Een FIDO2 hardware key (bijv. Yubikey of Google Titan) of een passkey.

Nádat de AitM met succes op de echte site is ingelogd, zal deze in veel gevallen het wachtwoord wijzigen (waardoor het slachtoffer wordt buitengesloten). Ook dit gebeurt meestal geautomatiseerd, dus onmiddelijk.

Als de echte site daarvoor extra beveiligd is, zijn er weer de volgende mogelijkheden:

1) Het wachtwoord moet opnieuw worden ingevoerd. Hier hoeft de AitM het slachtoffer niet voor lastig te vallen, want het wachtwoord kent de AitM al.

2) Indien de echte website een nieuwe SMS-OTP vereist, liegt de AitM naar het slachoffer dat het inloggen is mislukt. Ofwel dat de SMS-code verkeerd is ingevoerd, ofwel dat er iets anders mis ging (wachtwoord en/of OTP onjuist). In dat laatste geval liegt de AitM dat het slachtoffer geheel opnieuw moet inloggen. Het via SMS verzonden OTP misbruikt de AitM om het wachtwoord in iets naar diens wens te wijzigen.

3) Als de echte website om een TOTP vraagt, werkt de zojuist gebruike meestal nog (ze zijn 30 seconden geldig). Mocht die toevallig net niet meer werken, kan de AitM teruggevallen op de aanpak zoals beschreven voor SMS.

De AitM heeft nu het account van het slachtoffer overgenomen. Naast dat oude mails gelezen kunnen worden, kan de crimineel vaak ook toegang tot accounts van het slachtoffer op andere websites verkrijgen door daar voor "wachtwoord vergeten" te kiezen. En/of het adresboek uitlezen en nieuwe slachtoffers maken.