Eigen sessie system in combinatie met meerdere salts

[MuddyMagical]

De afgelopen tijd heb ik meegelezen in [PHP] Sessie beveiliging en salts over het gebruik van salts en hoe je het beste de wachtwoorden opslaat in je database.

Op dit moment gebruik ik nog geen salts, maar wil hier wel mee beginnen.

Mijn inlog systeem is gebaseerd op een uitleg van crisp:

Stap 1) Genereer een sessieid en sla die op in je sessietabel met userid = 0
Stap 2) Neem deze sessieid op in een hidden veld in je formulier als challenge
Stap 3) Gebruiker vult gebruikersnaam en wachtwoord in
Stap 4) Genereer een response dmv md5(md5(wachtwoord) + gebruikersnaam + sessieid)
Stap 5) Stuur username, sessieid en response terug (+ eventuele andere opties)
Stap 6) Controleer of de sessieid voorkomt in je sessietabel, de TTD niet verstreken is en deze toebehoort aan userid 0 (geen user)
Stap 7) Controleer of de gebruikersnaam bestaat in je DB
Stap Zo ja, haal zijn md5'ed wachtwoord op uit je database
Stap 9) Genereer ook serverside de md5(md5'ed wachtwoord + gebruikersnaam + sessieid)
Stap 10) Vergelijk dit resultaat met de response van de client
Stap 11) Indien matched: gooi oorspronkelijke sessieid weg
Stap 12) Genereer een nieuwe sessieid en sla die op in je sessietabel met het juiste userid (+ andere opties)
Stap 13) Stuur een cookie met het nieuwe sessieid daarin

Bij het openen van de login pagina wordt een sessionid gemaakt die een TTL van 10 minuten heeft.
Daarna stuur ik geen plain wachtwoord over de lijn vanaf de client, maar het volgende dmv JS:

PHP:

$enc_challenge = SHA1(enc_password + username + sessionid)

Server-side wordt de response ook gegenereerd en vergeleken. Is dit een match dan wordt je ingelogd.

Het probleem is nu dat als ik het wachtwoord met een global salt én een user-specifieke salt opsla in de database ik die 'challenge' niet meer clientside kan genereren waardoor deze opzet niet meer werkt.

Hoe kan ik nu beide techieken combineren?

[ytterx]

ooit bedacht dat als ik javascript uit heb staan en bij jou op je website kom ik niet kan inloggen?

het is voor zover ik kan bedenken niet mogelijk om deze technieken te combineren. een SSL connectie lost het beveiligings gat hier tussen enigzins op.

[MuddyMagical]

ytterx schreef op donderdag 13 oktober 2011 @ 21:43:
ooit bedacht dat als ik javascript uit heb staan en bij jou op je website kom ik niet kan inloggen?

het is voor zover ik kan bedenken niet mogelijk om deze technieken te combineren. een SSL connectie lost het beveiligings gat hier tussen enigzins op.

Klopt inderdaad dat je afhankelijk bent van JS, maar dat is een bewuste keuze op het moment.

SSL zou wel een optie zijn, maar dat is wel gelijk een dure optie voor een hobby project.

[ytterx]

SSL zelf is niet duur maar een certificaat kan wat kosten ja.

Eerste hit google: https://www.sslcertificaten.nl/ alleen domein verificatie 12 euro per jaar (of je die wilt is een 2e)

[Woy]

Op deze manier ga je de global salt inderdaad niet geheim kunnen houden, maar dat is dan ook niet zo'n ramp, want hoewel een geheime global salt een beetje veiligheid toevoegt is het niet zo heel veel. Het feit dat je je password, of de hash daarvan niet over het net hoeft te sturen is mee waard. Ik zou de global salt dus of gewoon laten vallen, of gewoom ook meesturen met het request.

ytterx schreef op donderdag 13 oktober 2011 @ 21:43:
ooit bedacht dat als ik javascript uit heb staan en bij jou op je website kom ik niet kan inloggen?

het is voor zover ik kan bedenken niet mogelijk om deze technieken te combineren. een SSL connectie lost het beveiligings gat hier tussen enigzins op.

Je kunt het prima combineren. Als JS niet aanstaat kun je gewoon als fallback wel het password over de lijn sturen, en aan de server kant valideren. Het is dan natuurlijk wel handig om een extra warning te geven dat de security lager is omdat JS uit staat. Dan kan een gebruiker er altijd nog voor kiezen om JS toch aan te zetten.

[MuddyMagical]

