Best way to encrypt?

[Storm90]

Hallo,

Ik ben bezig met een webbased ticket service programma die beschikt over een inlogsyteem. Voor het inlogsysteem wou het bedrijf (waarvoor ik het programma maak) wou graag gebruik maken van cookies ipv sessies, dus doen we dat maar he. Het probleem is nu echter dat alles wat in de cookies opgeslagen wordt moet worden gecodeerd voor de veiligheid. Ik de data nu mbv SHA1 en het werkt goed, passwords zijn gecodeerd en dus niet meer uit te lezen.

Nadat men is ingelogd worden de gegevens in de cookie ge-explode naar variables.

Echter is nu het probleem dat er ook variables worden opgeslagen waarin staat wat voor soort gebruiker het is, als ze deze kunnen veranderen, kunnen ze worden ingelogd als bv. beheerder. De makkelijkste oplossing is om deze te coderen (Ik kan ook erg vreemde getallen gebruiken maar daar komen ze op een gegeven moment toch wel achter).

Maar wat is dus het grote probleem met bovenstaande, ik kan de codes niet meer decoderen... Oftewel ik krijg erg rare namen als ik een variable echo. Nu kan ik alles gaan vergelijken met de database ipv ze in een cookie te stoppen, maar dat is zoveel werk om elke keer weer een connectie naar de database te maken (bovendien niet zo'n perfecte oplossing).

Iemand die een betere oplossing weet?

Erik

[ Voor 4% gewijzigd door Storm90 op 27-03-2009 13:36 ]

[crisp]

Waarom zou je een wachtwoord willen opslaan in een cookie? Het enige wat je in een cookie hoeft te stoppen is een unieke identifier voor de sessie waarmee je serverside de benodigde data weer kan ophalen.

maar dat is zoveel werk om elke keer weer een connectie naar de database te maken

dat doen wij niet anders hoor...

[ Voor 23% gewijzigd door crisp op 27-03-2009 13:36 ]

[OkkE]

Storm90 schreef op vrijdag 27 maart 2009 @ 13:34:
Hallo,

Ik ben bezig met een webbased ticket service programma die beschikt over een inlogsyteem. Voor het inlogsysteem wou het bedrijf (waarvoor ik het programma maak) wou graag gebruik maken van cookies ipv sessies, dus doen we dat maar he.

Nee.

In zo'n geval ga je met de opdrachtgever praten, vraag je waarom ze cookies willen ipv sessies, leg je de voor- en nadelen uit, en maak je samen een beslissing op basis van de wensen en behoeftes van de klant.

Iemand die een betere oplossing weet?

Met de klant overleggen aan welke technische- en veiligheidseissen het product moet voldoen, op basis daar van kiezen welke techniek het beste is voor het opslaan/bijhouden van de gegevens.

[Storm90]

Ja klopt, maar ik dacht dat het een foute oplossing zou zijn door continue weer verbinding te maken met de server om gegevens op te halen. Maar domme vraag ook, ik zou de connectie op de index.php kunnen plaatsen en dan alles op slaan in variables..,Sorry en nog bedankt voor je reactie

[disjfa]

Als je een website ophaalt, maak je toch altijd al connectie met de server

[Storm90]

@Okke: Ja ik heb het maar kort samengevat, we hadden er een tijd over gediscussieerd natuurlijk, ik vond persoonlijk sessies bezig aangezien een gebruiker tijdens het afsluiten van de browser kan vergeten uit te loggen... Hun vonden cookies beter omdat het toch maar een klein bedrijf is, alles lokaal wordt gehouden en het is "maar" een ticket service programma (dus om je vragen en problemen te posten), bovendien zijn cookies wat handiger als je kijkt naar dat de gebruiker steeds opnieuw moet inloggen als hij/zij de browser sluit. Uitendelijk zijn we voor cookies gegaan.

[disjfa]

Storm90 schreef op vrijdag 27 maart 2009 @ 13:45:
Uitendelijk zijn we voor cookies gegaan.

Mag ik vragen welke variabalen je allemaal in het koekje aan het stoppen bent?

[Storm90]

* myReactBekijk myReact van disjfa
* galleryBekijk de gallery van disjfa
* Direct MessageStuur een bericht naar disjfa
* homepageBezoek homepage van disjfa

Berichten: 24.998
Reg. datum: 10 april 2001
Als je een website ophaalt, maak je toch altijd al connectie met de server

Ik wil de pagina zo snel mogelijk houden en denk dat het sneller gaat als je zo min mogelijk connectie hoeft te maken met de server, lijk mij dan.. Maar veiligheid gaat voorop, dus ik ga dan maar voor de oplossing om alleen het userid in de cookie te stoppen.
@disjfa: soort gebruiker, voornaam, achternaam, username en gecodeerd password mbv sha1

[ Voor 76% gewijzigd door Storm90 op 27-03-2009 13:52 ]

[RobIII]

Storm90 schreef op vrijdag 27 maart 2009 @ 13:48:
@disjfa: soort gebruiker, voornaam, achternaam, username en gecodeerd password mbv sha1

Dan wijzig ik mijn cookie dus even en ben ik een "ander soort gebruiker"; admin bijvoorbeeld?
This is clearly not the way to go

[Gé Brander]

Storm90 schreef op vrijdag 27 maart 2009 @ 13:45:
bovendien zijn cookies wat handiger als je kijkt naar dat de gebruiker steeds opnieuw moet inloggen als hij/zij de browser sluit. Uitendelijk zijn we voor cookies gegaan.

Maar op Tweakers hoef ik toch ook niet steeds mijn wachtwoord opnieuw in te vullen, en wordt mijn wachtwoord toch ook niet in een cookie opgeslagen? Dus dat is geen argument wat je nu geeft.

[Storm90]

Dan wijzig ik mijn cookie dus even en ben ik een "ander soort gebruiker"; admin bijvoorbeeld?
This is clearly not the way to go

Nee dat klopt, daarom opende ik deze topic, zie mijn eerste post.

[disjfa]

Storm90 schreef op vrijdag 27 maart 2009 @ 13:54:
[...]
Nee dat klopt, daarom opende ik deze topic, zie mijn eerste post.

Dus wat ga je nu doen en wat heb je al aangepast na aanleiding van de eerste post van crisp?

[Storm90]

Dus wat ga je nu doen en wat heb je al aangepast na aanleiding van de eerste post van crisp?

veiligheid gaat voorop, dus ik ga dan maar voor de oplossing om alleen het userid in de cookie te stoppen.

Laatste vraag, iemand vertelde mij eerder dat je sessies terug kan halen van de server zelfs nadat de browser opnieuw is gestart?? Klopt dit? Is die mogelijkheid er?

[ Voor 4% gewijzigd door Storm90 op 27-03-2009 13:59 ]

[disjfa]

Storm90 schreef op vrijdag 27 maart 2009 @ 13:59:
[...]
veiligheid gaat voorop, dus ik ga dan maar voor de oplossing om alleen het userid in de cookie te stoppen.

Dus als ik deze zou aanpassen naar die van mijn buurman, dan ben ik ingelogd als mijn buurman?

[Rukapul]

RobIII schreef op vrijdag 27 maart 2009 @ 13:52:
[...]

Dan wijzig ik mijn cookie dus even en ben ik een "ander soort gebruiker"; admin bijvoorbeeld?
This is clearly not the way to go

In theorie kan het wel: combineer soort-gebruiker met hashed-pw (en evt. nog meer zooi) als een geheel en encrypt (bv AES in CBC mode) dat en voeg een message authenticatie code toe (bv HMAC-SHA1, of liever nog HMAC-SHA256).

Encryptie en MAC moeten berekend worden met een sleutel die alleen bij de server bekend is. De integrity code zorgt dat soort-gebruiker niet zomaar aangepast kan worden of 'geleend' kan worden van een andere gebruiker (cookie stealing is equivalent aan inloggen als andere gebruiker of password sharing dus wat dat betreft worden geen nieuwe risico's geintroduceerd). De encryptie zorgt ervoor dat de confidentiele info geheim blijft.

Aan de andere kant: er zijn eenvoudigere oplossingen

BTW: een hashfunctie als SHA1 is geen encryptie

[ Voor 6% gewijzigd door Rukapul op 27-03-2009 14:04 ]

[Storm90]

Dus als ik deze zou aanpassen naar die van mijn buurman, dan ben ik ingelogd als mijn buurman?

haha klopt, dom van mij, met encrypt password dan

[Osiris]

Storm90 schreef op vrijdag 27 maart 2009 @ 14:01:
[...]

haha klopt, dom van mij, met encrypt password dan

Euhm, en wat voor nut heeft het encrypted password in de cookie dan? Verifieer je met dat password en het password in je DB steeds of de gebruiker wel de 'echte' is?

Zo ja, dan kun je toch net zo goed Session-ID's gebruiken?

[jbdeiman]

De oplossing is hier eigenlijk al gegeven:

Je genereert aan de hand van een aantal gegevens (bijv een combinatie van userid/ name, inlogtijd (microtime()) en een eigenbedachte hash) een code, deze codeer je met SHA1 en deze sla je op in een cookie. Daarbij sla je deze hash ook op in een tabel in je database, samen met: userid, computergegevens als (ip/ browser etc, zodat vervalsen al lastiger wordt).

Bij opnieuw terugkomen kijk je dus of het cookie bestaat, ga je kijken of er de gegevens bekend zijn in je database (met sessies) voor een bepaalde sessiecode zoals ik in de omschrijving hierboven aangaf. Bestaat die, vergelijk dan evt. (indien gewenst) de computergegevens (als je die toevoegt) en indien alles ok: laat de user inloggen op zijn tickets.
Dit is al een stuk veiliger, iemand zou die cookie kunnen kopiëren, maar dat risico loop je altijd. Beste is wel sessies, evt. met een cookie, maar de eigenlijke controle via een sessie.

[Urlax]

je wilt een snelle site;

zelf heb ik ook iets moeten maken voor de zaak, en had 2 koekies:

gebruikersnaam

gehasht wachtwoord+salt.

vervolgens doe je een join op basis van de gebruikersnaam met de tabel met gebruikersrechten en de tabel met (gehashte) wachtwoorden, en als hebt één array met wat je wilt weten over die gebruiker.
je checkt of de wachtwoorden overeenkomen, en je bent klaar.

(evt. kun je ook het IP in de salt toevoegen, zodat de cookies niet transferable zijn. expiry kun je zelf verzinnen)

[Gersomvg]

Ik bouw toch geen websites met een ontzettend groot publiek dus ik doe meestal het volgende (ik gebruik nog ouderwets md5):

PHP:

$user[id] = 234;
$user[nickname] = 'pietje';
$user[password] = 'geheim';

$verification = md5( $user[nickname].$user[password] );

setcookie('login_onthouder', $user[id].'-'.$verification, time()+60*60*24*100);

Dat resulteert in zoiets:

code:

234-lljkOI235tkvVK83Dfv4

Vervolgens indien er geen sessie is kijken of er een cookie is. Splitten op streepje en sessievars van maken waarna je deze controleert

[Storm90]

Ik heb weer een gesprek gehad met de programmeurs van Barcelona-Home en ik heb de oplossing van jbdeiman voorgesteld, zij vinden (net als ik overigens) dat de beste oplossing. Het is erg veilig en alles wordt ook nog eens netjes in een database opgeslagen en die gegevens kunnen we weer gebruiken om te controleren wie er heeft ingelogd e.d.

Natuurlijk hebben we het idee om te kijken wie er online is, wel verder uitgewerkt met responsetijd (tijd wanneer ze voor het laatste ergens op hebben geklikt) e.d. Zodat we zo nauwkeurig mogelijk kunnen zien wie er nog online is en een cronjob die ieder uur controleert bij wie de responstijd langer dan (laten we zeggen) 10 minuten heeft geduurt, die gooien wij uit de database en dus werkt de cookie ook niet meer.

Dit moest erbij aangezien we het zo kunnen maken dat de cookies worden verwijdert nadat men uitlogt e.d. Maar indien men de cookies handmatig verwijdert krijg je weer problemen vandaar. Naast de cronjob stoppen we ook een kleine functie in de index pagina die nogmaals controleert welke records zijn verlopen.

Bedankt voor jullie reacties!
Ik heb er weer wat van geleerd

[ Voor 3% gewijzigd door Storm90 op 27-03-2009 15:34 ]

[Tarilo]

Het is nogal logisch dat je een wachtwoord niet kan decrypten. Dat is het hele idee achter encryptie.

[Cartman!]

Uh...tuurlijk kun je iets wat je encrypt ook weer decrypten. Wellicht ben je in de war met hashing?

[Tarilo]

Inderdaad in de war met hashing. Maar wachtwoorden hash toch ook meestal? en die encrypt je niet lijkt mij.

[mocean]

Storm90 schreef op vrijdag 27 maart 2009 @ 15:30:
Ik heb weer een gesprek gehad met de programmeurs van Barcelona-Home en ik heb de oplossing van jbdeiman voorgesteld, zij vinden (net als ik overigens) dat de beste oplossing. Het is erg veilig en alles wordt ook nog eens netjes in een database opgeslagen en die gegevens kunnen we weer gebruiken om te controleren wie er heeft ingelogd e.d.

Natuurlijk hebben we het idee om te kijken wie er online is, wel verder uitgewerkt met responsetijd (tijd wanneer ze voor het laatste ergens op hebben geklikt) e.d. Zodat we zo nauwkeurig mogelijk kunnen zien wie er nog online is en een cronjob die ieder uur controleert bij wie de responstijd langer dan (laten we zeggen) 10 minuten heeft geduurt, die gooien wij uit de database en dus werkt de cookie ook niet meer.

Dit moest erbij aangezien we het zo kunnen maken dat de cookies worden verwijdert nadat men uitlogt e.d. Maar indien men de cookies handmatig verwijdert krijg je weer problemen vandaar. Naast de cronjob stoppen we ook een kleine functie in de index pagina die nogmaals controleert welke records zijn verlopen.

Bedankt voor jullie reacties!
Ik heb er weer wat van geleerd

Je wilde geen sessies (standaard functionaliteit in veel programmeer talen), maar nu ga je zelf een sessie systeem ontwikkelen