[php] Wachtwoord opslaan in cookie, kan dit veiliger?

[RetroTycoon]

Heey,

In andere posts heb ik weleens aangegeven dat ik voor Wrts een Wrts-importeerdingetje heb gemaakt (zie ook: RetroTycoon in "[Alg] Welke tools heb jij gemaakt? - dee...") en daarbij gebruik ik de Wrts-api. Deze vereist bij gebruik een verbinding via http die zichzelf met basic authentication verifieert. Nu is het probleem dat het wachtwoord van de gebruiker ergens moet worden opgeslagen, op een veilige manier, maar wel un-encrypted (omdat het origineel voor de verbinding dus nodig is). Op dit moment laat ik het wachtwoord in de sessie stoppen, maar dat is (lijkt mij) niet de veiligste methode. Dus kan dit beter, en op welke manier is dat dan te realiseren? Ikzelf wil liever niet het wachtwoord niet zelf hebben, omdat ik dan 'de schuldige' kan zijn, en dat natuurlijk ook niet echt bevorderlijk is voor het gevoel dat het allemaal veilig is

Dank alvast aan alle mensjes voor hun fantastische (nog te komen) antwoorden

[Gersomvg]

Ik doe altijd

PHP:

$cookie = $userID.'-'.md5($userNickname.$userPassword);

Dan krijg je zoiets in je cookie:

1-098f6bcd4621d373cade4e832627b4f6

Als je vervolgens bij controle gewoon de cookie explode() op een streepje en dan de rij uit de database haalt met dat id kan je dit doen:

PHP:

$controle = explode('-', $cookie);
$valide = mysql_fetch_array(mysql_query("SELECT * FROM users WHERE id='".$controle[0]."' LIMIT 1"));
$valideHash = md5($valide['nickname'].$valide['password']);
if ($valideHash == $controle[1])
{
   print 'De cookie klopt';
}

zitten vast wel foutjes in maar heb het ff snel getypt

Je kan trouwens uiteraard ook nog een zwaardere encryptie gebruiken.

[ Voor 5% gewijzigd door Gersomvg op 21-07-2009 18:06 ]

[DexterDee]

@Gersompie: Jij doet hashing, geen encryptie. De TS heeft het originele wachtwoord nog nodig, wat erg lastig wordt met een MD5

Een wachtwoord lokaal opslaan in een formaat dat teruggebracht kan worden naar plaintekst (geen hashing dus) is per definitie nooit helemaal waterdicht te beveiligen. Het enige wat je kunt doen is de "hacker" vertragen door wat barrieres op te werpen. Een scriptkiddie zou wellicht de inhoud van de cookies folder kunnen kopieren op een USB stickje achter de PC van zijn slachtoffer. Thuis kan hij dan op zijn gemak de cookies openen en bekijken. Als je dan het betreffende wachtwoord plaintekst erin hebt staan dan maak je het erg makkelijk.

Afgezien wat je allemaal nog kan doen op de pagina die het cookie zet, zou je op z'n minst de tekst in het cookie kunnen encrypten en weer decrypten op de plaats waar je het nodig hebt. Dan staat het wachtwoord in ieder geval niet plaintekst in het cookie. Dit kan met verschillende methoden. Je kunt zelf wat vogelen met rot-13 en key rotations of je gebruikt een library als deze: http://dren.ch/js_blowfish/

[Confusion]

RetroTycoon schreef op dinsdag 21 juli 2009 @ 17:49:
In andere posts heb ik weleens aangegeven dat ik voor Wrts een Wrts-importeerdingetje heb gemaakt (zie ook: RetroTycoon in "[Alg] Welke tools heb jij gemaakt? - dee...") en daarbij gebruik ik de Wrts-api. Deze vereist bij gebruik een verbinding via http die zichzelf met basic authentication verifieert. Nu is het probleem dat het wachtwoord van de gebruiker ergens moet worden opgeslagen, op een veilige manier, maar wel un-encrypted (omdat het origineel voor de verbinding dus nodig is).

Dat stuk tussen haakjes begrijp ik niet. Waarom heb je het plaintext wachtwoord nodig 'voor de verbinding'? Bij basic http authentication wordt de header met de Base64 encoded versie van username+wachtwoord automatisch bij ieder request vanuit de client meegestuurd. Waarom moet jij datzelfde wachtwoord dan nog een keer opslaan?

[RobIII]

@Gersompie: Je beseft dat je een lelijke SQL injection mogelijk maakt met die code? Daarnaast heeft TS niets aan hashing (!= encryptie!) want het wachtwoord moet ergens "leesbaar" (of beter natuurlijk "decryptable") worden opgeslagen. Een hash is een one-way functie en dus niet "reversible" (op collisions na natuurlijk ; niet dat dat handig of bruikbaar is hier )

