[PHP] Crypt () en salt.

[Bor]

Ik ben wat scripting een noobie maar bezig daar verandering in te brengen

Op dit moment ben ik bezig met het experimenteren met het creeren van htaccess wachtwoorden mbv een php script. Hier zijn al meerdere topics over geweest die ik door heb gelezen. Helaas is mijn vraag tot nu toe nog niet beantwoord. Welnu,
ik begrijp dat men mbv de crypt functie een hash kan genereren van een willekeurige string (zoals password). Hierbij wordt de salt gebruik welke de encryptie beinvloed. Ik kom er echter niet achter waar die salt nou precies voor dient.

In scripts zie ik vaak dat de eerste 2 letters van de username als salt gebruikt worden. Is dit wel zo slim?

Wie kan mij uitleggen wat de salt precies doet en hoe deze goed te gebruiken?

Thanks in advance!

[TlighT]

De salt zorgt ervoor dat twee dezelfde passwords niet dezelfde hashcodes geven.

Meestal gebruiken ze (een gedeelte van) de username als salt omdat deze voor elke user verschillend is; op deze manier krijgt elke user een andere hashcode.

Een simpele methode om een hashcode met salt te genereren, is de salt achter het password te plakken en daarvan de hash te nemen.

Je kunt ook een aantal random tekens als salt nemen en deze achter de hashcode zelf plakken, zodat je de salt alleen nog maar bij het genereren van het password nodig hebt (bij het controleren gebruik je de salt uit het hashcode zelf).

Edit: grmbl... maak teveel fouten

Edit2: Voor de duidelijkheid: als je een salt gebruikt, maak je het voor eventuele hackers moeilijker om een dictionary attack te gebruiken.

[ Voor 25% gewijzigd door TlighT op 31-03-2003 12:41 ]

[Bor]

Een salt is een soort encryptie seed dus waarop de verdere encryptie wordt gebaseerd? M.a.w als ik geen salt opgeef neemt ie dan een random waarde als salt (en dus altijd goed volgens jouw uitleg) of 1 vaste waarde (en dus minder veilig). Een random waarde lijkt me niet echt mogelijk namelijk, dan krijg je elke keer een ander antwoord uit de hash toch en kun je nooit vergelijken?

[.oisyn]

Allereerst is het geen encryptie maar een hash algoritme
Als je de hash bekijkt dan zie je dat de eerste 2 tekens van de hash altijd de eerste 2 tekens van de salt zijn. Uit de hash kun je dus ook de salt halen. Een random salt werkt dus prima, aangezien je gewoon de hash kunt gebruiken als salt:

PHP:

$hash1 = crypt ($password);
$hash2 = crypt ($password, $hash1);

if ($hash1 == $hash2)
    echo "gelijk!";
else
    echo "ongelijk!";

dit stukje code output "gelijk!"

.edit:
$hash1 wordt dus gegenereerd bij het opnieuw zetten van een wachtwoord. De hash stop je bijvoorbeeld in een database, en als de betreffende user wilt inloggen dan hash je het opgegeven wachtwoord met als salt de hash die al in je database staat (dit wordt $hash2). Als de 2 hashes gelijk zijn dan is het ingevulde wachtwoord dus correct

[ Voor 26% gewijzigd door .oisyn op 31-03-2003 15:19 ]

[Bor]

Eeh.. Stapje terug. Als je dezelfde salt gebruikt krijg dezelfde uitkomst bij 2 keer dezelfde bewerking. Maar als je dan verschillende salts gebruikt krijg je toch ook verschillende uitkomsten? Of zie ik het nu verkeerd? Als je dus bijvoorbeeld de eerste 2 tekens van de username gebruikt worden dit ook de 2 eerste tekens van de hash? Draai ik iets om of lees ik het verkeerd? Is jouw voorbeeld niet sterk afhankelijk van de lengte van de salt?

[ Voor 9% gewijzigd door Bor op 31-03-2003 15:42 ]

[.oisyn]

