[PHP] Welke encryptie gebruiken voor user_id?

[RMX]

Het probleem zal vast wel voor de hand liggen maar ik kom er niet uit.
Ik heb een login systeem ergens vandaan geplukt van het internet. Na het testen leek me dit een goed script om in het intranet te gebruiken dus dat heb ik gedaan. Maar toen kwam ik erachter dat in de cookie user_id niet gecodeerd is.
Nu ben ik bezig geweest maar ik weet niet hoe ik dit het beste kan coderen?

Stel ik neem md5 op in m'n cookie. Hoe moet ik die dan authorizeren met de db? Dat lukt me niet.
Zelfde geld voor crypt. Als ik dit wil doen heb je toch een input nodig van de user maar die kun je moeilijk om hun user_id vragen want die weten ze toch niet.

Dus ik heb user_id 1 zeg maar. Die leest ie uit in mijn cookie maar hoe decrypt ik hem dan met md5? Ik kom er niet uit...

Kijk ik nou ergens overheen of zit ik toch verkeerd en moet ik iets anders opnemen in mijn cookie?

[Hermarcel]

Neem ook de ge-encrypte waarde op in je database. Vergelijk het cookie hiermee.

[Gerco]

md5 kun je niet decrypten.

Je zou de boel gecodeerd met een encryptiealgoritme (3des, blowfish, whatever) in de cookie kunnen zetten waarbij je de key op de server bewaart. Dan kun je op de client niets met de cookie. Je kan natuurlijk ook alleen gegevens in de cookie zetten waarbij het niet erg is als ze uitlekken of je gebruikt session cookies waardoor deze na 1 sessie gewist worden en dus ook nooit opgeslagen.

[Koeniepoenie]

md5 kun je niet decrypten, is een hash.

En ik zie niet wat je met een User ID kunt, want je zult nog altijd in de DB moeten komen wil je het wachtwoord en consorte kunnen achterhalen.

edit:
Spuit 11..

[ Voor 7% gewijzigd door Koeniepoenie op 22-11-2004 11:11 . Reden: to slow.. ]

[ludo]

Waarom zou je dit willen doen Je schiet er niet veel mee op, als je een beetje fatsoenlijk systeem hebt, kan iemand met een user_id niks doen. Hashen van het user_id met md5 heeft ook geen nut als je dezelfde waarde in de DB opslaat, je krijgt alleen maar meer overhead.

[ Voor 3% gewijzigd door ludo op 22-11-2004 11:12 ]

[royjn]

ik heb ooit ook een login gemaakt in php en mysql. het beste is hier al genoemd de md5 ge-encrypte data in je database zetten dit kun je dan vergelijken met wat er in de cookie staat.

[RMX]

Dan denk ik toch dat 'mijn' systeem niet goed is.
Want stel ik verander de user_id in de cookie, dan word ik als iemand anders ingelogged.

Hoe kan ik dan een dubbele check inbouwen waarbij gecontroleerd word of de user_id wel goed is.
Misschien toch de levensduur van de sessie verlagen? Maar dit wil ik graag als laatste bewaren.
Wat natuurlijk wel kan is een encrypte versie van de user_id in de database opslaan..
Misschien dat dit het handigste is.

Ludo: kun je me uitleggen misschien hoe ik die check moet doen dan?
Thnx

[RMX]

Ik denk dat ik toch voor de optie ga waarbij de encrypte user_id in de db word opgeslagen. Dit kost ook het minste tijd als ik alle scripts moet aanpassen.

Thnx!

[Gerco]

Als je het userid "encrypt" met md5, dan kan ik ook gewoon een ander "encrypted" userid in de cookie zetten, zelfde probleem

Je moet iets in de cookie zetten wat niet is te herleiden naar een bepaalde user, bij voorkeur iets wat volkomen random is (een SessionID). Op die manier is het zo goed als onmogelijk om zo'n ID te raden (stelen kan ook, maar dat is een andere discussie).

Dat ID zet je dan in je database en aan de hand daarvan ga je kijken welke user er is ingelogd.

[ Voor 4% gewijzigd door Gerco op 22-11-2004 11:23 ]

[Verwijderd]

het beste kun je userid in een sessie bewaren.

[RMX]

Gerco bedankt, ik ga er eens naar kijken..