@TS: Waarom zou je uberhaupt het wachtwoord (willen) opslaan dan? Waarom laat je 't niet aan de browser over die dat (vaak) prima kan. Wat je ook kunt doen is met een willekeurige encryptie het wachtwoord server-side encrypten (en decrypten) en die waarde in de cookie gooien. Dan hoef je het wachtwoord niet "aan jouw kant" op te slaan (maar gaat het dus wel "op-en-neer").

Een andere optie is de gebruiker een tweede wachtwoord geven en het wachtwoord van de wrts encrypten met het wachtwoord van de gebruiker. Als je dat netjes doet kun je prima server-side de wrts wachtwoorden onthouden; je kunt ze zelf immers niet decrypten zonder het benodigde wachtwoord. Dan moet de gebruiker dus ergens (eenmalig) het wrts wachtwoord ingeven en wordt het, versleuteld met het "accountwachtwoord van jouw site", aan jouw kant opgeslagen. Moet je er wel rekening mee houden dat als de gebruiker zijn/haar wachtwoord wil wijzigen dat je het orignele wachtwoord ook (tijdelijk) nodig hebt om het wrts wachtwoord te decrypten en dan opnieuw te encrypten met het nieuwe wachtwoord.

Confusion schreef op dinsdag 21 juli 2009 @ 18:27:
[...]

Dat stuk tussen haakjes begrijp ik niet. Waarom heb je het plaintext wachtwoord nodig 'voor de verbinding'? Bij basic http authentication wordt de header met de Base64 encoded versie van username+wachtwoord automatisch bij ieder request vanuit de client meegestuurd. Waarom moet jij datzelfde wachtwoord dan nog een keer opslaan?

Wat ik er van begrijp is dat TS z'n applicatie weer gebruik maakt van een applicatie van een derde partij waar hij dus "tussen" gaat zitten. Hij wil de wachtwoorden van zijn gebruikers niet 'hebben', enkel doorsluizen naar de derde partij. Ergens zullen die wachtwoorden dan opgeslagen moeten worden (althans; dat vind hij) en dan blijft dus enkel de client over.

[ Voor 69% gewijzigd door RobIII op 21-07-2009 18:38 ]

[RetroTycoon]

RobIII schreef op dinsdag 21 juli 2009 @ 18:27:
@TS: Waarom zou je uberhaupt het wachtwoord (willen) opslaan dan? Waarom laat je 't niet aan de browser over die dat (vaak) prima kan. Wat je ook kunt doen is met een willekeurige encryptie het wachtwoord server-side encrypten (en decrypten) en die waarde in de cookie gooien. Dan hoef je het wachtwoord niet "aan jouw kant" op te slaan (maar gaat het dus wel "op-en-neer").

Een andere optie is de gebruiker een tweede wachtwoord geven en het wachtwoord van de wrts encrypten met het wachtwoord van de gebruiker. Als je dat netjes doet kun je prima server-side de wrts wachtwoorden onthouden; je kunt ze zelf immers niet decrrypten zonder het benodigde wachtwoord.


[...]

Wat ik er van begrijp is dat TS z'n applicatie weer gebruik maakt van een applicatie van een derde partij waar hij dus "tussen" gaat zitten. Hij wil de wachtwoorden van zijn gebruikers niet 'hebben', enkel doorsluizen naar de derde partij. Ergens zullen die wachtwoorden dan opgeslagen moeten worden (althans; dat vind hij) en dan blijft dus enkel de client over.

Ik sla het wachtwoord ook niet op, dat laat ik ook bij de client gebeuren (althans, in de sessie-variabele. In hoeverre is dat 'zijn' domein en niet van mij?) De oplossing die je in eerste instantie aandraagt lijkt op DexterDee in "[php] Wachtwoord opslaan in cookie, kan ..." en lijkt mij een aardige oplossing om zonder veel moeilijkheden een goede verdedigingslaag op te werpen. Dat zonder een extra inlogsysteem (met bijbehorende veiligheidsissues) op te zetten, zoals je in je tweede voorstel voorstelt.

Dat laatste klopt ja.

Confusion schreef op dinsdag 21 juli 2009 @ 18:27:
[...]

Dat stuk tussen haakjes begrijp ik niet. Waarom heb je het plaintext wachtwoord nodig 'voor de verbinding'? Bij basic http authentication wordt de header met de Base64 encoded versie van username+wachtwoord automatisch bij ieder request vanuit de client meegestuurd. Waarom moet jij datzelfde wachtwoord dan nog een keer opslaan?