Alleen de eerste 2 tekens van een opgegeven salt worden gebruikt. Dus "blabla" en "bloblo" zijn dezelfde salt (ze beginnen allebei met "bl"). Verder zei ik dat die 2 tekens van de salt voor de hash worden geplakt. Een paar voorbeelden:

crypt ("geheim", "bla") = blgVPl9L8AJ7Q
crypt ("geheim", "blaat") = blgVPl9L8AJ7Q
crypt ("geheim", "blgVPl9L8AJ7Q") = blgVPl9L8AJ7Q

waarom? omdat alle salt's beginnen met "bl"
Je kunt dus prima een random salt gebruiken aangezien die 2 random tekens voor de hash worden geplakt:

crypt ("geheim") = se4GDvlgfsmng
crypt ("geheim", "se4GDvlgfsmng") = se4GDvlgfsmng

hier is "se" dus als random salt gebruikt

[ Voor 4% gewijzigd door .oisyn op 31-03-2003 15:54 ]

[Bor]

Even terug naar een oud probleem. Ik las mijn bookmarks nog eens door en kwam tot de ontdekking dat dit toch nog niet helemaal helder voor me is.

Als ik het goed begrijp gebruikt je dus een salt om de hash (one way encryptie) van de users met hetzelfde password toch anders te maken. Klopt dit?

Verder wat kun je beter gebruiken om wachtwoorden in een db op te slaan, de crypt (string, salt) functie of de md5(string) functie en waarom?

Onderstaand voorbeeld van .oisyn:

blgVPl9L8AJ7Q -> uit deze hash kunnen we de salt extracten, dit zijn namelijk de eerste 2 letter. Wat heeft de salt dan nog voor zin? Een attacker kan deze 2 karakters toch ook net zo makkelijk extracten, of zie ik nu iets belangrijks over het hoofd?

[ Voor 25% gewijzigd door Bor op 22-11-2003 11:41 ]

[Anoniem: 35513]

Een hacker kan thuis een heleboel wachtwoorden encrypten, zodat hij een lijstje heeft welk wachtwoord bij welke hash past. Hij kan dan vervolgens voor alle hashes in de hele wereld het wachtwoord achterhalen. Om dit tegen te gaan is de seed uitgevonden, waardoor je zo'n lijstje 4096 keer moet maken om zulke dingen te kunnen doen.

[Bor]

Anoniem: 35513 schreef op 22 november 2003 @ 13:30:
Een hacker kan thuis een heleboel wachtwoorden encrypten, zodat hij een lijstje heeft welk wachtwoord bij welke hash past. Hij kan dan vervolgens voor alle hashes in de hele wereld het wachtwoord achterhalen. Om dit tegen te gaan is de seed uitgevonden, waardoor je zo'n lijstje 4096 keer moet maken om zulke dingen te kunnen doen.

Ok dat begrijp ik , maar check dan mijn voorbeeld. Als je de seed voor de hash plakt heeft het toch niet veel zin meer lijkt me?

[Skaah]

is md5() niet handiger? Geeft je vier miljard+ mogelijke hashes en voor iedere user een unieke hash.

PHP:

$gehashed = md5($pwd + $user);

* Skaah weet niet precies wat het nut van crypt is voor wachtwoorden.

[Anoniem: 35513]

Bor_de_Wollef schreef op 22 november 2003 @ 11:40:
Als ik het goed begrijp gebruikt je dus een salt om de hash (one way encryptie) van de users met hetzelfde password toch anders te maken. Klopt dit?

Ja. De salt is geen geheim stukje, het is zelfs nodig om te kijken of het wachtwoord klopt. Daarom wordt de salt er meestal voor of achter geplakt. De salt zorgt dus voor een beetje variatie. Als twee mensen hetzelfde wachtwoord hebben hebben ze nu niet dezelfde encryptie daarvan.
Verder kan een hacker crypt("moederislief") doen en dan in /etc/passwd van een systeem met veel gebruikers zoeken naar de uitkomst daarvan. Als er een seed aan toegevoegd is werkt dat niet meer. Dan moet de hacker "aamoederislief", "abmoederislief", "acmoederislief", etc. uitrekenen wil hij dit trucje toepassen.

