[PHP] Digest authentication afhandelen

[eokken]

Ik zit met een vraag omtrent htaccess digest beveiliging in PHP. De wachtwoorden van mijn gebruikers staan zo in de database:

PHP:

$password = sha1(SALT . 'HetWachtwoord'); // Voorbeeldje ;-)

Bij het gebruik van htaccess basic kan je de ingevulde gebruikersnaam en wachtwoord zien en het wachtwoord ook zo muteren dat het overeenkomt met hetgeen in mijn database. Nu is het geval dat er bij htaccess digest geen wachtwoord binnenkomt in PHP maar alleen een response, die voldoet aan:

PHP:

$password = md5('username:realm:password');

Nu kan ik bij htaccess digest dus niet mijn wachtwoorden omtoveren. Ik kan wel voor elke gebruiker een tweede wachtwoord in mijn database zetten maar dat zou helemaal nergens op slaan. Heeft iemand ideeën hierover?

Erwin

[BtM909]

Helpt dit je verder: http://php.net/manual/en/features.http-auth.php?

[NMe]

Je hoeft toch niks om te toveren? Als iemand in wil loggen krijg je dat gewoon in plain text. Dat kun je toch hashen en vergelijken met je database?

[eokken]

@BtM909: Ja, daar ben ik al een hele dag mee aan het stoeien, ik doe wel iets voordat ik hier ga vragen ^^

@NMe: Voor zover ik weet krijg je bij digest authenticatie dit terug:

code:

array
  'username' => string 'Erwin' (length=5)
  'nonce' => string '4ab04702f4a2172ae62c2e457762c50e' (length=32)
  'uri' => string '/digest.php' (length=11)
  'response' => string '54122b2de11b991be5226ef819f3f5a2' (length=32)
  'qop' => string 'auth' (length=4)
  'nc' => string '00000001' (length=8)
  'cnonce' => string '076fb1828cd3cf24' (length=16)

De response die gegenereerd wordt, is (volgens mij) gebaseerd op het wachtwoord, die dus later niet meer te veranderen is. Althans: ik kan hem niet vinden.

[NMe]

Ah, ik haal Digest en Basic door elkaar. Waarom kies je niet voor Basic dan, trouwens?

Het is digest authentication, niet htaccess digest. Htaccess is niet meer dan een lokale configfile, dat heeft verder niks te maken met je beveiliging anders dan dat de meeste mensen de beveiliging meestal lokaal regelen.

[eokken]

@NMe Ja, ik wil nog wel eens htaccess digest zeggen omdat er veel mensen schijnen te zijn die het met htaccess associeren, ik zal het vanaf nu laten.

Ik wil graag extra beveiliging in mijn hele systeem inbouwen en ik gebruikte Basic maar het leek me hoog tijd om over te stappen naar Digest omdat het veel meer dingen controleert. Die controles kan ik allemaal zelf inbouwen als het niet anders is maar Digest leek me daarom een geschikte oplossing.

Is er naast 2 wachtwoorden opslaan of basic authenticatie gebruiken (en eventueel zelf de extra beveiligingen van Digest toepassen) nog een optie? Of ben ik op een dood spoor? ;-)

[NMe]

Ik heb zelf nog nooit digest authentication geprobeerd te combineren met wachtwoorden uit een database, dus ik weet er niet genoeg vanaf om te zeggen of het al dan niet op een goeie manier mogelijk is. Het enige dat ik kan verzinnen is je wachtwoorden plain text opslaan in je database zodat je die controlestring ertegen kan matchen, maar dat ga je (terecht uiteraard ) niet willen.

[eokken]

[sarcasm] Ga ik meteen uitproberen! [/sarcasm]

En het wachtwoord in mijn database zoals ik het nu heb (sha1 met salt) vervangen door het wachtwoord die digest authenticatie gebruikt is te onveilig zeker?

code:

md5($user . ':' . $realm . ':' .$password)

Stel mijn database wordt gehackt, dan hebben ze de gebruikersnaam al, de realm kan je zien bij het inloggen en als ze weten dat dit digest authenticatie is dan wordt bruteforce toch mogelijk, of heb ik het verkeerd?

[NMe]

Daar kun je ook iets anders voor doen natuurlijk:
sha1(md5($user . ':' . $realm . ':' .$password).$salt)

[CyBeR]

digest kun je alleen gebruiken als je de wachtwoorden plaintext (of een specifiek geschikte manier) opslaat.

Als je 't boeltje veiliger wilt maken zonder toeren uit te halen met de wachtwoorden kun je beter SSL gebruiken.

[eokken]

@NMe: Volgens mij is dit ook niet mogelijk, omdat je zelf helemaal geen invloed hebt op de check van het wachtwoord.

@CyBeR: SSL is me helemaal ontglipt trouwens. Ik zal morgen e.e.a lezen over SSL en certificaten maar ik vraag me wel af.. dan is een Basic authenticatie voldoende toch (omdat alles geëncrypt wordt verstuurd)?

