CONTENT
Terug naar community
Magazine
Proceedings
Blogs
Master thesis
Zoeken
THEMES
The CIO speaks
The architect answers
The business decides
Effect of architecture
SOA
BPM
Methods
Principles
Financial services
Public sector
Health sector
Most popular items
 
 
BLOGS
Nooit meer je token kwijt

Steeds meer mensen lopen rond met een (hardware) token aan hun sleutelbos. Ik ook. Met behulp van zo’n hardware token  - waarop een dynamische pincode te lezen is - kun je, in combinatie met je persoonlijke pincode, bijvoorbeeld toegang krijgen tot het beveiligde netwerk van je organisatie. Er kleven echter de nodige nadelen aan zo’n token. Ik stel een alternatieve oplossing voor die deze problemen niet heeft. Deze oplossing is gebaseerd op twee ideeën.

De nadelen van een hardware token zijn:

  1. Als je overal toegang wil hebben, dan moet je het hardware token overal mee naar toe nemen (en als deze zoals bij mij aan je sleutelbos hangt en je partner leent deze even dan ben je ook je token even kwijt);
  2. Mensen verliezen dingen (ook tokens);
  3. Tokens kosten (veel) geld (en moeten ook nog eens regelmatig worden vervangen);
  4. Tokens kunnen out-of-sync. raken;
  5. Iemand kan misbruik maken van het token door mee te kijken of het even te ‘lenen’.

Het eerste idee waarop de oplossing is gebaseerd is heel simpel en eenvoudig uit te voeren. Voor wie het token niet de hele tijd op zak wil dragen, maar wel een goede internetverbinding heeft (en een beetje handig is), hangt zijn token voor de webcam en publiceert het beeld met de dynamische pincode op een ‘geheime’ plek (bijvoorbeeld ergens verstopt op de eigen homepage). Met deze eenvoudige oplossing zijn we in ieder geval af van problemen 1. en 2. Je heb je token altijd bij de ‘hand’ en het hangt veilig thuis (voor de webcam).

Voor de problemen 3,4 en 5 is meer nodig. Het tweede idee is wat ingewikkelder en vereist een (publieke) infrastructuur. De oplossing hiervoor bouwt voort op het vorige idee. Maak een publiek plein van ‘geheime’ plekjes van dynamische pincodes (want dat is de primaire functie van een hardware token) – het ‘tokenplein’. Oftewel vervang het hardware token door het steeds verspringende cijfer te publiceren op een website. Op het tokenplein kunnen gebruikers hun eigen token bekijken. Ik stel me deze plek voor als het parkeerterrein van de Efteling, je hoeft alleen te onthouden waar je je auto hebt geparkeerd (bv. op het kaboutertje 2 de 6e auto). Het toewijzen van een plek kan heel veilig bijvoorbeeld door deze per post te sturen of – nog beter – de verzegelde envelop met de geheime plek te overhandigen (met fysieke verificatie van de identiteit). De plek is eenvoudig uit het hoofd te leren (zeker niet lastiger dan de gebruikelijke 4 cijferige pincodes).

Nu moet deze plek natuurlijk wel voldoende geheim zijn. Tot op zekere hoogte is de waarborg al inherent aan het feit dat het gaat om een virtueel plein; alleen jij weet waar je op het plein (een internetpagina) moet kijken. Op een fysieke parkeerplaats kun je zien wie zijn auto waar parkeert; op een virtuele plek in principe niet. Daarnaast moet de virtuele plek natuurlijk wel aan een paar basale randvoorwaarden voldoen; op de eerste plaats moeten er voldoende plekjes op een pagina staan om de kans van een toevalstreffer – ook als er een poging wordt gedaan door bijvoorbeeld een bende - voldoende klein te maken (minstens zo goed als de kans van het hardware token waar we te maken hebben met probleem 5). Hoe groot laat ik graag over aan de experts. Daarnaast moet het heel lastig zijn om de cijfers er met een computer voldoende snel vanaf te halen. Dit kan door de code visueel zodanig te vervormen dat de code wel voor mensen leesbaar is maar niet voor computers. Natuurlijk moet dit op basis van een random vervorming gebeuren. Tot slot zal het mechanisme voor het genereren van de unieke dynamische pincodes voldoende sterk moeten zijn (in tegenstelling tot de hardware tokens kan het algoritme eenvoudig worden vervangen).

