[PHP/SQL] Username en Password hashen met MD5 *

[Verwijderd]

Als beveiliging is dit dan is dit naar mijn inzicht wel een aardige methode om veilig te controleren en niet dubbel.


MD5, word gebruikt in dit voorbeeld maar zou ook een andere hash methode kunnen zijn!

code:

$usernameHash = md5($_POST['username']);
$passwordHash = md5($_POST['password']);

code:

SELECT * FROM `users` WHERE md5(`username`) = '$usernameHash' AND `password` = '$passwordHash'

Hierdoor hoef je enkel bij registratie te controleren. Ik weet alleen niet hoe intensief de MD5() functie in een query is..

Als de query goed is en rijen terug geeft dan kan je stellen dat de bij registratie ingevoerde data geldig/veilig was en $_POST['username'] gewoon terug naar een sessie schrijven etc.

Zeg het maar als ik iets over het hoofd zie ^^

[ Voor 12% gewijzigd door Verwijderd op 22-04-2008 11:44 . Reden: Kleine aanpassing ]

[Kettrick]

Md5 is opzich niet bijzonder zwaar, maar als je 20.000 users hebt laat je je DB nu wel 20.000x md5 doen, ik zou hier zelf niet direct voor kiezen . Daarnaast is een md5 hash ook niet uniek.

verder is het mij niet helemaal duidelijk hoe je dit in wil passen, iets meer info en een duidelijkere titel zou handig zijn

[storeman]

waarom een hash op username? De username moet uniek zijn, daarom kun je een constraint op deze kolom zetten. Als de rij uniek is, wil dit niet zeggen dat de hash hiervan ook uniek is. Dus die hash verwijderen.

Daarnaast is md5 nou niet bepaald een intensieve functie, dus daar zou ik niet voor vrezen.

[Johnny]

RoeLz schreef op dinsdag 22 april 2008 @ 11:40:
Md5 is opzich niet bijzonder zwaar, maar als je 20.000 users hebt laat je je DB nu wel 20.000x md5 doen, ik zou hier zelf niet direct voor kiezen . Daarnaast is een md5 hash ook niet uniek.

verder is het mij niet helemaal duidelijk hoe je dit in wil passen, iets meer info en een duidelijkere titel zou handig zijn

Nee, gemiddeld maar 10.000 keer want hij kan stoppen zodra de gebruiker gevonden is en hoeft dus niet alle gebruikers af te gaan.

[Verwijderd]

Titel kan ik volgens mij niet meer aanpassen.

Dit is bedoeld om overbodig user input te controleren te voorkomen.

En vandaar ook mijn opmerking: "Ik weet alleen niet hoe intensief de MD5() functie in een query is.."

Want dat is inderdaad een aandachts puntje met 20k gebruikers.

[RobIII]

Het is onzin om een username te hashen; geef me 1 goede reden...

Johnny schreef op dinsdag 22 april 2008 @ 11:42:
[...]

Nee, gemiddeld maar 10.000 keer want hij kan stoppen zodra de gebruiker gevonden is en hoeft dus niet alle gebruikers af te gaan.

Onzin; daarvoor moet je meer weten van het ontwerp en/of de query. Een hash garandeert niet dat het field unique is (sterker: die constraint zou je veiligheidshalve moeten verwijderen om collisions te voorkomen) en dan zou je enkel jouw 'gemiddelde halen' met een top / limit 1, anders weet je nooit zeker of er misschien nog meer records voldoen aan de criteria. Andersom kun je dan natuurlijk ook prima op de gehashte waarde zoeken (en een index gebruiken) en heb je dus niet 'gemiddeld' dat er 10.000 waardes gehashed moeten worden maar spit je gewoon ouderwets je index door. Da's dan een kwestie van je where-clause omdraaien (WHERE username = md5($usernameHash))

Hoe dan ook kom je op deze manier (zie mijn eerste zin) geheid in de knoop met dit soort vage constructies die nergens voor nodig zijn.

[ Voor 101% gewijzigd door RobIII op 22-04-2008 11:57 ]

[siknu]

Misschien wilt hij naast een niet af te vangen password ook een niet af te vangen username over de lijn sturen.

Sla gewoon gelijk met de eerste keer de plaintext username en de md5 hash van die username op. Dan hoef je die niet meer dynamisch iedere keer te genereren in je database maar staat hij gewoon vast opgeslagen.

[ Voor 21% gewijzigd door siknu op 22-04-2008 11:47 ]

[Kettrick]

Johnny schreef op dinsdag 22 april 2008 @ 11:42:
[...]

