Varför? Risken för kollision är i rundaslängor 2^-100. Vilket f.ö endast är relevant när de kommer till signering.

Nu är vi en hel del offtopic. Mitt fel så jag ber så mycket om ursäkt för detta.

Jag tolkade koden som om att det var en tabell med alla användare.
Då är det bättre att använda något annat än MD5 för att skydda lösenorden om någon skulle komma över databasen.

För att återgå till frågan så tycker jag det är väldigt oseriöst att lägga in en bakdörr i koden på detta sätt. Även om det "bara" var för att kunna använda ett adminkonto under utvecklingen. Då är det mycket bättre att be om att få tillgång till ett konto, om det behövs.

Ja, men varför. De va de som va frågan. Varför använda te.x SHA1 över MD5 när de kommer till att hasha lösenord.

Off-topic som sagt, men ett problem med t.ex. MD5 är ju att den är _för_ "snabb". Det går att generera en hash på mycket kort tid.

Vill man inte att det ska vara snabbt?
Nej, då blir det ju betydligt enklare att knäcka.

Använd t.ex. Bcrypt istället. Den är långsam och betydligt säkrare än t.ex. MD5.

Här finns lite mer info (lite gammal kanske...)
http://codahale.com/how-to-safely-store-a-password/

Då ska vi se hur långt tid de skulle ta å bruteforce:a ett saltat md5-lösenord.

Givet:
Lösenordet: a-öA-Ö0-9, 8 tecken.
Salt: a-öA-Ö0-9, 32 tecken.

En snabb GPU idag klarar att testa 5.6*10^8 lösenord / sekund.
Vilket ge c.a 10^55 år.

bcrypt är c.a 300 gånger långsammare än md5, vilket gör att samma sak skulle ta 10^58 år.

Kort och gott; sätt saker och ting i perspektiv.

Din uppgift är nu att räkna ut om hur många år lösenordet går att knäcka på under ett år enligt Moores lag.

Jag tolkade koden ovan att MD5-funktionen som användes inte använder salt, vilket gör att det inte är en bra lösning för att skydda användarnas lösenord. För om jag inte är helt fel ute så använder inte MD5() per automatik salt?

Men MD5()-funktionen som används här kanske saltar automatiskt, vad vet jag? Eller så har man saltat innan man skickar in lösenordet till MD5()-funktionen? Men annars, som sagt, byt hashfunktion. Vilket förvisso även kan innebära ett byte från MD5() till MD5() med salt. Vilket jag erkänner att jag borde ha nämnt när jag sa att man borde byta ut MD5() som hashfunktion.

Dock kan jag tycka att om man ändå ska implementera en ny version för sin hashning så kan man lika gärna gå upp några nivåer från MD5, bara för att vara på den säkra sidan (iaf några år längre). :)

Ber återigen om ursäkt att vi går helt offtopic i tråden. Dock antar jag att "alla" är helt överens om att man absolut inte bygger in liknande kod när man utvecklare något åt andra?

Vår diskussion handlade om huruvida MD5 var bra eller ej, givet att utvecklaren vet vad han/hon håller på med.

Om utvecklaren vet vad han/hon håller på med så bygger han/hon inte in möjligheter att ge sig själv adminrättigheter i koden. Så om TS har tänkt byta utvecklare så tyckte jag det även vore en bra ide att se över vilken hashfunktion som används och att detta görs på rätt sätt. Vilket i min mening innebär att inte bara förlita sig på MD5. Visst MD5 med salt är kanske ok. Dock är risken stor att en hackare även kommer över saltet, vilket i sin tur gör att det kan gå ganska snabbt att plocka fram lösenorden (om de inte är väldigt långa) från en så pass snabb hashfunktion som MD5 är.

UPDATE förutsätter att användaren redan finns.

insert ... On duplicate key update