Nu is de praktijk van security – in het bijzonder encryptie - dat dit een gebied is waar heel knappe koppen zich mee bezig houden. Dus mogelijk is deze oplossing binnen no time gekraakt. Hierbij dan ook de oproep aan de experts om deze oplossing met de vloer gelijk te maken of – en dat heb ik natuurlijk liever – deze oplossing te realiseren en te perfectioneren. Het leent zich in ieder geval uitstekend als Software as a Service concept.






Comments (11)
RSS comments
Written by FSchiphorst on 17-02-2010 12:36
 
 
Ik zie een groot probleem. Middels keylogging/mouselogging/urlloggin is snel te zien waar je auto staat. 
Voordeel van het token is dat het niet aan infra hangt en dus niet remote uit te vragen is middels een geinstalleerde rootkit bv. 
De locatie van het token kan bekend worden maar daarvoor moeten ze het wel leterlijk uit handen nemen dat ontdek je (snel)

 
Written by This e-mail address is being protected from spam bots, you need JavaScript enabled to view it on 17-02-2010 19:45
 
 
Het probleem van mouselogging/urllogging zie ik niet zo snel als de parkeerplaats maar groot genoeg is (op een url in een oogopslag). Wellicht - maar dat vraagt wel de nodige manuele inspanning - kan de ingetoetste code worden afgevangen. Maar dan zal deze real-time doorgestuurd moeten worden naar iemand die - binnen het timeframe (bv. 20 seconden) - erin slaagt om al die pincodes te vergelijken en de plek te achterhalen. Ook vraagt het dat de kwaadwillende weet met welke client het aanloggen gaat gebeuren. Daarnaast vraag ik me af in hoeverre het dan een groot probleem is (in vergelijking tot het hardware token). En - dat hoop ik dan weer - wellicht is er nog wel een slimmigheidje te bedenken om de parkeerplaats verder te beveiligen.

 
Written by FSchiphorst on 17-02-2010 20:23
 
 
Als iemand de pc heeft overgenomen. Dan kunnen ze de pagina copieren en middels keylogging zien welke kode is ingegeven.  
Ze kunnen dan zien waar op de pagina die kode staat en weten dan waar ze de volgende kode moeten oppikken. 
Een los token is niet door een externe partij op afstand uit te lezen. 
2 factor is something YOU have. In dit geval (een gehackte PC) hebben zij ook access tot de token kode

 
Written by This e-mail address is being protected from spam bots, you need JavaScript enabled to view it on 17-02-2010 20:33
 
 
Ook bij een hardware token toets ik alle cijfers in (persoonlijke pin plus dynamische pin). Degene die controle over mijn PC heeft kan dan ook direct met deze code toegang krijgen. Wat zie ik over het hoofd?

 
Written by FSchiphorst on 17-02-2010 20:39
 
 
Dat ze de volgende kode niet kunnen pikken. Ze hebben alleen de sessie die actief is maar niet automatisch de volgende. Ook kunnen ze de eenmalige kode niet elders gebruiken om een nieuwe sessie op te zetten omdat ze niet bij het token kunnen komen. Metd e door jou voorgestelde methode is het mogelijk om bij het token te komen.

 
Written by This e-mail address is being protected from spam bots, you need JavaScript enabled to view it on 17-02-2010 22:54
 
 
We kunnen dus ten minste vaststellen dat ook het hardware token niet bestand is tegen keylogging. Overigens kan de kwaadwillende de volgende keer gewoon hetzelfde trucje uithalen. Daarnaast denk ik dat er nog wel een extra trucje bedacht kan worden om de tokenplace nog veiliger te krijgen zonder de gebruiker al te veel te belasten. Daarnaast hebben hardware tokens een extra risico ('even lenen') dat bij de tokenplace niet aanwezig is. Als iemand - vaak iemand uit de omgeving van het slachtoffer - echt kwaad wil (heel gericht op een specifiek individu) dan zijn beide methoden dus niet waterdicht; alleen heb je met de virtuele tokenplace niet de problemen 1 t/m 5.

 
Written by This e-mail address is being protected from spam bots, you need JavaScript enabled to view it on 19-02-2010 13:45
 
 
Beste Erik, 
 
