Google Authenticator: 1 code meerdere Drupal-sites, issue?

[Rekcor]

Wij onderhouden en beheren een 30-tal Drupal 7-websites. Dit aantal blijft groeien. Users met een admin-rol (wijzelf dus) moeten met Two Factor Authentication inloggen. Dit doen we met een Google Authenticator-plugin.

Nu creëren we nieuwe sites op basis van een template-site. Voor deze template-site hebben we ook TFA ingesteld. Normaliter is de procedure dat we voor een nieuwe site, Google Authenticator opnieuw instellen voor die site. Onlangs kwamen we er echter achter, dat we - als we deze stap overslaan - ook gewoon kunnen inloggen met de code die op dat moment gegenereerd is voor de template-site.

Stiekem komt ons dit best goed uit: het is best wel een goede voor alle beheerders om voor iedere nieuwe site TFA opnieuw in stellen; ook bij het inloggen moeten we in een steeds langere lijst met codes zoeken naar de code voor de specifieke site waar je in wilt loggen.

Mijn vraag is: wat zijn de security risico's als we besluiten dat iedere admin in kan loggen met de TFA-code die eigenlijk bij de template-site hoort?
* De code wordt steeds opnieuw berekend
* Ongeoorloofde toegang tot één code (lees: hacker heeft mobiel van admin, heeft deze weten te ontgrendelen + weet het Drupal-wachtwoord van die admin) is gelijk aan toegang tot alle codes: die staan immers netjes onder elkaar in de Google Authenticator app.

Kortom: op basis hiervan is het risico zeer laag, maar wellicht zien we iets over het hoofd?

[DJMaze]

Er zijn verhalen dat ex-collega's / stagiaires de kans krijgen om websites te vernaggelen omdat een web bureau zijn zaakjes niet op orde heeft qua beveiliging.
Dat komt omdat men voor alle medewerkers op alle websites de zelfde login gegevens gebruikt.
Oftewel, je weet niet of je collega Henk of collega Ingrid of excollega Putin dingen heeft aangepast op de website.

Daarom is inloggen op een andere manier beter.

[Rekcor]

Dat komt omdat men voor alle medewerkers op alle websites de zelfde login gegevens gebruikt.

Dit is bij ons zeker niet het geval! Iedere medewerker heeft aparte logingegevens.

[Harrie_]

Ik ben zelf niet zo bekend met deze materie maar ik vraag me af: wat gebeurt er als je er een code/wachtwoord lekt en je wilt dit wijzigen. Kun je dan ook één wijziging doorvoeren die op alle sites werkt of moet je dan alsnog voor iedere site een aparte code gaan genereren?

[DJMaze]

Rekcor schreef op donderdag 15 februari 2018 @ 16:00:
Dit is bij ons zeker niet het geval! Iedere medewerker heeft aparte logingegevens.

Dan heeft iedere medewerker zijn eigen TOTP

Rekcor schreef op donderdag 15 februari 2018 @ 13:27:
Onlangs kwamen we er echter achter, dat we - als we deze stap overslaan - ook gewoon kunnen inloggen met de code die op dat moment gegenereerd is voor de template-site.

Dit struikt met "Iedere medewerker heeft aparte logingegevens"
Want, iedere medewerker moet natuurlijk wel zijn eigen 2FA activeren.
Als jij een 2FA inbakt in je "template" die voor elke medewerker het zelfde is, kan je net zo goed 2FA niet inbakken, want dat is gewoon een incorrecte implementatie.

Bouw dan een SSO (met 2FA) voor admins.
En dit is wel zo handig als een medewerker vertrekt. Disable zijn SSO en hij kan niet inloggen als admin op jullie ontwikkelde websites. In 1x je probleem opgelost dus.

[ Voor 13% gewijzigd door DJMaze op 15-02-2018 19:25 ]

[kwaakvaak_v2]

Ik gok dat ze voor iedere gebruiker niet dezelfde code gebruiken, maar de gewoon de user tabel + 2fa gegevens kopieeren via de template. (hopelijk is het idd niet de beruchte Drupal user 1 die dezelfde 2FA code heeft)


Als het idd alle user een eigen time-code hebben, is het relatief gezien veilig, want los van het wachtwoord moet ook iemands authenticatie app hebben om in te loggen in de site. Of het verstandig is, ja en nee.. Vanuit beheer oogpunt snap ik het wel, als je voor tientallen sites een losse 2FA code moet opzoeken om even wat te doen is ook zo wat. Maar een code voor alle sites kan iemand die kwaad wil wel in één keer op alle sites iets kwaad doen.

[ Voor 11% gewijzigd door kwaakvaak_v2 op 15-02-2018 19:36 ]

[DJMaze]

kwaakvaak_v2 schreef op donderdag 15 februari 2018 @ 19:34:
Ik gok dat ze voor iedere gebruiker niet dezelfde code gebruiken, maar de gewoon de user tabel + 2fa gegevens kopieeren via de template.

