Okta erkent dat klanten zijn getroffen door aanval van Lapsus$

Okta heeft een nieuwe verklaring doen uitgaan over de aanval van Lapsus$ op de systemen van het bedrijf. Volgens Okta is 2,5 procent van zijn klanten getroffen door de aanval van de hackergroep. Okta is een authenticatieplatform voor bedrijven als Apple en Amazon.

In de verklaring geeft Okta toe dat er van sommige klanten data kan zijn uitgelekt na de aanval van hackergroep Lapsus$. Eerder gaf het bedrijf aan dat er geen klanten waren getroffen. Het zou gaan om een hackpoging uit januari, waarbij hackers maar beperkt toegang hadden gekregen tot de systemen van het bedrijf. De impact blijkt nu groter te zijn. Het hoofd beveiliging bij Okta, David Bradbury, biedt in de verklaring zijn excuses aan.

Volgens het bedrijf hoeven klanten op dit moment geen actie te ondernemen. Okta neemt contact op met de klanten waarvan misschien data is uitgelekt of ingezien. Het zou gaan om 2,5 procent van de circa 15.000 klanten die Okta bedient. De schade kan groot zijn als de hackers ook toegang kunnen krijgen tot systemen van de klanten van Okta via het singlesign-onplatform van het bedrijf.

Hackergroep Lapsus$ zit achter de aanval op Okta en heeft screenshots online gezet als bewijs van de hack. Okta is naar aanleiding van de claim van de hackers een onderzoek begonnen. Lapsus$ schrijft dat het via Okta toegang wilde krijgen tot klanten van het bedrijf. De groep heeft vooralsnog geen eisen gesteld aan Okta, wat ze eerder wel deed bij andere aanvallen.

Lapsus$ wist eerder al binnen te dringen bij Nvidia en Samsung. Deze week werd ook bekend dat Microsoft is getroffen door een aanval van de groep. De techgigant heeft inmiddels bevestigd dat Lapsus$ toegang had tot broncode van Bing en Cortana.

Reacties (51)

Volgens het bedrijf hoeven klanten op dit moment geen actie te ondernemen. Okta neemt contact op met de klanten waarvan misschien data is uitgelekt of ingezien. Het zou gaan om 2,5 procent van de circa 15.000 klanten die Okta bedient. De schade kan groot zijn als de hackers ook toegang kunnen krijgen tot
systemen van de klanten van Okta via het singlesign-onplatform van het bedrijf.

Het zou fijn zijn als ze wat meer duidelijkheid geven over wat voor soort data er wel en, vooral, niet is gelekt. Om precies te zijn zou het fijn zijn als ze aangeven dat er geen wachtwoorden gelekt zijn (al dan niet gehashed). Ik weet eerlijk gezegd niet of ze die uberhaupt wel hebben. Ik hoop eigenlijk dat ze geen wachtwoorden van klanten hebben en dat die allemaal in bronsystemen staan die de klanten zelf beheren. Maar ik weet niet genoeg van wat ze doen, misschien hebben ze die wachtwoorden ook wel.

editIn de bron is ze daar duidelijker over. Okta heeft wel wachtwoorden maar de gestolen account had niet het recht om die in te zien. Wel heeft die account het recht om wachtwoorden en andere authenticatie-factoren te resetten. Of het dan ook mogelijk was om een nieuw wachtwoord in te stellen is mij niet duidelijk, maar ik vermoed van wel, ergens zal die mogelijkheid moeten bestaan.

[Reactie gewijzigd door CAPSLOCK2000 op 23 maart 2022 11:25]

Ik kan je vertellen, als je geïdentificeerd bent als een klant wiens data potentieel gebreached was dan had je daar gisteravond een mail over gehad. Daar staat ook in om wat voor data het ging. Ze maken het niet zomaar openbaar in ieder geval.

Volgens de bron:

Support engineers are also able to facilitate the resetting of passwords and multi-factor authentication factors for users, but are unable to obtain those passwords.

Support engineers kunnen dus een reset uitvoeren, waarbij de gebruiker een link via email krijgt toegezonden. Het lijkt erop dat ze dus niet direct een wachtwoord kunnen instellen.

Ik heb een Okta account, daar kan ik users aanmaken, OTP aan of uitzetten, wachtwoorden resetten door zelf een wachtwoord in te stellen of eindgebruiker wachtwoord laten instellen (mail link). En kan API tokens/keys maken.

