[PHP/JS] Herkennen 'trusted devices' voor website tbv 2FA

[Schonhose]

Onlangs heb ik twee-factor authenticatie toegevoegd aan mijn laravel applicatie. Dit werkt perfect, maar het inloggen op mijn mobiel is nu een stuk lastiger. Dit komt omdat de twee-factor gebruikt maakt van de Google Authenticator app.

Nu heb ik daarover zitten brainstormen en de meest voor de hand liggende optie lijkt mij om binnen een gebruikersaccount de mogelijkheid te hebben om 'trusted devices' te registeren. Wanneer de site wordt geopend op een trusted device wordt de twee-factor authenticatie overgeslagen (je hebt dan nog wel de username/password nodig).

Nu ben ik aan het nadenken hoe ik een 'trusted device' kan gaan herkennen. De eerste optie die in mij opkwam was gebruik maken van de User Agent die in de headers wordt meegestuurd. Ik ben me er volledig van bewust dat deze gespoofed kan worden, dus ik zit er aan te denken om het IP adres ook mee te nemen in de registratie van het apparaat.

Een andere optie is het zetten van een speciale (encrypted) cookie. Dit is overigens ook te combineren met de User Agent. Waar ik dan wel over twijfel is of het gebruik van cookies nog van deze tijd is.

Mijn vraag, hoe robust is het bovenstaande en zie ik iets over het hoofd?

[Compizfox]

Het overslaan van 2FA op bepaalde 'trusted devices' maakt volgens mij de 2FA inherent waardeloos. Als attacker kun je dat gewoon spoofen om de 2FA te omzeilen.

Cookies zijn zeker wel 'van deze tijd' (hoe implementeer je anders sessies?) maar ik vraag me af of je daar wat mee opschiet. Als je erover nadenkt gebruik je al cookies om een ingelogde gebruiker te herkennen en een sessie op te starten.

Stel je gebruikt een andere cookie om een "trusted device" te herkennen waardoor die client geen 2FA meer hoeft te doen. Dat kun je uiteraard pas doen nadat je de gebruiker geauthenticeerd hebt (m.a.w: nadat de gebruiker ingelogd is). Wat let je dan om in plaats daarvan gewoon diezelfde sessiecookie te gebruiken (m.a.w: de gebruiker in te loggen) en te zorgen dat de gebruiker gewoon ingelogd blijft?

[ Voor 11% gewijzigd door Compizfox op 06-01-2017 14:32 ]

[Schonhose]

Compizfox schreef op vrijdag 6 januari 2017 @ 14:30:
Het overslaan van 2FA op bepaalde 'trusted devices' maakt volgens mij de 2FA inherent waardeloos. Als attacker kun je dat gewoon spoofen om de 2FA te omzeilen.

Yup, dat klopt. Daarom zit ik er ook aan te denken om het ip-adres mee te nemen. Misschien zijn er nog wel andere zaken waarmee je het nog unieker kunt maken. Dan wordt het spoofen al weer een stuk lastiger.

[Afvalzak]

Schonhose schreef op vrijdag 6 januari 2017 @ 14:40:
[...]


Yup, dat klopt. Daarom zit ik er ook aan te denken om het ip-adres mee te nemen. Misschien zijn er nog wel andere zaken waarmee je het nog unieker kunt maken. Dan wordt het spoofen al weer een stuk lastiger.

Al die gegevens die je browser meestuurt naar de website zijn met bijvoorbeeld developer tools zo te spoofen.
Het kost misschien heel veel tijd voor een hacker om de juiste waardes in te vullen, maar als je op een trusted device hebt gezeten, gegevens gekopiëerd dan ben je binnen 5 min binnen.
Zeker met IP adres, dat is ongeveer het eerste wat ik zou proberen.

https://support.google.com/accounts/answer/2544838?hl=en maar kan je hier niets mee?
Misschien zit er wel een mogelijkheid in 2FA protocol?

[Compizfox]

