Vraagt mbt two-factor verification MS/Google

[FireFly]

Dit weekend heb ik getracht om de beveiliging van mijn Google en MS accounts door de 2-step verification/authentication in te schakelen.

Zoals al gekend is, zijn er apps/applicaties die dit niet ondersteunen, Beide leveranciers bieden dan "app specific password" (ASP) om deze applicaties toch te doen werken. Dit is in de vorm van string van X karakters (zelfs helemaal geen sterk paswoord zeg maar).

Toevallig heb ik een test gedaan met mijn MS account. Via een ASP heb ik mijn GMAIL app op Android geconfigureerd (Gmail 2-step pikt dit zonder problemen op, voor outlook.com echt niet).
Diezelfde code heb ik bij wijze van test ook gebruikt op mijn ipad-mail, daar werkt die ook.

Mijn vraag is nu, hoe veilig is dit? Vallen mijn accounts nu te hacken met dit (zwak) paswoord of zit er toch iets meer achter?

De outlook client die ik gebruik (versie 2016, tech preview) ondersteund ook geen two-factor terwijl Exchnge 2016 dit wel zou ondersteunen. Iemand hier ervaring mee om dit toch zonder ASP te doen werken?

[darkrain]

Die code moet je zien als wachtwoord, dus net zo goed als een wachtwoord te raden is is deze code dat ook. Hoe groot die kans is, dat is de vraag...

Verder is het slim om per applicatie een andere code te laten genereren. Op die manier kun je bij twijfel een code gewoon terugtrekken en kan er geen toegang meer verkregen worden.

[FireFly]

Per applicatie een nieuwe code maar zo maak je meer zwakke sleutels voor je huis. Lijkt me dan beter om het hele 2-step niet te activeren tot al je apps het out-of-the-box ondersteunen.
Het is letterlijk een zwakke key van X standaard no-caps karakters...

[P_de_B]

Waarom wachten? Voor de apps die het wél ondersteunen heb je 2factor. Ook voor de belangrijke zaken als het beheren van je account. Voor de apps die het nu nog niet ondersteunen heb je een sterk en voor die app uniek wachtwoord? Ik zie niet in hoe dat de totale veiligheid naar beneden brengt.

[darkrain]

FireFly schreef op maandag 17 augustus 2015 @ 10:20:
Per applicatie een nieuwe code maar zo maak je meer zwakke sleutels voor je huis. Lijkt me dan beter om het hele 2-step niet te activeren tot al je apps het out-of-the-box ondersteunen.
Het is letterlijk een zwakke key van X standaard no-caps karakters...

Dat ben ik niet met je eens. Als je 2 factor authenticatie helemaal niet gebruikt kun je op de website van Google of MS zo je hele account in als je het wachtwoord hebt weten te krijgen. Dat lukt met het app-wachtwoord niet!

[begintmeta]

De entropie van zo'n applicatiespecifiek wachtwoord bij Google is als ik me niet vergis 82,7 bits, niet heel goed maar ook niet heel slecht.

Een belangrijk punt bij het geheel is dat de gevoeligheid voor bepaalde aanvallen verandert door 2-factoren te gebruiken (eventueel met daarbij 'applicatiespecifieke wachtwoorden'):

Applicatiespecifieke wachtwoorden hoef je in principe nooit in ongecontroleerde ongevingen te gebruiken, bijvoorbeeld een keylogger of bewakingscamera of observator zal dat wachtwoord dan niet te pakken krijgen. Als je enkel overal je 'vaste' wachtwoord gebruikt in dat geval kan dat wel het geval zijn. Door een totp als tweede factor toe te voegen, krijg je voor dergelijke situaties weer iets wat het gevaar op onderscheppen van de toegangscode verkleint.

Dus of het zinvol is om 2FA in te schakelen ondanks dat je dan eventueel nog een zwakker wachtwoord introduceert ligt aan het gebruik dat je maakt van het wachtwoord, als je het alleen in gecontroleerde omgevingen gebruikt zal het niet-gebruiken van 2FA beter zijn, aangezien het de kans op bruteforcen van het wachtwoord verkleint. Als het echter mogelijk is dat je wachtwoord op een andere manier wordt onderschept omdat je het wel eens in minder gecontroleerde omgevingen gebruikt, kan 2FA toevoegen misschien toch verstandiger zijn.

De aanbieders zouden er natuurlijk goed aan doen 'applicatiespecifieke wachtwoorden' ook echt applicatiespecifiek te maken (en de entropie per applicatie te maximaliseren), al heeft men zoals ook hierboven en -onder is gepost al wel beperkingen op zijn plaats.

[ Voor 40% gewijzigd door begintmeta op 17-08-2015 10:58 ]

[FireFly]

Darkrain: het kon in elk geval wel: http://www.pcworld.com/ar...tion-researchers-say.html
Het artikel is van 2 jaar terug, potentieel is hier iets in het gedrag aangepast.

Zoals door jullie en Google/MS aanbevolen, zal ik bij elke app wel een anders ASP gebruiken. Mocht ik ooit misbruik vaststellen (hopelijk kan ik dat via activity report oid wel achterhalen), dan kan ik die sleutel nog uitschakelen. Bij MS is dit wat lastiger daar je niet per app/sleutel kan kiezen (alles of niets situatie).

Nu ja, in the end, hoop ik dat de apps/applicaties het gewoon ondersteunen. Ik heb veel minder problemen met het instellen van een trusted device dan zo een ASP wachtwoordje

Bedankt voor jullie inzicht.

[begintmeta]

FireFly schreef op maandag 17 augustus 2015 @ 10:44:
... Ik heb veel minder problemen met het instellen van een trusted device dan zo een ASP wachtwoordje ...

Wat is de entropie van zo'n 'trusted device cookie' eigenlijk?

[darkrain]

FireFly schreef op maandag 17 augustus 2015 @ 10:44:
Darkrain: het kon in elk geval wel: http://www.pcworld.com/ar...tion-researchers-say.html
Het artikel is van 2 jaar terug, potentieel is hier iets in het gedrag aangepast.

Zoals door jullie en Google/MS aanbevolen, zal ik bij elke app wel een anders ASP gebruiken. Mocht ik ooit misbruik vaststellen (hopelijk kan ik dat via activity report oid wel achterhalen), dan kan ik die sleutel nog uitschakelen. Bij MS is dit wat lastiger daar je niet per app/sleutel kan kiezen (alles of niets situatie).

Nu ja, in the end, hoop ik dat de apps/applicaties het gewoon ondersteunen. Ik heb veel minder problemen met het instellen van een trusted device dan zo een ASP wachtwoordje

Bedankt voor jullie inzicht.

Ik heb net nog even een testje gedaan en geprobeerd met een app-wachtwoord op mijn Google account in te loggen, dat gaat niet zoals ik ook zou verwachten. Hoe het bij MS zit heb ik niet getest.

[Bastiaan]

Als je een applicatiespecifiek wachtwoord bij Google maakt en gebruikt, kun je deze niet nogmaals voor een andere applicatie of inlogpoging gebruiken. Er zit dus wel degelijk een check achter of dat wachtwoord al in gebruik is. Dat is ook de reden dat als je diezelfde applicatie opnieuw wilt configureren, je ook een nieuw applicatiespecifiek wachtwoord moet maken (en om diezelfde reden kun je niets anders dan voor iedere applicatie een eigen wachtwoord maken).