Maar ik neem aan dat jij geen Okta support engineer bent, maar beheerder rechten hebt over je eigen Okta account. Die twee lijken dus niet equivalent te zijn.

Hij heeft 't over users; dus hij bedoelt niet zijn eigen account.

Account als in tenant

Sorry, ik weet niet wat tenant is. Is daar ook een Nederlands woord voor?

Voor de digibeten: 'tenant' refereert aan een instantie van een IT dienst, meestal in de context van een dienst aangeboden op infrastructuur en een besturingssysteeem en applicatie-laag gedeeld met andere klanten van die dienst (maar waarbij iedere klant alleen toegang heeft tot zijn eigen data).

En 'users' wat je in je eerdere reactie gebruikt refereert hier aan gebruikers in die instantie van de dienst.

Maar gezien je beroep in je profiel weet je dit al lang dus het voegt allemaal bijzonder weinig toe.

[Reactie gewijzigd door De Vliegmieren op 25 maart 2022 12:31]

Maar gezien je beroep in je profiel weet je dit al lang dus het voegt allemaal bijzonder weinig toe.

Ik doe niks met tenants.
En is er dan geen goed nederlands woord voor?

Nee

maar ze konden ook mailadressen en MFA telefoons resetten ?

Dat van die wachtwoorden betwijfel ik een beetje. Ik heb zelf de screenshots van Lapsus$ bekeken en daar zitten inderdaad tenants tussen waar ze inderdaad ook rechten hadden om dingen te resetten. Maar ik heb ook de shortcuts zien staan naar de "superuser" backends van diverse cellen en het lijkt me dat de tenants die in die cellen gezeten hebben wat meer "de sjaak" waren.

Overigens zijn de screenshots waar over gesproken wordt gewoon op Twitter te vinden:
https://twitter.com/BillDemirkapi/status/1506107157124722690

Gaat lekker zo... benieuwd of ze allemaal een zelfde exploit probleem hadden. Kan bijna niet, maar dit is wel verontrustend dat zo'n grote tech bedrijven slachtoffer worden.

Niemand is veilig als ze echt willen!

De exploit is eigenlijk heel simpel: gefrustreerde medewerkers een som geld beloven voor het opgeven van hun logingegevens. Bij Okta ging het via een medewerker van een externe helpdeskpartij, Sitel.

Dat zou bij de meeste personeelsleden nog steeds maar een beperkte impact moeten hebben als je alles op orde hebt, maar in de praktijk hebben zelfs securitybedrijven hun zaakjes zo goed op orde als dat ze zeggen.

Misschien mis ik iets, maar eigenlijk zou dat toch simpel opgelost kunnen worden?
Voor zulke cruciale functionaliteit als wachtwoord resets vanuit eigen medewerkers (zoals in de edit van @CAPSLOCK2000 aangegeven was dat de oorzaak), zou je toch een soort vier-ogen principe kunnen gebruiken?
Bij sommige andere beroepsgroepen is dat een verplichting.

[Reactie gewijzigd door TweakerTom op 23 maart 2022 11:31]

Ja, maar dan zou je niet zomaar meer je klantenservice aan een heel goedkope derde partij kunnen uitbesteden

Dat is vaak het grote euvel bij zulke multinationals; aan de voorkant dik doen & aan de achterkant behelpen ze zich met een servicedesk in India, of een Oostblok-staatje...
In dit geval gaat het dan om een wat duurdere sub-contractor https://en.wikipedia.org/wiki/Sitel, die nu waarschijnlijk niet meer voor Okta zal werken...

[Reactie gewijzigd door MazDaMan1970 op 23 maart 2022 13:40]

In dit geval zijn ze binnen gekomen via een tijdelijke medewerker die waarschijnlijk zijn/haar account verkocht heeft.

Dus eigenlijk, om antwoord te geven op de vraag van @Nees, hebben inderdaad alle bedrijven deze exploit

Uiteindelijk blijven mensen mensen, en kun je je IT zo inrichten dat je uiteindelijk 10 mensen nodig hebt om in te loggen, je fysiek op locatie moet zijn en je bloed af moet geven iedere 2 maanden om je password te resetten, het blijven nog steeds mensen die een zwakke schakel zijn.