Schonhose schreef op vrijdag 6 januari 2017 @ 14:40:
[...]


Yup, dat klopt. Daarom zit ik er ook aan te denken om het ip-adres mee te nemen. Misschien zijn er nog wel andere zaken waarmee je het nog unieker kunt maken. Dan wordt het spoofen al weer een stuk lastiger.

Het maakt niet uit wat je allemaal meestuurt; het punt is dat het selectief toepassen van wat voor beveiliging dan ook (in dit geval 2FA) die hele beveiliging nutteloos maakt.

Het gebruik van cookies is een ander geval. Dat zwakt het systeem niet per se af, maar is alleen toe te passen als je de gebruiker hebt geauthenticeerd (wat ook precies de reden is dat deze 'oplossing' het systeem niet afzwakt). En wat is op dat moment het nut dan nog? De gebruiker is dan al ingelogd. Je kunt het systeem dan beter zo maken dat de gebruiker ingelogd blijft (voor een langere tijd).

[ Voor 4% gewijzigd door Compizfox op 06-01-2017 14:51 ]

[Schonhose]

Hmm, het is me duidelijk dat bijna alles dus te spoofen is. Dus dan is het inderdaad misschien geen optie om daar vanuit te gaan als basis.

Afvalzak schreef op vrijdag 6 januari 2017 @ 14:45:
https://support.google.com/accounts/answer/2544838?hl=en maar kan je hier niets mee?

Nee, dit is alleen voor Google Accounts.

Compizfox schreef op vrijdag 6 januari 2017 @ 14:50:
[...]

Het maakt niet uit wat je allemaal meestuurt; het punt is dat het selectief toepassen van wat voor beveiliging dan ook (in dit geval 2FA) die hele beveiliging nutteloos maakt.

Ja, daar heb je een punt.

Het gebruik van cookies is een ander geval. Dat zwakt het systeem niet per se af, maar is alleen toe te passen als je de gebruiker hebt geauthenticeerd (wat ook precies de reden is dat deze 'oplossing' het systeem niet afzwakt). En wat is op dat moment het nut dan nog? De gebruiker is dan al ingelogd. Je kunt het systeem dan beter zo maken dat de gebruiker ingelogd blijft (voor een langere tijd).

Maar wat is een langere tijd? Ik heb hem nu op enkele dagen staan, maar bij geen activiteit wordt de sessie wel gelocked.

Het ging mij erom dat het toepassen van een 2FA niet echt handig is als je de site opent op hetzelfde device als waarmee je de authenticatie moet doen. Maar blijkbaar is dat iets waarmee ik dan maar moet leven.

[jbdeiman]

Wat je technisch kan doen is een "sleutel" in de app meegeven die een volgende keer gebruikt kan worden als 2e factor. Bij inloggen ververs je die sleutel weer.

Dus als iemand inlogt bewaar je ergens informatie in de app, die je volgende keer bij inloggen meestuurt, deze code bewaar je natuurlijk ook in je laravel applicatie zelf, zodat je deze kan vergelijken.

Iemand die het apparaat zelf spoofed moet dus ook die sleutel (die na iedere keer inloggen wijzigt) dan mee spoofen in je applicatie. Deze code kan je natuurlijk in een Coockie zetten, (ik denk dat je applicatie via de browser op mobiel benaderd wordt)

Je hebt zo toch iets van trusted devices, wanneer je als gebruiker de coockies bewaard, maar op een kale device moet je dan toch met de 3e factor werken.


Overigens ben ik het niet helemaal eens met eerder gemaakte opmerkingen dat je dan net zo goed geen 2e factor kan nemen:
- Immers iemand die het device spoofed heeft wel gebruikersnaam en WW nodig van een gebruiker, wat de authenticator app ook redelijk overbodig maakt als 2e factor, wanneer hij/ zij die app zelf ook heeft.

[P_de_B]

Compizfox schreef op vrijdag 6 januari 2017 @ 14:50:
[...]