Woy schreef op vrijdag 14 oktober 2011 @ 08:58:
Op deze manier ga je de global salt inderdaad niet geheim kunnen houden, maar dat is dan ook niet zo'n ramp, want hoewel een geheime global salt een beetje veiligheid toevoegt is het niet zo heel veel. Het feit dat je je password, of de hash daarvan niet over het net hoeft te sturen is mee waard. Ik zou de global salt dus of gewoon laten vallen, of gewoom ook meesturen met het request.

[...]

Je kunt het prima combineren. Als JS niet aanstaat kun je gewoon als fallback wel het password over de lijn sturen, en aan de server kant valideren. Het is dan natuurlijk wel handig om een extra warning te geven dat de security lager is omdat JS uit staat. Dan kan een gebruiker er altijd nog voor kiezen om JS toch aan te zetten.

De optie om inderdaad een waarschuwing te geven bij het niet encrypten van het wachtwoord is een goede suggestie!

Maar ook als ik de global salt laat vallen kan ik in mijn ogen de user specifieke salt niet gebruiken aangezien ik deze natuurlijk niet naar de client wil sturen. Is hier een manier omheen of heeft mijn implementatie als effect dat ik geen salts kan gebruiken?

[Cartman!]

Je kan de username als unieke salt gebruiken Die vult iemand immers zelf in op je formulier.

[ReenL]

Serieus? Gebruik gewoon SSL als je het wachtwoord niet plain text over de lijn wilt sturen.

Je hebt duidelijk mijn reacties niet gelezen in de post die je verwijst.

@Woy
Een geheime salt maakt het niet veiliger. Dat is hetzelfde als zeggen dat een 1000 kilo minder is dan 1000 kilo en een stukje stof. Het verschil is zo significant klein, dat je het niet zou mogen noemen.

Daarnaast bestaat er een regel dat je algoritme open moet kunnen zijn, zonder dat het te kraken is. De salt is onderdeel van het algoritme en zou dus gewoon open mogen zijn.

Je kan je slot van je deur immers ook niet verstoppen van de inbreker, alleen de sleutel. En de salt is onderdeel van het slot. Als je het slot voor de inbreker moet verstoppen, dan is er echt iets mis, want hij weet namelijk al dat ie in je deur zit .

[MuddyMagical]

ReenL schreef op vrijdag 14 oktober 2011 @ 12:10:
Serieus? Gebruik gewoon SSL als je het wachtwoord niet plain text over de lijn wilt sturen.

Je hebt duidelijk mijn reacties niet gelezen in de post die je verwijst.

@Woy
Een geheime salt maakt het niet veiliger. Dat is hetzelfde als zeggen dat een 1000 kilo minder is dan 1000 kilo en een stukje stof. Het verschil is zo significant klein, dat je het niet zou mogen noemen.

Daarnaast bestaat er een regel dat je algoritme open moet kunnen zijn, zonder dat het te kraken is. De salt is onderdeel van het algoritme en zou dus gewoon open mogen zijn.

Je kan je slot van je deur immers ook niet verstoppen van de inbreker, alleen de sleutel. En de salt is onderdeel van het slot. Als je het slot voor de inbreker moet verstoppen, dan is er echt iets mis, want hij weet namelijk al dat ie in je deur zit .

Via SSL het wachtwoord versturen is inderdaad een optie, maar buiten dit topic.

Hoe kan ik een salt gebruiken in mijn implementatie?

[ReenL]

Via SSL het wachtwoord versturen is inderdaad een optieMUST, maar buiten dit topic.

Ik snap dan verder niet wat je bedoelt met sessie tabel ofzo.

Hashen en salten werkt zo

PHP:

<?php
/**
 * The following functions allow you to make a secure hash. Note that hashing is only locking up the password
 * With unlimited time or unlimited calculation power, ANY hash can be cracked. Our goal is to simply delay
 * the hacker, so we can inform our dear customers of the breach and advise them to change there password(s).
 *
 * WARNING: You should revise the value of "$strength" and "$algoritm" at least once every year, to keep it save.
 *
 * NOTES:
 * - The metadata returned should also be saved;
 * - The metadata is used for a graceful transition between password strengths/algoritms;
 * - If you change strength or algoritm, then update the hash in your storage once a user logs in;
 * - Notify users with old strength / algoritms that they should log in after a couple of months,
 *   if they don't either lock the account, or send a new password.
 *
 * @author Reen Lokum
 */
 
/**
 *
 * @param $identity The identity the user logs in with, username or email for example.
 * @param $password The password the user prefers.
 * @return string Note that the length of the string can change when you change the string length of $strength or $algoritm.
 */