[CyBeR]

Correct.

[eokken]

Dan weet ik voor nu voldoende en kan dit topic gesloten worden, mocht dat nodig zijn.

[.oisyn]

CyBeR schreef op vrijdag 03 augustus 2012 @ 21:51:
digest kun je alleen gebruiken als je de wachtwoorden plaintext (of een specifiek geschikte manier) opslaat.

Je moet je wachtwoorden in dat geval gewoon opslaan als md5(username : realm : password), en de response is vervolgens md5(md5(username : realm : password) : nonce : md5(method : digestURI))

Probleem is vooral dat een dergelijke MD5 hash vandaag de dag niet bijzonder veilig meer is in de database (attackers kunnen vandaag de dag met consumer hardware veel te veel hashes per seconde berekenen).

Gewoon SSL icm PBKDF2 of bcrypt voor wachtwoordopslag is een heel een stuk veiliger.

[CyBeR]

.oisyn schreef op zaterdag 04 augustus 2012 @ 01:20:
[...]

Je moet je wachtwoorden in dat geval gewoon opslaan als md5(username : realm : password), en de response is vervolgens md5(md5(username : realm : password) : nonce : md5(method : digestURI))

Probleem is vooral dat een dergelijke MD5 hash vandaag de dag niet bijzonder veilig meer is in de database (attackers kunnen vandaag de dag met consumer hardware veel te veel hashes per seconde berekenen).

Het échte probleem is dat je hash op dat moment een plaintext-equivalent wordt. Als je die hash weet, heb je genoeg om in te loggen.

[.oisyn]

Als iemand de database leeg heeft kunnen trekken dan is het in kunnen loggen onder een bepaald account wel het minste van je problemen.

[CyBeR]

.oisyn schreef op zaterdag 04 augustus 2012 @ 01:49:
Als iemand de database leeg heeft kunnen trekken dan is het in kunnen loggen onder een bepaald account wel het minste van je problemen.

Ah wel, dat ligt aan de mate van toegang he.

[franssie]

----

[ Voor 101% gewijzigd door franssie op 04-08-2012 02:09 . Reden: naar bed ]

[eokken]

De conclusie lijkt me:

1. Een SSL certificaat aanschaffen
2. Wachtwoorden opslaan als SHA1 met (evt. per-user) SALT.
3. Mezelf verdiepen in PBKDF2 of bcrypt en kijken of ik daar nog iets mee kan.

Bedankt iedereen!

[CyBeR]

eokken schreef op zondag 05 augustus 2012 @ 15:40:
2. Wachtwoorden opslaan als SHA1 met (evt. per-user) SALT.

Niks "eventueel per-user". Gewoon per user een unieke salt, anders is 't niet zo nuttig meer.

[ValHallASW]

eokken schreef op zondag 05 augustus 2012 @ 15:40:
1. Een SSL certificaat aanschaffen

Aangezien dat tegenwoordig gratis kan is er eigenlijk geen enkele reden meer om het niet te doen, zelfs al zou je digest auth gebruiken: http://www.startssl.com/ (nouja, behalve dat je ieder jaar er een nieuw certificaat in moet hangen, dat blijft natuurlijk een beetje gedoe)

[ Voor 4% gewijzigd door ValHallASW op 05-08-2012 15:58 ]

[eokken]

@CyBeR: Zoals je merkt heb ik er nog vrij weinig ervaring mee. Die unieke salt, is die gebaseerd op een aantal eigenschappen van een gebruiker of maak je een random hash die je dan ook in de database stopt?

@ValHallASW Ik wist niet dat het tegenwoordig gratis kon, bedankt voor de link. Ik ga even uitzoeken hoe en wat.

[Soultaker]

StartSSL geeft helaas alleen gratis certificates voor TLD's; niet voor subdomains, en ook geen wildcards.

[.oisyn]

Wel voor subdomains. Sterker nog, ze geven alleen een gratis certificate voor 1 subdomain, met als subject alternate name je hoofddomein. Hier heb ik een gratis certificaat van StartSSL draaien.

(Een TLD is weer wat anders, gelukkig geven ze daar geen certificaten voor )

[ Voor 16% gewijzigd door .oisyn op 05-08-2012 17:20 ]

[CyBeR]

Soultaker schreef op zondag 05 augustus 2012 @ 16:52:
StartSSL geeft helaas alleen gratis certificates voor TLD's; niet voor subdomains, en ook geen wildcards.

Alleen niet voor subdomains als jij niet de eigenaar bent van het second (of third, bij .co.uk-constructies) level domein.

eokken schreef op zondag 05 augustus 2012 @ 16:24:
@CyBeR: Zoals je merkt heb ik er nog vrij weinig ervaring mee. Die unieke salt, is die gebaseerd op een aantal eigenschappen van een gebruiker of maak je een random hash die je dan ook in de database stopt?

