Nieuwe PHPhulp
Pagina: « vorige 1 2 3 ... 35 36 37 38 volgende »
Daan schreef op 02.02.2010 16:21:
Ow, zo ik schrok al...
Ik dacht dat door de SQL injectie alle MD5'jes nu in iemands bezit waren...
Mr.Ark schreef op 02.02.2010 16:17:
Het wachtwoord wordt als MD5 encryptie in een COOKIE gestopt, die kan je dus makkelijk krijgen van een persoon, en als je de md5 hebt dan kan je achter het wachtwoord komen.
Daan Middendorp schreef op 02.02.2010 16:15:
Bedoel je hiermee dat al onze wachtwoorden op straat liggen?
wesley schreef op 02.02.2010 15:53:
Advies aan iedereen: Verander je password in een ander password, wat je nergens anders gebruikt, je password staat namelijk ook gewoon als een md5 string in een cookie....
Bedoel je hiermee dat al onze wachtwoorden op straat liggen?
Het wachtwoord wordt als MD5 encryptie in een COOKIE gestopt, die kan je dus makkelijk krijgen van een persoon, en als je de md5 hebt dan kan je achter het wachtwoord komen.
Ow, zo ik schrok al...
Ik dacht dat door de SQL injectie alle MD5'jes nu in iemands bezit waren...
Dat heb je goed gedacht dan
Over het md5 en sha1 verhaal, beide zijn lek. Beide zijn tegenwoordig makkelijk te bruteforcen en kunnen door middel van raibow en dictionary aanvallen boven water gehaald worden.
kijk liever naar goede encryptie mogelijkheden. Wat ook nog goed werkt is de hash() methode in PHP.
Wat overigens niet helpt is bijvoorbeeld hash(md5(sha1())). Dit lijkt misschien moeilijker te kraken, maar de zwakste sleutel is alsnog de md5 en sha1. Wanneer deze bovenwater zijn, volgt de rest ook.
Een veilige manier om een goed wachtwoord te encrypten/hashen kan bijvoorbeeld met AES, RSA of iets wat hier op lijkt.
Helemaal mee eens!
Dit aangezien php(.net) dit niet standaard ondersteund zoals bijv. md5() en sha1 nu wel het geval is. En dit dus voor veel ontwikkelaars weer een extra handeling zal moeten zijn.
(Wat betreft php.net: Correct me if im wrong :)
Zeker wanneer je met gebruikersaccounts werkt, kan ik mij niet voorstellen dat de integriteit van je leden in het geding komt als het op veiligheid aan komt.
Liever 2 uur extra werk door alles goed te encrypten dan een standaard md5 hash gebruiken. Ik zelf heb de overstap een jaar geleden gemaakt, en heb een goede AES klasse gevonden, welke prima aansluit bij wat ik nodig heb.
Er zit een encryptie en decryptie in. En je wachtwoord? Die krijg je van je levensdagen niet meer terug. Implementatie kost mij misschien 5 minuten, omdat ik het al vaker gebruikt heb.
Ik kan het gewoon aanraden. Ik wil de link naar de klasse hier ook wel posten ( zowel RSA als ook de AES) , dus mocht je het willen, geef een gil.
Merijn schreef op 02.02.2010 18:55:
...Ik wil de link naar de klasse hier ook wel posten ( zowel RSA als ook de AES) , dus mocht je het willen, geef een gil.
Ben benieuwd!
Bij deze de link naar de RSA class. Ik weet niet zeker of de link meteen werkt, het kan zijn dat je een mirror moet kiezen, maar dit is de link voor RSA.
RSA:
http://www.phpclasses.org/browse/package/4121/download/zip.html
AES:
http://www.phpclasses.org/browse/package/4238/download/zip.html
en $PHPNewbie,
Nee je wachtwoord is wel veilig hoor. Het principe werkt niet helemaal zoals jij denkt. Een gecodeerd wachtwoord komt niet meer boven. Het gaat om het bericht dat je mee stuurt. Als je het wachtwoord als bericht mee stuurt, ja dan is je wachtwoord inderdaad te decoderen, maar als je hier een een random hex van maakt, kun je lang zoeken :)
RSA werkt dan ook met eeen publieke en geheime sleutel. Die kun je niet ontdekken. Dus zelfs als de code publiekelijk te gebruiken is, en dat is ook zo, dan nog kun je er niet achter komen. Je hebt namelijk de geheime sleutel nodig. Aangezien dit een astronomisch groot priem getal is, kun je daar niet achter komen.
Ter illustratie: het grootste priemgetal dat ooit ontdekt is bevat 13 miljoen(!!!!!!) karakters. Dus ga jij ze maar lekker allemaal bij langs, ( en je moet eerst de priemgetallen formule weten.. ) dan kun jij leuk achter de geheime sleutel komen :)
Over de classes: je moet ze wel nog een beetje tweaken, zoals de geheime sleutels, en de berichten die mee gestuurd worden, defaults zijn goed, neem daar een voorbeeld aan.
Quote:
Over het md5 en sha1 verhaal, beide zijn lek. Beide zijn tegenwoordig makkelijk te bruteforcen en kunnen door middel van raibow en dictionary aanvallen boven water gehaald worden.
Lolbroek, een hashingalgoritme *kan* niet "lek" zijn. Het is onomkeerbaar, er gaat data verloren die je dus nooit meer terug kan krijgen.
Daarmee zeg ik dan niet dat je totaal ongelijk hebt: door de onvoorzichtigheid van de meeste mensen is het makkelijk te bruteforcen omdat wachtwoorden vaak maar 6-8 tekens zijn. Dat duurt absoluut niet lang.
Wat je hier tegen kunt doen? Salt en pepper gebruiken, wat een vorm van "security through obscurity" is. Het lijkt veiliger, maar is dat alleen zolang de salt en pepper geheim blijven.
Waar het uiteindelijk op neerkomt is dat het niet zozeer de wachtwoorden zijn waar je je zorgen om moet maken, maar om dat iemand je server binnen kan komen zonder dat je het wil. Niet zo lastig uiteindelijk: zorg ervoor dat (bijvoorbeeld) SSH-toegang alleen met een certificaat mogelijk is. Onmogelijk omheen te komen, omdat zo'n certificaat "raden" eeuwig *kan* duren.
Zelfde met je databaseserver (indien je deze los hebt): zorg ervoor dat je de mogelijke verbindingen beperkt tot IP's waarvan je zeker weet dat het toegestaan moet zijn. SSL is daarbij dan ook weer geen overbodige luxe, dat kan alsnog weer worden onderschept, dan ben je het bokje.
Enfin, mijn punt: veiligheid is beperkt tot het IQ van degene die het ontwerpt.
Merijn schreef op 02.02.2010 18:55:
[...]
Er zit een encryptie en decryptie in. [..]
Er zit een encryptie en decryptie in. [..]
Wat versta jij dan onder decryptie?
RSA en AES hebben een geheime sleutel, en coderen een bericht. Dat bericht moet gedecodeerd kunnen worden. ( Denk aan SSL ).. Dit zou je wachtwoord kunnen zijn. Ik bedoel, RSA en AES kunnen voor veel dingen gebruikt worden. Maar als ik het gebruik voor het coderen van wachtwoorden, verzin ik wel een random hash als bericht. Daarmee krijg je je wachtwoord nooit meer terug.
@Richard, toegegeven ze zijn niet lek, maar jij weet net zo goed als veel andere mensen dat MD5 en SHa1 niet veilig meer zijn. Alleen al om de reden dat ze gebruteforced kunnen worden dmv rainbow tables en dictionary aanvallen.
Aangezien MD5 en SHA1 de meest gebruikte hash methoden zijn, is er al heel wat data over bekend, en ook al zijn de algoritmes niet bekend, en zullen ze dat ook niet worden, dan nog ben je kwetsbaar met deze methodes.
Salts bieden tegenwoordig ook echt niet meer de luxe dat het onkraakbaar is, omdat ook de (random) salts opgeslagen moeten worden. Dus als dit al het geval is, en je database is kwetsbaar, waardoor de (random) salts ook boven water komen, kan het alsnog gebruteforced worden.
Maar het klopt wel helemaal wat je zegt. Je beveiliging is zo sterk als het zwakste punt, en dat is vaak de programmeur. Nou kun je stellen dat veel programmeurs een laag IQ hebben , immers, veel systemen zijn niet echt zwaar beveiligd, desalnietemin denk ik niet dat dit het geval is.
Toch raad ik aan een externe class te gebruiken voor encryptie. Niet om het feit dat md5 of sha1 of hash() zo onveilig zijn, maar neem het zekere voor het onzekere. En SSL maakt ook gewoon gebruik van RSA, een certificaat is ook niets meer dan dat jij de publieke sleutel krijgt met handtekening. Alles wat jij verstuurt met die sleutel weet de server( van waaruit het certificaat is uitgegeven ) wel wat er mee moet gebeuren.
En op IP toegang verschaffen biedt natuurlijk ook weer veel onveiligheden. Publieke IP adressen en proxy`s bijvoorbeeld.
Gewijzigd op 01/01/1970 01:00:00 door Pieter Jansen
Dus ja, een salt zal ik bijna alle gevallen wel goed werken. Maar ik kies er niet meer voor. Ik ga liever voor 5 minuten extra werk, en codeer alles op een manier die niet terug te halen is.
En als jij AES in twijfel trekt, trek jij de gehele Amerikaanse Defensie beveiliging in twijfel. Deze maken gebruik van 1024bit AES encryptie.
Ik gebruik "slechts" 256bits AES momenteel.
Pagina: « vorige 1 2 3 ... 35 36 37 38 volgende »