Laten we even terug gaan naar de reden waarom mensen überhaupt tokens uitgereikt krijgen. Tokens worden gebruikt voor 2-factor authentication. Authenticatie (wie is iemand) kan gebaseerd zijn op iets dat je weet (pincode, wachtwoord, de plaats waar je auto staat, of iets anders dat alleen jij weet), iets dat je hebt (een pinpas, een sleutel, toegangspas, RFI chip of een token) en/of iets dat he bent (vingerafdruk, isris scan, stemherkenning). 
In de security theorie is de stelling dat de security verbetert als er van tenminste 2 factor authenticatie ebruik wordt gemaakt (dus bijvoorbeeld een username/password en een token). Nog beter is een 3-factor authentication (én username/password, én token én een iris scan).  
Jouw voorstel zorgt ervoor dat je van een 2-factor authentication (iets wat je weet en iets wat je hebt) teruggaat naar een 1-factor authentication (iets -of meerdere dingen- dat je weet). Dit verlaagt per definitie de sterkte van de authenticatie. 
 
Overigens geef ik mijn huisleutel nooit aan iemand weg - ook niet tijdelijk - , en aan diezelfde sleutelbos zit ook mijn token. Ik geeft ook mijn password aan niemand weg (zo laat ik anderen ook niet mijn tandenborstel gebruiken). 
 
Met vriendelijke groet, 
 
Sjaak Laan CISSP 
www.sjaaklaan.nl

 
Written by This e-mail address is being protected from spam bots, you need JavaScript enabled to view it on 19-02-2010 21:34
 
 
Beste Sjaak, 
 
Dank voor je reactie. 
 
Kun je aangeven waar precies mijn alternatieve oplossing minder veilig is dan het hardware token dat random geheime codes genereert die je vervolgens in moet toetsen op een website? Want dat is waar we het hier over hebben. De theorie van multi-factor authenticatie is mij bekend maar ik heb het over een specifieke - veel gebruikte - implementatie (dus geen afdrukken van vingers of scans van ogen en ook geen pas die je door een reader in een gesloten circuit moet halen). 
 
Voor wat betreft de sleutelbos met de huissleutel. Er is een verschil tussen iemand - bijvoorbeeld een wildvreemde - die je je sleutelbos geeft en bijvoorbeeld je partner. Ik durf te wedden dat de sleutelbos van de gemiddelde huiseigenaar - want beveiliging maak je niet voor degene die zich overal keurig aan houden - regelmatig even geleend wordt aan de partner. En als er aan die sleutelbos bijvoorbeeld ook nog een autosleutel hangt dan is dat ook weer anders (zeker als de auto door beide partners wordt gebruikt). Het is niet de bedoeling om tokens even uit te lenen, maar het feit is dat een hardware token geleend kan worden of gestolen. In mijn oplossing heb je daar geen last van (dus op dat punt veiliger en praktischer). 
 
Ik zie uit naar je reactie op met name het eerste punt. 
 
Groet, 
Erik

 
Written by FSchiphorst on 24-02-2010 10:14
 
 
Het volgende password van het token is niet te voorspellen als iemand de plaats van de online token weet dan is het volgende password wel te voorspellen bv doro schoulder surfing of doordat het te vinden is aan de hand van key en screen logging 
Als iemand weet waar hij moet kijken dan kom ik daar nooit achter todat de fraude opvalt. 
Als mijn token weg is dan merk ik dat. 
 
Zodra iemand weet waar de token auto geparkeerd is dan kunnen ze zoveel keys/sessies genereren als ze willen (vanuit moldavie of wit rusland) 
 