Maaruh user_id in een session bewaren... Sessie blijft maar tijdelijk geldig en ze willen toch echt ingelogged blijven...
Maar ik ga weer verder
Thnx all..

[abeker]

Wat je ook kunt doen is:
-hash van userid+wachtwoord in cookie zetten
-bij starten van sessie controleren of hash uit cookie overeenkomt met de hash van userid+wachtwoord uit db
-bij iedere pagina controleren of userid uit cookie overeenkomt met userid uit sessie

[ Voor 2% gewijzigd door abeker op 22-11-2004 12:23 . Reden: Eigenlijk is het overbodig om op iedere pagina te controleren of de userid uit de cookie wel goed is, omdat je toch de userid uit de sessie gebruikt. ]

[Verwijderd]

RMX schreef op maandag 22 november 2004 @ 11:33:
Gerco bedankt, ik ga er eens naar kijken..

Maaruh user_id in een session bewaren... Sessie blijft maar tijdelijk geldig en ze willen toch echt ingelogged blijven...
Maar ik ga weer verder
Thnx all..

sessie is net een cookie, je kunt zelf instellen hoelang het geldig moet blijven : ) check eens de php manual

[Vold]

Daarbij komt nog eens dat je met een beetje md5 brute force progje zo al een groot aantal user_ids zou kunnen achterhalen.. denk dat tot userids van 12345678 geen probleem moet zijn om aan de hand van de md5 hash achter het werkelijke id te komen.. Je kan dan beter voor de methode gaan van abeker.

[--MeAngry--]

Wat een brak inlogsysteem als er alleen een userid in die cookie wordt bewaard. Met je userid hoef je nooit iets int bijzonder te doen, dit kun je gewoon onencrypted in de cookie zetten, maar zet in die cookie dan ook het wachtwoord als MD5-hash en vergelijk dit dan met het wachtwoord in de DB die daar uiteraard ook MD5-gehashed staat.
Dit is de meest standaard vorm van een inlogsysteem, wordt best vaak gebruikt en is veilig genoeg voor de meeste gevallen. (Het wachtwoord is in ieder geval nooit te raden, of je moet een heel stevig computereiland hebben )

[eamelink]

Gerco schreef op maandag 22 november 2004 @ 11:23:
Als je het userid "encrypt" met md5, dan kan ik ook gewoon een ander "encrypted" userid in de cookie zetten, zelfde probleem

Euh, er ging iets mis, m'n reactie is weg. Ik verander dit straks weer , moet heel even m'n monitor uitdoen!

Daarom zou je een zoutje kunnen toevoegen aan de userid voor je hem hasht.

Als ik dit systeem zou moeten aanpassen zou ik het volgende doen : Naast de userid sla je ook een md5 hash van een userid + bepaalde geheime string op. (Bijvoorbeeld md5($userid . "woolooloo"));

Bij het openen van een pagina controleer jij of de md5 van de userid in de cookie + woolooloo gelijk is aan de md5 hash die in de cookie zit.

Een gebruiker kan wel de userid veranderen, maar de md5 hash kan hij niet zelf genereren zonder de string 'woolooloo' te weten. Dan zit je dus redelijk veilig

Dit systeem kan je ook gebruiken om je databaseserver te ontlasten. Je hoeft niet bij elke hit een userid + pass te controleren. Een userid + hash is genoeg om de gebruiker te identificeren. Bij het openen van een pagina hoef je alleen maar een md5 te trekken om een user te identificeren (dat kan je makkelijk uitbesteden aan een andere server), en niet met je database te connecten

[ Voor 92% gewijzigd door eamelink op 22-11-2004 15:56 ]

[Verwijderd]

Vertrouw niet te veel op een MD5 hash. Wanneer het wachtwoord kleiner is dan 8 karakters dan kraak je dat binnen 11 uur met je huis-tuin-en-keuken PC. Wanneer je beschikt over een rainbowtable(een database met alle mogelijke md5 hashes) zal het helemaal niet veel tijd kosten. Zoek eens goed op internet en je merkt dat men zelfs services heeft waar je MD5 wordt teruggedraaid.
Wat een handige oplossing is, is om de wachtwoorden te voorzien van een prefix. Deze plakt je systeem dan er voor wanneer de gebruiker zijn passwoord opstuurt. Dus in je database staat md5(prefix+userpasswoord), je gebruiker merkt dus niks.
De prefix vergroot het wachtwoord aanzienlijk waardoor het terug halen van je wachtwoord erg lang duurt (de reversetime loopt exponentieel op per karakter)

