Unieke code generator

@Jip:

Dat script decodeert niet, maar codeert gewoon brute-force alle mogelijke combinaties. En, zoals Jan al zei, dat is niet voor het avondeten klaar ;-)

Toch wel leuke info allemaal! Bij een inlogsysteem moet je dus geen korte wachtwoorden toestaan.

edit: ik heb de broncode van dat brute force script even bekeken, maar hij probeert alleen met combinatie van alphanumerieke tekens, terwijl je volgens mij nog veel meer tekens aan een md5 kunt voeren.

En inderdaad, een woordje van twee tekens heeft ie zo, maar een woord van zes tekens dat trekt ie niet.

Let wel: als er gedecode wordt is er al iets fundamenteel mis: dan is je database al ergens ten prooi gevallen aan een hacker.

Zon brute force script kwam ik laatst ook ergens tegen. Daarom hash ik altijd met een functie met verschillende dingen 8er elkaar dat is nooit te achterhalen:

<?
// Super Hash
function hash($input)
{
$input = md5($input);
$input = crc32($input);
$input = sha1($input);
$input = base64_encode($input);
$input = md5($input);
$input = crypt($input, "thijs");
$input = sha1($input);
$input = base64_encode($input);
$input = md5($input);
return $input;
}
?>

Edit:
http://www.webmastercity.nl/forum/viewtopic.php?t=12283

Je bedoeld // Super ProcessorVreetHash?

ja die ja:P

@thijs:

Door je input door meerdere hash-functies te halen maak je de output niet veiliger. Integendeel: het wordt zelfs gemakkelijker om je input te kraken.

Er zijn verschillende dingen fundamenteel mis met je gedachtengang. Om te beginnen het gebruik van crc32(). CRC-functies zijn niet gebouwd op databeveiliging en dus relatief gemakkelijk te kraken.

Vervolgens crypt(). Aangenomen dat in jouw geval de standaard Unix-crypt wordt gebruikt, kijkt die alleen naar de eerste 8 karakters van je input. Je gooit dus het grootste deel van je input weg, waardoor je input dus minder gevarieerd wordt, en dus gemakkelijker te kraken.

Ook de hash-functies gooien data weg om te voorkomen dat je de output terug kunt rekenen naar de input. Door de output daarna opnieuw te hashen vergroot je alleen maar de kans op collisions (oftewel: er komen meer input-strings die matchen op je output).

Het veiligst ben je dus door je input niet meer dan 1x te hashen, en dan nog het liefst met sha-1, aangezien md5 uit zichzelf al collision-gevoelig is (en over sha-1 wordt ook getwijfeld, al is dat nog niet bewezen).

Nee dat is niet waar Willem, doordat ik hem als laatst door de md5 haal word hij juist Wel veilig, dan krijg ik weer een 32 lange string eruit die niet de achterhalen is

Jip schreef op 23.10.2005 12:56

Daarom codeer ik wachtwoorden ook altijd twee keer met md5.
Laten we dus zeggen, gewoon wat extra beveiliging.

Volgens mij is het nog niet gezegd: dat heeft geen enkele zin :)
Je krijgt namelijk een hash, ook als je 2 keer md5 eroverheen gooit. Stel dat je 2 keer "karel" emdeevijft, zoals Jan het zo mooi noemt ;)
Dan krijg je een sterk vereenvoudigde output als x1. Ga je bruteforcen dan zal er -op den duur- ook een woord uitkomen wat ge-emdeevijft een hash heeft als x1, bijvoorbeeld "pietje". Dat woord werkt dus net zo goed als wachtwoord bij jouw inlogsysteem oid, als jouw dubbel ge-emdeevijfde "karel".

Het beste wat je imho kan doen, is een wachtwoord md5-en, vervolgens kijken of die hash toevallig niet hetzelfde is als een hash wat in een woordenboek voorkomt. Dat betekent dat je eerst een woordenboek moet omzetten naar de bijbehorende md5-waarden. Dat kost wat tijd, maar die md5-waarden kan je opslaan en - indien er geen match is- imo een goede indicatie voor veiligheid ;)

Overigens was hier, ik herhaal het maar weer even, laatst een erg leuk topic (eigenlijk meerdere) over. We gingen toen proberen een geëmdeevijft wachtwoord te kraken, en uiteindelijk is het gelukt (met tips over de lengte van het woord). Ik zal het nog eens proberen te achterhalen.

Edit: De grote md5-discussie dus. Jan zal geïnteresseerd zijn denk ik :)

Ik heb ooit een boek gehad, dat heette volgens mij
Algorithms in C++. Daar stond een leuk hoofdstuk over beveiliging in.

Ik denk dat het ook nogal uitmaakt #wat# je beveiligen wilt. Als je een ledensysteem voor de plaatselijke postduivenclub wilt maken, hoeft het niet van hetzelfde niveau te zijn dan wanneer je iets moet maken voor de RaboBank, zullen we maar zeggen.