Je genereert gewoon een random string die je voor of achter het wachtwoord plakt. Dat stukje sla je vervolgens bij de hash op in plaintext. De meeste functies doen dat a la zo:

$1$nw8XtJ9d$BUqWiqY0cUoZHz0vNg9PF.

waar $1$ aangeeft dat 't een md5 salted hash is, 'nw8XtJ9d' de salt is en de rest na de derde $ de hash.

[eokken]

Waarom zal je in de hash aangeven wat voor encryptie gebruikt wordt?

[Gomez12]

eokken schreef op zondag 05 augustus 2012 @ 19:34:
Waarom zal je in de hash aangeven wat voor encryptie gebruikt wordt?

Waarom niet? Een goede hash heeft geen belang bij security through obscurity. En op deze manier kan je library's maken die meerdere hashes kunnen maken en toch zonder externe instellingen kunnen zien welke ze moeten hebben.

[.oisyn]

CyBeR schreef op zondag 05 augustus 2012 @ 17:38:
Je genereert gewoon een random string die je voor of achter het wachtwoord plakt.

Beter erachter ipv ervoor, zodat hij bij het brute forcen van een wachtwoord ook elke keer opnieuw moet worden berekend (ipv gewoon de interne state van het hash algoritme capturen op het moment dat de salt gedaan is en het wachtwoord nog moet)

[eokken]

CyBeR schreef op zondag 05 augustus 2012 @ 17:38:
Je genereert gewoon een random string die je voor of achter het wachtwoord plakt. Dat stukje sla je vervolgens bij de hash op in plaintext. De meeste functies doen dat a la zo:

$1$nw8XtJ9d$BUqWiqY0cUoZHz0vNg9PF.

waar $1$ aangeeft dat 't een md5 salted hash is, 'nw8XtJ9d' de salt is en de rest na de derde $ de hash.

Ik ben het nu aan het proberen maar kom er nog niet helemaal uit. Waarvoor dient die salt nu dan? Als iemand weet dat na de $ het wachtwoord komt, dan kan je dat toch negeren?

[Barryvdh]

Als het allemaal dezelfde (of geen) salt is, kan je in principe een rainbow table genereren/gebruiken, om er achter te komen wat het wachtwoord is. Met een unieke salt weet je dus wel de key, maar dan moet je per gebruiker dus opnieuw alles berekenen, dus daar is veel meer moeite voor nodig. En aan alleen de hash heb je natuurlijk niets.

[ Voor 7% gewijzigd door Barryvdh op 06-08-2012 17:50 ]

[eokken]

Ik weet niet hoe ik het moet formuleren maar wat je zegt snap ik. Maar wat is dan de procedure bij het inloggen? Wat doe je met het gedeelte: $nw8XtJ9d$ ?

[.oisyn]

Dat is de salt, die combineer je met het ingevoerde wachtwoord om de hash te berekenen, en dat compare je vervolgens met de hash (het achterste deel van het opgeslagen stuk tekst)

[Barryvdh]

Zie bijvoorbeeld http://php.net/manual/en/function.crypt.php
Die $1 geeft aan dat je MD5 gebruikt. Die nw8XtJ9d is dan de salt, en het laatste deel de hash.
Om te controleren of het wachtwoord klopt, moet je je input opnieuw hashen, en daarvoor moet je weten wat de methode is (MD5 dus in dit geval), maar ook wat de salt is (bij een nieuwe random salt, krijg je dus een andere hash, dus kan je niet controleren)

[CyBeR]

eokken schreef op maandag 06 augustus 2012 @ 17:54:
Ik weet niet hoe ik het moet formuleren maar wat je zegt snap ik. Maar wat is dan de procedure bij het inloggen? Wat doe je met het gedeelte: $nw8XtJ9d$ ?

Nou, dat is dus de salt (zonder $$ overigens gewoonlijk). Dus als je een wachtwoord aan het controleren bent, haal je uit je tabel de hash en de salt, daarna neem je het ingevoerde wachtwoord en geef je dat met de salt aan dezelfde wachtwoord-hashfunctie. En als dan het resultaat identiek is aan wat er in de tabel staat, is 't wachtwoord goed.

Dus: je neemt een wachtwoord 'blaat' en een salt 'abcdef'. Dat gooi je door je wachtwoordhashfunctie. Het resultaat is "$1$abcdef$hashdieiknietgatypen".

Later probeert iemand in te loggen. Je haalt bovenstaand resultaat uit de tabel. Vervolgens heb je de salt: 'abcdef'. Het ingegeven wachtwoord samen met de salt geef je weer aan je hashfunctie. Als dan het resultaat identiek is aan bovenstaand klopte het wachtwoord. (Of je hier met of zonder salt eraan geplakt vergelijkt maakt niet uit-- die $1 en salt zijn toch al bekend.)