Ik moet elke keer een nieuwe verbinding maken, en heb dan het account weer nodig om me te identificeren, zoals RobIII ook al opmerkte.

[RobIII]

RetroTycoon schreef op dinsdag 21 juli 2009 @ 18:38:
De oplossing die je in eerste instantie aandraagt lijkt op DexterDee in "[php] Wachtwoord opslaan in cookie, kan ..."DexterDee in "[php]

Met het grote verschil dat Rot-13 of andere simpele brouwsels makkelijk reversible zijn terwijl je prima "degelijke" encryptie (AES, Blowfish, whatever) kunt gebruiken. Maar one-way-or-the-other, het wachtwoord moet door jouw server te "decrypten" danwel "lezen" zijn wil je het wachtwoord weer naar WRTS kunnen sturen; je kunt dus altijd "de schuldige" zijn; ook al sla je de wachtwoorden niet op en speel je (dus) alleen doorgeefluik. Bewijs maar eens dat het wachtwoord niet ergens uit het geheugen geplukt kan zijn bijvoorbeeld of verzin iets...

[ Voor 5% gewijzigd door RobIII op 21-07-2009 18:45 ]

[Gersomvg]

RobIII schreef op dinsdag 21 juli 2009 @ 18:27:
@Gersompie: Je beseft dat je een lelijke SQL injection mogelijk maakt met die code? Daarnaast heeft TS niets aan hashing (!= encryptie!) want het wachtwoord moet ergens "leesbaar" (of beter natuurlijk "decryptable") worden opgeslagen. Een hash is een one-way functie en dus niet "reversible" (op collisions na natuurlijk ; niet dat dat handig of bruikbaar is hier )

Zoals ik al zei; ik had snel getypt.. Had even niet de moeite genomen om er een addslashes() omheen te zetten.
Ik weet dat het niet reversible is maar dat hoeft toch ook niet perse? Je kan die hash toch gewoon vergelijken met een hash die je hebt gemaakt adhv een rij uit de DB die je selecteerd dmv dat ID? Als ik de TS lees lijkt het mij wel dat dat kan maar kan het ook helemaal mis hebben.. Als je nou dat wat ik in die cookie had gezet naar de api stuurt.. dan kan de api toch vergelijken met de database?

[RobIII]

Gersompie schreef op dinsdag 21 juli 2009 @ 18:43:
Ik weet dat het niet reversible is maar dat hoeft toch ook niet perse?

Wel als die API een plaintekst wachtwoord wil hebben* De crux is 'm hier dat die API beschikbaar wordt gesteld door een derde partij

*Overigens, of dat zo is weet ik niet, dat moet de TS maar uitzoeken; wellicht kun je die API ook wel de hashed versie aanbieden (maar then again is dat gegeven dus even "waardevol" als het plaintekst wachtwoord). De TS is in dit geval "man-in-the-middle" en zal dus net zo goed in staat zijn die "hashed versie" stiekem op te slaan als het plaintext wachtwoord. Het gaat er TS om dat hij eigenlijk die gegevens niet WIL hebben maar ze wel MOET hebben om de API te kunnen gebruiken in naam van zijn gebruiker(s). En dus komt het opslaan bij de client om de hoek kijken, maar dan is het natuurlijk netjes als je daar het wachtwoord ook niet als plain text in een cookie mikkert . Als hij dan "belooft" die wachtwoorden (al dan niet hashed, encrypted, whatever) op z'n eigen server op te slaan is 'ie minder makkelijk aan te wijzen als "schuldige" als de poep de ventilator raakt en wachtwoorden op straat blijken te liggen. Hij kan dan nog prima de schuldige zijn, maar kan dan wél aantonen de wachtwoorden niet op te slaan en dus het risico (deels) in te perken.

[ Voor 71% gewijzigd door RobIII op 21-07-2009 18:53 ]

[steffex]

ik zou eens gaan kijken naar:
MCrypt

[Gersomvg]

RobIII schreef op dinsdag 21 juli 2009 @ 18:46:
[...]
De crux is 'm hier dat die API beschikbaar wordt gesteld door een derde partij

Oke... duidelijk

Maar iemand typt dus de eerste keer in jouw tooltje z'n wachtwoord. Als jij die dan zelf opslaat in je database samen met bijv. het ip adres kan je toch gewoon zo doen?

PHP:

$cookie = $_SERVER['REMOTE_ADDR'].md5($userPassword)