Daarnaast kan je er ook voorkiezen om de username in de cookie te zetten.
Elke pagina wordt er een hash gemaakt van de username+ipadres, deze waarde wordt dan vergeleken met die allereerst in de database is gezet bij het inloggen.
Bij uitloggen wordt deze verwijderd. Deze methode wordt volgens mij gebruikt bij het publish systeem expresion engine.

[Gerco]

Het lijkt me dat het voor een md5 hash "terug te berekenen" niet uitmaakt hoe lang het password is (als de attacker niet weet hoe lang het is, als hij dat wel weet is het een ander verhaal). Hij zal toch alle mogelijkheden afmoeten (en dat zijn er een paar). Met bovengenoemde rainbowtable heb je zowiezo altijd een instant password. Niet hetzelfde als het origineel waarschijnlijk, maar dat hoeft ook niet altijd.

PS. Zo'n rainbowtable, wie heeft er zoveel tijd over om zo'n ding te maken? En hoeveel storage kost dat dan wel niet ?

[ Voor 11% gewijzigd door Gerco op 22-11-2004 17:43 ]

[Verwijderd]

Het beste is dat je dan in je database ook een gecrypteerd md5 wachtwoord opslaat;

En md5 is niet terug te herstellen naar het oorspronkelijke omdat een md5 encryptie het resultaat is van een aantal afgeronde delingen. vb

7/2=3,5 wordt door md5 afgerond tot 3, en zo wordt het nog een paar keer door andere delers gedeelt en nog wat andere bewerkingen en door die afrondingen is het onmogelijk dat ooit nog terug te achterhalen, in de toekomst met de opkomst van supercomputers zal deze technologie wel snel achterhaald zijn, maar dat is toekomst.

[Verwijderd]

even offtopic, wat is een hash

[Creepy]

Verwijderd schreef op maandag 22 november 2004 @ 19:53:
even offtopic, wat is een hash

Pak google er eens bij en klik op de, pak hem beet, de 6de link "what is a hash function"

[Verwijderd]

wat ik meestal in een cookie gooi is: userid (leesbaar) en een hash

de hash bestaat uit het wachtwoord (al gehashed), het ipadres en salt (een random getal). Daarmee maak ik weer een sessie aan, indien alles overeenkomt

[Verwijderd]

Verwijderd schreef op maandag 22 november 2004 @ 15:27:
Vertrouw niet te veel op een MD5 hash. Wanneer het wachtwoord kleiner is dan 8 karakters dan kraak je dat binnen 11 uur met je huis-tuin-en-keuken PC. Wanneer je beschikt over een rainbowtable(een database met alle mogelijke md5 hashes) zal het helemaal niet veel tijd kosten. Zoek eens goed op internet en je merkt dat men zelfs services heeft waar je MD5 wordt teruggedraaid.

Om je even uit je droom te halen, je hebt voor alle mogelijke md5 hashes een opslagcapaciteit nodig van 2¹³⁵ bits. Dat is 2¹³² bytes, oftewel 5.44 Tredabyte. Ik neem aan dat er een goede kans is dat je het woord niet eens kent. Het is namelijk best veel. Zoveel dat het onzin is om te denken dat iemand ergens een database heeft met alle mogelijke combinaties.

Als je een password neemt dat bestaat uit 8 of meer willekeurige cijfers, letters en tekens mag je ervanuit gaan dat het al niet via het internet gekraakt gaat worden. Zelfs als iemand database toegang heeft, is zijn machine nog aardig gek bezig voor hij een wachtwoord van 8 willekeurige tekens heeft gevonden door brute-force.

[ Voor 4% gewijzigd door Verwijderd op 22-11-2004 20:07 ]

[Verwijderd]

Verwijderd schreef op maandag 22 november 2004 @ 20:03:
[...]

Om je even uit je droom te halen, je hebt voor alle mogelijke md5 hashes een opslagcapaciteit nodig van 2^135 bits. Dat is 2^132 bytes, oftewel 5.44 Tredabyte. Ik neem aan dat er een goede kans is dat het woord niet eens kent. Het is namelijk best veel. Zoveel dat het onzin is om te denken dat iemand ergens een database heeft met alle mogelijke combinaties.

