Niet alle tweefactorauthenticatieschema's zijn hetzelfde. Sommige vormen van 2FA, zoals het sturen van een sms, zijn niet beveiligd tegen deze aanval. Andere vormen van 2FA, zoals FIDO U2F, zijn beveiligd tegen deze aanval - ze zijn opzettelijk ontworpen met dit soort aanval in gedachten.

FIDO U2F biedt twee verdedigingen tegen de man-in-the- middelste aanval:

1. Registratie - De gebruiker registreert zijn U2F-apparaat bij een bepaalde website ("oorsprong"), zoals google.com . Dan reageert het U2F-apparaat alleen op authenticatieverzoeken van een geregistreerde oorsprong; als de gebruiker wordt misleid om goog1e.com (een phishing-site) te bezoeken, zal de U2F niet reageren op het verzoek, omdat het kan zien dat het van een site komt die het niet heeft eerder geregistreerd bij.

2. Kanaal-ID en oorsprongsbinding - U2F gebruikt de TLS Channel ID-extensie om man-in-the-middle-aanvallen te voorkomen en stel het U2F-apparaat in staat om te verifiëren dat het met dezelfde website praat die de gebruiker in zijn webbrowser bezoekt. Ook weet het U2F-apparaat met welke herkomst het denkt te praten, en zijn ondertekende authenticatiereactie bevat een handtekening over de herkomst waarmee het denkt te praten. Dit wordt gecontroleerd door de server. Dus als de gebruiker zich op goog1e.com bevindt en die pagina vraagt ​​om een ​​U2F-authenticatie, geeft de reactie van het U2F-apparaat aan dat de reactie alleen goed is voor communicatie met goog1e.com - als de aanvaller dit antwoord probeert door te geven aan google.com , merkt Google dat er iets mis is gegaan, aangezien de verkeerde domeinnaam aanwezig is in de ondertekende gegevens.

Beide functies hebben betrekking op de integratie tussen het U2F-apparaat voor tweefactorauthenticatie en de browser van de gebruiker. Door deze integratie weet het apparaat welke domeinnaam (herkomst) de browser bezoekt, en kan het apparaat phishing en man-in-the-middle-aanvallen detecteren of voorkomen.

Meer informatie over dit mechanisme :

• Een fragment uit de FIDO U2F-specificatie, betreffende verdediging tegen MITM-aanvallen.

• Yubico's uitleg van de protocolstromen.

2FA buiten de band is de juiste benadering. Dit betekent dat je een tweede factor hebt die niet kan worden phishing, zoals een clientcertificaat of FIDO U2F. Codes of sms-gebaseerde 2FA-modellen zijn de zwakste 2FA-opties omdat ze in-band zijn, en zoals je hebt beschreven, kunnen worden gephishing op dezelfde manier als inloggegevens.

Ze zijn handig omdat ze door bijna iedereen kunnen worden gebruikt, en ze zijn zeker beter dan niets, maar de beveiliging die ze bieden mag nooit worden verward met de beveiliging die wordt geboden door out-of-band 2FA.

Dit is een van de situaties waarin een (in browser) wachtwoordbeheerder je kan helpen.

Omdat een wachtwoordbeheerder wachtwoorden opslaat op basis van hun echte url, wordt deze niet automatisch ingevuld op de pagina van de aanvaller, of zelfs geef suggesties. Behalve dat het 2-staps wachtwoordtoken niet lekt, beschermt het ook het wachtwoord tegen uitlekken.

Deze bescherming werkt zelfs beter als de gebruiker zijn eigen wachtwoord niet kent en kan alleen communiceren via de wachtwoordbeheerder voor het invullen van het wachtwoord.

Waar het op neerkomt, is dat als een aanvaller je voor de gek kan houden door alle inloggegevens op te geven, het spel voorbij is. Het maakt niet uit hoeveel factoren er bij betrokken zijn. Er zijn dingen die de blootstelling kunnen helpen beperken, zoals zeer korte time-outs voor tokens die het voor een aanvaller moeilijk maken om het token binnen de tijdslimiet te bemachtigen en opnieuw te gebruiken. Time-outs bieden echter beperkte bescherming, omdat het moeilijk kan zijn om de juiste balans te vinden, vooral met 'nep' 2FA, die zo wijdverspreid is geworden en waar je vertragingen moet toestaan ​​bij zaken als sms-bezorging om bruikbaarheidsproblemen te voorkomen (ik heb dit gezien met internationale gebaseerde services waarbij de sms-bezorging langzamer kan zijn en het token een time-out krijgt voordat u het kunt ontvangen en in de browser kunt invoeren).