Dan kan je dus cookie uitlezen.. vergelijken dmv ipadres met database, en vervolgens password doorsturen naar api..
Dan heb je een niet decryptbaar geëncrypt wachtwoord clientside en een niet gëencrypt wachtwoord serverside..
Of zeg ik nu weer iets geks?

[ Voor 65% gewijzigd door Gersomvg op 21-07-2009 19:00 ]

[Confusion]

RobIII schreef op dinsdag 21 juli 2009 @ 18:27:
Wat ik er van begrijp is dat TS z'n applicatie weer gebruik maakt van een applicatie van een derde partij waar hij dus "tussen" gaat zitten. Hij wil de wachtwoorden van zijn gebruikers niet 'hebben', enkel doorsluizen naar de derde partij. Ergens zullen die wachtwoorden dan opgeslagen moeten worden (althans; dat vind hij) en dan blijft dus enkel de client over.

Tjah, ik zou het wachtwoord gewoon bij ieder request opnieuw uit de header halen. Of de implementatie van
getPassword(RequestObject)
nu het parsen van de authenticatieheader of het opzoeken van het wachtwoord in de sessie is maakt weinig uit, maar het eerste bespaart je de hoofdpijn die bij sessies en het opslaan van wachtwoorden hoort.

[ Voor 3% gewijzigd door Confusion op 21-07-2009 19:14 ]

[DexterDee]

RobIII schreef op dinsdag 21 juli 2009 @ 18:42:
[...]

Met het grote verschil dat Rot-13 of andere simpele brouwsels makkelijk reversible zijn terwijl je prima "degelijke" encryptie (AES, Blowfish, whatever) kunt gebruiken. Maar one-way-or-the-other, het wachtwoord moet door jouw server te "decrypten" danwel "lezen" zijn wil je het wachtwoord weer naar WRTS kunnen sturen; je kunt dus altijd "de schuldige" zijn; ook al sla je de wachtwoorden niet op en speel je (dus) alleen doorgeefluik. Bewijs maar eens dat het wachtwoord niet ergens uit het geheugen geplukt kan zijn bijvoorbeeld of verzin iets...

Daar heb je helemaal gelijk in, maar het is ook een risk vs. reward spelletje. Als een aanvaller toch al cookies kan lezen van een betreffende user, dan maakt het niet zo zeer meer uit of men rot-13 of AES256 encryptie gebruikt. De aanvaller kan met weinig moeite ook achter het versleutelproces komen met dergelijke verregaande toegang. Voor iemand die casual die cookies onder ogen krijgt werkt het dus als een soort obfuscation, in plaats van open en bloot de wachtwoorden uit te stallen. Diegenen die echt de kennis en motivatie hebben om toegang te verkrijgen kun je met de gegeven opzet moeilijk stoppen. Overigens is de blowfish library die ik aanwees nog steeds een leuke uitdaging, helemaal als je een server-side salt gebruikt.

[T-MOB]

Het wachtwoord in een sessie opslaan is iets anders dan het wachtwoord in een cookie stoppen.

Verder denk ik dat het antwoord van confusion het zinnigste is: proxy gewoon de http-authenticate header. Als dat geen optie is dan is een sessie zo gek nog niet. Afhankelijk van de serverconfig is het dan nog aan te bevelen om de wachtwoorden encrypted op te slaan. De boel kan zo (brak) zijn ingericht dat een andere gebruiker bij jouw sessiedata kan - in geval van shared hosting kan dat een issue zijn...

[RetroTycoon]

T-MOB schreef op dinsdag 21 juli 2009 @ 20:17:
Het wachtwoord in een sessie opslaan is iets anders dan het wachtwoord in een cookie stoppen.

Verder denk ik dat het antwoord van confusion het zinnigste is: proxy gewoon de http-authenticate header. Als dat geen optie is dan is een sessie zo gek nog niet. Afhankelijk van de serverconfig is het dan nog aan te bevelen om de wachtwoorden encrypted op te slaan. De boel kan zo (brak) zijn ingericht dat een andere gebruiker bij jouw sessiedata kan - in geval van shared hosting kan dat een issue zijn...

Je kunt de session-map met ini_set verplaatsen, maar wat Confusion nou in gedachten had, snap ik niet echt. Kan iemand dit toelichten?

[RobIII]

Confusion schreef op dinsdag 21 juli 2009 @ 19:13:
maar het eerste bespaart je de hoofdpijn die bij sessies en het opslaan van wachtwoorden hoort.

Dat zie ik anders, maar dat komt wellicht omdat ik dat soort zaken al goed geregeld heb in mijn "gereedschapskistje" (en daarbij zelden met PHP werk). Voor mij is het simpel te implementeren, maar true, het wachtwoord proxiën is net zo handig.