Als je een password neemt dat bestaat uit 8 of meer willekeurige cijfers, letters en tekens mag je ervanuit gaan dat het al niet via het internet gekraakt gaat worden. Zelfs als iemand database toegang heeft, is zijn machine nog aardig gek bezig voor hij een wachtwoord van 8 willekeurige tekens heeft gevonden door brute-force.

Toch gaat het best hard, ik heb hier een md5 cracker staan die op mijn enkele Duron op 2400mhz een 255.000 keys per seconde checkt. Als je een dual Opteron tot je beschikking hebt zoals Femme bv, dan zijn wachtwoord <8 tekens niet een heel groot probleem. Het vergt enkel wat geduld

[Gerco]

Verwijderd schreef op maandag 22 november 2004 @ 20:03:
Om je even uit je droom te halen, je hebt voor alle mogelijke md5 hashes een opslagcapaciteit nodig van 2¹³⁵ bits. Dat is 2¹³² bytes, oftewel 5.44 Tredabyte. Ik neem aan dat er een goede kans is dat je het woord niet eens kent. Het is namelijk best veel. Zoveel dat het onzin is om te denken dat iemand ergens een database heeft met alle mogelijke combinaties.

Ik denk eerder dat hij alle md5 hashes van combinaties van 1-8 characters bedoelde. Dat is een beetje haalbaarder dan alle mogelijke md5 hashes totaal Is nog steeds achtelijk veel, belachelijk veel misschien zelfs, maar mogelijk wel haalbaar.

[ Voor 8% gewijzigd door Gerco op 22-11-2004 20:15 ]

[Tux]

eamelink schreef op maandag 22 november 2004 @ 15:27:
[...]
Als ik dit systeem zou moeten aanpassen zou ik het volgende doen : Naast de userid sla je ook een md5 hash van een userid + bepaalde geheime string op. (Bijvoorbeeld md5($userid . "woolooloo"));

Maar dan moet je wel het volgende onthouden: obscurity != security

Zelf gebruik ik een session id wat uit een aantal random en niet random waardes wordt gegenereerd. Vervolgens wordt er in een session tabel gekeken of de hash wel klopt met de gegevens die voor die sessie bekend zijn.

[Verwijderd]

Als uitgangssituatie neem even aan dat een wachtwoord kan worden opgebouwd uit letters, cijfers en een stuk of 10 veelgebruikte tekens. Met 8 karakters heb je dan 72⁸ mogelijkheden. Dat is nog steeds best veel, namelijk 722204136308736.

Als je in staat bent om een miljoen wachtwoorden per seconde te proberen, doe je er nog altijd 722204136 seconden = 200612 uur = 23 jaar over

Ik denk eerder dat hij alle md5 hashes van combinaties van 1-8 characters bedoelde. Dat is een beetje haalbaarder dan alle mogelijke md5 hashes totaal Is nog steeds achtelijk veel, belachelijk veel misschien zelfs, maar mogelijk wel haalbaar.

Volgens mij heb je daar voor de hashes alleen al 2048 Exabyte voor nodig. Nog steeds behoorlijk wat schijven, zo bij elkaar. Het is veel slimmer om alleen de wachtwoorden op te slaan waarvan er een goede kans is dat iemand ze gebruikt. Probeer bijvoorbeeld alle woorden, alle woorden gevolgd door 1, 2 of 3 cijfers, alle woorden met klinkers vervangen door cijfers, etcetera. Het is gekkenwerk om van willekeurig gegenereerde wachtwoorden de hashes op te gaan slaan. Met als doel ze snel omgekeerd te kunnen herleiden naar een wachtwoord.

[ Voor 53% gewijzigd door Verwijderd op 22-11-2004 20:26 ]

[Grijze Vos]

eamelink schreef op maandag 22 november 2004 @ 15:27:
Als ik dit systeem zou moeten aanpassen zou ik het volgende doen : Naast de userid sla je ook een md5 hash van een userid + bepaalde geheime string op. (Bijvoorbeeld md5($userid . "woolooloo"));

Mja, tenzij je je source wilt distribueren. (Zoals bij PHP wel eens het geval is.) Ik zou toch wel even een random iets gebruiken. Of de tijd in microseconds ofzo.