Veel van de systemen met de naam 2FA zijn helemaal niet echt 2FA - ze zijn eigenlijk 2SA (authenticatie in twee stappen). In echte 2FA zijn de factoren iets dat je weet (wachtwoord) en iets dat je hebt (token, vaak hardware-gebaseerd). Schema's waarbij een code wordt verzonden via sms zijn GEEN 2FA, ze zijn 2SA - u hebt niet echt het token - deze wordt naar u verzonden. Omdat het iets is dat naar u wordt verzonden, zijn er nieuwe bedreigingsvectoren, zoals het omleiden van het mobiele nummer enz. Dit is een van de redenen waarom NIST op SMS gebaseerde tokens heeft afgeschaft als een betrouwbaar authenticatieproces.

Met respect op de specifieke vraag van de OP's, is de enige betrouwbare bescherming het kunnen detecteren van de phishing-pagina. Google heeft een Chrome-extensie uitgebracht om hierbij te helpen. De extensie waarschuwt u als deze detecteert dat u uw Google-inloggegevens opgeeft op een pagina die geen Google-pagina is.

Het grote probleem is dat we jarenlang mensen hebben geleerd om te zoeken naar het "groene hangslot" in URL's om enige zekerheid te geven dat de pagina legitiem is. Helaas hebben inspanningen zoals Lets Encrypt het nu gemakkelijk gemaakt om domein-geverifieerde certificaten te krijgen, dus veel van deze phishing-pagina's hebben nu het groene hangslot. Dit wil niet zeggen dat het probleem te wijten is aan Lets Encrypt - dit is een heel goed initiatief. Het probleem is gedeeltelijk te wijten aan zwakke punten in de PKI-infrastructuur, maar vooral aan het bewustzijn en begrip van de gebruiker. Over het algemeen begrijpen mensen PKI niet en begrijpen ze niet hoe ze kunnen verifiëren dat een certificaat legitiem is voor de site en dat de site de site is waarvan ze denken dat het is. Om het nog erger te maken, zelfs als u het begrijpt, zijn de stappen / tijd die nodig zijn om die verificatie uit te voeren vaak onhandig of gewoon te moeilijk, zodat mensen het niet doen. De situatie wordt nog verergerd door slechte acteurs van het hakmes die manieren vinden om dingen er legitiem uit te laten zien - een recente exploit maakt bijvoorbeeld gebruik van zwakheden in de manier waarop browsers URL's en Unicode-tekens weergeven om een ​​URL te genereren die in de adresbalk wordt weergegeven op een manier die bij een blik ziet er correct uit, maar de daadwerkelijke tekens in de URL specificeren een phishing-site. De gebruiker kijkt naar de adresbalk, ziet een groen hangslot en kijkt naar de URL die er goed uitziet (je brein zal zelfs dingen invullen om de match er beter uit te laten zien!) En accepteert de pagina als legitiem. U merkt geen extra witruimte tussen tekens of ietwat vreemd uitziende tekenvormen.

Dus hoe beschermen we ons hiertegen. Helaas is er geen enkele "doe dit en je bent veilig". Sommige wachtwoordbeheerders kunnen helpen, omdat ze de inloggegevens alleen verstrekken als de URL correct is, gebruik nooit URL's in e-mailberichten - typ deze altijd zelf in of gebruik een door u gemaakte bladwijzer. ga ervan uit dat u op een bepaald moment voor de gek zult worden gehouden en pas praktijken toe die de schade beperken wanneer deze zich voordoet, dwz verschillende wachtwoorden voor elke site, gebruik op hardware gebaseerde 2FA indien mogelijk, klik daadwerkelijk op de knop met certificaatdetails voor sites met een hoge waarde en kijk er staat en voor wie het certificaat is geregistreerd, zorg ervoor dat uw systeem alle updates heeft en dat u de meest recente browserversie enz. gebruikt, wees wantrouwend van aard en onthoud dat de grote bedreiging social engineering is, dus wees voorzichtig met alles dat onder druk staat u om actie te ondernemen op basis van angst, schuld, beloning of straf. Dit zijn zeer effectieve motivatoren en dreigingsactoren vertrouwen erop. Phishingcampagnes zijn veel geavanceerder geworden in hun implementatie, maar in de kern vertrouwen ze nog steeds op emotionele manipulatie - een belofte van iets geweldigs of een dreiging van iets vreselijks.

Tot slot, als je in de verleiding komt om te reageren omdat ik wachtwoordbeheerders noem, doe dat dan niet. Ja, er zijn risico's met wachtwoordbeheerders en ja, sommige zijn erger dan andere. Over het algemeen biedt een goede wachtwoordbeheerder die correct wordt gebruikt, meestal meer bescherming voor de gemiddelde gebruiker dan hun huidige wachtwoordbeheerproces. Ja, als de wachtwoordbeheerder wordt gecompromitteerd, zijn al uw wachtwoorden gecompromitteerd. Veel mensen vinden wachtwoordbeheer echter te moeilijk en gebruiken sowieso op elke site hetzelfde, vaak zwakke wachtwoord. Zodra één site is gecompromitteerd, zijn al hun sites gecompromitteerd. Als u technologie begrijpt en wachtwoorden, hashing enz. Begrijpt, kunt u waarschijnlijk een veiligere oplossing bedenken, maar u bent niet het publiek voor wachtwoordbeheerders. Bedenk hoe uw ouders of grootouders omgaan met wachtwoordbeheer en hoe goed ze phishing-sites herkennen of certificaten begrijpen, en bedenk vervolgens hoe gemakkelijk ze uw aangepaste op GPG gebaseerde wachtwoordbeheer kunnen afhandelen via cfile of synchronisatie.