Nee, gemiddeld maar 10.000 keer want hij kan stoppen zodra de gebruiker gevonden is en hoeft dus niet alle gebruikers af te gaan.

Ik ga altijd uit van het worstcase scenario , maar mijn punt is duidelijk volgens mij. Zoals storeman ook al aangeeft, waarom zou je je username hashen ?. Een hash is daar niet geschikt voor, ongeacht de soort hash.

[Hydra]

Edit: doh.

[ Voor 96% gewijzigd door Hydra op 22-04-2008 11:50 ]

[Janoz]

Verwijderd schreef op dinsdag 22 april 2008 @ 11:43:
Titel kan ik volgens mij niet meer aanpassen.

Maar je kunt middels een topic report wel even een voorstel doen. Ik heb geen zin om een titel voor je te bedenken..

[Kettrick]

Hydra schreef op dinsdag 22 april 2008 @ 11:48:
[...]


Ik vermoed dat hij de username en userhash in de DB opslaat.

Waar je dat vermoeden vandaan haalt is me niet duidelijk, komt niet echt uit de TS toch ?, daarnaast is ook dat helemaal nergens goed voor

[Hydra]

RoeLz schreef op dinsdag 22 april 2008 @ 11:49:
Waar je dat vermoeden vandaan haalt is me niet duidelijk, komt niet echt uit de TS toch ?, daarnaast is ook dat helemaal nergens goed voor

Kwestie slecht de vraag lezen

[Verwijderd]

Username word niet gehashed, maar enkel op deze manier gechecked om SQL injections te voorkomen.

[RobIII]

Verwijderd schreef op dinsdag 22 april 2008 @ 11:51:
Username word niet gehashed, maar enkel op deze manier gechecked om SQL injections te voorkomen.

Dat is wel een héél creatieve manier om SQL injection te voorkomen; je hebt zojuist een vierkant wiel uitgevonden

Over het gebruik van Parametrized Queries

[ Voor 15% gewijzigd door RobIII op 22-04-2008 11:52 ]

[Janoz]

Ah, het voorkomen van sql-injecties is je eigenlijke vraag?

In dat geval is dit de meest zinloze oplossing die ik tegen gekomen ben. Wat is er mis met de escape functies?

[Verwijderd]

Nja alleen in dit voorbeeld, en die escape functies zijn idd ook een oplossing maar dit is een manier om daar geen gebruik van te maken.

[RobIII]

Verwijderd schreef op dinsdag 22 april 2008 @ 13:03:
Nja alleen in dit voorbeeld, en die escape functies zijn idd ook een oplossing maar dit is een manier om daar geen gebruik van te maken.

Nee, dit is een manier om jezelf met handen en benen in de knoop te leggen totdat je je nek en rug breekt. Je gebruikt een schoenzool om een schroef in een plank te draaien. Je misbruikt een functie voor een compleet ander doel dan waar 'ie voor bedoeld is. Je doet aan symptoombestrijding terwijl je het 'probleem' moet bestrijden.

[Kettrick]

Verwijderd schreef op dinsdag 22 april 2008 @ 13:03:
Nja alleen in dit voorbeeld, en die escape functies zijn idd ook een oplossing maar dit is een manier om daar geen gebruik van te maken.

Heb je een reden dat je geen escape functies wil gebruiken?

[!null]

Hoe doen jullie dat trouwens, met escapen?
Zo'n soort constructie?

PHP:

if (get_magic_quotes_gpc()) {
    $name = stripslashes($name);
}
$name = mysql_real_escape_string($name);
mysql_query("SELECT * FROM users WHERE name='{$name}'";);

Al ben ik niet zo gecharmeerd van het gebruiken van een variabele door de string heen, maar dat is een detail.

[RobIII]

GreenSky schreef op dinsdag 22 april 2008 @ 14:13:
Hoe doen jullie dat trouwens, met escapen?
Zo'n soort constructie?

Kijk eens: RobIII in "\[PHP/SQL] Username en Password hashen me...". Daar staat een hele mooie link in welke weer op zijn beurt verwijst naar 'Escapen' van quotes in queries?

[ Voor 20% gewijzigd door RobIII op 22-04-2008 14:16 ]

[storeman]

RobIII schreef op dinsdag 22 april 2008 @ 13:04:
[...]

Nee, dit is een manier om jezelf met handen en benen in de knoop te leggen totdat je je nek en rug breekt. Je gebruikt een schoenzool om een schroef in een plank te draaien. Je misbruikt een functie voor een compleet ander doel dan waar 'ie voor bedoeld is. Je doet aan symptoombestrijding terwijl je het 'probleem' moet bestrijden.

Prima metafoor!