Verder wat kun je beter gebruiken om wachtwoorden in een db op te slaan, de crypt (string, salt) functie of de md5(string) functie en waarom?

MySQL manual -6.3.6.2 Miscellaneous Functions
ENCRYPT() ignores all but the first 8 characters of str, at least on some systems. This behaviour is determined by the implementation of the underlying crypt() system call. If crypt() is not available on your system, ENCRYPT() always returns NULL. Because of this we recommend that you use MD5() or SHA1() instead; these two functions exist on all platforms.

[Bor]

Anoniem: 35513 schreef op 23 november 2003 @ 12:22:
[...]

Ja. De salt is geen geheim stukje, het is zelfs nodig om te kijken of het wachtwoord klopt. Daarom wordt de salt er meestal voor of achter geplakt. De salt zorgt dus voor een beetje variatie. Als twee mensen hetzelfde wachtwoord hebben hebben ze nu niet dezelfde encryptie daarvan.
Verder kan een hacker crypt("moederislief") doen en dan in /etc/passwd van een systeem met veel gebruikers zoeken naar de uitkomst daarvan. Als er een seed aan toegevoegd is werkt dat niet meer. Dan moet de hacker "aamoederislief", "abmoederislief", "acmoederislief", etc. uitrekenen wil hij dit trucje toepassen.


[...]

Maar als je de salt voor of achter de hash plaatst weet je hem toch al? Dan zijn er maar 2 mogelijkheden per password extra lijkt me.

[ Voor 5% gewijzigd door Bor op 23-11-2003 12:49 ]

[Anoniem: 35513]

De salt is niet om het wachtwoord geheimer te maken, het is om de hash minder voorspelbaar te maken. Welk deel begrijp je nou precies niet?

[Olaf van der Spek]

Bor_de_Wollef schreef op 23 november 2003 @ 12:42:
Maar als je de salt voor of achter de hash plaatst weet je hem toch al? Dan zijn er maar 2 mogelijkheden per password extra lijkt me.

Ja, maar dan moet de aanvaller elke keer opnieuw hashen, terwijl dat zonder salt maar een keer hoeft.

[Bor]

Anoniem: 35513 schreef op 23 november 2003 @ 13:14:
De salt is niet om het wachtwoord geheimer te maken, het is om de hash minder voorspelbaar te maken. Welk deel begrijp je nou precies niet?

Ik snap de toegevoegde waarde van de salt niet echt als de salt rechtstreeks uit de uiteindelijke hash te halen is bij bv een brute force attack.

Zelfde wat ik paar posts terug zei:

Maar als je de salt voor of achter de hash plaatst weet je hem toch al? Dan zijn er maar 2 mogelijkheden per password extra lijkt me.

Ja, maar dan moet de aanvaller elke keer opnieuw hashen, terwijl dat zonder salt maar een keer hoeft.

Dat zijn 2 hashes per password extra of zelfs 1 als je weet of de salt voor of achteraan de hash wordt geplakt.

[ Voor 37% gewijzigd door Bor op 23-11-2003 15:47 ]

[Olaf van der Spek]

Als je geen salt gebruikt, kan een aanvaller alle woorden (aantal D) in zijn woordenboek een keer hashen. Dan kan hij jouw password lijst (aantal P) afgaan en per pass kijken of dat in het woordenboek voorkomt. Dat is dus D keer hashen.

Als je wel een salt gebruikt, moet de aanvaller of elk woord hashen met alle mogelijke salts (4096x werd genoemd), of Px D woorden hashen met het bekende salt. Dat is dus D * P * W keer hashen, en dat kost meer tijd dan D keer hashen, capice?

[Bor]