De $type$salt$hash-constructie is overigens voornamelijk in gebruik bij het gebruik van crypt() functies. Daarmee zorgen ze dat ze meerdere typen hashes kunnen checken omdat ze weten welke hashfunctie gebruikt is. Dat is op zich namelijk niet altijd te zien aan alleen de hash zelf (twee verschillende 128-bits hashes zijn niet van elkaar te onderscheiden). Een andere manier die daarvoor veel gebruikt wordt is die van LDAP: {SSHA}salthash (waar salt een bepaalde vooraf vastgestelde lengte heeft).

Als jij dat handiger vindt kun je dat prima in aparte databasekolommen opslaan, dat is op zich aan jou.

[ Voor 5% gewijzigd door CyBeR op 06-08-2012 18:06 ]

[eokken]

Bedankt voor de uitleg, heb deze dagen veel gezocht naar verschillende methoden dus ik ben nogal in de war. Heb ik het zo goed begrepen: http://pastebin.com/Q8gWpErz ?

[CyBeR]

Lijkt erop. Ik zou nog gebruik maken van de hash() functie ipv direct md5() aanroepen. Uitvoer is hetzelfde maar als je besluit over te schakelen van md5 naar sha1 dan hoef je die functie niet aan te passen. (Oh, en ik zou direct naar sha1 overschakelen trouwens.)

En aangezien je op deze manier toch niet met crypt() compatibel bent, voel je vooral vrij om de $-constructie uit te voeren op de manier die je het handigst vindt.

[eokken]

SHA1 gebruik ik op dit moment inderdaad, md5 was even om te testen. De functie hash kende ik nog niet maar is wel handig, dankje. Ik denk dat ik het als aparte kolommen in de database op ga slaan. Bedankt voor alle feedback!

[Barryvdh]

Maar waarom gebruik je niet gewoon de crypt functie meteen dan?

[eokken]

Ik heb even een snippet gemaakt om te bevestigen of ik het snap of niet. Als je $6$"16-tekens-lange-salt" kiest, dan weet crypt dat ik SHA-512 wil gebruiken. Standaard gebruikte hij MD5. Zal ik dan gewoon voor SHA-512 moeten gaan of is er nog een 'slimme keuze' in dit verhaal?

Bedankt!

PHP:

<?php
$password = 'Erwin';
$hashed_password = crypt($password, '$6$dFbGiJdFvSqWzDoP$');
$user_input = 'Erwin';
$new = crypt($user_input, $hashed_password);
echo ($new == $hashed_password) ? 'Success' : 'Failed'; // Success
?>

[ Voor 0% gewijzigd door eokken op 07-08-2012 12:48 . Reden: dollarteken vergeten ]

[CyBeR]

SHA512 met een zooi rounds is goed.

[eokken]

Standaard is 5000, is dat goed? Dit soort dingen heb ik echt geen verstand van, ik zou zeggen dat 5000 keer toch wel goed is maarja..

Ik heb het uiteraard wel opgezocht maar ik kan niet vinden wat een normale waarde zou zijn, behalve dat 5000 standaard is.

[ Voor 31% gewijzigd door eokken op 07-08-2012 14:11 . Reden: Additional information ]

[CyBeR]

Wel, het lastige is dat shasums heel snel uit te rekenen zijn, dus je hebt een enorm aantal rounds nodig. Het idee daarvan zijnde dat je de berekening vertraagt waardoor het bruteforcen langer duurt.

[eokken]

Zo ver zit ik dan weer niet in bruteforcen / rainbowtables volgens mij. Ik dacht dat als je een willekeurige salt neemt van bijv 16 chars lang dat het bruteforcen dan al heel lastig wordt gemaakt. SHA512 met salt, 5000 rounds en een SSL verbinding is dus eigenlijk nog niet genoeg?

[Barryvdh]