Het maakt niet uit wat je allemaal meestuurt; het punt is dat het selectief toepassen van wat voor beveiliging dan ook (in dit geval 2FA) die hele beveiliging nutteloos maakt.

Je houdt toch nog steeds 2 factoren over? Je wachtwoord dat je weet en het 'trusted device' dat je in je bezit moet hebben. Dat daar fouten in de implementatie gemaakt kunnen worden is wellicht mogelijk, maar dat het dan per definitie waardeloos is ben ik niet met je eens.

[johnkeates]

Schonhose schreef op vrijdag 6 januari 2017 @ 15:03:
Het ging mij erom dat het toepassen van een 2FA niet echt handig is als je de site opent op hetzelfde device als waarmee je de authenticatie moet doen. Maar blijkbaar is dat iets waarmee ik dan maar moet leven.

Je kan toch even app switchen naar de authenticator, op de code drukken (die doet een copy) en dan terug naar de 2FA invoer en dan paste doen?

[Der Rudi]

Als je het echt veilig wilt hebben kun je een PKI opzet kiezen, waarbij dan je device als 'smart card' fungeert. Dan heb je nog steeds one time passwords ipv een static in bv een cookie.

Vanuit security aspect is die 'smart card' als je het draait in je mobile app omgeving minder veilig. Veiliger is als je de in het device aanwezige security hardware kunt/wilt gebruiken (Trusted Execution Environment ed).

Tis niet iets wat je zo even doet, ook aan de Laravel kant overigens.

[Patriot]

Compizfox schreef op vrijdag 6 januari 2017 @ 14:50:
[...]

Het maakt niet uit wat je allemaal meestuurt; het punt is dat het selectief toepassen van wat voor beveiliging dan ook (in dit geval 2FA) die hele beveiliging nutteloos maakt.

Het gebruik van cookies is een ander geval. Dat zwakt het systeem niet per se af, maar is alleen toe te passen als je de gebruiker hebt geauthenticeerd (wat ook precies de reden is dat deze 'oplossing' het systeem niet afzwakt). En wat is op dat moment het nut dan nog? De gebruiker is dan al ingelogd. Je kunt het systeem dan beter zo maken dat de gebruiker ingelogd blijft (voor een langere tijd).

Jouw voorstel is toch in feite onveiliger dan het uitschakelen van 2FA voor bepaalde devices? Als ik een trusted device die geen 2FA meer hoeft te doen in handen krijg moet ik nog steeds de gebruikersnaam en het wachtwoord weten. Als de hele sessie niet verloopt dan ben ik er gewoon direct als ik het apparaat in handen krijg. Een sessie niet (of pas na geruime tijd) doen verlopen is gewoon het uitschakelen van 2FA én meer.

Zoals gewoonlijk is de afweging ook hier: Wat probeer je te beschermen, en hoeveel ongemak is dit waard. Als de data zeer gevoelig is dan zijn je sessies kort van levensduur en zul je altijd 2FA gebruiken. Als de gegevens niet zo belangrijk zijn, en in feite voor niemand behalve de gebruiker zelf interessant, dan kun je de sessies gerust wat langer bewaren en wat minder streng zijn op het gebruik van 2FA.

jbdeiman schreef op vrijdag 6 januari 2017 @ 15:17:
Overigens ben ik het niet helemaal eens met eerder gemaakte opmerkingen dat je dan net zo goed geen 2e factor kan nemen:
- Immers iemand die het device spoofed heeft wel gebruikersnaam en WW nodig van een gebruiker, wat de authenticator app ook redelijk overbodig maakt als 2e factor, wanneer hij/ zij die app zelf ook heeft.

Niet lullig bedoeld, maar dit klinkt alsof je de klok hebt horen luiden maar niet weet waar de klepel hangt. Het spoofen waar het in dit topic over gaat zet de standaard 2e factor inderdaad buiten spel (de sleutel waarmee het apparaat zich als trusted identificeert is in feite de 2e factor geworden), maar het al dan niet beschikken over de app waarmee de 2FA is geïmplementeerd heeft hier natuurlijk niks mee te maken. Gebruik maken van 2FA is niet veiliger omdat een eventuele kwaadwillende niet zou kunnen verzinnen dat hij de Google Authenticator app kan downloaden.