Gelukkig is daar steeds meer aandacht op, maar persoonlijk vind ik dat dit deel van IT security echt wel achterblijft. En dat terwijl het eigenlijk nog veel relevanter is geworden nu iedereen thuis zit met een laptop vol met bedrijfsgeheimen en in sommige gevallen steeds minder met een bedrijf verbonden zijn. Dan worden de risico's van omkoping of gewoon social engineering opeens een stuk groter, maar ook meteen heel onzichtbaar.

Maar dat los je weer op met bijvoorbeeld hardware tokens. Google is al enkele jaren overgestapt en sindsdien, volgens hen, geen enkele succesvolle poging meer om met gestolen gegeven in hun systemen in te breken.

Een nachtmerrie voor hen die regelmatig hun sleutels en dergelijke misplaatsen, geen snelle oplossing als je off-site bent en een nieuw token nodig hebt, maar wel weer moeilijker voor hackers om binnen te geraken. Werpt ook een drempel op om bijv. je credentials te verkopen.

[Reactie gewijzigd door Blokker_1999 op 23 maart 2022 12:32]

Hardware tokens helpen niet tegen het misbruik via RDP van een ingelogde user. Wat hier het probleem was: https://www.okta.com/blog...-january-2022-compromise/

So while the attacker never gained access to the Okta service via account takeover, a machine that was logged into Okta was compromised and they were able to obtain screenshots and control the machine through the RDP session.

en was deze medewerker nog in dienst ? of was het nog niet afgesloten ?

Dat geldt overigens niet alleen voor online toegang. Kijk naar bijvoorbeeld naar TheLockPickingLawyer op Youtube en je ziet hoe je met een beetje oefen de meeste sloten makkelijk open maakt. En met veel oefenen en ervaring bijna alle sloten zoals hij doet.

Toch ook probleem van de cloud hoor, on-prem was dit niet zo snel gebeurd.

Want onpremise kan je geen corrupte helpdesk medewerker hebben?

Met on prem heb je niet 1 account waarmee je bij 375 bedrijven binnen kan komen.

Nee maar dat is ook gewoon slecht van Okta, dat het bij Okta zo is betekent niet dat het bij elke cloud provider zo is.

Geen enkele Okta medewerker zou zelfstandig toegang moeten hebben tot klanten tenzij goedgekeurd door de klant, of via de klant zelf via een remote sessie.

Nee daar denk ik toch wel anders over als je support desk hebt uit besteed naar een partij die meerdere klanten heeft. En daar zitten hele grote partijen bij die dit doen.

Natuurlijk wel, maar de schaal is anders.

Bovendien is de cloud gewoon een gewild doelwit, daarmee wordt de kans dat je slachtoffer wordt ook groter.

Als mijn collega’s benaderd worden om tegen betaling wachtwoorden af te staan is de kans groot dat ze er niet op in gaan en ik dat van ze te horen krijg en maatregelen kan nemen.

Bovendien is de cloud voor mij niet transparant wie er allemaal theoretisch bij mijn data kan (of die zou kunnen wissen). Op mijn eigen systemen weet ik dat beter (ook niet waterdicht geef ik toe)

[Reactie gewijzigd door hjtuinenburg op 23 maart 2022 11:35]

On-prem kan het net zo snel gebeuren.. Credentials van een medewerker verkrijgen en via bijvoorbeeld een VPN of Citrix en je bent ook binnen..

Ontopic: ons zusterbedrijf in Amerika maakt ook gebruik van OKTA. Gisteren alles stil gezet en door Secureworks nagekeken. Niks kunnen ontdekken qua logging of wat dan ook. Las wel in een mailtje dat hun security team de komende week een 24/7 dienst gaat draaien..

[Reactie gewijzigd door nextware op 23 maart 2022 11:39]

Ik ben meerdere keren in mijn leven tegen technische of functionele beheerders aangelopen die hun on prem spul saboteerden omdat ze ongelukkig waren.

Jammer dat Okta niet echt open communiceert, geeft mij niet zoveel vertrouwen & dat terwijl hun moeten leven van het vertrouwen die klanten in hun hebben! Ken bedrijven die hun hele authenticatie uit handen geven aan Okta...

het heeft er anders voorlopig alle schijn van dat ze alleen naar de buitenwereld toe op zo'n manier communiceren. Over communicatie naar klanten is niks vermeld anders dan dat klanten binnenkort een rapport ontvangen. Zie hiervoor mijn reactie hierboven.

Dit is well erg serieus. Honderden klanten die misschien een data lek hebben nu. Een flinke dreun voor Okta.