function createHash($identity, $password)
{
    // The algoritm you prefer (http://nl.php.net/manual/en/function.hash.php)
    $algoritm = 'sha512';
    // Set this value as high as possible. Review it every year. (GPU's are getting stronger)
    $strength = 10000;
    // Do the actual hashing
    $hash = doHash($algoritm, $strength, $identity . $password);
    // Add metadata
    return $algoritm . '!' . $strength . '|' . $hash;
}

/**
 *
 * @param $hash The hash to compare the password to.
 * @param $identity The identity the user logs in with.
 * @param $password The password the user filled in.
 * @return boolean
 */
function checkHash($hash, $identity, $password)
{
    // Strip metadata.
    $meta = explode('!', $hash);
    $algoritm = array_shift($meta);
    $strength = array_shift($meta);
    $hash = implode('!', $meta);
    // Calculate the hash for the given password.
    $givenHash = doHash($algoritm, $strength, $identity . $password);
    if ( $givenHash === $hash ) {
        return true;
    }
    return false;
}

/**
 *
 * @param $algoritm
 * @param $strength
 * @param $string The string to calculate the hash for.
 * @return string
 */
function doHash($algoritm, $strength, $string)
{
    for ( $i = 0; $i < $strength; $i++ ) {
        $string = hash($algoritm, $string);
    }
    return $string;
}

[smesjz]

@ReenL: waarom denk je dat 10000 keer sha512 veiliger is dan 1 keer?

[Gomez12]

smesjz schreef op zaterdag 15 oktober 2011 @ 12:31:
@ReenL: waarom denk je dat 10000 keer sha512 veiliger is dan 1 keer?

Exact 1000x levert weer andere problemen op (rainbow tables), dan kan je beter voor 999x of 1001x gaan.
Of hoe ik het ooit eens gemaakt heb : De server pikt uit een range van 950 tot 1100 een willekeurig aantal te hashen keren en verstuurd dit naar de client.

En de reden om meerdere keren te hashen is dat er minder rainbow tables voor bestaan/de processing tijd wordt langer.
1-malige sha-512 hashing is nu misschien nog niet reëel te doen, maar over 2 jaar waarschijnlijk weer wel.

1000x hetzelfde doen verlengt die 2 jaar weer (zolang er geen shortcuts als rainbow tables ontstaan)

[ReenL]

smesjz schreef op zaterdag 15 oktober 2011 @ 12:31:
@ReenL: waarom denk je dat 10000 keer sha512 veiliger is dan 1 keer?

Omdat je met brute forcen meer dan 50 miljoen pogingen per seconden kan doen (met een redelijke GPU, met een cloud kan je er meer), als je 10000 keer sha512 doet, dan is dat nog maar 5 duizend pogingen per seconde.

Ik vraag me sterk af of er rainbow tables bestaan van van deze methode, kost namelijk relatief veel om zo'n tabel te maken, en de toepassing is beperkt omdat er een salt bij zit, als iemand al zover gedacht heeft. Dit maakt het momenteel niet rendabel. Maar als je daar dan toch bang voor bent, kun je inderdaad een raar getal kiezen.

[Gomez12]

ReenL schreef op zaterdag 15 oktober 2011 @ 14:15:
[...]
Ik vraag me sterk af of er rainbow tables bestaan van van deze methode, kost namelijk relatief veel om zo'n tabel te maken

Ik kan je vertellen dat er al tig rainbow tabellen bestaan (of nog draaien) met 10x / 100x en 1000x en dat is inclusief en exclusief een aantal generieke salts.

Teveel mensen denken leuk en origineel te zijn met salts als : niemandweetdit, salt, geheim etc. etc.
Terwijl ze niet inzien dat zelfs een straatnaam / plaatsnaam nog een betere salt is (want dan gelden die bruteforce resultaten enkel voor 1 target ipv voor alle nl-sprekende communities die dezelfde "unieke/grappige" salt uitkiezen)

[Anoniem: 28958]

ReenL schreef op zaterdag 15 oktober 2011 @ 14:15:
[...]

Omdat je met brute forcen meer dan 50 miljoen pogingen per seconden kan doen (met een redelijke GPU, met een cloud kan je er meer), als je 10000 keer sha512 doet, dan is dat nog maar 5 duizend pogingen per seconde.

Het lijkt me zeer onwaarschijnlijk dat je kunt bewijzen wat je hier claimt.

Waarom zou een aanvaller weet ik niet hoeveel keer een of andere functie gaan itereren, terwijl dit in werkelijkheid waarschijnlijk niet eens nodig is?

[Gomez12]

Anoniem: 28958 schreef op zaterdag 15 oktober 2011 @ 15:48:
[...]

Het lijkt me zeer onwaarschijnlijk dat je kunt bewijzen wat je hier claimt.

