image

Column: Het einde van Single Sign On

donderdag 10 januari 2013, 11:13 door Peter Rietveld, 13 reacties

Single Sign On ofwel SSO: het ultieme streven in beveiligingsland. Een enkelvoudige login maakt toegang simpeler, vermindert het aantal wachtwoorden en maakt het mogelijk om sterkere wachtwoord policies in te voeren. Met een enkelvoudig account zijn audits bovendien eenvoudiger uit te voeren en is provisioning en deprovisioning van autorisaties beter te regelen.

De boel wordt veiliger omdat je één wachtwoord gemakkelijker kunt onthouden dan 25. Hierdoor kun je ook sterkere wachtwoorden invoeren. Immers, 25 moeilijke wachtwoorden onthouden, die je eigenlijk ook nog elke maand moet veranderen, dat gaat gewoon niet. Eentje lukt nog wel. Heb je niet eens een Post It op je beeldscherm voor nodig.

Ideaal dus, dat SSO. Maar het is een gepasseerd station. Om verschillende redenen, waarvan de bekendste is: als een user account wordt gekaapt, en dat account geeft toegang tot een stuk of vijftien systemen, dan zijn ze alle vijftien gecompromitteerd. De oplossing die daarvoor aangereikt wordt is sterke authenticatie. Dat heeft slechts een heel enkele organisatie daadwerkelijk ingevoerd, dus met SSO is de veiligheid verminderd.

Maar goed, dit is nog te overzien. Een wezenlijker zwakte ligt besloten in het verschijnsel toegangsbeheer in het algemeen. Toegangsbeveiliging bestaat uit twee afzonderlijke vraagstukken. De eerste is toegang tot informatie gebonden aan een systeem, applicatietoegang dus. De tweede is toegang tot informatie die onafhankelijk is van het systeem: in een bestand, zoals een Excelsheet. Deze twee manieren van toegang vragen ieder een eigen aanpak en een eigen beveiligingstechnologie. Het overgrote deel van de toegangsbeveiligingsmiddelen gaat over applicatietoegang en beschouwt een fileshare ook als een applicatie.

Gegeven dat een Excelsheet op iedere andere willekeurige machine geopend kan worden, is dat een zeer merkwaardige denkfout. En daarmee ook een probleem. Dat al behoorlijk dringend werd met de opkomst van de laptop, maar dat nu, sinds de smartphone, de tablet en de cloud een levensgroot probleem is.

Nu kun je een dergelijke fout pas oplossen als je de oorzaak onderkent – er is geen simpele oplossing want dan zouden we het probleem helemaal niet hebben.

