Security: TFA vs IP-whitelisten

[Rekcor]

De situatie:

• Om in te loggen in onze webapplicaties hebben admins TFA (Google Authenticator)
• Men klaagt over het gebruikersgemak hiervan

Mijn vraag: wat is de security impact als we TFA zouden vervangen door IP-whitelisting?

• Uiteraard gaat de webapplicatie via https
• Het IP-adres van ons kantoor zou op de witte lijst komen
• Thuiswerkers zouden via OpenVPN verbinding moeten maken met ons kantoornetwerk

Mijn eigen overwegingen: die OpenVPN-verbinding is in feite je T in TFA. Echter, hoe gemakkelijk is het voor een hacker om het IP-adres van ons netwerk te achterhalen en vervolgens e.e.a. zo te hacken dat hij toch kan inloggen? Ik kan me voorstellen dat het de Mossad/CIA uiteindelijk wel zou lukken, maar de kans dat die geinteresseerd zijn in onze inlog, acht ik gering.

Relevante software en hardware die ik gebruik
* Drupal

Wat ik al gevonden of geprobeerd heb
* Gesproken met techneut
* Wikipedia: Internet protocol spoofing

P.S. Liever niet mopperen op "Men klaagt over het gebruikersgemak [van TFA]", het gaat me puur even om de security.

[ Voor 5% gewijzigd door Rekcor op 03-07-2020 08:52 . Reden: P.S. toegevoegd ]

[Hydra]

Waarom zorg je niet gewoon dat de TFA een bepaalde tijd geldig blijft voor dat device? Dat is hoe het met de meeste systemen werkt; dat je per device max eens per week of maand die tweede factor door moet.

[kwaakvaak_v2]

Wij gebruiken voor een aantal van onze Drupal klanten een combinatie van beiden. Ip whitelisting voor mensen die op een voorspelbaar vast IP zitten kunnen met een naam/wachtwoord combo inloggen. Mensen buiten die zone moeten verplicht via 2FA inloggen. In dit geval hebben wij het voordeel dat dit op de authenticatie laag is geregeld via een Azure openID inlog.

Maar het is niet heel ingewikkeld om dit gedrag in met een paar form_alter hooks na te maken zonder Azure er tussen zit.

[Rekcor]

Ip whitelisting voor mensen die op een voorspelbaar vast IP zitten kunnen met een naam/wachtwoord combo inloggen.

Maar mijn vraag is dus: hoe veilig is dat?

[PureLOOD]

Waar je misgaat is de aanname dat 'hackers' alleen van buitenaf komen. Cijfers op dit vlak lopen nogal uiteen, maar iets waar je zeker rekening mee moet houden. Dan is IP-whitelisting als 2e factor nogal beperkt. '

Eigenlijk wil je voor je admin en andere high privilege accounts gewoon mfa hebben. Zoals Hydra aangeeft zou je wel een bepaalde geldigheidsduur mee kunnen geven.

[418O2]

Tsja, lastig punt. Veiligheid kost wat meer moeite. Is een eventuele magic-link via de mail geen optie?

[kwaakvaak_v2]

Rekcor schreef op vrijdag 3 juli 2020 @ 09:26:
[...]


Maar mijn vraag is dus: hoe veilig is dat?

Veilig is altijd een relatief begrip. Hoe veilig moet het zijn, is iets wat je af moet zetten tegen de aard van je applicatie.

Moet het CMS van een brochure site hetzelfde niveau van beveiliging hebben als je de site waar je bankzaken regelt?

Meer beveiliging komt altijd met een prijs van 'ongemak', op het moment dat je daarop gaat besparen, verzwak je automatisch je beveiliging.

[xh3adshotx]

Rekcor schreef op vrijdag 3 juli 2020 @ 09:26:
[...]


Maar mijn vraag is dus: hoe veilig is dat?

IP whitelisting is leuk voor een blog waar iemand zijn reisfoto's plaatst. Voor een website waar meer persoonsgegevens rond gaan zoals een webshop of iets dergelijks is het twijfelachtig. Met IP whitelisting geef je potentieel een heel kantoorpand. Dit betekend dat mensen die géén toegang nodig hebben ook (potentieel) toegang krijgen terwijl 2-factor door middel van OTP / vingerafdruk etc. veel gerichter zijn. Daarnaast kan, afhankelijk van andere beveiligingen, iedereen potentieel het pand binnen lopen en achter een computer gaan zitten. Op dat moment heb je alleen nog een username/password nodig en kan je inloggen. Of als een laptop gestolen wordt even buiten op de parkeerplaats verbinding met het wi-fi netwerk maken.