Waarom zou een aanvaller weet ik niet hoeveel keer een of andere functie gaan itereren, terwijl dit in werkelijkheid waarschijnlijk niet eens nodig is?

Online brute-forcen daar heb je idd geen last van de 1.000x hashen. Daar voldoet de 1e brute-force die door de server geaccepteerd wordt.

Enkel online brute forcen is extreem traag en makkelijk te stoppen ( gooi een max van 10x authorizen per seconde op je inlogprocedure en niemand merkt het enkel brute-forcen is niet meer mogelijk )

1.000x hashen is enkel geldig bj offline brute-forcen en dat is ook de enige effectieve brute-force methode. En ja, daar kan je die waardes makkelijk halen...

Als jij offline met 1x hashen een resultaat vind, gefeliciteerd maar je hebt er niets aan online, aangezien de server 1000x hashed en dus jouw invoer niet overeenkomt met wat er op de server staat.

[MuddyMagical]

Heren, mag ik jullie vragen om de discussie over welke manier van hashen en hoe vaak het veiligste is kunnen jullie beter ergens anders voeren.

@ReenL : Ik weet hoe je moet hashen. De vraag is anders:

Ik genereer een eigen sessionid die geldig is voor 10 minuten en gooi die in een sessietabel.
Dit sessionid wordt hidden in een form gezet en nadat de gebruiker zijn user & pass heeft ingevoerd wordt er op de client een challenge gemaakt van sha1(sha1(password)+username+sessionid). Deze wordt naar de server gestuurd.

De server pakt van de username de password hash en maakt de response van sha1(sha1(password)+username+sessionid). Als de challenge en response overeenkomen wordt de sessionid weggegooid en een nieuwe (met langere ttl) sessie gemaakt en in een cookie naar de client gestuurd.

Als ik nu een user specifieke salt toevoeg in de database dan werkt bovenstaande niet meer zonder dat ik ook de salt naar de client stuur. Dat wil ik niet, dus vraag ik me af of er een andere mogelijkheid is.

[Gomez12]

Wat is dan precies het probleem?

Als je simpelweg zorgt dat je je hashing methode in 2 stappen opdeelt dan heb je toch geen probleem?

bijv eerst een hash van username + pw, deze kan je op de client en server uitvoeren. Dit resultaat is dan weer een invoer voor je server-side only hashing die bijv adhv het user-id in de db werkt en dus user-afhankelijk is.

De user-specifieke hash zal je zeer waarschijnlijk op de server moeten doen (of je moet die gegevens ook weer naar de client toesturen) maar de input voor die hash kan gerust een hash vanaf de client zijn.

[Priet]

MuddyMagical schreef op zaterdag 15 oktober 2011 @ 16:03:
Als ik nu een user specifieke salt toevoeg in de database dan werkt bovenstaande niet meer zonder dat ik ook de salt naar de client stuur. Dat wil ik niet, dus vraag ik me af of er een andere mogelijkheid is.

Zoals hier beschreven is de username toch al de user-specifieke salt Wat is hier nog mis mee dan? Je hebt op deze manier een 'challenge-response authentication' en een mechanisme tegen rainbow tables. Perfect toch?

[Voor 18% gewijzigd door Priet op 15-10-2011 16:32]

[Gomez12]

Priet schreef op zaterdag 15 oktober 2011 @ 16:30:
[...]

Zoals hier beschreven is de username toch al de user-specifieke salt Wat is hier nog mis mee dan? Je hebt op deze manier een 'challenge-response authentication' en een mechanisme tegen rainbow tables. Perfect toch?

Moet je er alleen wel even rekening houden met dat elke username change ook een password reset vereist (want salt veranderd)

Een lollige admin die even tijdelijk een username verandert krijgt dan ietwat meer uitwerking

[ReenL]

Ik blijf nog steeds vragen waarom? SSL lost het probleem op wat je hier op aan het lossen bent, maar dan wel veilig.

Als je het zo nodig zelf moet implementeren, stuur dan gewoon een public key naar de client, laat hem zijn data encrypten en stuur het terug naar de server, waar je het zooitje decrypt met je private key. Maar dit zit standaard ingebakken in SSL, dus waarom zelf doen?

[Cartman!]

Gomez12 schreef op zaterdag 15 oktober 2011 @ 16:34:
[...]
Een lollige admin die even tijdelijk een username verandert krijgt dan ietwat meer uitwerking

Dat is geen issue, de user laat je z'n wachtwoord ter controle nog n keer invullen. Als een admin de username wijzigt dan krijgt de user een nieuw wachtwoord die hij kan wijzigen.