kopiëren is een slecht idee.
Ga je dan alle websites updaten als er een nieuwe medewerker komt, of als er eentje weggaat?

Ik begrijp wel waarom je het denkt, denk dan eerder dat er één "standaard" admin account inzit (met alle eventuele gevolgen van dien, precies ook zoals jij zegt).

[Rekcor]

kwaakvaak_v2 schreef op donderdag 15 februari 2018 @ 19:34:
Ik gok dat ze voor iedere gebruiker niet dezelfde code gebruiken, maar de gewoon de user tabel + 2fa gegevens kopieeren via de template.

Inderdaad, iedere relevante medewerker heeft een eigen admin-account, met een eigen TFA time code.

kwaakvaak_v2 schreef op donderdag 15 februari 2018 @ 19:34:
Als het idd alle user een eigen time-code hebben, is het relatief gezien veilig, want los van het wachtwoord moet ook iemands authenticatie app hebben om in te loggen in de site.

Juist, en als een hacker die app eenmaal heeft, heeft hij in de huidige opzet ook alle codes, want die staan netjes onder elkaar.

kwaakvaak_v2 schreef op donderdag 15 februari 2018 @ 19:34:
Of het verstandig is, ja en nee.. Vanuit beheer oogpunt snap ik het wel, als je voor tientallen sites een losse 2FA code moet opzoeken om even wat te doen is ook zo wat. Maar een code voor alle sites kan iemand die kwaad wil wel in één keer op alle sites iets kwaad doen.

Nu ja, hij moet wel steeds apart inloggen op iedere site, de TFA-code opzoeken. De enige winst is dat hij die code nu in 4 sec vind ipv in 30 sec.

[Rekcor]

DJMaze schreef op donderdag 15 februari 2018 @ 23:02:
[...]

kopiëren is een slecht idee.
Ga je dan alle websites updaten als er een nieuwe medewerker komt, of als er eentje weggaat?

Jup, we hebben procedures/checklists voor als een medewerker weggaat/komt, en daar staat ook een item 'drupal accounts verwijderen/aanmaken'. Bovendien krijgt de security officer iedere maand een overzicht met alle admin-accounts per site, om te checken of daar geen gekke dingen in staan.

[DJMaze]

Aha, zo te zien is het tijd om je bedrijfsprocessen te verbeteren.

[kunnen]

Je kunt de TOTP codes server-side prima hergebruiken. Maar:

Houd er wel rekening mee dat dit je risico vergroot: als iemand een van je sites hackt, dan kunnen ze zowel logingegevens onderscheppen van inloggende mensen als ook een TOTP code die ook werkt op een andere site. Als mensen dus ook hetzelfde wachtwoord op meerdere van jullie sites gebruiken, dan kan iemand de een site hackt daarna (binnen 1 minuut) bij alle sites inloggen.

[ Voor 8% gewijzigd door kunnen op 16-02-2018 18:09 ]

[Rekcor]

DJMaze schreef op vrijdag 16 februari 2018 @ 18:04:
Aha, zo te zien is het tijd om je bedrijfsprocessen te verbeteren.

Want? Preach it to me, brother :-).

kunnen schreef op vrijdag 16 februari 2018 @ 18:07:
Je kunt de TOTP codes server-side prima hergebruiken. Maar:

Houd er wel rekening mee dat dit je risico vergroot: als iemand een van je sites hackt, dan kunnen ze zowel logingegevens onderscheppen van inloggende mensen als ook een TOTP code die ook werkt op een andere site. Als mensen dus ook hetzelfde wachtwoord op meerdere van jullie sites gebruiken, dan kan iemand de een site hackt daarna (binnen 1 minuut) bij alle sites inloggen.

We waren ons bewust van dit risico. Zoals zo vaak, is het ook hier een 'trade off' tussen veiligheid en gebruikersgemak.


Wat voor soort hack zou dit moeten zijn (aangezien alles uiteraard via SSL-verloopt). Ik kan alleen een keylogger bedenken, die dan niet herkent wordt door onze - nogal paranoïde - antivirus/-malware-scanner.

[ Voor 1% gewijzigd door Rekcor op 19-02-2018 14:33 . Reden: Aanmoediging ]

[DJMaze]

Rekcor schreef op maandag 19 februari 2018 @ 14:31:
Want? Preach it to me, brother :-).

Heb je daar niet iemand voor in dienst? Een externe consultant inhuren is natuurlijk een goede optie.
Bedrijfsprocessen maken of breken elke organisatie. Je moet die dus regelmatig via een helikopterview analyseren.

Zeker omdat je in de eerste post al aangaf:

Rekcor schreef op donderdag 15 februari 2018 @ 13:27:
Wij onderhouden en beheren een 30-tal Drupal 7-websites. Dit aantal blijft groeien.....

Dan ga ik er vanuit dat er "verspilling is van arbeidscapaciteit"