OlafvdSpek schreef op 23 november 2003 @ 16:27:
Als je geen salt gebruikt, kan een aanvaller alle woorden (aantal D) in zijn woordenboek een keer hashen. Dan kan hij jouw password lijst (aantal P) afgaan en per pass kijken of dat in het woordenboek voorkomt. Dat is dus D keer hashen.

Als je wel een salt gebruikt, moet de aanvaller of elk woord hashen met alle mogelijke salts (4096x werd genoemd), of Px D woorden hashen met het bekende salt. Dat is dus D * P * W keer hashen, en dat kost meer tijd dan D keer hashen, capice?

Dat geldt inderdaad als de salt niet bekend is. Als je echter de hash kan zien, maar niet weet wat het originele password is kun je de salt bepalen (de laatste 2 of eerste 2 letters). Dan is die extra bescherming toch helemaal weg? Nou juist op dit vlak ligt de kracht van een hash -> als ik de hash weet, weer ik nog niet de originele waarde (het password) welk gehashed is.

[Olaf van der Spek]

Bor_de_Wollef schreef op 23 november 2003 @ 18:36:
Dat geldt inderdaad als de salt niet bekend is. Als je echter de hash kan zien, maar niet weet wat het originele password is kun je de salt bepalen (de laatste 2 of eerste 2 letters). Dan is die extra bescherming toch helemaal weg? Nou juist op dit vlak ligt de kracht van een hash -> als ik de hash weet, weer ik nog niet de originele waarde (het password) welk gehashed is.

Nee, mijn verhaal gaat over het geval waarin het salt wel bekend is.
Salts zorgen er voor dat een attack meer tijd kost (wat indirect de veiligheid verhoogt), maar ze verhogen niet direct de veiligheid.

[ Voor 12% gewijzigd door Olaf van der Spek op 23-11-2003 18:53 ]

[Bor]

OlafvdSpek schreef op 23 november 2003 @ 18:43:
[...]

Nee, mijn verhaal gaat over het geval waarin het salt wel bekend is.
Salts zorgen er voor dat een attack meer tijd kost (wat indirect de veiligheid verhoogt), maar ze verhogen niet direct de veiligheid.

Als de salt bekend is hoef je dus niet meer alle mogelijke saltst te proberen zoals je zegt in:

Als je wel een salt gebruikt, moet de aanvaller of elk woord hashen met alle mogelijke salts (4096x werd genoemd),

Dan is het toch gewoon een extra hash?!

[ Voor 4% gewijzigd door Bor op 23-11-2003 19:42 ]

[Soultaker]

Er zijn wat misverstanden ontstaan. Ten eerste is het zo dat de salt bepalend is voor de uitkomst van het algoritme; hij wordt er niet pas achteraf voor- of achter geplakt. Dat zou inderdaad nergens op slaan. Hetzelfde password kan dus afhankelijk van de gebruikte salt heel verschillende uitkomsten opleveren.

Mijn tweede punt kan ik alleen maar een beetje bij elkaar gokken. Het gebruik van de salt verhoogt de beveiliging niet echt, maar ik kan me voorstellen dat het nuttig is in een situatie waarin (per ongeluk) de gecodeerde passwords beken worden. In oude UNIX-systemen kon je bijvoorbeeld gewoon /etc/passwd uitlezen, waarin de wachtwoorden in gecodeerde vorm te zien waren. Als ik dan zie dat een andere gebruiker dezelfde gecodeerde tekst achter zijn naam heeft staan als ik, dan kan ik concluderen dat 'ie (heel toevallig) hetzelfde wachtwoord had gekozen en kan ik dus als die gebruiker inloggen! Dat is natuurlijk niet de bedoeling.

De beperking tot twee karakters lijkt me ook uit dezelfde tijd stammen, toen allerlei ingewikkelde berekeningen met strings nog relatief duur waren en men waarschijnlijk om performenceredenen met 16-bits getallen wilde werken. Ik kan me voorstellen dat als je het systeem tegenwoordig toepast, je wel gewoon een hele string toestaat.