Ik ben ook wel benieuwd, of er niet ergens 'best practices' zijn. http://www.phptherightway.com/#password_hashing_with_bcrypt geeft aan bcrypt (dus Blowfish) te gebruiken omdat dat zwaarder is, maar ook niet echt hoeveel rounds/cost ed.
En het laatste comment op http://php.net/manual/en/function.crypt.php gebruikt de date functie om de cost te bepalen, zodat ook over x jaar, de hash nog effectief zou moeten zijn. (Maar hoe betrouwbaar die comments zijn, is natuurlijk ook maar de vraag)
(Overigens is het dus wel een issue binnen PHP, dat het nogal ingewikkeld/onduidelijk is soms, en hopelijk wordt dat ook aangepakt; https://wiki.php.net/rfc/password_hash)

[ Voor 14% gewijzigd door Barryvdh op 07-08-2012 14:39 ]

[.oisyn]

eokken schreef op dinsdag 07 augustus 2012 @ 14:25:
Zo ver zit ik dan weer niet in bruteforcen / rainbowtables volgens mij. Ik dacht dat als je een willekeurige salt neemt van bijv 16 chars lang dat het bruteforcen dan al heel lastig wordt gemaakt.

Een (userspecifieke) salt maakt het lastiger dat een attacker niet de hele database tegelijk kan bruteforcen. Het is niet zo dat hij de salt ook nog eens moet gaan bruteforcen, want die hoeft niet geheim te zijn.

SHA512 met salt, 5000 rounds en een SSL verbinding is dus eigenlijk nog niet genoeg?

Gisteren wel, morgen niet, maar wat vandaag de stand van zaken is hangt een beetje van de hardware af. Je moet je rounds groot genoeg maken dat je nog maar X aantal hashes per seconde kan berekenen. En het is natuurlijk ook wel een beetje afhankelijk van hoeveel mensen er per seconde op je site inloggen. Een seconde doen over een enkele hash is op zich geen enkel probleem, maar met 10 logins per seconde heb je dan vervolgens een denial of service aan je broek hangen.

[Barryvdh]

Zie dit voorbeeld, dat gebruikt ook nog een prefix optioneel; https://gist.github.com/1...040f9e97ddb9891597647e394
Zou je dat aanraden, om bijvoorbeeld gebruikers te beschermen tegen te simpele wachtwoorden (bestaande woorden/veelgebruikte wachtwoorden), of dan beter een password policy gebruiken. (Prefix heeft natuurlijk geen nut meer als hij uitlekt, maar als je alleen je database verliest, wel toch)

[eokken]

@Barryvdh Ik denk dat cost increasen per jaar zinloos is, als ik nu de hash maak dan is hij toch over 5 jaar nogsteeds hetzelfde, daar schiet je toch niets mee op of ligt dat nu aan mij? In mijn geval kan de gebruiker zelf geen wachtwoord kiezen maar voor een library script wil je inderdaad wel een prefix. Die link snap ik overigens niet, ik zie overal base64 met (voor mij) moeilijke expressies terugkomen maar dat gaat me nu nog even mijn pet te boven.

@.oisyn Duidelijke uitleg!

Ik ben even wat dingen aan het uitvogelen, als ik dat voor elkaar heb dan zal ik m'n bevindingen posten, bedankt voor jullie input nogmaals!

Met een cost van 12 duurt hij lokaal al 0.7 sec en als ik de cost ophoog naar 13 dan wordt het anderhalve seconde. En dan gebruik ik het zo:

PHP:

<?php
crypt($password, '$2y$12$' . generateHash(22) . '$')
?>

[ Voor 15% gewijzigd door eokken op 07-08-2012 15:24 . Reden: Additional information ]

[CyBeR]

eokken schreef op dinsdag 07 augustus 2012 @ 14:25:
Zo ver zit ik dan weer niet in bruteforcen / rainbowtables volgens mij. Ik dacht dat als je een willekeurige salt neemt van bijv 16 chars lang dat het bruteforcen dan al heel lastig wordt gemaakt. SHA512 met salt, 5000 rounds en een SSL verbinding is dus eigenlijk nog niet genoeg?

Die zaken hebben allemaal een ander doel:
• SHA512 (tov md5 of sha1): minder kans op een collision, moeilijker om expres een uit te rekenen (Zodat ik met 'abcdef' kan inloggen ipv 'h4ll0' omdat dat dezelfde hash oplevert).
• Salt: zorgen dat elke hash uniek is, zelfs als de wachtwoorden hetzelfde zijn, plus rainbow tables tegengaan (in mijn tabel kan wel staan dat hash 1234 wachtwoord 'abcdef' oplevert, maar dat klopt dan niet omdat de hash niet van abcdef gemaakt is)
• SSL: zorgen dat een over het netwerk verstuurd gegeven (wachtwoord) niet afgeluisterd kan worden, zodat bovenstaande kansloos is. Als ik 't wachtwoord weet immers maakt 't niet uit hoe 't versleuteld is.

[eokken]

@CyBer Dat eerste dacht ik al wel, heb het nooit echt opgezocht maar het leek me logisch dat wanneer je een string met een length van 16 genereert, dat als je boven de 16 uitkomt dat je dan sowieso dubbele kan krijgen. Voor de rest kende ik het wel en het was ook niet mijn bedoeling om alles met elkaar te associeren maar alles wat met beveiliging te maken heeft dat probeer ik nu te realiseren.

[Barryvdh]

eokken schreef op dinsdag 07 augustus 2012 @ 15:20:
@Barryvdh Ik denk dat cost increasen per jaar zinloos is, als ik nu de hash maak dan is hij toch over 5 jaar nogsteeds hetzelfde, daar schiet je toch niets mee op of ligt dat nu aan mij? In mijn geval kan de gebruiker zelf geen wachtwoord kiezen maar voor een library script wil je inderdaad wel een prefix. Die link snap ik overigens niet, ik zie overal base64 met (voor mij) moeilijke expressies terugkomen maar dat gaat me nu nog even mijn pet te boven.

Nee, je huidige hashes veranderen niet persé, maar je kan dus wel kijken welke cost/algo de huidige salt heeft, en als je besluit dat het niet meer genoeg is, ophogen en de hash vervangen door een sterkere hash (zodra er ingelogd wordt dus). (Maar dat kan natuurlijk ook wanneer je dat zelf besluit, als je blijft opletten). Die moeilijke expressies zijn verder alleen maar om de salt te bepalen, daar kan je natuurlijk ook je eigen code voor gebruiken.

[eokken]

Ja, want wat ik me afvroeg, wat voor nut heeft die "getBytes" methode ten opzichte van iets wat ik zelf gemaakt heb. In de tweede reply zegt de auteur dat wanneer ze je broncode beschikbaar hebben, ze er nog niets tot vrij weinig mee kunnen, maar dat is bij een eigen gemaakte random hash generator toch ook zo?

[.oisyn]

eokken schreef op dinsdag 07 augustus 2012 @ 15:41:
Ja, want wat ik me afvroeg, wat voor nut heeft die "getBytes" methode ten opzichte van iets wat ik zelf gemaakt heb.

Het feit dat ie op een uitgebreide manier genoeg bits aan entropie probeert te verzamelen. Standaard random functies leveren niet zoveel bits aan entropie (volgens mij zijn ze in PHP hooguit gebaseerd op de huidige tijd en het process id)

In de tweede reply zegt de auteur dat wanneer ze je broncode beschikbaar hebben, ze er nog niets tot vrij weinig mee kunnen, maar dat is bij een eigen gemaakte random hash generator toch ook zo?

Die reply gaat nergens over, alsmede het aantal rondes van HMAC. Daardoor krijg je niet op magische wijze ineens meer entropie - het blijft louter gelimiteerd aan de input (uniqid() icm microtime())

[eokken]

Is je conclusie nu dat ik eigenlijk dat hele verhaal weg zou kunnen laten en de salt dus zou kunnen maken met:

PHP:

function getBytes() // De naam zou niet meer voldoen, maar toch
{
    return uniqid($this->prefix, true);
}

En in principe kan ik die prefix toch ook gebruiken om letterlijk voor alle wachtwoorden te zetten:

PHP:

    public function hash($input)
    {
        $hash = crypt($this->prefix . $input, $this->getSalt());
        if(strlen($hash) > 13)
            return $hash;
        return false;
    }

    public function verify($input, $existingHash)
    {
        $hash = crypt($this->prefix . $input, $existingHash);
        return $hash === $existingHash;
    }

[.oisyn]

eokken schreef op dinsdag 07 augustus 2012 @ 16:12:
Is je conclusie nu dat ik eigenlijk dat hele verhaal weg zou kunnen laten en de salt dus zou kunnen maken met:

Behalve dat uniqid nou wellicht juist net niet genoeg entropie levert voor je salt. 't Is gebaseerd op microtime.

Wat is je doel van de prefix (ookwel bekend als "pepper") überhaupt? Ik zou 'm gewoon weglaten. Leesvoer.

[ Voor 46% gewijzigd door .oisyn op 07-08-2012 16:20 ]

[eokken]

Barryvdh schreef op dinsdag 07 augustus 2012 @ 15:08:
Zie dit voorbeeld, dat gebruikt ook nog een prefix optioneel; https://gist.github.com/1...040f9e97ddb9891597647e394
Zou je dat aanraden, om bijvoorbeeld gebruikers te beschermen tegen te simpele wachtwoorden (bestaande woorden/veelgebruikte wachtwoorden)

Wat het artikel zegt klopt en hoewel het niet veel toevoegt is er in dit geval ook geen reden om het niet te doen. Het algoritme blijft hetzelfde alleen voor het plain password zet ik een prefix. De prefix van de uniqid kan ik overigens weglaten.

En dit?

[ Voor 5% gewijzigd door eokken op 07-08-2012 16:36 . Reden: Linkje toegevoegd ]

[.oisyn]

is er in dit geval ook geen reden om het niet te doen.

Die is er dus wel:

There is actually no documentation that a pepper actually increases security that was written by security experts. All of the documentation that I've seen has been written by ordinary developers. There are no RFCs that recommend adding peppers to hashes. There are no significant academic papers that prove they improve security (that I've seen at least). In the world of security, just because a concept sounds good doesn't mean anything. It has to be proven. And peppers, up until this point, have not been proven to improve security