Het zou gaan om 2,5 procent van de circa 15.000 klanten die Okta bedient.

Een mooie manier om het te downplayen. Ze kiezen de meest gunstige statistiek om de impact zo laag mogelijk weer te geven zonder onjuistheden te vertellen. De klanten van Okta zijn de bedrijven. Achter die bedrijven zitten ook nog de consumenten die dáár weer klant van zijn. Als die 2,5% van de bedrijven toevallig ook de grootste klanten zijn van Okta zou een veel groter deel van de door hun verwerkte consumenten geraakt kunnen zijn.

Gelet op de sector waarin Okta opereert zou je mogen verwachten dat er juist meer transparantie gegeven wordt. Nu leest het als 'weer zo'n verhaal' van eerst zeggen dat er weinig/niks aan de hand is, vervolgens is er toch wel iets aan de hand en straks is het toch wel een aanzienlijk groot probleem. Zou Okta hun klanten de afgelopen maanden meer transparantie geboden hebben?

De reden dat ik dit zo stellig schrijf is dat in recent bijgewoonde webinars door beveiligingsbedrijven wordt geadviseerd niet alleen transparant te zijn in communicatie naar klanten, maar ook naar de buitenwereld toe. Wat kunnen goede argumenten zijn voor een bedrijf als Okta om toch voor dit "communicatie pad" te kiezen?

Overigens goed te vermelden dat hier wordt aangegeven dat klanten van Okta een samenvatting gaan ontvangen.

edit: leesbaarheid van de laatste zin

[Reactie gewijzigd door McNutters op 23 maart 2022 15:53]

Ik zou bijna gaan denken dat de hacks van afgelopen paar weken van Lapsus$, te maken hebben met deze hack op Okta.

Waarom komt niemand op het idee om Lapsus$ te vervolgen?

Hoe handig ik dingen als single-sign-on en social-logins ook vind, het blijft altijd iets engs.

De bedrijven waar je de dienst vanaf neemt (okta / facebook / github) kunnen simpel bij al jou accounts. Dit houdt ook in dat:

• Overheden er mogelijk ook bij kunnen.
• De werknemers van deze bedrijven erbij kunnen.
• Hackers die deze bedrijven hacken erbij kunnen.

Dit is allemaal niet best. Het grootste voordeel is echter:
"Ik heb er meer vertrouwen in de beveiliging van de social-login van GitHub, dan in een login-systeem wat ik zelf in elkaar knutsel"

Als je echter wat een gigantisch doelwit bedrijven als dit zijn, dan wordt dit voordeel al bijna weer teniet gedaan.

Bij het maken van een nieuwe website, wat denken jullie van de oplossing:
Social login via facebook/google/github/gitlab/wie dan ook
plus
2FA verzorgt en gehost op de eigen server.

Dit lijkt mij een relatief waterdichte oplossing, met het beste van beide werelden

Het zelf in elkaar knutselen van software lijkt heel simpel en toch maken we daar op de een of andere manier altijd foutjes in. Ik zit toevallig net te kijken naar een aantal kwetsbaarheden in Cisco routers die via IKE een stuk geheugen teruggeven. Met een beetje werk kunnen dit soort scenarios ook op jouw zelf geknutselde oplossing gebeuren, misschien niet met IKE maar dan wel op een andere manier.

Overigens ben je in het bovenstaande scenario met 2x Login beperkt door minder gebruikersvriendelijkheid, kwetsbaar voor cookie stealing, en een denial of service attack hoeft maar een van de technieken om zeep te helpen om te werken.
Twee factor authenticatie klinkt heel fijn voor dagelijks gebruik onder gewone condities, maar voor admin toegang in nood situaties is het een vergroting van het risico.

Het zelf in elkaar knutselen van software lijkt heel simpel en toch maken we daar op de een of andere manier altijd foutjes in.

100% mee eens, daarom denk ik ook aan een oplossing waar je het overgrote gedeelte uitbesteed aan een SSO oplossing. Maar zoals we hier zien is dat niet altijd het beste idee, een 2e factor is tegenwoordig toch wel gewenst. Het liefst zou ik deze 2FA aan een ander bedrijf (in een ander land) willen uitbesteden, of door een open-source versie zelf te hosten.

Overigens ben je in .... risico.

Interessant, zou je daar iets meer over kunnen uitbreiden?