[Schonhose]

Wat betreft de Google Authenticator app, je hebt daarvoor een secret key nodig. Dit kan via gewoon tekst of door een QR-code ingeladen worden in de Authenticator App.

Op dit moment (alleen development versie) zijn deze gegevens toegangkelijk via het gebruikersprofiel. Naar aanleiding van deze discussie vraag ik me af of het handig is om deze altijd zichtbaar te hebben of alleen 1x aan de gebruiker te laten zien. Op het moment dat de gebruiker het niet meer weet zou hij dan een nieuwe code kunnen aanvragen. Dit klinkt natuurlijk heel netjes en veilig of niet?

Tenzij een aanvaller al toegang heeft tot het systeem. Dan maakt het niet uit of je het elke keer aan de gebruiker laat zien of dat je de gebruiker een nieuwe laat aanvragen. In beide gevallen ziet de aanvaller de gegevens. Enige voordeel wat ik kan bedenken is dat de oude gebruiker door heeft dat er iets mis is met zijn gegevens wanneer er een nieuwe code aangevraagd wordt.

Wat betreft de applicatie, het gaat om een app voor het beheren van een sportteam. Hierin zitten teamleden waaraan diverse zaken worden gekoppeld: statistieken, wedstrijden, trainingen etc. Persoonlijke gegevens die worden opgeslagen zijn naam en emailadres. Deze worden overigens versleuteld opgeslagen in de database (net als alle andere kenmerken). Kortom, er worden minder persoonlijke gegevens bewaard dan bij een willekeurige webshop.

P_de_B schreef op vrijdag 6 januari 2017 @ 15:19:
[...]

Je houdt toch nog steeds 2 factoren over? Je wachtwoord dat je weet en het 'trusted device' dat je in je bezit moet hebben. Dat daar fouten in de implementatie gemaakt kunnen worden is wellicht mogelijk, maar dat het dan per definitie waardeloos is ben ik niet met je eens.

Ja, dit was mijn gedachte dus ook. En eigenlijk was ik op zoek naar manieren om de implementatie hiervan zo foutloos mogelijk te maken. Laat ik realistisch zijn: zijn er mensen op zoek naar hoeveel schoten Pietje Puk heeft genomen in de uitwedstrijd tegen Amsterdam in december vorig jaar?

[We Are Borg]

Interessant onderwerp. Apps hebben toegang tot een device id maar voor jouw toepassing is dat dus helaas niet beschikbaar.

De uitdaging die ik voorzie met user agent is dat deze eenvoudig kan wijzigen door een browser update. Ip adres kan ook wijzigen (mobiel gebruik bijvoorbeeld, WiFi op verschillende locaties). Een cookie vind ik nog best het beste idee . Wel een vervelend nadeel: cookies verwijderd is weg trusted device

[ Voor 8% gewijzigd door We Are Borg op 06-01-2017 19:40 ]

[Schonhose]

Dat is dan nog een alternatief: dat ik een app ga schrijven. Het is nu een mobiele webapp en ik heb geen benul hoe ik daarvan een app kan maken die zowel draait op iOS als android. alhoewel ik begreep dat de Rabobank ook zoiets doet :x

[Cartman!]

Sessie + IP-Adres + User-Agent zou ik best als trusted kunnen zien voor een bepaalde tijd. User-Agent is te spoofen maar IP-adres spoofen is echt niet weggelegd voor een gemiddelde script-kiddie. Een eigen app maken hiervoor klinkt als complete overkill, even switchen tussen een app en een browser is toch zo gepiept?

[ Voor 3% gewijzigd door Cartman! op 06-01-2017 21:09 ]

[We Are Borg]

