[authentication] ontwerp

[Bint]

Dag,

ik ben bezig met het ontwerpen van een kleine authenticatie module, en het moet ongeveer als volgt werken:

server genereert een key als een client connectie maakt

iemand gaat aan de client werken, en wil voor een uurtje (bijvoorbeeld) wat meer acces. Hij stuurt mij een mail, en ik voeg in een programmatje het volgende in:
- key
- userlvl
- tijd

Aan de hand daarvan moet een password worden gegenereerd. De gebruiker ontvangt dat password, en vult het in. Gaat weer naar de server, en de server haalt dat password door een functie, die het password, tijd en userlevel kan achterhalen. de server stelt dan een timer in dat de sessie geldig is, en een gebruikerslevel.

Nu kan het best zijn dat dit helemaal niet veilig is, maar het lijkt mij goed genoeg voor in onze applicatie hier. Nu wilde ik vragen: zijn er functies die ik hiervoor goed kan gebruiken, of zijn er technieken die ik maar eens goed moet gaan bestuderen? Of hebben jullie tips voor mij om dit te realiseren? Kritiek op dit mechanisme is natuurlijk ook goed betere ideeen zijn altijd welkom

[ Voor 4% gewijzigd door Bint op 25-04-2006 11:46 . Reden: nog wat info toegevoegd ]

[MicroWhale]

Soap webservices hebben sessies. Elke sessie is uniek en hieraan kun je dus je user-info hangen.

Je kunt daar bovenop via een standaard-authorization met users werken. Als je dit op een goede manier wilt doen, kun je hierbij de Active Directory raadplegen en om het windows-wachtwoord vragen.

Hierbovenop kun je dan weer je eigen authorisaties leggen als je wilt.

[Bint]

probleem is dat het niet via AD en niet via webservices gaat gebeuren

zijn 2 programma's die op 2 pc's met elkaar staan verbonden, and that's it. Dus 1 kabeltje ertussen, voor de rest niet aan internet ofzo..

[ Voor 50% gewijzigd door Bint op 25-04-2006 12:00 ]

[Rukapul]

Het mechanisms wat je voorstelt is gebaseerd op assertions (claims/credentials/...). Jij genereert een assertion, de client presenteert de assertion en de server interpreteert de assertion en past z'n authorizaties voor de client aan.

Normaal gesproken creeer je een assertion door een signature over de data te zetten. In jouw geval is dat userlvl en de tijd. (NB: het precise doel van de 'key' die je noemt is me niet geheel duidelijk. Dient deze om een sessie te bepalen? Is it werkelijk een cryptografische sleutel die gebruikt wordt voor encryptie/authenticatie?)

Een assertion is normaal iets anders dan een 'password'.

Met betrekking tot praktische aspecten:
- hoe groot mag de assertion ('password') zijn en moet deze door een mens over te typen zijn?
- een handtekening kan met een public/private keys, maar ook met een eenvoudig symmetrisch algoritme en een gedeelde sleutel tussen jou en de server applicatie.

[joopst]

misschien heb je hier wat aan.

[whoami]

-> SE&A

[RobIII]

joopst schreef op dinsdag 25 april 2006 @ 12:12:
misschien heb je hier wat aan.

Dat heeft er totaal niets mee van doen Encryptie != Authenticatie
Het verhaal van Rukapul is echter spot-on en TS zal wat meer moeten uitwijden over wat hij nu precies bedoelt.

[ Voor 4% gewijzigd door RobIII op 25-04-2006 12:21 ]

[Bint]

Ok, ik zal het proberen duidelijk te maken.
Waar ik stage loop, maken we stukken software.

een deel van die software stuurt hardware aan, andere software zorgt voor de proces controle e.d.
Nu heb ik een tooltje gemaakt, dat gemakkelijk veel, heel veel informatie uit die hardware kan trekken, voor debugging.

Nu willen wij niet dat iedereen dat zomaar kan gebruiken, en alleen wat basis functionaliteit kan gebruiken. Maar ooit moeten ze wel iets meer kunnen.

En daar komt het verhaaltje kijken wat ik had bedacht. Voor elke keer dat iemand connectie maakt, wordt er een random sleutel gegenereerd op de server

die wordt mee naar de client verzonden. Degene op de client mailt//belt die key door, en wij zorgen er voor dat hij een "password" krijgt zodat hij bij die extra functionaliteit kan.