Zodra ze mijn token password online hebben gejat hebben ze alleen die ene sessie te pakken en kunnen ze geen nieuwe sessies opstarten. 
 
Als ik op een ander pc (die niet gehacked is) ga werken is jouw oplossing nog steeds gehacked maar de token oplossing is weer veilig voor de sessie die opgestart is. 
 
Uiteindelijk is jouw oplossing een oplossing voor mensen die te lui zijn om hun token goed te beveiligen. En dan maakt het niet uit wat het token is of waar het staat, het kan altijd uitgeleend worden waarbij in jouw oplossing er een optie zou moeten bestaan om de "auto" ergens anders te parkeren (wat dan nog steeds niet veilig is)

 
Written by This e-mail address is being protected from spam bots, you need JavaScript enabled to view it on 25-02-2010 23:21
 
 
Er zijn eenvoudig aanvullende maatregelen te bedenken om het risico dat je aangeeft tot een minimum te beperken. Maar laat ik eerst wederom vaststellen dat beide oplossingen niet bestand zijn tegen zaken als keylogging / screen logging / shoulder surfing. Dat er vervolgens nog verschillen (kunnen) zijn is dan al enigzins een discussie in de marge; binnen is binnen (in korte tijd kan er veel schade worden aangericht). 
 
Je wijst er terecht op dat zonder aanvullende maatregelen de kwaadwillende die de parkeerplek van het virtuele token heeft weten te acherhalen vaker naar binnen kan. Maar daar zijn wel enkele eenvoudige maatregelen voor te treffen: 
i) de optie om de auto regelmatig elders te parkeren (zo werkt het bij de Efteling ook) 
ii) bij het aanloggen altijd een melding van de laatste keer dat je hebt - proberen - aan te loggen. Eventueel met een extra vinkje en eventueel ook nog met een expliciete waarschuwing als het om een verdachte inlogpoging gaat (bv. van een verdacht ip-adres of op een ongebruikelijk tijdstip) 
iii) na drie foute inlogpogingen blokkeren (voor het geval er toch nog een gok element inzit) 
iv) na succesvol aanloggen een berichtje sturen (bijvoorbeeld een sms-je, maar een mailtje aan het einde van de dag is wellicht te verkiezen) 
 
Maatregel iv) lijkt me persoonlijk een beetje overkill. Maatregelen i), ii) en iii) zijn kosteloos en eenvoudig. 
 
Je redenatie over mensen die te lui zijn is op de eerste plaats een argument tegen beide oplossingen. Maar - minsten zo belangrijk - het is een onjuist argument. Beveiliging die is afgestemd op minder oplettende mensen is de facto veiliger dan beveiliging die vereist dat mensen goed op moeten letten. Denk maar eens aan het tanken van de verkeerde brandstof (de ANWB heeft jaarlijks meer dan 23.000 gevallen van verkeerde brandstof). Als dieselrijder stoor ik me aan het gegeven dat de beveiliging in eerste aanleg is bedacht voor benzinerijders. Helemaal irritant is de inconsequente kleurcodering bij Shell, een groene lip - de kleur die hoort bij benzine - over het vulpistool van de dieselpomp. Inmiddels rust BMW haar dieselauto\'s uit met een ‘slot’ in de tankopening dat alleen open gaat voor een standaard diesel vulpistool, dat een grotere diameter heeft dan bij benzine.

 


 

Via Nova Architectura is not responsible for the content of blogs, but authors and readers are asked to adhere the following guidelines. Authors are strongly encouraged to check facts, cite sources, present balanced views, acknowledge and correct errors. Respect copyright, fair use and financial disclosure laws. Please do not disparage organizations, or individuals. Being critical of someone's practice is acceptable, when it is done in a professional manner. Prevent usage of marketing statements. Comments should be relevant to the specific post they are attached to. Spam, flaming, personal attacks, and off-topic comments are not permitted. Readers are requested to notify This e-mail address is being protected from spam bots, you need JavaScript enabled to view it of any violations. The editor holds the right to remove any statements that, in the editors opinion, infringe the above guideline(s). The author receives a notification of this action.