Maar aangezien de TS een app bouwen overweegt doe ik de aanname dat de eindgebruikers vaak wisselend ip adres hebben. Dus dan schiet ip lock niet op.

[Cartman!]

Als het vooral gericht is op mobiel gebruik heb je een goed punt ja

[DJMaze]

Een https only cookie met browser fingerprint is een optie.
Daarnaast kan je die dan ook nog als channel bound cookie beveiligen.
Dit wordt nog niet echt ondersteund, maar het is de opvolger van client certificates om verschillende redenen

[ Voor 41% gewijzigd door DJMaze op 06-01-2017 22:58 ]

[Janoz]

TS wil het inloggen op zijn mobiel makkelijker maken. Maar wel veiliger door het IP mee te nemen in de authenticatie.

Met een mobiel lijkt mij dat compleet zinloos. Die heeft natuurlijk aan een stuk door een ander IP-adres.

[BarôZZa]

Je moet het wat duidelijker voor jezelf scheiden:
- Je beveiligt je app met een device sessie en login sessie
- De device sessie kan kort(clientside verloopt na browsersessie, serverside na xx minuten) of lang zijn (verloopt na xxx dagen voor de gekoppelde devices), login sessie is altijd kort. Beide gewoon random tokens, cookies zijn prima geschikt
- Login sessie is gekoppeld aan een device sessie
- Bij een nieuwe device sessie moet je je authentificeren met de Google Authenticator app
- Aan een sessie kan je informatie koppelen die elk request moet kloppen (bijvoorbeeld browsernaam, device, browserversie niet lager dan de vorige, land van ip etc). Je weet nooit of deze gegevens gespooft zijn, maar je weet wel dat als ze niet kloppen, dat er iets mis is of een verhoogd risico(ander land). Belangrijkste is dat je hier gevolgen aan hangt (anders kan je eindeloos proberen). Bij scenario's die nooit voor mogen komen (device token met andere browser, login token dat bij een andere device token hoort) moet de sessie worden gesloten en de gebruiker worden geinformeerd. Bij een hoog risico kan je er bijvoorbeeld voor kiezen om de gebruiker te informeren en opnieuw te laten authentificeren.
- Daarnaast moeten de devices te beheren zijn en die sessies/tokens ingetrokken kunnen worden.

Er vanuit gaande dat alles via SSL verloopt zou dat veilig zat moeten zijn, zelfs zonder de extra info bij de sessie. Google Authenticator beschermt tegen password leaks en SSL zorgt ervoor dat niemand je sessie-id zou moeten kunnen inzien. Enige mogelijkheid is als iets of iemand toegang heeft tot je device, maar in dat geval helpt niks en moet je de toegang vanaf het device ontzeggen. Geavanceerde fishing methodes blijven ook vrijwel altijd mogelijk, maar dit zijn voornamelijk zaken aan de klantkant. Je kan het hackers hooguit wat moeilijker maken met extra checks.

Daarnaast kan je ervoor kiezen dat je bijvoorbeeld wel gegevens kan inzien, maar dat je voor het wijzigen moet authentificeren of andersom.


Als één klant meerdere gebruikers heeft, dan kan je er ook voor kiezen dat er een beheer/admin account is dat de devices moet goedkeuren.

Los van de beveiliging moet je ook naar de gebruikers kijken. Ik werkte in het verleden met accountants (vaak oudere digibeten) en die wilden bijvoorbeeld simpelweg altijd two factor authentificatie hebben omdat ze dat veiliger vonden. Ze gebruikten bovendien de app niet enorm vaak, waardoor de extra stap niet als storend werd ervaren. Uitkijken dat je deze feature niet bedenkt doordat je het als developer tijdens het ontwikkelen/testen als storend ervaart en de gebruikers een onveilig gevoel geeft. Voor sommige gebruikers voelt het veiliger als ze een smsje krijgen omdat ze dat kennen van DigiD en internetbankieren aka belangrijke zaken.