Dat password wordt ingevoerd, en naar de server verzonden. Nu kan de server aan de hand van het password afleiden hoe lang, en op welk userlevel diegene mag werken.

Ik hoop dat ik zo duidelijker ben

[Bint]

Rukapul schreef op dinsdag 25 april 2006 @ 12:10:
Het mechanisms wat je voorstelt is gebaseerd op assertions (claims/credentials/...). Jij genereert een assertion, de client presenteert de assertion en de server interpreteert de assertion en past z'n authorizaties voor de client aan.

Normaal gesproken creeer je een assertion door een signature over de data te zetten. In jouw geval is dat userlvl en de tijd. (NB: het precise doel van de 'key' die je noemt is me niet geheel duidelijk. Dient deze om een sessie te bepalen? Is it werkelijk een cryptografische sleutel die gebruikt wordt voor encryptie/authenticatie?)

Een assertion is normaal iets anders dan een 'password'.

Met betrekking tot praktische aspecten:
- hoe groot mag de assertion ('password') zijn en moet deze door een mens over te typen zijn?
- een handtekening kan met een public/private keys, maar ook met een eenvoudig symmetrisch algoritme en een gedeelde sleutel tussen jou en de server applicatie.

Het klinkt interessant, en is denk ik, voor zover ik het begrijp, wel zoiets als ik wil.
Het password mag niet te groot zijn, omadt het moet worden overgetikt door een mens (dit omdat de machine niet aan het netwerk hangt).

Is het zo ook mogelijk een file met een key te gebruiken, die tot een bepaalde tijd geldig is?
bijvoorbeeld een textfile met een sterk ge-encrypte sleutel erin, die op bovenstaande manier een eindtijd//datum bevat ofzo?

[Rukapul]

Die random sleutel zou ik een challenge of sessie-id noemen.

De response is vervolgens de assertion. De server mag deze overigens maar eenmalig accepteren.

Een nette oplossing zou de assertion kunnen definitieren als { DATA, MAC} waarbij DATA gedefinieerd is als { challenge, userlevel, validitytime, randomnonce* } en MAC (message authentication code) gedefinieerd is als HMAC-SHA1{ DATA, secretkey}, waarbij secretkey bekend is bij de server en bij degene/applicatie die de assertion uitgeeft. Het probleem is dat DATA >100 bits groot kan zijn is en MAC in dit voorbeeld 160 bits. Indien we het hexadecimaal representeren dan is dat dus al gauw zo'n 64 karakters, wat iets te lang is om per telefoon door te geven. Door DATA klein te houden en een ander algoritme voor de MAC te kiezen kan het kleiner.

Een aanpak die hier wellicht het meest geschikt is is het volgende: houd DATA klein (bv 128 bits, precies 1 block) en encrypt data met secretkey (bv AES). Zodoende beperk je het tot 128 bits, wat hexadecimaal neerkomt op 32 karakters.

(* ivm choosen plaintext, etc.)

[ Voor 6% gewijzigd door Rukapul op 25-04-2006 15:51 ]

[Bint]

zou je misschien nog meer info kunnen geven over die assertions? klinkt heel interessant namelijk, ben ook al op zoek geweest, maar misschien heb je nog handige links

[Rukapul]

In principe is een assertion niet meer dan een claim door een partij dat een bepaald statement waar is. Informatie over assertions vind je bijvoorbeeld hier. Dat wikipedia gaat in op de meest relevante standaard mbt assertions: Security Assertion Markup Language (SAML).

In dit geval praten we over een zgn authorisatie assertion. De applicatie/persoon die de assertion maakt geeft de gebruiker/client een authorisatie, namelijk het mogen uitvoeren van functies op de server op een bepaald level gedurende een bepaalde tijd. De server accepteert alleen assertions die gemaakt zijn door de applicatie die de assertion maakt. Dit wordt afgedwongen door een geheime sleutel te gebruiken.

Laat bovenstaand Wikipedia artikel je niet van de wijs brengen. Assertions als concept hoeven niet ingewikkeld te zijn. De standaarden zoals SAML zijn slechts complex door de vele opties die ze bieden.

In dit geval doe je er goed aan om slechts het concept te snappen. Vervolgens maak je je eigen eenvoudige realisatie om aan de andere ontwerpeisen te voldoen. SAML zelf kun je niet gebruiken omdat het te groot wordt om telefonisch door te geven, o.a. omdat er gebruik gemaakt wordt van XML encoding.

[Bint]

bedankt, ik ga dat eens bekijken..

leuk leesvoer voor nu