Bcrypt
Pagina: « vorige 1 2 3 4 5 volgende »
en van die 07 was een reactie op deze post:
Henze Berkheij op 20/12/2012 10:42:41:
nee..dan is hij niet random, maar dan krijg je unexpected behaviour omdat de crypt functie dan zelf gaat bepalen welk algoritme er gebruikt gaat worden..
is the way to go: de 2a geeft aan dat het gaat om blowfish_encrypt gaat welke je moet hebben, 07 is de cost die je opgeeft waarmee je de functie trager of sneller kan laten gaan.
is the way to go: de 2a geeft aan dat het gaat om blowfish_encrypt gaat welke je moet hebben, 07 is de cost die je opgeeft waarmee je de functie trager of sneller kan laten gaan.
@Chris...het idee van een Salt is om rainbow tabellen tegen te gaan. Dit zijn lijsten met wachtwoorden in bepaalde hashes. gebruik je geen salt, is dat makkelijk gedaan. gebruik je een single salt, hoeft de hacker alleen de salt nog te weten om een rainbow tabel te genereren. heb je een random salt dan zal het genereren van genereren van rainbow tabellen geen nut meer hebben omdat dat te lang gaat duren.
Dus wat kan ik nu het beste doen? een random salt gebruiken (en die opslaan in de database bij het registreren van een user) of een vaste salt gebruiken.
Gewijzigd op 20/12/2012 10:59:10 door - Marco -
Henze Berkheij op 20/12/2012 10:57:23:
@Chris...het idee van een Salt is om rainbow tabellen tegen te gaan. Dit zijn lijsten met wachtwoorden in bepaalde hashes. gebruik je geen salt, is dat makkelijk gedaan. gebruik je een single salt, hoeft de hacker alleen de salt nog te weten om een rainbow tabel te genereren. heb je een random salt dan zal het genereren van genereren van rainbow tabellen geen nut meer hebben omdat dat te lang gaat duren.
Rainbow/dictionary attack het is maar hoe je het beestje wilt noemen. Beide houdt het zelfde in, een db met woorden en hun bijbehoorde hashes.
Er is overigens een groot verschil tussen random (Bijvoorbeeld een 'faceroll' over je keyboard) of een random salt met bijvoorbeeld rand(). De eerste is random maar statisch en veranderd niet, de tweede zal telkens wijzigen wat niet werkt voor vergelijkingen.
Gewoon eenmalig een 'random' salt maken en deze als string declareren aan $salt in een config file. Dus bijvoorbeeld $salt = 'JKL*^234-0dfg;j*()^d';
Deze dan in elke crypt() toevoegen.
Dus niet telkens een nieuwe random maken maar 1x een random salt en deze hergebruiken.
Gewijzigd op 20/12/2012 11:04:09 door Chris PHP
Chris NVT op 20/12/2012 11:01:48:
de tweede zal telkens wijzigen wat niet werkt voor vergelijkingen.
Dat kan toch wel werken als je die random salt die dan gegenereerd is op de pagina (tijdens het registreren) in de database opslaat? en dan tijdens het inloggen de username vergelijkt met username en dan de salt uit de database haalt en dan het ingevulde wachtwoord encrypt met die salt en dan ook het wachtwoord vergelijkt?
Want dat kan toch ook en zoals ik van Henze begreep was dat dus ook veiliger?
stappenplan die ik voor ogen heb en jij hopelijk ook is
1. wachtwoord wordt ingevoerd
2. script genereerd random salt, bcrypt wachtwoord met deze salt en plakt de random salt aan de bcrypted wachtwoord.
3. gebruiker wil inloggen en voert wachtwoord in
4. script knipt de salt van het in de db opgeslagen wachtwoord
5. met de salt wordt het wachtwoord opnieuw gebcrypted.
6. vervolgens wordt hiermee vergeleken of er het zelfde uitkomt
piece of cake toch?
Nogmaals een database is over het algemeen gevoeliger voor hacken dan .php bestanden. Dus als jij in je users tabel een veld maakt rand_salt of iets dergelijks en daar je salt in plakt, is dat velemalen gevoeliger dan een statische $salt in je config file.
Het is aan jou wat je wil.
Toevoeging op 20/12/2012 11:10:15:
@Henze,
Piece of cake? Ik vind het behoorlijk omslachtig en overdreven. Het is nergens voor nodig om elke gebruiker een eigen salt te geven, wanneer je gewoon een sterke salt maakt en deze verwerkt in je crypt (SHA256 aangeraden) zit je safe.
Waarom z'n omslachtig script gaan schrijven en salt's opslaan in een database?
Dat het wat meer tijd kost om dan in te loggen, is overigens een voordeel.
Gewijzigd op 20/12/2012 11:59:30 door Erwin H
in mijn geval is zo'n hacker jaren bezig om een klein deel te kraken...
Hoe wil jij doormiddel van een SQL query te manipuleren (niet geescapte input van $_POST of $_GET) een 'script' zodanig aanpassen dat je ineens alles kan laten echo'en?
Toevoeging op 20/12/2012 11:30:14:
@Erwin,
Jou aanpak is dan logischer en stukken 'makkelijker' uit te voeren zonder salt's op te slaan in een db. Zolang je idd niet wijzigende gegevens van een gebruiker hanteert is dat een mooie oplossing, en genereerd een unieke salt per user.
@Marco,
Mocht je toch een unieke salt per user willen, zou ik de methode van Erwin aanhouden.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<?php
function generateCode($length=8)
{
$string = "";
$possible = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*()-_+=";
for($i=0;$i < $length;$i++)
{
$char = $possible[mt_rand(0, strlen($possible)-1)];
$string .= $char;
}
return $string;
}
// Deze word opgesladen in de database bij de registratie van een gebruiker
echo generateCode(40)."\n";
echo "<br>";
?>
function generateCode($length=8)
{
$string = "";
$possible = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*()-_+=";
for($i=0;$i < $length;$i++)
{
$char = $possible[mt_rand(0, strlen($possible)-1)];
$string .= $char;
}
return $string;
}
// Deze word opgesladen in de database bij de registratie van een gebruiker
echo generateCode(40)."\n";
echo "<br>";
?>
Ik krijg alleen het laatste stukje niet werkend:
en dan later als de gebruiker wilt inloggen checken USERNAME=USERNAME
en dan pakt die het opgeslagen salt uit de db en encrypt die het password en vergelijkt die dat.
Gewijzigd op 20/12/2012 11:51:02 door - Marco -
Chris NVT op 20/12/2012 11:14:48:
Zolang je idd niet wijzigende gegevens van een gebruiker hanteert is dat een mooie oplossing, en genereerd een unieke salt per user.
Dat is inderdaad wel key. Als je bijvoorbeeld zijn geboortedatum neemt en die blijkt opeens toch niet te kloppen...
@Marco,
Genereer dat random nummer dan buiten de functie en geef het mee aan de functie. Anders moet je het vanuit de functie terugsturen.
Als je toch perse je salt wilt opslaan moet je dat maar doen, ik raad het alleen niet aan. Ga voor de methode van Erwin, stukken veiliger en makkelijk te hanteren.
Behalve UserID voor de rest kan de user alles aanpassen.
En om van userid een random salt te maken heeft net zo veel effect als helemaal een random salt te maken.
Gewijzigd op 20/12/2012 12:00:26 door - Marco -
Ook met variabele gegevens werkt de methode van Erwin, ook vrij simpel aan te passen.
Stel je maakt gebruik van bijvoorbeeld voornaam, achternaam en geboortedatum om een salt te genereren. Dan is het heel makkelijk aan te passen wanneer een gebruiker bijvoorbeeld zijn achternaam wijzigd.
In de profiel wijzigen pagina waar de gebruiker dus zijn gegevens kan wijzigen laat je hem zijn gegevens wijzigen. Dus stel hij is aangemeld met piet hein, en hij maakt er jan hein van. Dan kun je dus voor het opslaan de gebruiker verplichten zijn wachtwoord in te vullen (ter beveiliging als reden bijvoorbeeld).
Op dat moment genereer je op de zelfde gegevens een nieuwe hash met zijn wachtwoord en gewijzigde naam, en sla je dit vervolgens op. Dus dan is de hash aangepast naar de nieuwe 'vaste' gegevens als salt, en heb je geen problemen tijdens het inloggen.
Vrij makkelijk te maken zie je wel.
Gewijzigd op 20/12/2012 12:05:15 door Chris PHP
Pagina: « vorige 1 2 3 4 5 volgende »