DexterDee schreef op dinsdag 21 juli 2009 @ 19:29:
De aanvaller kan met weinig moeite ook achter het versleutelproces komen met dergelijke verregaande toegang.

Maar dan heeft 'ie nog geen sleutel voor het decrypten (want: die is enkel server-side bekend) en dus schiet 'ie er geen zak mee op; itt tot ROT13

DexterDee schreef op dinsdag 21 juli 2009 @ 19:29:
Voor iemand die casual die cookies onder ogen krijgt werkt het dus als een soort obfuscation, in plaats van open en bloot de wachtwoorden uit te stallen.

Niet als je degelijke encryptie zou gebruiken dus

DexterDee schreef op dinsdag 21 juli 2009 @ 19:29:
Overigens is de blowfish library die ik aanwees nog steeds een leuke uitdaging, helemaal als je een server-side salt gebruikt.

Komt 'ie nou mee Die moet je sowieso altijd gebruiken En dan boeit blowfish, aes of whatever niet eens zo heel veel meer.

RetroTycoon schreef op dinsdag 21 juli 2009 @ 20:45:
Kan iemand dit toelichten?

Hij bedoelt dat, als een gebruiker zijn wachtwoord ingeeft, je dat uit de HTTP Authentication kunt halen en dan 1:1 kunt doorspelen naar de API; nadeel is dat je er elke keer als je de API opnieuw wil aanspreken (lees: een dag later bijvoorbeeld, dus niet in dezelfde sessie) je weer om het wachtwoord moet vragen aan de gebruiker (tenzij je het aan de browser over laat die, again, (vaak) ook wachtwoorden kan opslaan). En je wou het nou net opslaan

[ Voor 69% gewijzigd door RobIII op 21-07-2009 21:54 ]

[DexterDee]

RobIII schreef op dinsdag 21 juli 2009 @ 21:44:
[...]
Maar dan heeft 'ie nog geen sleutel voor het decrypten (want: die is enkel server-side bekend) en dus schiet 'ie er geen zak mee op; itt tot ROT13

Volgens mij mis je mijn punt een beetje. Als iemand al fysieke toegang heeft om cookies te kunnen uitlezen, dan zijn er legio andere mogelijkheden om de gewenste informatie naar boven te toveren, zelfs al heb je een serverside encrypted wachtwoord zonder lokale key. Vaak is het genoeg om de website op die PC te benaderen die de gewenste webservice uitvoert. 9 van de 10 mensen hebben 'remember this password' aanstaan en dan heb je niet het wachtwoord maar wel de uiteindelijke data te pakken. En als dat niet werkt dan kun je nog een keylogger installeren en zo zijn er tal van mogelijkheden.

Ik zal de laatste zijn die zegt dat security by obscurity een goed design pattern is, maar ik vind wel dat je goed per geval moet kijken of je niet aan het over-engineeren bent en of je niet je voordeur barricadeert met 20mm staal en de achterdeur vergeet op slot te draaien.

[RobIII]

DexterDee schreef op woensdag 22 juli 2009 @ 10:34:
[...]

Volgens mij mis je mijn punt een beetje. Als iemand al fysieke toegang heeft om cookies te kunnen uitlezen, dan zijn er legio andere mogelijkheden om de gewenste informatie naar boven te toveren, zelfs al heb je een serverside encrypted wachtwoord zonder lokale key. Vaak is het genoeg om de website op die PC te benaderen die de gewenste webservice uitvoert. 9 van de 10 mensen hebben 'remember this password' aanstaan en dan heb je niet het wachtwoord maar wel de uiteindelijke data te pakken.

Uiteraard; dan heb ik dan idd verkeerd begrepen. My bad.

[Janoz]

Gersompie schreef op dinsdag 21 juli 2009 @ 18:49:
[...]

Oke... duidelijk

Maar iemand typt dus de eerste keer in jouw tooltje z'n wachtwoord. Als jij die dan zelf opslaat in je database samen met bijv. het ip adres kan je toch gewoon zo doen?

PHP:

$cookie = $_SERVER['REMOTE_ADDR'].md5($userPassword)

Dan kan je dus cookie uitlezen.. vergelijken dmv ipadres met database, en vervolgens password doorsturen naar api..
Dan heb je een niet decryptbaar geëncrypt wachtwoord clientside en een niet gëencrypt wachtwoord serverside..
Of zeg ik nu weer iets geks?

Asjeblieft. Gewoon ophouden met op basis van vaststaande gegevens gegenereerde tokens. Het biedt geen enkele meerwaard en gewoon een random string gebruiken is ook nog eens een stuk veiliger.