SSO komt voort uit het traditionele gesloten netwerk, waarbij de bakstenen de belangrijkste laag vormen in de informatiebeveiliging. Toegang is in die werkelijkheid een probleem van het netwerk en van de firewall. In dit Old School denken is de eigen omgeving een gesloten geheel, met een harde buitenkant. De beveiliging is dan ook geconcentreerd op die buitenkant. Toegangsbeveiliging is de beveiliging van de poort. De beveiliging van de binnenkant is in deze opzet veel minder belangrijk, want daar kunnen alleen medewerkers bij en die zijn technisch niet zo slim als de hackers buiten. Dit gedachtegoed wordt wel het kokosnootmodel genoemd (hard van buiten, zacht van binnen), of, meer theoretisch, System High Mode (http://en.wikipedia.org/wiki/System_high_mode).

Nu het gesloten netwerk iets van het verleden is, is het kokosnootmodel dat ook. Met het verdwijnen van de buitenmuren is toegangsbeveiliging niet zo simpel meer. De impact van Jericho is echter bij de meeste mensen nog steeds niet doorgedrongen. Zij zien het grootste gevaar nog altijd in de Post It met het wachtwoord op het beeldscherm. Dat is achterhaald: er zijn veel minder aanvallers die fysiek toegang hebben tot je werkplek om de Post It op het beeldscherm te kunnen lezen, dan er mogelijke aanvallers via het internet zijn.

Dus: liever een heel sterk wachtwoord op een papiertje dan een wat zwakker wachtwoord dat gebruteforced kan worden. Wat de meeste mensen zich niet realiseren is dat het Brute Forcen van een wachtwoord op internet veel beter uitvoerbaar is dan op een LAN en de oplossing van het LAN op het internet niet werkt. Op het internet hebben miljarden mensen toegang tot het loginscherm, en is het hoogst ongebruikelijk een lock-out policy te hebben dat een account afsluit na drie verkeerde wachtwoorden achter elkaar. Dat is immers een instant Denial of Service aanval. Facebook, LinkedIn en Salesforce hebben daarom ook geen lock-out policy. Dus als een organisatie Single Sign On ‘doet’ met een cloudapplicatie, betekent dit effectief het einde van de lock-out policy, ook voor het interne netwerk.

Natuurlijk zouden we helemaal zonder wachtwoorden moeten werken. Want ook na twintig jaar gebruikersopvoeding staan 123456 en password nog bovenaan de keuzelijst (http://nakedsecurity.sophos.com/2012/07/13/yahoo-voices-poor-passwords/). **

Strikt genomen hoort SSO niet onlosmakelijk bij wachtwoordauthenticatie. Maar in de praktijk werkt het wel zo. Een organisatie zou er immers voor kunnen kiezen iedere gebruiker een hardware token te geven. Dat kan, maar als behalve medewerkers ook klanten toegang hebben, wordt het opeens een heel ander verhaal; een kostbaar verhaal vooral. En, nog veel belangrijker: hoe koppel je Dropbox of LinkedIn aan die corporate strong authentication? Bovendien moet dat dan met een technologie die het doet op een iPhone of op die kekke Android tablet. Dream on.

Dat SSO over wachtwoorden gaat en niet voor andere authenticatietypes werkt wordt nog duidelijker als we het PAM (privileged account management) dossier erbij betrekken: vanuit beveiligingsoptiek is het eigenlijk wenselijk dat toegang tot beheerdersaccounts (die zo ongeveer alles mogen) extra beveiligd wordt – dus zeker met sterke authenticatie. We willen ook dat beheerders aparte accounts hebben, omdat ze anders de hele tijd alle rechten hebben en dat vergroot de risico’s.

Wat we zien is iets heel anders: in plaats van een smartcard voor de beheerder hebben we een procedure met een envelop.Want die beheerders moeten op al die dozen aanloggen met lokale accounts. Als we de toegang voor beheerders erbij betrekken dan is de Sign On nooit Single geweest.

In de post-jericho-tijd is dit de realiteit: als organisatie kun je niet de enkelvoudige sterke authenticatie afdwingen op de eigen tablet waarmee de klant toegang zoekt, de medewerker thuiswerkt of op de cloudapplicatie die de gekozen technologie niet ondersteunt. Wil je de toegang gecentraliseerd beheersen (en beheren), zullen hiervoor een andere manier moeten bedenken. En dat kan. Sommige organisaties zijn hier al mee bezig. Hoe ziet zoiets er dan uit?

Je moet het kind natuurlijk niet met het badwater weggooien. Je wilt wel dat gebruikersaccounts zo gecentraliseerd mogelijk zijn, voor auditing en provisioning. Het wordt dus wel een geünificeerde login. Laten we het de Unified Sign On noemen, de USO. Zo’n omgeving zal gebruik maken van directories (je zult de users toch ergens moeten opslaan) en het daarbij gebruikelijke LDAP. Omdat niet alleen medewerkers toegang moeten hebben, maar ook mensen van buiten, zul je verschillende directories inzetten.

De interne directory geeft ook LAN toegang, alle andere gebruikers doe je op een extern gerichte directory die geen Kerberos doet. Beide logins koppel je aan een federatieve login, waarbij je met een trucje die Where Are You From (http://saml.xml.org/blog/saml-20-usability) wegmoffelt. Klein beetje extra werk, een stuk minder sores.

Op de netwerk-laag zal de USO een Multi-protocol voorziening zijn. Dat Multi-protocol komt zo: het klassieke SSO project bevatte onlosmakelijk de term kerberisatie: de aanpak om alle logins koppelen aan de login van AD. Dat is een prima aanpak: Kerberos is een mooi protocol en cryptografisch sterk. Maar het heeft een vervelende beperking; het werkt niet op het internet. Op internet gebruiken we SSL of niets. Nu kunnen we in het netwerk wel SSL gebruiken, maar SSL is zwakker dan Kerberos, met name vanwege de offline rootCA en omdat we het altijd single side gebruiken. Voor dual side moet je continu die certificaten verversen op al die PC’s en zeg nou zelf, daar hebben we toch geen tijd voor?

Internet SSL is bovendien gebonden aan de Internet namespace (de common name in het certificaat bevat de hostname) en dat werkt weer niet binnen een afgesloten namespace. Dus een Unified Sign On die systemen binnen en buiten bestrijkt zal geen technische eenheid zijn; het zal een samengesteld systeem worden dat op de grens tussen binnen en buiten Kerberos tickets omzet in SSL tokens en vice versa.

Bovenstaande Unified Sign On wordt in de praktijk vormgegeven met SAML en WS-FED standaarden, met uitlopers naar specifieke technologieën met andere protocollen. Daar horen producten bij als OpenAM en ADFS. Dergelijke Federatieve producten worden intussen meer en meer uitgebreid met ondersteuning voor sterke authenticatie, zodat de centrale login voorzien kan worden van extra beveiliging. Als deze centrale login alleen voor medewerkers is, dan is het mogelijk hiervoor te kiezen en iedere medewerker een hardware token te geven.

Het is echter opeens veel lastiger als klanten en medewerkers van zakenpartners ook toegang moeten krijgen, of van die lastige mensen met die eigen apparaten. Nu is het mogelijk een tweede centrale login op te stellen die een zwakkere login toestaat, maar dat is dan weer hoogst onlogisch; waarom moeten vertrouwde medewerkers méér moeite doen om ergens bij te komen? Bovendien is een centrale login niet meer centraal als er twee zijn. Waarschijnlijk zal de integratie met wat erachter zit ook losser worden, wat het geheel onveiliger maakt.

De oplossing is differentiatie: verschillende gebruikersgroepen via dezelfde login /andere authenticatiemethodes/ bieden. De logische volgende stap is deze differentiatie ook te gebruiken voor de verschillende device typen. Dit mondt dan uit in een step up systeem waarbij de gekozen applicatie een vereist authenticatiemiddel krijgt, en dat op basis van een aantal variabelen. Zo zal een eigen medewerker die met een beheerd werkstation vanuit het eigen LAN aanlogt met een zwakker authenticatiemiddel toe kunnen dan dezelfde medewerker vanaf een privé tablet thuis. Hiermee komt de identiteit en de locatie van de device in de beveiligingsafweging bovendrijven, als extra variabelen in een Risk Based Access control.

Het plaatje wordt echt mooi als ook binnen een applicatie gedifferentieerd kan worden. Zo zal deze medewerker aanvullend moeten authenticeren als hij een gevoelige transactie wil uitvoeren: als je honderdduizend euro wilt overmaken vanaf je thuis PC, moet je het One Time Password invullen dat op je hardware token verschijnt. Heb je dat al gedaan in een sessie, dan hoeft dat niet nog een keer.

De eerste applicatieservers die dergelijke differentiatie ondersteunen zijn inmiddels beschikbaar, en step up is de ontbrekende schakel in toekomstige toegangsoplossingen. Het wordt dus tijd om de traditionele RBAC matrices uit te breiden met devices en locaties, want de rol van een persoon is al lang niet meer het enig relevante gebruikersattribuut in een toegangssysteem.

Dat probleem van die bestanden – ja dat heb ik dan dus nog steeds niet opgelost. Goed punt.

Door Peter Rietveld, Senior Security consultant bij Traxion - The Identity Management Specialists -

Laatste 10 columns


Meer columns van Peter Rietveld.
Reacties (13)
10-01-2013, 11:53 door Dick99999
Een veilige wachtwoord kluis komt dicht bij SSO zonder de nadelen: elke app of site heeft een eigen sterk wachtwoord.
10-01-2013, 13:03 door WhizzMan
Peter: Je omschrijft een redelijk pragmatische manier om om te gaan met authenticatie nu je niet meer uit kan gaan van bakstenen.

Dat mensen aan de haal gaan met gegevens die ze na authenticatie kunnen benaderen en die buiten de "beveiligde" omgeving brengen is iets wat je tussen de oren op moet lossen. Je kan wel spreadsheets gaan verzinnen die het niet doen op computers waar de signature niet in het tabelletje van toegestane systemen staat, maar er is geen gebruiker die dat gaat accepteren.
10-01-2013, 14:56 door Evert_S
Peter,
goed onderbouwd artikel! Ik kan alleen maar zeggen dat ik het volmondig met je eens ben; het is dan ook die aanpak die wij bij ons aan het uitrollen zijn.

Overigens zijn er voor het probleem van Privileged Users ook goeie oplossingen verkrijgbaar.
Wij zijn op dit moment een product aan het uitrollen dat -naast de functie van passwordvault - ook de mogelijkheid heeft om sessie op doelsystemen op te zetten mbv van de privilegd users.

Deze sessies draaien volledig in de gecontroleerde omgeving die het pakket opzet en dat zorgt er dus voor dat - naast het feit dat de systeembeheerder gewoon zijn werk kan doen - alles wat hij doet kan worden opgenomen in een videobestand (je kan dus de hele sessie opnieuw afspelen) en/of in een commandologfile.

Wat betreft het bestandsprobleem (intern maar evengoed via mobile devices, al dan niet byod) heb ik een tijdje geleden al es een reactie hier neergeschreven.

Ik quote ze nog even hieronder:
Door Anoniem: Ik denk dat mobiele toestelen (BYOD of zelfs corporate), cloud en vooral de combinatie van de twee het einde ingeluid hebben van de security architectuur die tot nu toe als gemeengoed wordt beschouwd.

Een architectuur die praktisch volledig is gericht op het be-/afschermen van een toestel/netwerk. Een architectuur die zijn hoogdagen beleefde in het mainframetijdperk en die sindsdien alsmaar meer problemen vertoonde.

Vandaag de dag is informatie extreem mobiel geworden doordat de dragers dat zijn geworden. Die toegenomen mobiliteit is al lang geen "leuke feature" meer maar een keiharde business eis. Toegenomen mobiliteit zorgt namelijk voor toegenomen productiviteit (potentieel dan toch) maar het maakt ook meer flexibiliteit van werken mogeiljk.

Een interessant gegeven in een tijdperk waar "tijd" een schaars goed is geworden voor velen.

Informatieveiligheid moet boven al ten dienste staan van medewerkers, niet in de weg ervan. De geschiedenis heeft al ruimschoots bewezen dat "in de weg staan" uiteindelijk ook maar een illusie is, gebruikers zijn creatief genoeg om ook de meest vernuftige beveiligingsmaatregelen te omzeilen als hen dat genoeg voordeel oplevert.

wat hebben dan wel nodig?

Een architectuur die gericht is op het beveiligen van de informatiedragers (documenten) zelf, veeleer dan de devices waarop ze bewaard worden.

In zo'n architectuur worden de informatiedragers versleuteld, de sleutel kan enkel bemachtigd worden door je (op een voldoende sterke manier) te authenticeren aan de keymgmt server.

Het geeft je (als informatie-eigenaar) de mogelijkheid om zélf te beslissen wat met je document al dan niet kan gebeuren en door wie. Zelfs fijnmazige beveiliging als het verbieden om een document te wijzigen, af te drukken, te copy-pasten, screenshots te nemen, .. behoort tot de mogelijkheden.

Een technologie die op maat gesneden is op onze mobiele maatschappij.
Het is wat mij betreft het enige zinnig antwoord op discussie als BYOD, mobile en cloud.

Meer info, zie bvb http://en.wikipedia.org/wiki/Information_Rights_Management

E
11-01-2013, 09:20 door Dick99999
Door Evert_S:
..................................
Ik quote ze nog even hieronder:
Door Anoniem:
....................
In zo'n architectuur worden de informatiedragers versleuteld, de sleutel kan enkel bemachtigd worden door je (op een voldoende sterke manier) te authenticeren aan de keymgmt server.

Op wat voor termen moet ik zoeken voor zo'n keymgmt server. Of kan je een paar voorbeeld producten geven? Hoe goed zijn die geïntegreerd met de normale, maar onveilige, werkwijze?
11-01-2013, 16:36 door Evert_S
Als je zoekt naar "Information Rights Management" zal je al veel vinden.
Makkelijkste voorbeeld is waarschijnlijk Microsoft. IRM is ondertussen al een heel eindje geïntegreerd in hun Office Suite. Adobe heeft ook iets dergelijks weet ik ivm hun PDF-formaat.

Integratie met de "onveilige" werkwijze is zo "goed" als de veiligheidsvereisten die je instelt op het document en de manier waarop je je architectuur opzet.

Als je bvb vereist dat voor het openen van een willekeurig document de PKI-infrastructuur gecontacteerd moet kunnen worden maar deze is niet benaderbaar vanop het internet dan beperkt dat de mobiliteit van je informatie uiteraard..

Sowieso is het altijd mogelijk om documenten te maken zonder beveiliging.
13-01-2013, 03:26 door Sokolum
RBAC, voeg dan NAC dan ook eraan toe.
14-01-2013, 11:56 door Anoniem
leuk verhaal, maar er zijn nog wel wat kanttekeningen.

Je schrijft: "Internet SSL is bovendien gebonden aan de Internet namespace (de common name in het certificaat bevat de hostname) en dat werkt weer niet binnen een afgesloten namespace."
Er is geen enkele reden waarom je externe namespace intern niet zou repliceren.

En dat beheerders een smartcard zouden moeten inruilen voor een password in envelop is te zot voor woorden.
Smartcards zorgen voor two-factor-authentication. Dus als je na de storing de (evt nood)-pas weer hebt ingeleverd, heb je geen toegang tot het systeem meer.

Einde van SSO? Tegendeel! Maar dan wel SSO gekoppeld aan strong-authentication. Dus je kunt pas een kerberos ticket krijgen nadat je je hebt ge-identificeerd obv card (what you have) een een PIN-code.

Enige stap die men moet maken, is om de houder van de pas persoonlijk betokken te houden bij het beveiligen van de PIN. Te vaak zien we smartcards en tokens waarop medewerkers de pin achterop hebben geschreven.
Zodra je van de mensen hun prive GSM-sim kunt benutten, of hun bank pas, dan pas weet je zeker dat ook zij er zorgvuldiger mee omgaan.
14-01-2013, 12:32 door Anoniem
Stukje Jericho project propaganda ?

Terwijl dat project toch aardig vol complete onzin fantasie 'security' zit.
Zie : http://qcic.nl/item.78.html
16-01-2013, 13:23 door Anoniem
Jericho, Oh boy.
En risk management op systemen en niet op de data. Corporate bull. En overal kom je dat tegen.

SSO maar dan met allemaal unique wachtwoorden. Oftewel, wanneer de ene app gehakt is wordt niet automatisch de anderen ook uitgeleverd. Zie CAS of pubcookie.

En voor federatie van authenticatie systemen iets als Shibboleth?

Beiden al jaren in gebruik bij niet een klein aantal en de minste universiteiten. (Shibboleth wiki heeft het over 4M+ accounts)


Waarom ga je over naar zwakkere authenticatie methoden? En niet naar uitgebreidere toegang?
17-01-2013, 02:27 door Anoniem
Universiteiten in de VS etc draaien geen shib protocol meer, hoor. Shib2 van unis draait gewoon SAML1.1 en 2.0 als protocol. In ons land was het ASELECT, en na de demise van alfa ariss en het maar niet van de grond komen van de tweede poging openaselect, nu onder bezielende leiding van Vasco (jeweetwel, die van diginotar), is de hele wereld saml. MS doet nog wel leuke dingen met WSFED.

CAS is al ook een ouder product. Loop je een beetje achter?
27-11-2013, 18:34 door Anoniem
Grappig alsof Ik een artikel lees van 5 jaar geleden. De wereld heeft niet stil gestaan.
27-05-2014, 16:57 door Jacob Lageveen
leuk artikel.
11-06-2014, 20:38 door denii - Bijgewerkt: 11-06-2014, 20:39
Wat de meeste mensen zich niet realiseren is dat het Brute Forcen van een wachtwoord op internet veel beter uitvoerbaar is dan op een LAN en de oplossing van het LAN op het internet niet werkt. Blablabla. Facebook, LinkedIn en Salesforce hebben daarom ook geen lock-out policy.

Er zijn talloze oplossingen die je in de praktijk tegenkomt en ook effectief zijn:
1. CAPTCHA
2. IP-based (temp) lockout
3. timeout van N seconden tijdens submit credentials

Denk je nou echt dat je effectief (1000+ wachtwoorden per minuut) online kan bruteforcen op een site als Facebook of LinkedIn?

Wat we zien is iets heel anders: in plaats van een smartcard voor de beheerder hebben we een procedure met een envelop.Want die beheerders moeten op al die dozen aanloggen met lokale accounts. Als we de toegang voor beheerders erbij betrekken dan is de Sign On nooit Single geweest.

Waar heb je het over? Waarom zou SSO voor beheerders niet werken? Waarom zouden beheerders geen aparte 'beheeraccount' kunnen gebruiken voor activiteiten met een verhoogd risico. Of 2-factor authenticatie of of of of. Waarom 'moeten' ze lokaal aanloggen?

Jouw mening over de rol (in het verleden en heden) van SSO staat echt haaks tegenover de realiteit.

En het onderhouden van een risk based authenticatieoplossing is gewoonweg een lachertje. Waarom zou die medewerker van crediteuren niet altijd met 2-factor authenticatie worden geconfronteerd als er een factuur met een bedrag hoger dan N wordt betaald. Alsof de tijd die men bespaard met het eenvoudiger kunnen betalen opweegt tegen de administratie die je bij mag gaan houden. Bovendien vind ik je voorbeeld maar gevaarlijk. Het verlagen van de beveiligingseisen wanneer je op het LAN werkt geeft medewerkers alleen maar een vals gevoel van veiligheid. Waarom nog locken als ik even koffie ga halen? Ik zit toch op kantoor... Tot je collega onder jouw naam een transactie tekent...
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.