Je hebt er ook geen kont aan. Het prefixen van een wachtwoord met een pepper zorgt effectief alleen maar dat de initialization vector van de hash anders is. Het berekenen van de hashes "blaat_aap", "blaat_noot" en "blaat_mies" kan net zo snel als "aap", "noot" en "mies" door eerst te bekijken wat voor interne state de prefix "blaat_" oplevert in de hashfunctie, en vanuit die state vervolgens door te rekenen.

[ Voor 24% gewijzigd door .oisyn op 07-08-2012 16:42 ]

[eokken]

Ik heb het hele artikel gelezen en het enige wat ze zeggen is dat er geen reden is om het te doen maar (behalve als het algoritme veranderd) is er ook geen reden om het niet te doen. Over het algemeen wordt gezegd dat je het niet bij peppers moet zoeken maar bij andere methoden. Ik zie niet in waarom ik beide niet zou doen, ze moeten ook toegang hebben tot de broncode in dit geval. Ik vind (mening) dat je niet aan een pepper zou moeten beginnen als je de rest niet in orde hebt, maar daar ben ik volop me bezig.

Je hebt er ook geen kont aan. Het prefixen van een wachtwoord met een pepper zorgt effectief alleen maar dat de initialization vector van de hash anders is. Het berekenen van de hashes "blaat_aap", "blaat_noot" en "blaat_mies" kan net zo snel als "aap", "noot" en "mies" door eerst te bekijken wat voor interne state de prefix "blaat_" oplevert in de hashfunctie, en vanuit die state vervolgens door te rekenen.