Tot slot is de door jouw hierboven aangegeven oplossing juist eentje die de topicstarter nog minder zou willen. Hij wil juist helemaal niet het wachtwoord onthouden, laat staan deze in een database opslaan.

[Verwijderd]

Ik zou zeggen, laat er verschillende manieren van encryptie op los, die allemaal terug te draaien zijn, maar wel moeilijker door de 'hacker' zijn te achterhalen.

Een combinatie van verschillende keren ROT13 en Base64, perhaps?

[RobIII]

Verwijderd schreef op woensdag 22 juli 2009 @ 11:58:
Ik zou zeggen, laat er verschillende manieren van encryptie op los, die allemaal terug te draaien zijn, maar wel moeilijker door de 'hacker' zijn te achterhalen.

Dat maakt het niet veiliger...

Verwijderd schreef op woensdag 22 juli 2009 @ 11:58:
Een combinatie van verschillende keren ROT13 en Base64, perhaps?

ROT13 mag de naam "encryptie" niet dragen en Base64 is meer een encoding dan encryptie...

ROT13 has been described as the "Usenet equivalent of a magazine printing the answer to a quiz upside down"

[ Voor 9% gewijzigd door RobIII op 22-07-2009 12:05 ]

[Verwijderd]

RobIII schreef op woensdag 22 juli 2009 @ 12:04:
[...]

Dat maakt het niet veiliger...


[...]


ROT13 mag de naam "encryptie" niet dragen en Base64 is meer een encoding dan encryptie...


[...]

Tja, maar het moet toch terug te draaien zijn...
ik weet het ook niet echt hoor, encryptie/encoding/hashing is niet bepaald mijn ding.

[RobIII]

Verwijderd schreef op woensdag 22 juli 2009 @ 12:13:
[...]


Tja, maar het moet toch terug te draaien zijn...
ik weet het ook niet echt hoor, encryptie/encoding/hashing is niet bepaald mijn ding.

Met alle respect, maar verdiep je daar dan eerst even in voor je rare dingen gaat roepen.

Kort door de bocht:
Encryptie = versleutelen van gegevens met als doel de gegevens dus onleesbaar te maken behalve voor degenen die de juiste sleutel hebben

Encoding = transformatie van gegevens in formaat A naar B

Hash = "Controlegetal" dat berekent wordt a.d.h.v. een bepaalde set gegevens; a.d.h.v. dit "controlegetal" kun je echter de originele gegevens niet meer achterhalen (collisions even buiten beschouwing gelaten). Een string van 3 tekens levert, bij MD5 bijvoorbeeld een hash van 128 bits op, maar een bestand van 15Gb levert evenzogoed een hash van 128 bits op. Peuter jij uit die 128 bits maar eens de originele 15Gb

Zie ook, bijv., http://www.di-mgt.com.au/encode_encrypt.html

[ Voor 31% gewijzigd door RobIII op 22-07-2009 12:26 ]

[Verwijderd]

Ok, sorry man.
Je hebt ook wel gelijk, ik wat rare dingen gaan roepen zonder dat ik er echt iets vanaf weet

Ja, het verschil tussen Hashen en de rest wist ik nog wel, ik zat met het verschil tussen encryptie en encoding.

[leroyk2]

Encrypt de inhoud van de cookie met rijndael 256 bits encryption
http://www.phpsnaps.com/s...-encryption-using-mcrypt/

Bewaar in het cookie op zijn minst ook het ip adres, user agent of een ander uniek kenmerk om te kunnen proberen te vookomen dat de cookie gejat wordt. Succes.

[RetroTycoon]

RobIII schreef op dinsdag 21 juli 2009 @ 21:44:
Hij bedoelt dat, als een gebruiker zijn wachtwoord ingeeft, je dat uit de HTTP Authentication kunt halen en dan 1:1 kunt doorspelen naar de API; nadeel is dat je er elke keer als je de API opnieuw wil aanspreken (lees: een dag later bijvoorbeeld, dus niet in dezelfde sessie) je weer om het wachtwoord moet vragen aan de gebruiker (tenzij je het aan de browser over laat die, again, (vaak) ook wachtwoorden kan opslaan). En je wou het nou net opslaan

Als ik je goed begrijp neem je aan dat bij elke request er opnieuw verbinding met de api wordt gemaakt. Dit is echter niet het geval, enkel wanneer er wordt geüpload naar Wrts worden deze gegevens gebruikt. Deze oplossing lijkt me daarom ook niet te werken.

