Vad baserar du de på? Saltet bör varken i applikationen eller i databasen, så ja skulle snarare säga att chansen är liten.

Jag baserar det på att de flesta implementationer av lösenordssäkerhet jag har sett antingen har saltet i koden eller i databasen. Samt att man "räknar" med att saltet är känt för hackaren när man bedömer hur lätt eller svårt det är att komma över lösenorden.

Sen finns det säkert en hel del lösningar där saltet inte är "direkt" tillgängligt, men i de flesta fall är saltet tillgängligt och då bör man, som sagt enligt mig, inte använda MD5, utan någon annan bättre metod för att säkra lösenorden.

Varför skyddar man lösenorden över huvud taget? Det ska ju vara omöjligt att komma åt databasen iaf? Då kan de lika gärna lagras i ren text? Men både du och jag vet att så är inte fallet. Det finns alltid risker och då är det bättre att vara förberedd på bästa möjliga sätt, eller hur?

Vad är din anledning till att man inte ska använda en bättre metod (i mina ögon) än MD5? Du säger att chansen är liten att man kommer över saltet? Men då finns det ändå en risk och varför ska man då inte försöka försvåra (utan att påverka applikationen negativt) så mycket som möjligt för att minimera denna risk?

Men jag tror dock inte vi behöver dra detta längre. Du har din lösning och jag skulle välja en annan, tror jag :)

Men det är ju ingen update, utan en insert med en "on duplicate key"-clause. Därmed stämmer det att man inte kan göra en update. Sedan fungerar bara den där lösningen på MySQL så orginallösningen är den klart säkraste lösningen om man inte har access till systemet.