Want meestal kost een wijziging bij 1 website veel minder werkt dan bij 100 websites.
Zeker als er een medewerker bij komt, je kan niet zo even die nieuwe medewerker aan elke website toevoegen met ID "10". Kan best zijn dat iemand op de website dat nummer al gebruikt.

[ Voor 16% gewijzigd door DJMaze op 19-02-2018 15:38 ]

[Rekcor]

DJMaze schreef op maandag 19 februari 2018 @ 15:35:
[...]

Heb je daar niet iemand voor in dienst? Een externe consultant inhuren is natuurlijk een goede optie.
Bedrijfsprocessen maken of breken elke organisatie. Je moet die dus regelmatig via een helikopterview analyseren.

Ik dacht dat jij uit mijn eerdere posts opmaakte dat we iets fundamenteel verkeerds doen, maar dat wordt me nog niet helemaal duidelijk.

DJMaze schreef op maandag 19 februari 2018 @ 15:35:
Want meestal kost een wijziging bij 1 website veel minder werkt dan bij 100 websites.
Zeker als er een medewerker bij komt, je kan niet zo even die nieuwe medewerker aan elke website toevoegen met ID "10". Kan best zijn dat iemand op de website dat nummer al gebruikt.

Dit is eenvoudig m.b.v. scripts op te lossen, zodat de gebruiker inderdaad maar 1 account hoeft aan te maken.

[DJMaze]

Oké even een scenario:

1. Je kopieert je "template" met 10 medewerkers (user id 1 t/m 10) naar een nieuwe website
2. Je maakt een admin user aan voor de klant (user id 11)
3. Je voegt een webshop module toe aan die website
4. Een klant van de webshop maakt een account aan (user id 12)
5. Een klant van de webshop maakt een account aan (user id 13)
6. Een klant van de webshop maakt een account aan (user id 14)
7. Een klant van de webshop maakt een account aan (user id 15)
8. Admin maakt een nieuwe admin user aan (zijn vrouw, user id 16)
9. Een klant van de webshop maakt een account aan (user id 17)
10. Een bezoeker van de webshop plaatst commentaar door in te loggen met Facebook (user id 18)
11. Je voegt een nieuwe medewerker toe aan de template database (user id 11)

Hoe ga jij die nieuwe medewerker op alle websites toevoegen?
Gebruik je een migratie script?
Hoeveel tijd is jullie medewerker kwijt om dit door te voeren bij 1 website?
Hoeveel tijd is jullie medewerker kwijt om dit door te voeren bij 30 websites?
Hoeveel tijd is jullie medewerker kwijt om dit door te voeren bij 100 websites?
Hoevaak gebeurt dit per jaar (stagiaires meegerekend enzo)?
Hoeveel tijd kost het om bijvoorbeeld een SSO (of andere) oplossing te ontwikkelen voor de medewerkers?


Ooit had ik bij een bedrijf een SSO gemaakt op basis van login met e-mailadres.
Als het e-mailadres @bedrijfsnaam.nl is, dan werd het wachtwoord getoetst via IMAP.
Als de PHP code kan inloggen via IMAP met het opgegeven e-mailadres + wachtwoord, dan werd de gebruiker automatisch een Admin gebruiker (als deze nog niet bestond).
Natuurlijk is het nadeel van deze SSO dat als de IMAP er uit ligt je niet kan inloggen.
Voordelen zijn er daarentegen genoeg.
Ik zeg niet dat IMAP voor jullie de oplossing is, er zijn genoeg andere mogelijkheden (OpenID Connect, LDAP, etc. etc.).
Daarvoor moet je dus gewoon een specialist in de arm nemen.
Wij kunnen namelijk niet vanaf hier jullie bedrijfsprocessen zien.

[ Voor 20% gewijzigd door DJMaze op 19-02-2018 17:35 ]

[Rekcor]

Hoe ga jij die nieuwe medewerker op alle websites toevoegen?
Gebruik je een migratie script?
Hoeveel tijd is jullie medewerker kwijt om dit door te voeren bij 1 website?
Hoeveel tijd is jullie medewerker kwijt om dit door te voeren bij 30 websites?
Hoeveel tijd is jullie medewerker kwijt om dit door te voeren bij 100 websites?
Hoevaak gebeurt dit per jaar (stagiaires meegerekend enzo)?
Hoeveel tijd kost het om bijvoorbeeld een SSO (of andere) oplossing te ontwikkelen voor de medewerkers?

Het syncen van accounts gebeurt allemaal automatisch, en kost dus heel weinig tijd. Ook hebben we maar 4 admin-accounts en krijgen stagiairs nooit een admin-account.

Dank voor je uitgebreide antwoord en het meedenken! SSO staat zeker op onze radar, maar betreffende modules werken (voor zover wij weten) bijv weer niet samen met de third-party TFA-module. We hebben dus een afwegingen gemaakt met plussen en minnen voor de diverse oplossingen, en de huidige kwam daar als beste (minst slechte) uit de bus.