Het hangt compleet af van de data waar je mee werkt en de mate van beveiliging die nodig is maar op zich is ip-whitelisting bijna nooit de (beste) keuze.

[emnich]

Laatst nog een artikel op de FP reviews: Wat kun je met deze fysieke beveiligingssleutels?

Kijk of je dat kan implementeren. Zoals anderen ook al zeggen, veiligheid gaat altijd gepaard met ongemak dus het is altijd een afweging die je moet maken. Hoe veilig het moet zijn, hangt vooral af van wat de impact is als er toch iemand bij komt die er eigenlijk niet bij mag.

[kamerplant]

Met twee factor:
* Heb je kennis (het wachtwoord) nodig, en een fysiek apparaat (de betreffende telefoon).

Met IP whitelisting:
* Heb je kennis (het wachtwoord van Drupal) nodig, en nog meer kennis (wachtwoord van VPN). Er is dus geen tweede factor.

Op het moment dat iemand een password manager gebruikt en verliest hiervan de toegang, of iemand gebruikt identieke wachtwoorden, dan biedt de IP whitelisting lagere bescherming.

TFA wordt meer-en-meer de standaard, dit is onomkeerbaar. Als mensen er nu nog niet aan zijn gewend, dan komt dit de komende jaren wel via andere apps. Een keer moet iedereen door "de zure appel" heen (om erachter te komen dat het wel meevalt ).

[Kalentum]

Ik ben zelf niet zo'n fan van IP whitelisten. Voordat je het weet staat de Harry van sales op een beurs en moet 'ie snel even toegang voor een demo en blijkt zijn vpn niet goed te werken en dan hup, een 'tijdelijk' extra ip in de whitelist. Je krijgt er hoe dan ook een operationeel taakje bij om die whitelist te onderhouden

Het mooie van jullie huidige oplossing is dat het altijd werkt, overal, en behoorlijk veilig is. Ja, het is een extra drempel, maar je kan ervoor zorgen dat die 2FA niet elke keer nodig is maar alleen bij een nieuwe onbekende browser ofzo.

[kwaakvaak_v2]

Waarom doet iedereen hierboven of het altijd OF moet zijn? Je kunt toch prima een EN combinatie van 2 dingen maken?

IP Whitelist EN normale user/password, het één sluit het ander toch nooit uit?

[emnich]

@kwaakvaak_v2 Ik mag hopen dat de whitelist allowlist de TFA vervangt en NIET het wachtwoord....

[ Voor 11% gewijzigd door emnich op 03-07-2020 09:59 ]

[kwaakvaak_v2]

emnich schreef op vrijdag 3 juli 2020 @ 09:58:
@kwaakvaak_v2 Ik mag hopen dat de whitelist allowlist de TFA vervangt en NIET het wachtwoord....

Dat zeg ik toch ook.. Je kunt een allowlist maken en als iemand aan die voorwaarden voldoet hoeft die persoon enkel maar een user/wachtwoord combo te gebruiken.
Sta je daar niet op, heb je gewoon pech en moet je verplicht de 2FA loop door.

(wat ik ook als in mijn edit zei, maar voor het gemak en de flow maar even hieronder paste)

Kalentum schreef op vrijdag 3 juli 2020 @ 09:53:
Ik ben zelf niet zo'n fan van IP whitelisten. Voordat je het weet staat de Harry van sales op een beurs en moet 'ie snel even toegang voor een demo en blijkt zijn vpn niet goed te werken en dan hup, een 'tijdelijk' extra ip in de whitelist. Je krijgt er hoe dan ook een operationeel taakje bij om die whitelist te onderhouden

Dan heeft Harry op de beurs mooi pech en kan ie netjes via username/password EN Authenticator code inloggen.

Ik weet dat het in de aard van ons developers ligt om dingen zo zwart/wit en soms nodeloos complex als mogelijk te maken, maar dat hoeft het niet altijd te zijn. Er is altijd een balans te vinden. Soms moet je alleen even buiten de gepreekte paden te denken en de afweging zelf durven te maken over WAT je nu precies aan het beveiligen bent.

