Authenticatie dmv Tokens

[Spockz]

Gebruikers hebben bij ons een account, op de site kunnen ze inloggen dmv een username/emailadres en password. Nu gaan wij ook een client uitbrengen. Aangezien het niet handig is om wachtwoorden in plaintekst op te slaan en wij iets meer controle willen, en we ook willen dat als er geen verbinding is ze nog steeds zijn ingelogd hebben had ik het volgende bedacht:

Alle communicatie verloopt via SSL.

1. User opent de login dialoog in onze client
2. User vult zijn username en wachtwoord in, dit wordt opgestuurd naar de server
3. Server checkt deze gegevens en maakt een token aan. Dit token bestaat uit een bepaalde random string dat de daadwerkelijke access key is en uit accountinfo van het account waar net mee ingelogd is. De token is gesigned met het private cert van ons dat alleen op de server staat
4. De client ontvangt het token, checkt of de signature goed is en zo ja dan wordt de token opgeslagen en gebruikt.

De reden dat we gebruikers ingelogd willen houden is dat we willen dat persoonsgebonden instellingen actief blijven.

Nu is mijn vraag, zie ik hier nog een beveiligingsprobleem over het hoofd of is dit nodeloos ingewikkeld? De signing is ervoor om te zorgen dat een grappenmaker niet de naam/emailadres kan veranderen in iets wat niet hoort bij de access key.

[Verwijderd]

Signen is zinloos. Je moet geen informatie op de client opslaan en die vertrouwen. Sla dat op de server op en gebruik die unieke token om de data weer op te vragen.

Dit is natuurlijk gewoon een session cookie, niet meer en niet minder.

[Spockz]

En hoe kan je die gegevens opvragen als je offline bent? We kunnen de token ook opslaan in ons licentiebestand, dat maakt het dat de token niet zomaar meer aan te passen is zonder dat de licentie ongeldig wordt. Het idee is wel dat dat licentiebestand moeilijk aan te passen is.

[Verwijderd]

Ik geloof niet dat ik het hele doel begrijp. Als er gebruikersinstellingen moeten worden bewaard, ook offline, horen ze van de server te worden gedownload. Als de gebruiker offline instellingen moet kunnen wijzigen dan is dat op zich prima, maar moeten ze worden gesynchroniseerd zodra de gebruiker weer online is.

Dan kun je prima een token of session cookie (in welke vorm dan ook) op de client bijhouden en die gebruiken om het profiel op te vragen zodra de gebruiker online is. De rest van de gegevens hoort gewoon op de server te staan. Ik zie niet in waarom de gebruiker bijvoorbeeld zijn eigen emailadres nodig heeft in een bestand met preferences, als hij dat niet zou mogen wijzigen.

Login => User krijgt token, profiel wordt gesynchroniseerd met lokaal bestand
User wijzigt instellingen => profiel wordt gesynchroniseerd met lokaal bestand
User gaat offline
User wijzigt instellingen => lokaal bestand wordt aangepast als zijnde voorlopige instellingen
User gaat online => Server zoekt user bij token, profiel wordt vergeleken met lokaal bestand, nieuwe instellingen worden één voor één doorgegeven aan de server en gevalideerd, daarna wordt het profiel gesynchroniseerd

Maar ik begrijp niet zo goed wat het voor client is, wat er offline gewijzigd moet worden, etcetera. Maar alles wat een client offline doet is eigenlijk een soort job queue, zodra je online gaat moet die worden uitgevoerd en stuk voor stuk gevalideerd.

Het is erg lastig om dit goed te doen bij ingewikkelde taken, omdat je nog geen resultaat hebt van de daadwerkelijke acties. Een beveiligingsprobleem kun je nooit hebben als de token niet te raden is, de server geen informatie stuurt die de client niet kan raden, en de client geen informatie mag wijzigen als dat niet eerst gevalideerd is (op correcte inhoud en voldoende permissies).

[Spockz]

De client geeft op het moment de toegang tot twee onderdelen:

1. Projectbeheer
2. Documentatie

Bij projectbeheer kun je denken aan een iets uitgebreidere variant van projectbeheer uit Visual Studio/Eclipse etc. Documentatie is documentatie van ons programma. Elk gedeelte heeft zo account gerelateerde instellingen. Wijzigingen in Projecten worden ook bijgehouden aan de hand van wie is ingelogd.

De reden waarom we de usergegevens offline beschikbaar willen hebben is zodat men zonder verbinding met onze server deze functionaliteit kan blijven gebruiken. De reden voor het gebruik van een token is zodat de username en password niet elke keer over de lijn hoeven en er makkelijk gelogged kan worden per bijv. locatie (elke token krijgt een locatie/comment toegewezen, net zoals hier op t.net). Het signen is dus om er zeker van te zijn dat de token ook daadwerkelijk bij de gebruikersnaam/naam/emailadres hoort die is opgeslagen.

Edit: Ik bedenk mij net dat het signen niet nodig is als het licentiemechanisme inderdaad zoals we aannemen het bewerken van de token onmogelijk maakt.

[ Voor 14% gewijzigd door Spockz op 03-03-2012 22:51 ]

[thegve]

Ik snap, volgens mij net als de rest hierboven, nog niet exact wat je probeert te bereiken, maar volgens mij wil je zoiets.

*Online*
Stap 1 en 2 zoals jij omschrijft, vervolgens word er een check-sum teruggeven van een "dump" van de informatie die in je online systeem staat. Dit vergelijk je met je lokale kopie, als deze niet gelijk aan elkaar zijn, download je een nieuw exemplaar van je applicatieserver, deze applicatieserver zorgt er eerst voor dat deze is geencrypt met een wachtwoord. Dit sla je op in een structuur naar keuze, bijvoorbeeld een sqlite database, access database, of een xml bestand.
Wat technisch hiervoor het handigst is kan je vast elders wel uitzoeken.

*Off-line*
Je client constateerd dat hij geen verbinding krijgt met de applicatieserver, of de gebruiker kiest ervoor om off-line te werken. Dan de-crypt je gewoon het lokale bestand met behulp van de gebruikersnaam + wachtwoord.

Dit is wat ik begrijp dat je ongeveer wilt bereiken. Wat ik niet snap is wat je in gedachten hebt bij je verwijzing naar "wachtwoorden in plain text opslaan" en "ook als er geen verbinding is ze nog steeds ingelogd hebben".
Dit laatste kan sowieso niet, inloggen houd in dat je ergens op inlogged, als hetgeen waar je op wilt inloggen niet bereikbaar is, valt er weinig in te loggen.

Volgens mij maak je inderdaad zaken nodeloos ingewikkeld, en je moet anno 2012 wel een hele specifieke case hebben wil het uit kunnen om veel tijd te steken in het off-line bereikbaar maken van je applicatie.
Eventueel zou je nog kunnen kijken wat er mogelijk is met HTML5 Offline storage, als afhankelijkheden van hele moderne browsers geen probleem is. Hier heb ik verder nog geen ervaring mee.