BEWERKEN : Bij het herlezen van mijn antwoord, weet ik niet zeker of ik genoeg heb benadrukt dat echte 2FA in toenemende mate beschikbaar is en veel van de providers die momenteel de minder veilige 2SA met sms-codes ondersteunen, ondersteunen ook veel veiligere 2FA, in veel gevallen met behulp van U2F ( zoals vermeld in andere antwoorden). Hardware 'sleutels' van Yubico of duo (en anderen) zijn goedkoop en gemakkelijk in te stellen / te gebruiken. Mijn enige aanbeveling is dat als je besluit om naar de hardwaretoken / sleutelroute te gaan, je ervoor zorgt dat je twee sleutels krijgt, ze beide registreert en een sleutel op een veilige locatie opbergt. Ik heb er een die ik bij me draag en een die ik thuis in een kluis heb. Herstellen van een verloren / beschadigde sleutel is niet zo eenvoudig als het herstellen van een vergeten wachtwoord, dus u wilt zoveel mogelijk voorkomen dat u in die situatie terechtkomt.

Zoals aangegeven in de opmerkingen, is dit geen goede manier om dingen te doen.

Keer de test volledig om.

In dit geval vertrouwt u erop dat de mobiele telefoon van de gebruiker 'veilig' is, dus gebruik dit om hem te authenticeren. Wanneer de gebruiker probeert in te loggen op de website, dient u telefonisch een verzoek in om akkoord te gaan met deze login (via push-notificatie idealiter rechtstreeks naar de applicatie, niet via sms of e-mail, aangezien deze gemakkelijk kunnen worden geschonden). 'Het lijkt erop dat u zich aanmeldt vanaf IP x.y.z / geolocation foobar - wilt u doorgaan?'

U kunt ze ook een certificaat laten verstrekken dat op de telefoon aanwezig is, maar niet op de computer. Op deze manier heeft de 'aanvaller' geen toegang tot deze informatie door de gebruiker simpelweg naar de verkeerde site om te leiden.

Deze aanval staat bekend als phishing . Alle beveiliging in de wereld zal geen goed doen als u een eindgebruiker voor de gek kunt houden door de inloggegevens vrijwillig in te leveren.

De maatregelen tegen phishing zijn onder meer: ​​

1. E-mailservers kunnen e-mails doorzoeken op links naar bekende phishing-sites.

2. E-mailclients schakelen links vaak standaard uit en geven een waarschuwing wanneer ze worden ingeschakeld.

3. Gebruikers moeten vermijden op links in e-mails te klikken. Het is vaak veiliger om het adres in te typen.

4. Gebruikers mogen nooit toegang krijgen tot een gevoelige site (bijvoorbeeld een banksite) via een link waar dan ook. Gebruik een bladwijzer of typ deze.

5. In tegenstelling tot wat algemeen wordt aangenomen, moeten gebruikers moeten wachtwoordbeheer gebruiken voor gevoelige sites. Een wachtwoordbeheerder zal u geen wachtwoord voor de verkeerde site laten verstrekken.

Als aanvulling op de andere antwoorden kan dit soort aanvallen worden belemmerd als de site zich authenticeert bij de gebruiker , zodat de gebruiker de gewoonte heeft om een sterker signaal dat ze inloggegevens invoeren op een authentieke pagina, zelfs als ze geen wachtwoordbeheerder gebruiken of niet super aandacht besteden aan de URL. Dit wordt meestal gedaan met een door de gebruiker geselecteerde beveiligingsafbeelding (uit een groot aantal opties) plus een door de gebruiker ingestelde tekstreeks. Het wordt weergegeven na het invoeren van de gebruikersnaam maar vóór het wachtwoord (dat wordt opgesplitst over twee pagina's). Het is niet helemaal waterdicht (je moet voorkomen dat de aanvallers de afbeelding / string krijgen door simpelweg een bulkverzoek te doen), maar het is ontworpen om phishing tegen te gaan, en het maakt succesvolle phishing een beetje moeilijker om uit te voeren. Als de aanvallers proberen om beveiligingsafbeeldingen / strings op te halen, kunnen deze verzoeken de echte serviceprovider ook een tip geven dat er iets niet klopt, en wat forensische informatie geven over waar die verzoeken vandaan komen.

Of het in de praktijk werkt of niet, is een andere vraag, en het bewijs uit een paper uit 2007 suggereert niet, althans voor de meeste gebruikers.