[Rekcor]

Bedankt zover! Begin een beeld te krijgen.

Maar hoe kan een indringer IP-whitelisting omzeilen? Wat zijn de 'attack vectors' (ja heb ook wat gelezen ;-)).

- Inloggen op bedrijfsnetwerk Wifi (nodig: wachtwoord Wifi + in de buurt zijn van hotspot)
- IP-spoofing (is dat realistisch als alles via https verloopt?)
- Inloggen op VPN (nodig: username / wachtwoord VPN)
- ...

[xh3adshotx]

Rekcor schreef op vrijdag 3 juli 2020 @ 15:17:
Bedankt zover! Begin een beeld te krijgen.

Maar hoe kan een indringer IP-whitelisting omzeilen? Wat zijn de 'attack vectors' (ja heb ook wat gelezen ;-)).

- Inloggen op bedrijfsnetwerk Wifi (nodig: wachtwoord Wifi + in de buurt zijn van hotspot)
- IP-spoofing (is dat realistisch als alles via https verloopt?)
- Inloggen op VPN (nodig: username / wachtwoord VPN)
- ...

- inloggen op bedrijfsnetwerk kan op meerdere manieren. Zo kan dat via wifi waarbij je theoretisch gezien het wachtwoord nodig hebt en in de buurt moet zijn van een hotspot. Daarnaast is het mogelijk om bijvoorbeeld een laptop te stelen/vinden (iemand van buitendienst die hem "kwijt" raakt). Dan heb je het "lastigste" obstakel al weggenomen en hoef je alleen nog maar in de buurt van een hotspot te zijn. Daarnaast weet ik niet hoe de rest van het IT beleid is maar bij een groter kantoor kan je soms ook naar binnen lopen en vervolgens gewoon een LAN kabel aansluiten .
- IP-spoofing is niet geheel realistisch en relatief complex maar is wel een mogelijkheid. HTTPs gaat daar weinig aan veranderen want daarmee bewijst een server dat hij inderdaad bij het domein hoort.
- Inloggen op VPN is inderdaad een mogelijkheid om op het bedrijfsnetwerk te komen

Je vergeet alleen de "aanvallen" van binnenuit. Truus die op haar laptop/telefoon een virus heeft en verbinding maakt met het bedrijfsnetwerk. Piet die geen toegang hoort te hebben tot de pagina maar via username/wachtwoord van Klaas die hij ooit gezien heeft op zijn laatste werkdag even alles sloopt. Een virus op een van de PCs binnen het bedrijf die als relay/automatisch werkt etc.

[Freeaqingme]

Het grootste nadeel van ip-whitelisting is het scenario dat je 'ineens' een ander IP-adres hebt. Dan kan je ineens nergens meer bij.

Verder gebruik ik sinds een tijdje U2F, en dat vind ik als TFA nog wel wat gebruiksvriendelijker dan zo'n app. Hoef nu alleen maar op een knopje te drukken, en ik ben ingelogd. In plaats van dat ik m'n telefoon moet ontgrendelen, de app moet openen, en een code overtypen.

[kwaakvaak_v2]

Rekcor schreef op vrijdag 3 juli 2020 @ 15:17:
Bedankt zover! Begin een beeld te krijgen.

Maar hoe kan een indringer IP-whitelisting omzeilen? Wat zijn de 'attack vectors' (ja heb ook wat gelezen ;-)).

- Inloggen op bedrijfsnetwerk Wifi (nodig: wachtwoord Wifi + in de buurt zijn van hotspot)
- IP-spoofing (is dat realistisch als alles via https verloopt?)
- Inloggen op VPN (nodig: username / wachtwoord VPN)
- ...

staar je er niet blind op, elke beveiliging is in theorie te breken of te omzeilen. Het is net de vraag of het voor de aanvallers de prijs waard is.

[Anoniem: 316512]

Ik denk dat een whitelist op zich redelijk veilig kan zijn. Maar dan moet je het wel goed aanpakken.

- Weet je zeker dat alle adressen die je gaat toestaan legitiem zijn?
- Doe je periodiek controles op de whitelist?
- Documenteer je goed welk ipadres waarvoor dient / wie heeft de aanvraag gedaan / wie is de provider etc.?
- Hoe ga je om met mensen die vanaf huis inloggen vanaf een dynamisch adres (wat vrij gewoonlijk is bij een consumenten lijn)