leroyk2 schreef op woensdag 22 juli 2009 @ 14:19:
Encrypt de inhoud van de cookie met rijndael 256 bits encryption
http://www.phpsnaps.com/s...-encryption-using-mcrypt/

Bewaar in het cookie op zijn minst ook het ip adres, user agent of een ander uniek kenmerk om te kunnen proberen te vookomen dat de cookie gejat wordt. Succes.

Ik denk dat ik idd met een stevige encryptie ga werken. Maar hoe kan ik voorkomen door ip-adres te gebruiken dat een cookie gejat wordt überhaupt?

En om even mijn gedachten met die van jullie op een lijn te krijgen, het wordt dan zo'n soort script? In pseudo:

PHP:

function encrypt($wachtwoord) {
$_SESSION['encrypt'] = encryptiefunctie($wachtwoord.$_SERVER['REMOTE_ADDR']);
}

function decrypt($encrypted) {
$decrypted = decryptiefunctie($_SESSION['encrypt']);
if (strpos($decrypted, $_SERVER['REMOTE_ADDR']) !== false)) {
return str_replace($_SERVER['REMOTE_ADDR'], '', $decrypted;}

Zoiets?

[Gerco]

RetroTycoon schreef op woensdag 22 juli 2009 @ 18:41:
Als ik je goed begrijp neem je aan dat bij elke request er opnieuw verbinding met de api wordt gemaakt. Dit is echter niet het geval, enkel wanneer er wordt geüpload naar Wrts worden deze gegevens gebruikt. Deze oplossing lijkt me daarom ook niet te werken.

De echte vraag is natuurlijk of er *alleen* geupload wordt naar Wrts in reaktie op een request.

Wanneer het antwoord "Ja" is hoef je het wachtwoord niet per-se op te slaan. Dan kun je het in een cookie ofzo opslaan (al dan niet encrypted) of 1op1 doorspelen via http auth. Wanneer je met een cron script of zoiets upload kom je er niet onderuit om het wachtwoord op te slaan in een decyptbare vorm.

Het feit dat je niet bij elke request verbinding moet maken met Wrts doet namelijk niets af aan de oplossing van RobIII. Bij requests waarbij je dat moet doen doe je het en wanneer je het niet moet doen negeer je de gegevens in de cookie of http authenticatie gegevens.

On-topic:
Ik zou het wachtwoord niet in een cookie opslaan. Wanneer iemand zijn Wrts password heeft gegeven genereer je een random key en die sla je in de cookie op. Vervolgens encrypt je het password met die key en dat zet je in je database. Andersom kan natuurlijk ook, het belangrijke punt is dat geen van die twee gegevens (cookie of database) genoeg is om aan het wachtwoord te komen.

Wanneer de gebruiker dan zijn cookie verliest dient hij/zij het wachtwoord opnieuw op te geven, daar is niet onderuit te komen.

[ Voor 21% gewijzigd door Gerco op 22-07-2009 18:59 ]

[leroyk2]

Op onderstaande manier hebben ze weinig aan de inhoud van het cookie en kunnen ze het cookie ook niet makkelijk kopieren. Het is verstandig om het ip adres mee te nemen in de encryptie key.

PHP:

function encrypt($encrypt, $mc_key) {   
    $iv = mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB), MCRYPT_RAND);  
    $passcrypt = trim(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $mc_key, trim($encrypt), MCRYPT_MODE_ECB, $iv));  
    $encode = base64_encode($passcrypt);    
    return $encode;
}

function decrypt($decrypt, $mc_key) {   
    $decoded = base64_decode($decrypt); 
    $iv = mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB), MCRYPT_RAND);  
    $decrypted = trim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $mc_key, trim($decoded), MCRYPT_MODE_ECB, $iv));  
    return $decrypted;
}

// in het cookie opslaan
$inhoud = encrypt($wachtwoord,$ip.$useragent.$salt);
setcookie("mijncookie", $inhoud, time()+3600, "/");

//uit het cookie halen
$inhoud = decypt($_COOKIE['mijncookie'],$ip.$useragent.$salt);

[Gerco]

leroyk2 schreef op woensdag 22 juli 2009 @ 20:30:
Het is verstandig om het ip adres mee te nemen in de encryptie key.

Ik heb altijd geleerd dat een encryptie key zo random mogelijk moet zijn en indien mogelijk nergens op gebaseerd. Op die manier minimaliseer je de kans dat iemand de key weet te achterhalen op basis van mogelijk gelekte gegevens.

Kun je uitleggen waarom het verstandig is om de key te baseren op het ip adres?

[leroyk2]

Gerco schreef op woensdag 22 juli 2009 @ 20:51:
[...]