[ Voor 1% gewijzigd door een moderator op 22-04-2008 14:18 . Reden: Typo uit m'n eigen quote verwijderd 8)7 ]

[DizzyWeb]

GreenSky schreef op dinsdag 22 april 2008 @ 14:13:
Hoe doen jullie dat trouwens, met escapen?
Zo'n soort constructie?

PHP:

if (get_magic_quotes_gpc()) {
    $name = stripslashes($name);
}
$name = mysql_real_escape_string($name);
mysql_query("SELECT * FROM users WHERE name='{$name}'";);

Al ben ik niet zo gecharmeerd van het gebruiken van een variabele door de string heen, maar dat is een detail.

Dat detail is anders simpel te verhelpen

Overigens gebruik ik die magic_quotes dinges niet, ik weet wat ik op mijn eigen server aan heb staan. Veder zet ik de query altijd in een variabele.

PHP:

$name = mysql_real_escape_string($name);
$sql = "SELECT * FROM users WHERE name='" . $name . "'";
mysql_query($sql);

Zoiets zou het bij mij zijn dus.

[!null]

Ja dat ben ik met je eens, zoals jij het hebt geschreven is het ook een stuk duidelijker. (dat bedoelde ik ook met het detail) Ik had gewoon even ergens een voorbeeldje vandaan geplukt.

@RobIII, ik had dat parametrized gebeuren al bekeken, dat is duidelijk de netste oplossing. Het ging mij de escape functies die mensen hier gebruiken tegen SQL injection.

Maar het is duidelijk zo.

[ Voor 5% gewijzigd door !null op 22-04-2008 14:29 ]

[SinergyX]

DizzyWeb schreef op dinsdag 22 april 2008 @ 14:19:
[...]


Dat detail is anders simpel te verhelpen

Overigens gebruik ik die magic_quotes dinges niet, ik weet wat ik op mijn eigen server aan heb staan. Veder zet ik de query altijd in een variabele.

PHP:

$name = mysql_real_escape_string($name);
$sql = "SELECT * FROM users WHERE name='" . $name . "'";
mysql_query($sql);

Zoiets zou het bij mij zijn dus.

Nu wil er niet helemaal een nieuw topic voor openen, maar wordt dit steeds op grotere schaal 'misbruikt'? Krijg nu echt hoge bloeddruk, hardslag omhoog omdat ik nog ergens simpele queries heb draaien op een website

[RobIII]

SinergyX schreef op dinsdag 22 april 2008 @ 14:31:
[...]

Nu wil er niet helemaal een nieuw topic voor openen, maar wordt dit steeds op grotere schaal 'misbruikt'? Krijg nu echt hoge bloeddruk, hardslag omhoog omdat ik nog ergens simpele queries heb draaien op een website

Aanval #1 als je een website wil 'hacken'. Nogal wiedes, hier kun je het meeste mee. En dat gaat heus niet 'wel een keer over'.

[SinergyX]

Kijk, dat is duidelijk Toch maar een week vrijmaken om alles door te bladeren

sorry voor kleine hijack

@hieronder, het is geen login, maar 'enkel' een submit query. Was juist van plan hele gebeuren op de schop te gooien en opnieuw te bouwen, maargoed dat ik dit topic tegenkwam

[ Voor 62% gewijzigd door SinergyX op 22-04-2008 14:44 ]

[!null]

SinergyX schreef op dinsdag 22 april 2008 @ 14:31:
[...]

Nu wil er niet helemaal een nieuw topic voor openen, maar wordt dit steeds op grotere schaal 'misbruikt'? Krijg nu echt hoge bloeddruk, hardslag omhoog omdat ik nog ergens simpele queries heb draaien op een website

Dus... welke sites heb jij zoal gemaakt?
Het is hier geen HK...

[ Voor 4% gewijzigd door RobIII op 22-04-2008 14:47 ]

[RobIII]

SinergyX schreef op dinsdag 22 april 2008 @ 14:38:
Kijk, dat is duidelijk Toch maar een week vrijmaken om alles door te bladeren

sorry voor kleine hijack

@hieronder, het is geen login, maar 'enkel' een submit query. Was juist van plan hele gebeuren op de schop te gooien en opnieuw te bouwen, maargoed dat ik dit topic tegenkwam

Login, zoekquery, whatever. Het maakt geen drol uit welke query het is of wat 'ie doet. Als 'ie vatbaar is voor SQL injection dan ben je de pineut. Het is dus niet zo alsof enkel login-queries vatbaar zijn voor SQL injection Als je dat denkt moet je je toch even wat meer in de materie verdiepen

[ Voor 14% gewijzigd door RobIII op 22-04-2008 14:48 ]