Met goed ingestelde 2FA kun je een apparaat bijvoorbeeld 30 dagen onthouden en dit een stuk lastiger te omzijlen (mits je niet een 2FA programma op je PC hebt draaien en de PC wordt gehacked). Ik begrijp dat je die discussie nu niet aan wil, maar vraag mij wel af of je van alle mogelijkheden op de hoogte bent en de voordelen.

[Spiral]

Als een laag van beveiliging zou je ook mutual TLS kunnen gaan toevoegen. Dat betekend op de clients een certificaat installeren, die door de web applicatie wordt geverifieerd. Zie bv. https://docs.microsoft.co...configure-tls-mutual-auth

[Rekcor]

Freeaqingme schreef op vrijdag 3 juli 2020 @ 16:35:
Het grootste nadeel van ip-whitelisting is het scenario dat je 'ineens' een ander IP-adres hebt. Dan kan je ineens nergens meer bij.

Bij ons zou er maar 2 IP-adressen op de lijst staan: dat van ons bedrijfsnetwerk en dat van een backup-netwerk (voor als het bedrijfsnetwerk omvalt). Medewerkers loggen hier vanaf thuis op in via VPN.

Voorlopig hebben we overigens een andere oplossing bedacht: waarom hebben we eigenlijk admin-toegang nodig? Blijkt dat het heel vaak helemaal niet nodig is (maar ja, men wil nu eenmaal graag alle opties hebben). We gaan nu dus veel vaker inloggen met 'lichtere' accounts, waarvoor we geen TFA nodig hebben.

Spiral schreef op zondag 5 juli 2020 @ 15:09:
Als een laag van beveiliging zou je ook mutual TLS kunnen gaan toevoegen. Dat betekend op de clients een certificaat installeren, die door de web applicatie wordt geverifieerd. Zie bv. https://docs.microsoft.co...configure-tls-mutual-auth

Interessant! Er is ook een Drupal-module voor https://www.drupal.org/project/certificatelogin. Vraag me dan wel altijd af hoe veilig die code is.

[Trommelrem]

IP whitelisting is onveilig. Je maakt er een security gat mee.

Waarom werk je niet gewoon met compliancy? Je kunt in Conditional Access meerdere voorwaarden stellen voor toegang in een OF/EN variant: MFA, Compliancy, Hybrid.

Als er echt iemand van hogerhand vraagt om de beveiliging te beperken, doe dat dan met Compliancy en Hybrid regels in je Conditional Access policies. Eventueel ga je ook toegang controleren op basis van Sign-in Risk (vereist P2). Maak het niet moeilijk door IP adressen te whitelisten want daarmee wordt het voor de users wel "makkelijker" (ook weer niet), maar voor jou en voor de security officer niet.

Bovendien heb ik gemerkt dat IP whitelisting voor users toch niet zo gemakkelijk is in de praktijk. Ja, op kantoor heb je een onveilige IP whitelist, en daar komt bij dat als de user verhuist naar buiten dat er plotseling wel een MFA challenge moet worden gedaan. Het blijven immers users, die kun je niet laten wennen aan twee verschillende situaties.

Als er toch nog een manager bovenaan de keten is die eist dat diegene geen MFA heeft, dan kun je eventueel CAS toepassen via een Conditional Access policy. Zorg wel voor een akkoord van de security officer, want een CAS is geen algehele blokkade.

Rekcor schreef op maandag 6 juli 2020 @ 09:07:
Voorlopig hebben we overigens een andere oplossing bedacht: waarom hebben we eigenlijk admin-toegang nodig? Blijkt dat het heel vaak helemaal niet nodig is (maar ja, men wil nu eenmaal graag alle opties hebben). We gaan nu dus veel vaker inloggen met 'lichtere' accounts, waarvoor we geen TFA nodig hebben.

Waarom is de userdata van het bedrijf minder belangrijk dan de admindata? Het is eerder andersom. De userdata is datgene waar het bedrijf door functioneert, de admindata faciliteert het bedrijf slechts.

[ Voor 76% gewijzigd door Trommelrem op 06-07-2020 09:27 ]