Maar dat moet nog wel gebeuren, en van te voren weet je niet dat het "blaat_" is, tenzij je de broncode hebt.

En md5(uniqid()), wordt daar de entropie wel beter van?

[ Voor 36% gewijzigd door eokken op 07-08-2012 16:48 ]

[.oisyn]

is er ook geen reden om het niet te doen

Het feit dat security experts niet bewezen hebben dat het iets toevoegt zou voor jou reden genoeg moeten zijn om het niet te doen. Door je wachtwoorden te prefixen zou ook weleens kunnen betekenen dat een pre-image attack veel makkelijker te doen is, waardoor je de boel dus onnodig compromitteerd.

En het feit dat je hiermee komt:

eokken schreef op dinsdag 07 augustus 2012 @ 16:31:
En dit?

geeft eigenlijk al aan dat je momenteel niet echt over de kennis beschikt om dat soort keuzes te maken.

Entropie krijg je aan de hand van input. Het is niet zo dat er een magische functie bestaat die, geheel zonder externe input, ineens entropie kan creëren. Het hashen van uniqid() voegt daarom ook compleet niets toe. Een dom persoon zal wellicht denken dat de token meer tekens bevat en dat zijn zoekruimte daardoor groter is, maar niets is minder waar: een slimme attacker kijkt gewoon naar hoe de token tot stand is gekomen, ziet dat ie gebaseerd is op microtime(), en gaat vervolgens daarmee aan de slag om de tokens te bruteforcen.

Simpel voorbeeld:

PHP:

srand(getmypid()); // seed based on process id
$token = "";
for ($i = 0; $i < 16; $i++)
    $token .= chr(rand(0, 255));

Dit genereert een token van 16 bytes (128 bits). Hoeveel mogelijke tokens kan dit programmaatje genereren?

[eokken]

Ik heb ook nooit beweerd dat ik over die kennis beschik, anders was ik hier natuurlijk nooit gaan vragen. De pepper wordt niet gebruikt voor de salt maar voor het wachtwoord zelf en die komt 'erbij' dus in mijn beleving zal het de hash alleen maar langer maken, waardoor het (eventueel, misschien wel niet) lastiger wordt, maar niet minder moeilijk wordt (tenzij ik het zou gebruiken in de salt, waarbij mijn pepper de eerste X chars van de 22 lange salt zou zijn).

Die entropie snap ik ook niet echt. Op php.net hebben ze het er telkens over maar ik vind geen uitleg. Ik denk dat jouw programmaatje 16 ^ 256 mogelijkheden kan genereren.

Note: As of PHP 4.2.0, there is no need to seed the random number generator with srand() or mt_srand() as this is now done automatically.

Mijn doel is niet om je af te kraken maar ben juist zeer dankbaar voor je/jullie hulp. Maar ik zit wel zo in elkaar om niet alles klakkeloos te gebruiken, ik moet ergens wel achter staan.

[Barryvdh]

Ik zou ook zeggen, dat als je gebruikers een wachtwoord laat bepalen, er een grote kans is op simpele wachtwoorden (tenzij je strenge regels hebt), denk aan '123abc', 'Password', of namen/voorwerpen. Die zijn makkelijker te bruteforcen, als je van makkelijke wachtwoorden uit gaat. Als je daar een aantal tekens voor zet, en de aanvaller weet die niet, maak je het hem toch een stuk moeilijker, omdat de meeste gebruikte 10.000 pogingen al waardeloos zijn.
Maargoed, zoals je al zegt, dat is mijn gevoel, geen idee of het ook echt zo werkt.

Over entropie voor je salt ben ik ook wel benieuwd, wat nu wel/niet goed is. Op php.net/stack overflow/phpass doen ze het allemaal anders steeds..

[CyBeR]

eokken schreef op dinsdag 07 augustus 2012 @ 17:05:
De pepper wordt niet gebruikt voor de salt maar voor het wachtwoord zelf en die komt 'erbij' dus in mijn beleving zal het de hash alleen maar langer maken

Nee, de hash blijft evenlang. Je maakt alleen de invoer langer.