• De gebruiksvriendelijkheid is inherent aan 2FA, het kost nou eenmaal altijd een stap extra.
• Cookie stealing: bij bijvoorbeeld Next-Auth 'praat' jouw server met bijv. Facebook, en geeft vervolgens een cookie uit. Als je ook 2FA toevoegt, krijg je nog steeds dezelfde cookie, alleen is deze 'moeilijker' te krijgen. (de server verifieert ook 2fa). Ik zie ook niet in hoe een 'okta' cookie veiliger is dan een cookie van mijn server?
• Qua noodgevallen/admin logins kan je gelijk hebben, maar ik heb het nu meer over persoonlijke accounts van klanten. Al klinkt een 1-factor admin-account mij ook niet echt als muziek in de oren

Ik zou me kunnen voorstellen dat het uitdelen van de cookie via een ander kanaal misschien een verbetering oplevert?

Voordat je mij op deze 'vriendelijke' (/s) manier probeert te verbeteren, zou ik zelf het nog maar eens opzoeken

Ik heb het niet over het risico dat bijvoorbeeld Tinder bij mijn Facebook data kan, maar juist anders om.... Facebook kan bij mijn Tinder data.

Als je Social-login gebruikt, is er vaak helemaal geen wachtwoord (tenzij je het combineert met een wachtwoord systeem). Het hele verhaal over wachtwoorden is hier dus ook niet relevant.

Zo'n partij kan dus al niet zomaar inloggen in je account met gebruikersnaam en wachtwoord want dat laatste weten ze niet. Ook hebben ze geen gegevens van de applicatie om daar direct in te loggen, puur een client id en secret om een verzoek te starten tot authenticatie en daarmee de url te krijgen waar naar de gebruiker moet navigeren om in te loggen. Die redirect weer terug (+ nog allemaal checks of die url wel toegestaan is etc) met een code. De applicatie doet weer een verzoek om die code te ruilen voor een authenticatie code en voila, ingelogd. Nu is het dus zelfs andersom zo dat de applicatie toegang heeft tot de derde partij via een API en niet andersom.

Je verhaal klopt, maar je slaat de laatste stap over: Tinder heeft nu, dankzij de authenticatie code access-token, toegang tot een deel van mijn Facebook data (email / misschien wat foto's). Maar wat nu? Ik wil toch echt inloggen op Tinder. Achter de schermen gebeurt er dit:

• 1. Tinder vraagt, bij Facebook, het email-adres op, dat bij de access-token hoort.
• 2. Tinder controleert, bij Facebook, of het access token echt is uitgegeven voor de Tinder applicatie, en niet voor iets anders.
• 3. Als dit klopt, dan weet Tinder zeker dat ik degene ben die de eigenaar is van het Facebook account dat bij dat email-adres hoort, én dat ik wil inloggen bij Tinder.
• 4. Vervolgens krijg ik toegang tot mijn tinder-account / foto's / chatgeschiedenis.

Wat is in deze flow het belangrijkste stuk informatie? Het access-token.... wie kan dat genereren? Facebook. Wie heeft er toegang tot mijn Tinder gegevens? Facebook (FBI/FB-medewerkers/hackers).

Daar is waar ik het gevaar zie. Dit is te voorkomen door een 2FA oplossing die niet in handen van Facebook is.

Laat ik het anders stellen:
Ik heb voor Tinder geen wachtwoord ingesteld. Waar is dán de benodigde informatie om in te loggen, als dat niet bij Facebook ligt?

Kortom, doe jezelf een plezier en lees je eens in, in hoe dat soort dingen geïmplementeerd worden.

Kortom, probeer een beetje vriendelijk te reageren. We hebben beiden genoeg kennis in huis om hier een normale discussie over te hebben

Hoe kom je er bij dat je met het access token (voor de API van Facebook, in dit geval de 3rd party) toegang hebt tot Tinder?

Also, we praten langs elkaar heen. Waar ik het over heb is dat de 3rd party (Facebook) geen toegang heeft tot jouw wachtwoord vanwege hashing. Zij kunnen dus niet de flow starten vanuit Tinder en dan inloggen met jouw Facebook account want daarvoor moet je je wachtwoord hebben of je sessie gekaapt zijn. Van dat laatste gaan we even niet uit want zoals ik al zei, je moet wel enig vertrouwen hebben in de 3rd party. Kortom, ze kunnen niet inloggen in je Tinder zonder verregaande backdoors. Maar again, je moet enig vertrouwen hebben en dit ligt niet aan SSO.

1. De gebruiker wil inloggen bij Tinder
2. Tinder redirect naar Facebook
3. De gebruiker logt in bij Facebook
4. De gebruiker wordt geredirect naar Tinder, met een code in de url
5. Tinder (server-side) wisselt deze code in voor een access-token

Klopt dit? Volgens mij is dit een samenvatting van wat je in de vorige post schrijft.

6. Tinder gebruikt het access-token, om het email-adres te krijgen van de gebruiker via Facebook.
7. (Tinder controleert ook, of het acces-token is uitgegeven voor Tinder, en niet voor een andere app)
8. Als al deze checks gelukt zijn, dan krijgt de gebruiker toegang, tot het Tinder account dat bij dit email adres hoort.

Klopt dit? Dit is een samenvatting van wat ik in mijn post zei.

Mijn hele punt is nu: Wie houdt Facebook tegen, om bij stap 6, een ander email-adres terug te geven? Als zij in stap 6, [e-mail] teruggeven, dan zit ik in jouw account. Facebook heeft dus deze macht. Je moet dus volledig vertrouwen, dat Facebook jouw profiel niet wil inzien. (en dat ze niet gehackt worden / niet samenwerken met de fbi / dat een medewerker niet zijn/haar ex wil stalken)

Een vergelijkbaar probleem zie je hier met Okta. Als je de authenticatie volledig uit handen geeft, dan heb je het risico dat zij (of een hacker, of een werknemer) kan inloggen.

Volgens mij praatten wij inderdaad langs elkaar heen, maar heb ik ook niks gezegd dat niet klopt. Als dat wel zo is, zou ik graag weten welke stap hier verkeerd gaat. Ik heb genoeg gewerkt met dit soort login-systemen om wel een aardig idee te hebben, maar ben geen expert.

Tot slot:

Zij kunnen dus niet de flow starten vanuit Tinder en dan inloggen met jouw Facebook account want daarvoor moet je je wachtwoord hebben of je sessie gekaapt zijn.

Ik heb geen wachtwoord bij Tinder, en als ik m'n telefoon leeghaal ook geen sessie. Toch kan ik wel een authenticatie flow starten (gewoon klikken op 'login with facebook). De authenticatie gebeurt dan weer bij Facebook, en zij hebben alle controle daarover, zij hebben geen wachtwoord nodig, maar kunnen access-tokens genereren wanneer ze willen