Ik heb altijd geleerd dat een encryptie key zo random mogelijk moet zijn en indien mogelijk nergens op gebaseerd. Op die manier minimaliseer je de kans dat iemand de key weet te achterhalen op basis van mogelijk gelekte gegevens.

Kun je uitleggen waarom het verstandig is om de key te baseren op het ip adres?

Helemaal mee eens. In $salt kan je ook een zo random mogelijk key in opslaan. Als je het ip adres meeneemt in het cookie of in de key dan kan het cookie moeilijker misbruikt worden. Als dan iemand het cookie zou kopieeren en op een andere pc(ip) wil gebruiken dan mislukt het decrypten. Een poging om cookie hijacking te voorkomen.

[Gerco]

leroyk2 schreef op woensdag 22 juli 2009 @ 20:55:
Een poging om cookie hijacking te voorkomen.

Het lijkt me niet verstandig om dat op IP adres te doen. Je sluit dan hele groepen users uit. Bij hele grote providers worden ip adressen veel vaker gewisseld dan in NL en kan het zomaar voorkomen dat je opeens een nieuw IP hebt tijdens een browsing sessie.

Ook mobiele users en users achter een proxy cluster hebben hier regelmatig last van. In NL komt het weinig voor, maar in grotere landen is het vrij normaal. Beter zorg je gewoon dat je goede maatregelen tegen session fixation hebt en vertrouw je niet alleen op het IP adres.

Als je dan toch het IP adres wilt gebruiken, doe het dan met een random encryptie key en sla het ip gewoon in de encrypted data op. Dan kun je de key gewoon goed random houden en heb je toch je ip beveiliging.

[ Voor 13% gewijzigd door Gerco op 22-07-2009 21:35 ]

[Gomez12]

Tja, imho blijf je linksom of rechtsom altijd de situatie houden dat het wachtwoord via jouw server loopt en dat jouw server het kan ontcijferen ( en dit ook actief doet, want hij moet het plaintext verder zenden ).

Dus je blijft altijd de situatie houden dat je "klanten" moeten vertrouwen dat jij het niet logt.

Imho zijn alle trucjes van het in cookies geencodeerd verstoppen etc. dan ook enkel schijnmaatregelen, server-side decodeer je het wachtwoord nog net zo hard en stuur je het gewoon door ( en log je het misschien ook nog wel... )
Ik zou gewoon kiezen voor openheid en eerlijkheid en het wachtwoord opslaan in een server-side goed beveiligde dbase, qua logging / aftap mogelijkheden maakt het technisch niets uit en qua beveiliging kan je dan veel meer common used techniques gebruiken.

Misschien dat je truus op de hoek ( die niets van techniek begrijpt ) verliest omdat die dan het idee heeft dat jij haar wachtwoord hebt ( mogelijkheid daartoe heb je anders ook ). Maar ik gok dat je meer tech-savvie users aantrekt omdat je geen cloak and dagger spelletje meer speelt.

Technisch gezien heb jij namelijk altijd de mogelijkheid tot ongemerkt loggen als jouw server het wachtwoord in plaintext moet verzenden.

[Voutloos]

Gomez12 schreef op woensdag 22 juli 2009 @ 23:02:
Imho zijn alle trucjes van het in cookies geencodeerd verstoppen etc. dan ook enkel schijnmaatregelen, server-side decodeer je het wachtwoord nog net zo hard en stuur je het gewoon door ( en log je het misschien ook nog wel... )

Dat het tijdens de uitvoer te onderscheppen is klopt, maar met een implementatie als in Gerco in "[php] Wachtwoord opslaan in cookie, kan ..." kan je in ieder geval zorgen dat 'men' met de gegevens in je db/op je fs niets kan. Niet je primary line of defense, maar mogelijk wel een aardige manier om de schade te beperken bij major fuckups.

[RetroTycoon]

RobIII schreef op dinsdag 21 juli 2009 @ 21:44:
[...]

Hij bedoelt dat, als een gebruiker zijn wachtwoord ingeeft, je dat uit de HTTP Authentication kunt halen en dan 1:1 kunt doorspelen naar de API; nadeel is dat je er elke keer als je de API opnieuw wil aanspreken (lees: een dag later bijvoorbeeld, dus niet in dezelfde sessie) je weer om het wachtwoord moet vragen aan de gebruiker (tenzij je het aan de browser over laat die, again, (vaak) ook wachtwoorden kan opslaan). En je wou het nou net opslaan

Kan je dit met een voorbeeldje verduidelijken, of in ieder geval nader toelichten? Het klinkt verstandig, maar ik weet niet precies hoe je dat zou moeten aanpakken.