waardoor het (eventueel, misschien wel niet) lastiger wordt, maar niet minder moeilijk wordt (tenzij ik het zou gebruiken in de salt, waarbij mijn pepper de eerste X chars van de 22 lange salt zou zijn).

Dat kun je prima doen, want het effect is dat je de volgende string hasht: <pepper><salt><wachtwoord>.

Niet dat 't dus nuttig is.

[ Voor 83% gewijzigd door CyBeR op 07-08-2012 17:31 ]

[.oisyn]

eokken schreef op dinsdag 07 augustus 2012 @ 17:05:
De pepper wordt niet gebruikt voor de salt maar voor het wachtwoord zelf

Same difference.

en die komt 'erbij' dus in mijn beleving zal het de hash alleen maar langer maken

De hash wordt nooit langer.

Die entropie snap ik ook niet echt. Op php.net hebben ze het er telkens over maar ik vind geen uitleg. Ik denk dat jouw programmaatje 16 ^ 256 mogelijkheden kan genereren.

Een pseudo random generator is perfect voorspelbaar als je de interne staat weet. Door een seed in te stellen bepaal je die interne staat. Als je een keer seed(5) doet en daarna een aantal getallen genereert, dan zal bij de volgende keer dat je seed(5) doet exact diezelfde getallen gegenereerd worden.

Welnu, een process id is 16 bits, dus de entropie is 16 bits (in de werkelijkheid iets minder omdat je bepaalde aannames kan doen over het process id van het PHP process, maar dat terzijde). Er zijn dus maar 2¹⁶ verschillende begin-states van het random-algoritme, derhalve er zijn ook maar 2¹⁶ verschillende uitkomsten mogelijk.

Met hashes is het precies zo. Het lijkt random, maar het is perfect voorspelbaar wat een hash wordt als je z'n input weet (logisch, anders waren ze niet bruikbaar ). Het aantal verschillende hashes is dus gelimiteerd aan het aantal verschillende inputs. Als je een enkele bit hasht dan zul je maximaal maar 2 verschillende uitkomsten kunnen krijgen. md5(uniqid()) is dus niet meer random dan gewoon uniqid(). Het lijkt op het oog wel zo, door de langere strings, maar iemand die alle mogelijkheden af wil gaan doet dat op basis van de input, niet op de output.

Entropie is trouwens de mate van willekeurigheid, meestal gemeten in bits. Wikipedia: Entropy (information theory)

Maar ik zit wel zo in elkaar om niet alles klakkeloos te gebruiken, ik moet ergens wel achter staan.

En toch gebruik je dus klakkeloos die prefix?

[ Voor 46% gewijzigd door .oisyn op 07-08-2012 17:32 ]

[eokken]

Nee, omdat dat in mijn denkwijze klopt(e), dat is het enige waar ik van uit kan gaan. Ik kan jou geloven, willekeurige posts op stackoverflow geloven, maar als ik in de praktijk bezig ga ben ik toch degene die het moet doen.

Ik geloof nu wel dat wanneer je de broncode bemachtigd hebt, de hash onveiliger wordt omdat je de eerste "len(pepper)" karakters van het wachtwoord al weet. Dat was ik even vergeten.

Om op je theorie van entropy in te gaan, in dat geval moet die persoon dan wel weten dat je de seed van het process id gebruikt. Dit gaat mijn pet toch wel vet te boven ben ik bang. Op wat voor manier kan ik dan wel een goede entropie krijgen?

Je bent overigens wel een held in uitleggen, ik begrijp zelfs wat je zegt, al had ik veel te veel tijd moeten doorbrengen op het internet om hier zelf achter te komen. Briljant.

[ Voor 12% gewijzigd door eokken op 07-08-2012 17:47 ]

[.oisyn]

eokken schreef op dinsdag 07 augustus 2012 @ 17:38:
Om op je theorie van entropy in te gaan, in dat geval moet die persoon dan wel weten dat je de seed van het process id gebruikt.

Ik ben van mening dat je er vanuit moet gaan dat het voor de attacker een koud kunstje is om de door jouw gebruikte algoritmes te achterhalen. Vrijwel alle gangbare vormen van encryptie gaan uit van dat principe: het algoritme is niet geheim, maar de sleutels wel.

Dit gaat mijn pet toch wel vet te boven ben ik bang. Op wat voor manier kan ik dan wel een goede entropie krijgen?

Die GetBytes() functie van eerst heeft een aantal alternatieven die goed zijn, zoals openssl_random_pseudo_bytes() of het lezen van /dev/urandom. Dergelijke functies baseren zich op entropie uit externe factoren, zoals user input, harddisk seek times, network packets, input van een microfoon, etc. Of ze gebruiken dedidated random hardware (indien beschikbaar) die zich baseert op atmosferische ruis of de polarisatie van fotonen oid.

[eokken]

Lastig onderwerp (voor mij toch). Voor nu verander ik de Bcrypt klasse terug naar wat het was. Ik wil jullie (alweer) hartelijk bedanken voor alle input en uitleg.