Hoi Svane,

sorry voor de verlate reactie, werk en zo .
In bovenstaande scenarios voor Facebook heb je volkomen gelijk. Facebook is de identity provider en authenticatie provider naar Tinder. Dit is een ontwerpkeuze van Tinder in combinatie met een wens van Facebook om in deze rol te zitten.
Overigens hoeft het email adres hier niet de gebruiker te zijn, maar is dat het bij facebook wel.
In het geval van bijvoorbeeld Microsoft (bijvoorbeeld [e-mail]) is dit ook het geval. Je kan bij Xbox gaming aanmelden met je hotmail identiteit en de authenticatie wordt door Microsoft gedaan (niet door het Xbox platform).
In het geval van Okta zijn er meerdere flows mogelijk, hier kan Okta als identity provider optreden, of als proxy naar andere identities, zoals een on-premise active directory, een azure active directory, of een overige identity provider zoals Google of Facebook.
In de desbetreffende authenticatie flow kunnen extra authenticatie slagen door Okta gedaan worden. In veel (maar niet alle) scenarios wordt door Okta aangegeven of de gebruiker toegang moet krijgen tot een applicatie.
In ieder geval is het belangrijk om altijd goed door te hebben wat iemand met admin rechten in een dergelijke omgeving met jouw gegevens kan doen.

PS met betrekking tot admin toegang en 2 factor: Laten wij er vanuit gaan dat admin's in nood situaties iets belangrijks te doen hebben op de omgeving, en dat een van de redenen van een nood situatie kan zijn dat de 2 factor niet meer werkt. Dan moet er nog wel een scenario zijn dat je alsnog binnen komt. Iets wat bijvoorbeeld niet afhankelijk is van externe systemen.
Een paar maanden terug had Facebook een probleem in een datacenter, en toegang tot het datacenter was gekoppeld aan de identiteit van een facebook account. Ik vermoed dat ze een deur hebben moeten forceren om binnen te komen. Wellicht dat dat de reden was dat het 7 uur duurde voordat Whatsapp weer werkte...