[PHP] Sessie beveiliging en salts

[bindsa]

Ik heb een paar vragen over beveiliging in PHP.

Als eerste een vraag over sessies, ik gebruik momenteel het volgende script om te kijken of de sessie veilig is:

PHP:

if (!isset($_SESSION['initiated'])) {
    session_regenerate_id();
    $_SESSION['initiated'] = true;
}
if (isset($_SESSION['fingerprint'])) {
    $fingerprintCheck = md5($_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDRESS']."@#$%^&*()");
    if ($_SESSION['fingerprint'] != $fingerprintCheck) {
        fatalError(SESSION_FINGERPRINT_MISMATCH);
    }
}
else {
    $_SESSION['fingerprint'] = md5($_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDRESS']."@#$%^&*()");
}

Is dat afdoende om een veilige sessie te creëren en te behouden? (Ik ga userid etc. in de sessie opslaan)

En dan had ik nog een vraag, voor het beveiligen van wachtwoords deed ik tot nu toe meestal het volgende:
- wachtwoord + timestamp registreren user + string met vage karakters (constant) en die hashen met sha1
Maar nu ben ik bezig met een applicatie waarbij er veel users tegelijk worden aangemaakt en dus is het timestamp idee niet meer zo zinvol. Is het afdoende om er bij elke user een string met karakters aan vast te plakken? Die string is voor elke user hetzelfde en is alleen in het PHP script bekend, niet in de database. Of weet iemand een betere methode?

[Korben]

Een salt is idealiter voor elke user uniek. Daarmee bereik je dat brute force en dictionary attacks veel moeilijker worden gemaakt, omdat je niet kunt vaststellen dat twee users hetzelfde wachtwoord hebben door naar de hash te kijken. Als de username uniek is (daar ga ik vanuit) dan kun je dat ook als salt gebruiken; dat maakt rainbow table aanvallen ook minder haalbaar.

Het beste blijft een unieke salt van een aantal random bytes, die niet in de database staan. Als dan je database wordt gestolen, worden de hashes extreem moeilijk om te kraken.

Zie ook: http://en.wikipedia.org/wiki/Salt_(cryptography)

[Voor 5% gewijzigd door Korben op 07-05-2010 11:08]

[Kalentum]

PHP:

$fingerprintCheck = md5($_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDRESS']."@#$%^&*()");

Realiseer je wel dat dit misschien wat overkill is. Als mijn IP adres veranderd of ik upgrade mijn browser dan ben ik uitgelogd. Of dat gewenst gedrag is hangt af van de aard van de gegevens die achter de login zitten.

[RobIII]

^^ Met hem. En wat is het nut van "@#$%^&*()" in de fingerprint Als ik iemands Useragent en IP weet te spoofen voeg je dezelfde string toe en dus heeft het geen meerwaarde voor de fingerprint.

[Voor 4% gewijzigd door RobIII op 07-05-2010 11:32]

[voodooless]

rutgerw schreef op vrijdag 07 mei 2010 @ 11:27:
Als mijn IP adres veranderd

Browser update.. oke.. IP adressen kunnen echter redelijk makkelijk wijzigen. Denk bijvoorbeeld aan mobiel internet. Als je bijvoorbeeld via Vodafone aan het surfen bent, kan ieder request van een andere proxy server komen.

[RoadRunner84]

Ik gebruik een dubbele MD5 met de salt ertussenin:

PHP:

$key = md5(md5($password . $name) . $nonce . $cnonce);

Waarbij nonce gerandomed wordt door de server en cnonce door de client. Zo wordt het wachtwoord onmogelijk onderschept met een man in the middle attack (toch?). De server kent md5($password . $name) in de database.

Het enige waar ik dus vanuit ga (en wat jij probeert te voorkomen) is dat het SESSION_ID niet gekaapt wordt, maar dat werkt niet. Immers sla je die gegevens op in een SESSION variabele, die gekoppeld zitten aan het SESSION_ID.
Het klopt dat je op jouw manier een lock-in op de browser en het ip adres maakt, maar is die lock-in op de browser nodig? Als iemand een IP spoof kan doen, dan moet een HTTP header spoof geen punt zijn...

Ik controleer elders in mijn script het IP met deze code:

PHP:

if(isset($_SESSION['ip']) && ($_SESSION['ip'] != $_SERVER['REMOTE_ADDR'])){
  unset($_SESSION['ip']);
  $smarty->display_error('Het IP (internet adres) van uw computer is veranderd sinds het laatste bezoek. Log opnieuw in.');
} else {
  $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
}

[FragFrog]

voodooless schreef op vrijdag 07 mei 2010 @ 11:46:
Browser update.. oke.. IP adressen kunnen echter redelijk makkelijk wijzigen. Denk bijvoorbeeld aan mobiel internet. Als je bijvoorbeeld via Vodafone aan het surfen bent, kan ieder request van een andere proxy server komen.

Niet geheel onbelangrijk punt dit. Zelf eens in de praktijk meegemaakt voor een grote zakelijke website (waarvoor we een custom DB-based session handler geschreven hadden aangezien daar meerdere webservers in een cluster aan hingen), klant stond demonstraties te geven op een beurs (met een mobiel internet dongle) en werd ineens continue uitgelogd. Dat was een paar jaar geleden toen mobiel internet nog nieuw en onbekend was, tegenwoordig gebruikt half nederland het..

Daarnaast hoeft een hacker alleen maar de user agent en remote address te spoofen (wat afaik gewoon te doen is, bovendien gaan die gegevens plain-tekst over je connectie) en vervolgens heeft'ie al de sessie - en wordt juist de rechtmatige user uitgelogd als de hacker sneller een nieuwe pageview doet dan de user. Ik ben bang dat je beveiliging dan ook voornamelijk vervelend is voor users en security-wise bar weinig toevoegt. Als je je echt zorgen maakt over MitM aanvallen kun je beter SSL/TLS gebruiken, eventueel in combinatie met een externe tokengenerator voor de initiele connectie en belangrijke transacties (ie, wat bijna alle online banken doen).

That being said, voor 99.99% van de website is het allemaal dikke overkill en zou ik me er niet al te druk over maken Zeker met session_regenerate_id() wordt het al lastig om iemands sessie-cookie te stelen, als een aanvaller al zoveel informatie over de user heeft kun je er wel vanuit gaan dat hij ook andere methodes heeft om met die user mee te kijken.

[Voor 8% gewijzigd door FragFrog op 07-05-2010 14:01]

[hostname]

Buiten het nut en onhandigheid van het meehashen van IP-adres, doe je dat ook nog niet eens. Het IP staat in $_SERVER["REMOTE_ADDR"], niet in $_SERVER['REMOTE_ADDRESS']. Als je error_reporting aan had staan op E_ALL | E_STRICT had je een melding gekregen en sluipen dit soort slordige fouten er niet in

[bindsa]

hostname schreef op vrijdag 07 mei 2010 @ 14:43:
Buiten het nut en onhandigheid van het meehashen van IP-adres, doe je dat ook nog niet eens. Het IP staat in $_SERVER["REMOTE_ADDR"], niet in $_SERVER['REMOTE_ADDRESS']. Als je error_reporting aan had staan op E_ALL | E_STRICT had je een melding gekregen en sluipen dit soort slordige fouten er niet in

Juist, bedankt, tikfoutje

[Avalaxy]

Je kunt overigens beter sha1() gebruiken ipv md5(). SHA1 heeft een iets hogere encryptie en kan in tegenstelling tot MD5 niet makkelijk gekraakt worden mbv rainbow tables. Syntactisch maakt het nauwelijks verschil, qua beveiliging wel

[LuCarD]

Gebruik voor de salt een random string en plaats die ook in de database.

Joomla doet het bijvoorbeeld in het wachtwoord veld zelf, maar je kan ook bv user_id nemen. Of username

Avalaxy schreef op vrijdag 07 mei 2010 @ 17:27:
Je kunt overigens beter sha1() gebruiken ipv md5(). SHA1 heeft een iets hogere encryptie en kan in tegenstelling tot MD5 niet makkelijk gekraakt worden mbv rainbow tables. Syntactisch maakt het nauwelijks verschil, qua beveiliging wel

Beide zijn geen encryptie, en voor zowel md5 als SHA1 zijn rainbow tabellen beschikbaar.

Een goed salted md5 is beter als een unsalted SHA.

[Manuel]

Misschien vindt iemand het interessant maar dit is de methode die ik op dit moment gebruik. Als de speler inlogt op zijn account wordt het wachtwoord veranderd met de salt erbij in, als de speler uitlogt wordt het wachtwoord nog een keer veranderd. Ik pak een random getal, zijn gebruikersnaam, een stukje prefix en 2 letters van zijn eigen wachtwoord, die hash ik beide 2 keer. Voordat het bij de tweede keer hashen aankomt is er een ander stukje prefix aan toegevoegd. Van deze gegenereerde string pak ik dus 20 tekens (willekeurig) en sla die op in mijn user tabel.

Het is misschien iets wat overkill maar dan ben ik er tenminste zeker van dat ik de komende tijd even veilig zit. Qua performance op kort termijn vrees ik nergens voor, niet eens op lang termijn om eerlijk te zijn, omdat het dan maximaal micro-seconden zal geen en niet om millisecondes. (Als het daar in de buurt bij komt pas ik het wel aan, het moet nog wel 'goed snel' zijn

@L0calh0st: Zoals RobIII al aangeeft is jouw methode niet echt waterproof, jij salt nu eigenlijk waardes die je gewoon kunt spoofen. De user-agent spoofen is het makkelijkste van allemaal, dus om die nou te hashen lijkt me niet echt verstandig.

Ik pak het nu zo aan bij mijn spel dat als mensen inloggen op hun account dat ik standaard hun IP, browser en hun naam log in mijn sessie, dat is nog de minimale informatie die nodig is om basis checks uit te voeren. Indien de uitkomst normaal blijkt te zijn en er geen gekke (of aangepaste) dingen tussen zitten vind ik het allemaal best en laat ik de input checken door mijn script(s). Indien de input ook is zoals ik het hebben willen krijgen ze data terug, anders krijgen ze een foutmelding op de pagina te zien. Hopelijk heb ik je hier wat mee kunnen helpen.

[Voor 0% gewijzigd door Manuel op 07-05-2010 18:04. Reden: woord vergeten]

[afraca]

Nu ben ik misschien heel debiel bezig hoor (heel waarschijnlijk), maar stel dat je wel gewoon simpelweg de hash pakt van IP en User Agent..... Uiteraard, beiden zijn eenvoudig te spoofen. Maar als TS dit topic nou nooit had geopend, dan had niemand geweten dat deze methode gebruikt wordt. Hoe kan een hacker dan ooit weten welke dingen hij precies moeten spoofen om sessie te stelen...... Uiteraard is het bij open-source projecten een hele andere situatie....

I know, security by obscurity, nooit geweldig plan...

[Voor 5% gewijzigd door afraca op 07-05-2010 21:59]

[bindsa]

Ben ik nou gek of is het gebruiken van een user_id niet ideaal om mee te salten? Als je de hashes hebt, dan heb je toch meestal de database en dus ook de user_id?

Ik dacht juist van ik pak het wachtwoord, plak daar met PHP een stringetje aanvast en ga dan hashen. Dan moet je 2 dingen hebben, de PHP broncode en de database. Of zie ik iets over het hoofd?

Bedankt voor alle reacties trouwens

[RayNbow]

L0calh0st schreef op vrijdag 07 mei 2010 @ 22:04:
Ik dacht juist van ik pak het wachtwoord, plak daar met PHP een stringetje aanvast en ga dan hashen. Dan moet je 2 dingen hebben, de PHP broncode [...]

Eis van secure cryptography is dat de methode bekend moet zijn. In dit geval moet je er vanuit gaan dat je PHP broncode bekend is.

Zie verder: Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes

[Gomez12]

L0calh0st schreef op vrijdag 07 mei 2010 @ 22:04:
Ben ik nou gek of is het gebruiken van een user_id niet ideaal om mee te salten? Als je de hashes hebt, dan heb je toch meestal de database en dus ook de user_id?

In theorie wel, enkel heb je toch de broncode nodig om dit feit te weten. Je kan namelijk net zo goed de registratiedatum gepakt hebben, of een eigen php gegenereerde salt.

Zonder broncode weet hacker nog steeds niet wat jouw precieze salt was.
En een md5-dbase gaan bruteforcen met bruteforce salts, ik gok dat daar nog niet echt een tijd aan te hangen valt ( ergens in de richting van langer dan het heelal ooit bestaan zou kunnen hebben )

Ik dacht juist van ik pak het wachtwoord, plak daar met PHP een stringetje aanvast en ga dan hashen. Dan moet je 2 dingen hebben, de PHP broncode en de database. Of zie ik iets over het hoofd?

Bedankt voor alle reacties trouwens

Yep, je salt is enkelvoudig. Met 1 salt een rainbow-table genereren ( of brute-forcen ) levert alle wachtwoorden op.
Door de salt per gebruiker uniek te maken krijgt de hacker per brute-force run maar 1 wachtwoord te pakken.

Ideale situatie voor een salt (wmb) is dan ook : user-id + eenmalig in code handmatig ingegeven php-salt
enkel user-id maakt het makkelijk te bruteforcen ( er bestaan gewoon rainbow tables met 1/2/3 etc als salt en aangezien een admin meestal als 1e wordt aangemaakt heeft die bijna altijd het laagste userid )
enkel in code aangegeven salt maakt het supersimpel om met 1 custom rainbow table alle wachtwoorden te krijgen.

Combinatie is afaik redelijk unbeatable

[bindsa]

Gebaseerd op jullie feedback heb ik de volgende hash en hashcontrole functies gemaakt:

PHP:

function calculateHash($password) {
    $random = rand();
    $randomId = uniqid($rand, true);
    $salt = sha1($randomId);
    $hash = sha1($salt.$password);
    return $salt.$hash;
}

function checkHash($password, $hash) {
    $salt = substr($hash, 0, 40);
    $hashCheck = $salt.sha1($salt.$password);
    if ($hashCheck == $hash) {
        return true;
    }
    else {
        return false;
    }
}

Met calculateHash() wordt op basis van een password een hash aangemaakt (met een 40 karakters lange, random salt), die hash kan dan worden opgeslagen in de db.

Als je dan wilt controleren of een ingevoerd wachtwoord matcht met de hash in de db kan dat met hashCheck(), die krijgt als argumenten het ingevoerde wachtwoord en de hash uit de db mee en kijkt dan of die matchen. Retourneert true als het wachtwoord klopt en false als het niet klopt.

Volgens mij heb ik zo wel een oplossing te pakken die voor de komende jaren afdoende is Of is dat niet zo? Bedankt voor al jullie hulp

Nog iets wat ik tegen kwam: Op een site van een kleine SSL aanbieder las ik dat SSL verplicht is je gegevens waarmee iemand geidentificeerd kan worden over de lijn gaat gooien (i.v.m. Wet Bescherming Persoonsgegevens). AFAIK is dat grote onzin, kan op de site van WBP ook niks vinden. Weet iemand van jullie hier toevallig nog iets over? Is voor mij namelijk redelijk belangrijk, want als het wel verplicht is moet ik maar eens SSL gaan aanschaffen... (De link: https://www.networking4al...ficaten/wettelijke+eisen/ volgens mij is het gewoon een goedkope verkooptruc maar weet het liever even zeker heb liever geen boete van €4500 eurie)

[Voor 30% gewijzigd door bindsa op 08-05-2010 20:54. Reden: Toevoeging]

[Kalentum]

De wet verplicht je om passende maatregelen te nemen. Het gaat er daarbij meer om dat niet iedereen zomaar bij alle persoonlijke gegevens van iedereen kan. BV een bank moet zorgen dat niet elke klant zomaar op de rekening van een andere klant kan kijken. Als je een verenigingssite hebt mag je niet zomaar een ledenlijst publiceren.

SSL (= het versleutelen van de verbinding) levert relatief weinig extra beveiliging op. Een slecht beveiligde website wordt door https niet opeens wel veilig.

[frickY]

L0calh0st schreef op vrijdag 07 mei 2010 @ 10:43:

PHP:

$fingerprintCheck = md5($_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDRESS']."@#$%^&*()");

Dit deed ik in het verleden ook, maar gaf te vaak problemen.
In IE8 veranderd bijv de User-agent wanneer men de Compatability-Mode (IE7) aanzet.
En sommige bedrijven hebben meerdere uitgaande verbindingen waartussen geloadbalanced wordt waardoor per request een ander IP kan gelden.

Met het eerste voorkom je in ieder geval dat ik jouw sessieID kan bepalen door je een gefixte url te sturen. Vraag is hoeveel die sessie waard is tot je bent ingelogd. Het is gebruikelijker de session_regenerate_id() pas te gebruiken zodra dat nut heeft, zoals na een succesvolle login.
Het tweede zou ik dus achterwege lagen.

Wat betreft het hashen van usernames kun je het eenvoudigst de username zelf plus een secret meehashen. De username zorgt dat je nooit 2 dezelfde hashes in je systeem hebt, en samen met de secret (dus niet salt ) voorkom je het gebruik van rainbow tables om wachtwoorden te herleiden.

L0calh0st schreef op vrijdag 07 mei 2010 @ 22:04:
Ben ik nou gek of is het gebruiken van een user_id niet ideaal om mee te salten? Als je de hashes hebt, dan heb je toch meestal de database en dus ook de user_id?

Het idee is dan ook dat je hierdoor nooit 2 dezelfde hashes in je database krijgt. Mocht een hacker toegang tot je database krijgen maar kan hij de 'secret' niet herleiden, dan kan hij net zo langs accounts aanmaken met wachtwoorden tot die hash overeenkomt met één van je andere accounts.


Spoofen van het remote_addr lijkt me in deze geen reëel gevaar. Ja, de attacker kan een request maken maar nee, de response zal hij nooit zien.

[Voor 48% gewijzigd door frickY op 09-05-2010 12:27]

[FragFrog]

L0calh0st schreef op zaterdag 08 mei 2010 @ 20:40:

PHP:

function calculateHash($password) {
    $random = rand();
    $randomId = uniqid($rand, true);
    $salt = sha1($randomId);
    $hash = sha1($salt.$password);
    return $salt.$hash;
}

Het heeft niet zo gek veel nut om eerst rand() te doen, daarna uniqid, en vervolgens over het geheel weer sha1 te trekken - simpelweg sha1(rand()) is net zo willekeurig, en het gaat er uiteindelijk om dat je een random string hebt om je password mee salten. Immers, stel dat iemand in een rainbowtable op kan zoeken wat de originele string geweest is van salt.password, dan maakt het niet zo gek veel uit dat die persoon daarna moeite heeft om salt te herleiden - hij heeft dan immers toch al het wachtwoord

PHP:

function checkHash($password, $hash) {
    $salt = substr($hash, 0, 40);
    $hashCheck = $salt.sha1($salt.$password);
    if ($hashCheck == $hash) {
        return true;
    }
    else {
        return false;
    }
}

Kwestie van smaak, maar die else (en die brackets) zijn hier overbodig - sterker nog, zelfs die if is hier overbodig (al wil ik'm zelf ook nog wel eens laten staan voor de duidelijkheid):

PHP:

function checkHash($password, $hash) {
    $salt = substr($hash, 0, 40);
    $hashCheck = $salt . sha1($salt . $password);
    return $hashCheck == $hash;
}

Op zich wel een aardige methode, al is het wellicht een idee de salt in een los veld op te slaan in plaats van gecombineerd in een enkele kolom. Het zo doen heeft alleen nut als iemand wel bij je database kan en niet bij de code danwel doorheeft dat je de salt prepend aan de hash, en dan nog is het een vrij zwakke vorm van security through obscurity. Netter is het om losse waardes ook los op te slaan - een ontwerptip die je later wellicht nog een berg hoofdpijn gaat schelen

Op een site van een kleine SSL aanbieder las ik dat SSL verplicht is

"Wij van WC eend".. Nee, het is niet verplicht. Maar goed ook, voor een signed certificaat ben je al snel een paar honderd euro kwijt, dat is meer dan veel bedrijven (helaas) over hebben voor hun hele website

[EDIT]

Maar goed ook, voor een signed certificaat ben je al snel een paar honderd euro kwijt

Mwa, voor 15 euro per jaar heb je al een geldig certificaat dat door alle grote browsers (lees IE, FF, Chrome, Safari, Opera, etc) geaccepteerd wordt. Die extra versleuteling tussen client en server kan nooit kwaad als je met gevoelige gegevens werkt.

[FragFrog]

EDIT schreef op zondag 09 mei 2010 @ 13:20:
Mwa, voor 15 euro per jaar heb je al een geldig certificaat dat door alle grote browsers (lees IE, FF, Chrome, Safari, Opera, etc) geaccepteerd wordt. Die extra versleuteling tussen client en server kan nooit kwaad als je met gevoelige gegevens werkt.

Ik had het dan ook over een signed certificaat. Een unsigned certificaat zegt niet alleen vrij weinig over de betrouwbaarheid van een site (aangezien iedereen die zelf gewoon aan kan maken), het zorgt er ook nog eens voor dat je bezoekers een popup krijgen of ze het certificaat wel willen accepteren. Kun je imo als bedrijf niet maken om te doen - dat staat ongeveer net zo slordig als een geocities account, of een .tk adres.

[begintmeta]

offtopic:
Volgens mij kan SSL nog goedkoper.^{Voorbeeld Engels/Duits} Over de identiteit van de site-eigenaar zegt dat natuurlijk weinig, maar slecht weinigen kijken echt zorgvuldig de certificaatsgegevens door. Een groen balke voor een extended verification certificaat valt dan natuurlijk al meer op, en zegt ook meer. Popups hoef je afaik in beide gevallen niet te hebben.

[Voor 38% gewijzigd door begintmeta op 09-05-2010 13:51]

[Voutloos]

Excuse my french: wat een gelul om niets. Voor SSL moet je gewoon een goed certificaat kopen. Hierop besparen is imo een schoolvoorbeeld van verkeerde zuinigheid en prio's.

[EDIT]

FragFrog schreef op zondag 09 mei 2010 @ 13:29:
[...]

Ik had het dan ook over een signed certificaat. Een unsigned certificaat zegt niet alleen vrij weinig over de betrouwbaarheid van een site (aangezien iedereen die zelf gewoon aan kan maken), het zorgt er ook nog eens voor dat je bezoekers een popup krijgen of ze het certificaat wel willen accepteren. Kun je imo als bedrijf niet maken om te doen - dat staat ongeveer net zo slordig als een geocities account, of een .tk adres.

Ik heb het ook over een signed certificaat hoor (zoek voor de grap eens op RapidSSL, die krengen worden uitgegeven door Equifax Secure, en worden dus door alle major browsers geaccepteerd. )
Ben nou ook weer niet zo gek dat ik 15 euro ga uitgeven voor een self-signed certificaat

Maar goed, dit heeft verder niets te maken met PHP sessies, weer ontopic lijkt me

[Voor 12% gewijzigd door EDIT op 09-05-2010 14:25]

[frickY]

Voutloos schreef op zondag 09 mei 2010 @ 14:08:
Excuse my french: wat een gelul om niets. Voor SSL moet je gewoon een goed certificaat kopen. Hierop besparen is imo een schoolvoorbeeld van verkeerde zuinigheid en prio's.

Een self-signed certificaat is net zo secure als een certificaat van duizenden euro's. Het verschil zit hem in de identiteitscontrole, maar dat is alleen een zekerheid die je de gebruiker bied, en waar je zelf niets op wint.

[Gomez12]

Tja, als jij gebruikersgemak / gebruikersvertrouwen niets winnen vindt?

Afaik geeft elke browser tegenwoordig een waarschuwing ( met als default een afraden om door te gaan ) bij self-signed certificaten.

Sorry, maar dan liever 80 dollar per jaar dan die gebruikersellende...

[FragFrog]

EDIT schreef op zondag 09 mei 2010 @ 14:18:
Ben nou ook weer niet zo gek dat ik 15 euro ga uitgeven voor een self-signed certificaat

offtopic:
Mea culpa, easy mistake to make, had vorige week nog een klant aan de lijn die dus wel met iets dergelijks aankwam van ook rond de 15 euro en de vraag of dat handig was te implementeren

[Bapawe]

frickY schreef op zondag 09 mei 2010 @ 12:13:
[...]
Dit deed ik in het verleden ook, maar gaf te vaak problemen.
In IE8 veranderd bijv de User-agent wanneer men de Compatability-Mode (IE7) aanzet.
En sommige bedrijven hebben meerdere uitgaande verbindingen waartussen geloadbalanced wordt waardoor per request een ander IP kan gelden.

Ook lijkt het erop dat sommige browser addons de user-agent tussentijds veranderen waardoor de sessie verloren gaat, dat wil je dus niet . Volgensmij was het zelfs de google toolbar

[Voutloos]

frickY schreef op zondag 09 mei 2010 @ 15:30:
[...]

Een self-signed certificaat is net zo secure als een certificaat van duizenden euro's. Het verschil zit hem in de identiteitscontrole, maar dat is alleen een zekerheid die je de gebruiker bied, en waar je zelf niets op wint.

Dat hoor ik wel vaker, maar die eigenschap is imo toch echt minstens zo belangrijk.

Aan encryptie zonder dat je weet met wie je praat heb je echt helemaal niets. Je houdt jezelf voor de gek als je denkt dat dat uberhaupt iets toevoegt.

[frickY]

Die eigenschap is uiteraard heel belangrijk. Het is de reden waarom er root authorities zijn. Het is de zekerheid die een bezoeker krijgt niet met een phisher te maken te hebben.
Maar puur naar encryptie gekeken win je er geen zak mee, en dat was mijn punt.

Je hoort ook wel eens van mensen die een duur certificaat kopen voor een intranet, of één of andere afgeschermde koppeling, omdat ze perse SSL willen gebruiken. Zonde.

[Anoniem: 147126]

FragFrog schreef op zondag 09 mei 2010 @ 12:25:
[...]

Het heeft niet zo gek veel nut om eerst rand() te doen, daarna uniqid, en vervolgens over het geheel weer sha1 te trekken - simpelweg sha1(rand()) is net zo willekeurig, en het gaat er uiteindelijk om dat je een random string hebt om je password mee salten. Immers, stel dat iemand in een rainbowtable op kan zoeken wat de originele string geweest is van salt.password, dan maakt het niet zo gek veel uit dat die persoon daarna moeite heeft om salt te herleiden - hij heeft dan immers toch al het wachtwoord


[...]

Kwestie van smaak, maar die else (en die brackets) zijn hier overbodig - sterker nog, zelfs die if is hier overbodig (al wil ik'm zelf ook nog wel eens laten staan voor de duidelijkheid):

PHP:

function checkHash($password, $hash) {
    $salt = substr($hash, 0, 40);
    $hashCheck = $salt . sha1($salt . $password);
    return $hashCheck == $hash;
}

Op zich wel een aardige methode, al is het wellicht een idee de salt in een los veld op te slaan in plaats van gecombineerd in een enkele kolom. Het zo doen heeft alleen nut als iemand wel bij je database kan en niet bij de code danwel doorheeft dat je de salt prepend aan de hash, en dan nog is het een vrij zwakke vorm van security through obscurity. Netter is het om losse waardes ook los op te slaan - een ontwerptip die je later wellicht nog een berg hoofdpijn gaat schelen


[...]

"Wij van WC eend".. Nee, het is niet verplicht. Maar goed ook, voor een signed certificaat ben je al snel een paar honderd euro kwijt, dat is meer dan veel bedrijven (helaas) over hebben voor hun hele website

Ik ben het van plan met de ingebouwde crypt() van php te implementeren, omdat die ook blowfish gebruikt als dat op het systeem staat (standaard vanaf php 5.3):

PHP:

function checkHash($saltedPasswordHash, $enteredPasswordHash) {
    return crypt($enteredPasswordHash, $saltedPasswordHash) == $saltedPasswordHash)
}

$saltedPasswordHash is de hash die opgeslagen is in de database (gegenereerd met generateHash hieronder) en $enteredPasswordHash is de sha1 hash van het wachtwoord die de client heeft ingevoerd. Het wachtwoord kan dan op de client sha1 gehashed worden als je niet wil dat het wachtwoord plain over de lijn gaat.
Het eerste gedeelte van de saltedPasswordHash is de (random) salt, die automatisch door crypt gemaakt wordt bij het aanmaken van de gebruiker:

PHP:

function generateHash($password) { 
    return crypt(sha1($password));
}

Nog op- of aanmerkingen?

[wizzkizz]

Anoniem: 147126 schreef op vrijdag 21 mei 2010 @ 20:51:
Het wachtwoord kan dan op de client sha1 gehashed worden als je niet wil dat het wachtwoord plain over de lijn gaat.
[...]
Nog op- of aanmerkingen?

Op het risico af dat je dit niet meer lees omdat je reactie al bijna een week oud is:

Ja, en dat gaat niet alleen over je schaamteloze topic-hijack.

Het heeft geen enkele meerwaarde om een wachtwoord gehashed over de lijn te sturen als die hash niet iedere keer anders is. Oftewel, gebruik dat alleen als je ook het challenge/response mechanisme gebruikt, anders heeft het geen toegevoegde waarde. Een aanvaller stuurt dan ipv het wachtwoord de onderschepte hash naar de server en dat heeft precies hetzelfde effect als zou de aanvaller het wachtwoord weten.

[Voutloos]

^ Het is dus een 'password equivalent', maar dat heeft (mits goede salt) toch een klein voordeel: Deze password-equivalent zal dan niet hetzelfde zijn voor andere omgevingen waar user hetzelfde wachtwoord gebruikt.

[Anoniem: 147126]

Uiteraard lees ik dit...

De enige aanpassing die ik had voorgesteld op de eerdere oplossingen was het gebruiken van crypt in plaats van zelf hashen en de string's aan elkaar plakken. Het gaat er toch vooral om dat de wachtwoorden niet teruggerekend kunnen worden mocht de database ooit in verkeerde handen vallen (zoals recent bij FoK! is gebeurt bijvoorbeeld.) Dus een zo sterk/traag mogelijk hashing algoritme lijkt me wenselijk.
Ik begrijp dat het redelijk zinloos is zonder challenge/response systeem maar dat zit hier gewoon als laag bovenop.

Dat wachtwoorden onderschept kunnen worden kun je toch nooit voorkomen (kan ook met een keylogger, of over iemands schouder meekijken bij het intypen, of...) maar dan is er maar toegang tot 1 gebruiker. Dat het wachtwoord als hash over de lijn gaat voorkomt tenminste dat niet op andere accounts van de gebruiker (email etc.) ingelogd kan worden waar de (domme) gebruiker hetzelfde wachtwoord gebruikt (zoals bij FoK....)

[wizzkizz]

Anoniem: 147126 schreef op donderdag 27 mei 2010 @ 15:39:
[...]
Dus een zo sterk/traag mogelijk hashing algoritme lijkt me wenselijk.
Ik begrijp dat het redelijk zinloos is zonder challenge/response systeem maar dat zit hier gewoon als laag bovenop.

Zoals ik het las, laat je het ww op de client hashen, stuur je dat over de lijn en ga je server-side verder met crypt(). Ik zie dan zo ff niet hoe je het challenge/response mechanisme nog wilt toepassen. Bovendien, bij het c/r mechanisme is je $enteredPasswordHash iedere keer anders vanwege de meegehashte challenge, dus kun je $saltedPasswordHash niet zomaar uit de db halen zoals je zegt.

Anoniem: 147126 schreef op donderdag 27 mei 2010 @ 15:39:
Dat wachtwoorden onderschept kunnen worden kun je toch nooit voorkomen (kan ook met een keylogger, of over iemands schouder meekijken bij het intypen, of...) maar dan is er maar toegang tot 1 gebruiker. Dat het wachtwoord als hash over de lijn gaat voorkomt tenminste dat niet op andere accounts van de gebruiker (email etc.) ingelogd kan worden waar de (domme) gebruiker hetzelfde wachtwoord gebruikt (zoals bij FoK....)

Roger that, mits je dan wel een salt gebruikt zoals Voutloos ook aangeeft.

En een keylogger of op andere wijze gecompromitteerd systeem van de gebruiker vind ik diens probleem, niet dat van jouw applicatie. Uiteindelijk is het de gebruiker die daar last van heeft en niet jouw app. Zolang het niet aan de beveiliging van de applicatie ligt (jouw probleem), moet je de verantwoordelijkheden leggen waar die horen te liggen.

[Beatboxx]

Ik kick dit topic omdat ik zelf al even aan't zoeken ben maar ik het niet de moeite waard vind een nieuw topic te openen.

Ik heb een website, waarvan ik verwacht dat niemand 'm probeert te hacken. De database met userdate staat netjes op de Localhost, en ik ben al flink bezig geweest om injections te voorkomen, dus daar zal het probleem ook niet liggen. Ik heb ook flink wat serverpower beschikbaar, ik host het thuis op m'n 100/100Mbit/s glasvezel verbinding op m'n eigen 2500K PC, die dus wel wat kan hebben. Als ik het wachtwoord eerst met MD5 en daarna met SHA1 onder handen neem, is het likely dat iemand die de tabel in handen krijgt dit hackt? Of kan ik het nog veel beter hashen/salten?

[Gomez12]

Ongeacht wat je doet altijd salten die hash (met een persoonlijke salt).

Het is 2 minuten extra programmeerwerk en het maakt je beveiliging 10x beter.

[Woy]

Waarom zou je het eerst met MD5 en daarna nog eens met SHA1 hashen? Het dubbel hashen voegt echt geen veiligheid toe. Het toevoegen van een Salt voor het hashen is inderdaad wel altijd een goed idee.

[joppybt]

Beatboxx schreef op maandag 10 oktober 2011 @ 18:45:
Als ik het wachtwoord eerst met MD5 en daarna met SHA1 onder handen neem, is het likely dat iemand die de tabel in handen krijgt dit hackt? Of kan ik het nog veel beter hashen/salten?

Het zou me niet verbazen als er rainbow tabellen bestaan voor de combinatie MD5+SHA1. Daar ben je sowieso dan nog kwetsbaar voor.
Belangrijker: stel dat voor één gebruiker het wachtwoord is gekraakt (of gegokt): dan is nu eenvoudig te controleren welke gebruikers hetzelfde wachtwoord hadden (niet onmogelijk). Als je een salt per user gebruikt voorkom je dat ook.

Anderzijds: ik proef een beetje dat dit een hobby-site is. Dan is het veel belangrijker dat je er van leert dan dat het extreem veilig is. Alleen al daarom zou ik het salt-mechanisme inbouwen.

[begintmeta]

een hash hashen verkleint eventueel de groep mogelijke ingangswaarden van de tweede hash (van SHA1 in dit geval) die je zou moeten zoeken en is daarom onverstandig (een md5 hash is altijd 128 bits, een wachtwoord niet (meestal minder en dus zwakker, maar theoretisch gesproken zou bruteforcen makkelijker kunnen worden van dubbel hashen) Maar IANAC

Wat je doet door twee keer te hashen is vooral de rekentijd vergroten, dat kan je beter doen door een geschikter algoritme. (bcrypt bijvoorbeeld)

Salten (liefst uniek) moet je altijd, en is ook niet zo heel moeilijk normaalgesproken..

[Voor 10% gewijzigd door begintmeta op 10-10-2011 19:54]

[Beatboxx]

Ik heb nu nog geen idee wat salten is, maar ik ga wel even een half uurtje op tutorials googlen!

[Cartman!]

Of je leest gewoon dit topic door...

[begintmeta]

key stretching is ook een sleutelterm heb ik net gezien

[TheNephilim]

Het beste blijft een unieke salt van een aantal random bytes, die niet in de database staan. Als dan je database wordt gestolen, worden de hashes extreem moeilijk om te kraken.

Oké misschien ben ik nog niet helemaal wakker, maar als je een wachtwoord hashed met salt, dan moet je die salt toch opslaan? Anders kun je toch nooit checken of het wachtwoord klopt bij het inloggen?

[begintmeta]

Je kan de salt buiten de database bewaren, maar of dat echt praktisch zinvol is weet ik niet. De hashes worden ook niet echt moeilijker om te kraken, zolang geen rainbowtables bestaan voor wachtwoorden+salts die dan eventueel met de database worden buitgemaakt zou ik denken.

[Voor 51% gewijzigd door begintmeta op 11-10-2011 10:35]

[Woy]

begintmeta schreef op dinsdag 11 oktober 2011 @ 10:29:
Je kan de salt buiten de database bewaren, maar of dat echt praktisch zinvol is weet ik niet. De hashes worden ook niet echt moeilijker om te kraken, zolang er geen rainbowtables bestaan voor hashes+salts die dan eventueel met de database worden buitgemaakt zou ik denken.

Het kan handig zijn om zowel met een user-specifieke salt ( die gewoon in de database staat ) en een globale salt ( die bijvoorbeeld op het filesystem staat ) the salten. Op die manier is het lastiger om te brute-forcen als je alleen de database buit gemaakt hebt, immers zul je de salt dan ook moeten brute-forcen.

[begintmeta]

Het vinden van een collision op een hash van een wachtwoord+salt (of ook een wachtwoord alleen) lijkt me in principe niet lastiger te bruteforcen dan het vinden van een collision op een hash van een wachtwoord+salt+salt. Vanwege de grotere voorspelbaarheid van wachtwoorden alleen kan je in dat geval echter wat werk doen voordat je de aan te vallen hash hebt.

[Voor 10% gewijzigd door begintmeta op 11-10-2011 10:46]

[Flard]

bruteforcen hash wachtwoord+salt+salt is theoretisch niet zwaarder dan wachtwoord+salt.

Als je alléén een database- of tablewide salt gebruikt, kun je bij het bruteforcen ineens álle hashes bruteforcen. Door een per-user salt toe te voegen, moet je ieder wachtwoord los bruteforcen.

[TheNephilim]

Flard schreef op dinsdag 11 oktober 2011 @ 10:54:
bruteforcen hash wachtwoord+salt+salt is theoretisch niet zwaarder dan wachtwoord+salt.

Als je alléén een database- of tablewide salt gebruikt, kun je bij het bruteforcen ineens álle hashes bruteforcen. Door een per-user salt toe te voegen, moet je ieder wachtwoord los bruteforcen.

Klopt, maar waar sla je die per-user-salt op, dat zal buiten de database moeten. Anders blijft heeft het weinig nut, als de database op straat ligt heeft iedereen toegang tot de hash en de salt. Het zal niet vaak voorkomen dat het wachtwoord gehashed buiten de database zichtbaar is. Je accepteerd een wachtwoord, hashed die en vergelijkt die met het gehashte wachtwoord in de database.

[Woy]

begintmeta schreef op dinsdag 11 oktober 2011 @ 10:43:
Het vinden van een collision op een hash van een wachtwoord+salt (of ook een wachtwoord alleen) lijkt me in principe niet lastiger te bruteforcen dan het vinden van een collision op een hash van een wachtwoord+salt+salt. Vanwege de grotere voorspelbaarheid van wachtwoorden alleen kan je in dat geval echter wat werk doen voordat je de aan te vallen hash hebt.

Het is wel degelijk een stuk makkelijker te bruteforcen als je de global salt weet. Want alleen met een collission van de hash ben je er niet. Je moet een collission vinden die ook aan de voorwaarde voldoet dat de hash resulteert uit [secret]_[userSalt]_[globalSalt]. Het is niet erg als secret een andere waarde heeft als het origineel, maar als het userSalt en globalSalt gedeelte niet overeenkomt zal je nog niet in kunnen loggen op de site.

Als je zowel userSalt als globalSalt weet hoef je alleen nog maar secret te permuteren tijdens het bruteforcen. Als je de globalSalt ook niet weet zul je die ook moeten bruteforcen.

Bernardo schreef op dinsdag 11 oktober 2011 @ 10:58:
[...]
Klopt, maar waar sla je die per-user-salt op, dat zal buiten de database moeten. Anders blijft heeft het weinig nut, als de database op straat ligt heeft iedereen toegang tot de hash en de salt. Het zal niet vaak voorkomen dat het wachtwoord gehashed buiten de database zichtbaar is. Je accepteerd een wachtwoord, hashed die en vergelijkt die met het gehashte wachtwoord in de database.

De user salt heeft een andere reden, en dat is om te zorgen dat 2 users die hetzelfde wachtwoord hebben niet dezelfde hash krijgen, en het zorgt er voor dat er per user gebruteforced moet worden, en dat er niet voor de hele database in een keer gebrute-forced kan worden. Het is dan dus ook niet erg dat die salt bij een aanvaller bekend is.

[Voor 37% gewijzigd door Woy op 11-10-2011 11:09]

[begintmeta]

Ik snap het eigenlijk niet helemaal geloof ik. Je hebt een hash:
2da56ca25556da8881b5b634c120cae4
je hebt ook een salt buitgemaakt 'gh6' Nu mogen jullie bruteforcen. Volgen mij maakt het daarvoor niet uit of ik nu geen of meer bekende salts heb toegevoegd. Zodra je een collision hebt kan je inloggen. Een onbekende salt heeft natuurlijk wel zin zoals hieronder heel duidelijk wordt uiteengezet

Voor het bruteforcen van een serie hashes allemaal met dezelfde (bekende) salt gezouten ziet dat er natuurlijk anders uit.

[Voor 16% gewijzigd door begintmeta op 11-10-2011 11:31]

[Woy]

Ik ga er even van uit dat je kennis van het systeem hebt, en dus weet hoe de hashes zijn opgebouwd ( security through obscurity willen we immers niet ).

Stel je weet dat de hash het resultaat is van

code:

var hash = HashFunction( $password + '_' + $userHash );

En je weet de userhash, dan ga je op de volgende manier brute-forcen

code:

var $permutation;
var $hashToMatch = 'somehash';
while($permutation = nextPermutation())
{
    if( $hashToMatch == HashFunction( $permutation + '_' + $userSalt ) )
        Profit();
}

Als er voor de hash echter nog een global salt aan geappend word ( en die weet je niet ) zul je die ook moeten permuteren, want je hebt het password ( of een andere waarde voor password die dezelfde hash oplevert ) nodig om in te kunnen loggen.

Als je geen rekening houdt met het feit dat er een salt bij zit, en je vind bijvoorbeeld dat 'Foo' dezelfde hash oplevert, dan heb je daar niks aan. Immers vul je 'Foo' in als password, de server append daar de userSalt en de globalSalt bij, en dan krijgt hij een andere hash, en zal dus de toegang weigeren.

begintmeta schreef op dinsdag 11 oktober 2011 @ 11:12:
Zodra je een collision hebt kan je inloggen.

Dat is de denkfout die je maakt. Met een collission kun je niet inloggen. Je moet een collission hebben die aan bepaalde voorwaardes voldoet, namelijk dat hij op dezelfde manier is opgebouwd als dat de server de hash gaat berekenen, anders zal de server altijd op een andere hash uitkomen, en dus geen toegang verschaffen.

[Voor 18% gewijzigd door Woy op 11-10-2011 11:22]

[begintmeta]

Woy schreef op dinsdag 11 oktober 2011 @ 11:20:
...
Dat is de denkfout die je maakt. Met een collission kun je niet inloggen. Je moet een collission hebben die aan bepaalde voorwaardes voldoet, namelijk dat hij op dezelfde manier is opgebouwd als dat de server de hash gaat berekenen, anders zal de server altijd op een andere hash uitkomen, en dus geen toegang verschaffen.

Je hebt gelijk, een onbekende salt heeft zo natuurlijk wel zin, heb mijn post maar geedit.

Zaak dus database en salts separaat te houden. Het is natuurlijk wel security through obscurity

[Voor 8% gewijzigd door begintmeta op 11-10-2011 11:54]

[Woy]

begintmeta schreef op dinsdag 11 oktober 2011 @ 11:29:
Zaak dus database en hashes salts separaat te houden.

Ik zou de user-hashes dus wel gewoon in de database zetten ( Die zijn immers vrij dynamisch ), maar de global hash niet ( Dat is immers maar 1 waarde, en veranderd als het goed is nooit ).

Het is natuurlijk wel security through obscurity

Nee natuurlijk niet. Dingen geheim houden is niet meteen security through obscurity. Het is gewoon een secret die je op een andere plaats opslaat dan andere gegevens om zo het risico kleiner te maken. Het geheim houden van je wachtwoord is ook geen security through obscurity.

Verwachten dat je login veilig is omdat je niet kenbaar hebt gegeven hoe de input voor je hashing algorithme geregeld word is security through obscurity.

[begintmeta]

Woy schreef op dinsdag 11 oktober 2011 @ 11:43:
...
Ik zou de user-hashes dus wel gewoon in de database zetten ( Die zijn immers vrij dynamisch ), maar de global hash niet ( Dat is immers maar 1 waarde, en veranderd als het goed is nooit ).
...

User hashes wel, maar je zou bijvoorbeeld een aantal global salts kunnen gebruiken om nog meer stukken van de database af te scheiden (bv een global salt voor elke beginletter van de gebruikersnamen.)

mbt security through obscurity: vergeet mijn niet

[Voor 1% gewijzigd door begintmeta op 11-10-2011 11:55. Reden: salt, hash...]

[djluc]

Die globale salt apart houden zal 't meest moeilijke zijn. Die moet uiteindelijk toch snel beschikbaar zijn op de server wat het wat lastiger maakt?

Wat bijvoorbeeld zou kunnen is een aparte server (kan virtueel natuurlijk) die de controle doet en de globale salt bevat?

[Cartman!]

Das misschien wat overdreven, bovendien is t scenario meestal dat een usertable wordt uitgelezen dmv. sql injection. Als je dan de salt in je code hebt staan dan kun je die niet direct te pakken krijgen. Als je server compleet open en bloot ligt zal t niet lang duren voordat je ook contact kan leggen met die aparte server.

[TheNephilim]

Je slaat in je (bijv.) config.php een $globalSalt op en in de database je usersalt. Deze kun je dan in een andere tabel zetten dan je users zodat de kans dat ze beide te pakken krijgen wel erg klein is.

[Anoniem: 241683]

Of je doet het nog beter en je slaat het als environment variable op in je apache vhost config

[ReenL]

waarvan ik verwacht dat niemand 'm probeert te hacken

Probleem opgelost?

met userdate

Bedoel je userdata?

ik ben al flink bezig geweest om injections te voorkomen

Hoe dan?

op m'n eigen 2500K PC

Wat is dat? een pc van 2.500.000 euro lijkt me een beetje over de top.

Als ik het wachtwoord eerst met MD5 en daarna met SHA1 onder handen neem, is het likely dat iemand die de tabel in handen krijgt dit hackt?

Een hash is, gegeven dat er genoeg tijd is, altijd terug te rekenen naar zijn originele wachtwoord. Het hash algoritme is bedoeld om ervoor te zorgen dat de hacker zo erg vertraagt wordt dat jij genoeg tijd hebt om:
1) Te ontdekken dat je gehackt bent;
2) Je gebruikers te informeren;
3) De gebruikers hun wachtwoord te laten veranderen.

Het is naief om te denken (ongeacht de implementatie) dat een hacker de wachtwoorden niet kan achterhalen. Dit is te vergelijken met een kluis. Je kan een dure kluis hebben, maar als de inbreker hem bezit en ermee kan doen wat hij wil, dan is de kans groot dat hij de inhoud achterhaald.

Dat gezegt hebbende, is de vraag dus eigenlijk of jou methode vergelijkbaar onaantrekkelijk is om te kraken als de kluis van een bank.

Het antwoord? NEE

Om precies te zijn:
- Een gpu uit 2008(!!!) kan 110 miljoen hashes per seconden genereren;
- Jij gebruikt 2 hash methodes, dus je kunt dit delen door 2 = 55 miljoen per seconden;
- Als je alleen de gebruikers wilt kraken met een wachtwoord kleiner dan 9 tekens met A-Za-z0-9 dan zijn er ongeveer 3 * 10^14 mogelijkheden;
- Ofwel ongeveer 70 dagen om ALLE wachtwoorden te kraken met een 3(!!!) jaar oude gpu.

Hoe dan wel?
- Salt toevoegen uniek per gebruiker;
==> Omdat elke gebruiker een ander algoritme gebruikt kost het dan 70 dagen PER gebruiker in het bovenstaande voorbeeld;
- Meer hashen of zwaarder algoritme (bcrypt);
==> Hashes zijn gemaakt om snel uitgevoerd te worden, daarom zijn ze op te delen in een hele boel kleine taken, een GPU kan deze tegelijk uitvoeren. Als je echter 2 maal hashed moet de GPU wachten op het resultaat van de eerste hash. Dit is ook waarom je de 110 miljoen door 2 moest delen in het voorbeeld omdat je eerst md5 en daarna sha1 gebruikt. Let op dat het niet beter wordt door methodes te mixen. Keep it simple.
- Zwaarder hash algoritme;
==> Waarom sha1 gebruiken als je shiny sha512 hebt? Algoritme is ietsje zwaarder en minder kans op collission, ook al is dat extreem zeldzaam op gelijkwaardige lengte input.

Wat niet?
- Unieke salt per applicatie;
==> Nutteloos ik heb immers toch meestal maar 1 applicatie gehackt en al had ik er meer gehackt, de unieke salt per gebruiker vangt dit al af;
- Moeite doen om je salt te verbergen;
==> De enige reden dat je dat ding nodig hebt is dat de hacker elke keer opnieuw moet beginnen;

Hoe nog veiliger?
- Verplaats je mysql naar een apparte (mysql) server;
- Draai een SQL-firewall op die server (bijvoorbeeld greensql);
- Gebruik alleen whitelisted queries en SELECT nooit "*" of "password" van je gebruikerstabel, maar gebruik "WHERE password = '<HASH>'";
- Leg een restrictie op het aantal keren dat deze query uitgevoerd mag worden per uur/minuut.

Nog veiliger?
- Vanaf dit punt ga ik uurtarief rekenen haha

offtopic:
Ik vraag me overigens af waarom dit topic nog open is. Als deze starter een eigen topic had geopend, dan was het commentaar geweest dat hij geen research gedaan heeft. Ofwel, als je lui bent kun je lekker in iemand anders topic gaan reageren dan krijg je wel antwoord.

[Gomez12]

ReenL schreef op dinsdag 11 oktober 2011 @ 19:48:
[...]
Een hash is, gegeven dat er genoeg tijd is, altijd terug te rekenen naar zijn originele wachtwoord.

Met welke gare hash-implementatie is dit?
Hashes hebben afaik altijd collisions, dit is een acceptabel risico en zorgt ervoor dat iemand niet 1 wachtwoord terugkrijgt, maar een aantal mogelijk wachtwoorden...

Wat niet?
- Unieke salt per applicatie;
==> Nutteloos ik heb immers toch meestal maar 1 applicatie gehackt en al had ik er meer gehackt, de unieke salt per gebruiker vangt dit al af;

Vind ik erg discutabel, ik zou dit ook niet laten afhangen van een applicatie, maar meer van een user/pw tabel.
Per user/pw table zou ik wel een unieke salt aanraden. Geef die hacker geen speedboost als hij 2 tabellen heeft waardoor hij tig accounts niet meer hoeft te hashen. Laat hem maar werken...

[Cartman!]

Hoeveel user/pw tables heb jij dan per app? Ik eigenlijk altijd maar 1 Gewoon een globale salt die in je app staat en een user salt (username of emailadres oid). Het is echt moeite van niks en t zorgt ervoor dat iemand met je user table per user moet bruteforcen, die moeite neem je echt niet met een sterk algoritme. Zelf neem ik meestal Whirlpool, SHA256 of SHA512.

[Avalaxy]

Nu het over hashes gaat, hoeveel toegevoegd waarde heeft SHA512 eigenlijk ten opzichte van SHA384 (de truncated versie, zover ik weet even sterk)? Kan het op google niet vinden, behalve dat de performance van de SHA384 net iets minder slecht is.

[Cartman!]

Truncated dus krijg je in theorie sneller collisions, tja...

[ReenL]

Met welke gare hash-implementatie is dit?

Alle

Hashes hebben afaik altijd collisions,

Klopt

Dit is een acceptabel risico en zorgt ervoor dat iemand niet 1 wachtwoord terugkrijgt, maar een aantal mogelijk wachtwoorden...

Het is niet een rekensom wat resultaat geeft het is een brute force, je stopt bij de eerste match. Als je een langere hash hebt (bijvoorbeeld sha512) is die collision als het goed is minder dan 1% op de scope van je aanval.

Vind ik erg discutabel

Geef een argument, je zegt alleen wat je zelf zou doen.

Geef die hacker geen speedboost als hij 2 tabellen heeft waardoor hij tig accounts niet meer hoeft te hashen. Laat hem maar werken...

Daarvoor heb je de unieke salt per gebruiker. En omdat hij per gebruiker uniek is is hij ook per tabel uniek. Dus waarom alsnog per tabel of applicatie uniek, juist, dat is nutteloos.

[Priet]

ReenL schreef op woensdag 12 oktober 2011 @ 08:17:
Daarvoor heb je de unieke salt per gebruiker. En omdat hij per gebruiker uniek is is hij ook per tabel uniek. Dus waarom alsnog per tabel of applicatie uniek, juist, dat is nutteloos.

Mee eens. De salt hoeft niet geheim te zien. Iedereen mag weten dat ik de username als salt gebruik. Iedereen weet ook hoe de password-hash berekend wordt.

Het punt is dat door het gebruik van de salt de standaard rainbow-tables niet meer gebruikt kunnen worden (en het gebruik van dezelfde wachtwoorden door verschillende users verschillende hashes opleveren). En dan maakt het niet uit of je één, twee of meerdere salts gebruikt.

[TheNephilim]

Wij maken hier gebruik van de PBKDF2 methode, een collega van me heeft dit geïmplementeerd, dus ik ben niet op de hoogte van alle details.

Meer informatie: Wikipedia: PBKDF2

We begonnen met kale MD5 hashes bij onze eerste projecten (5 jaar geleden), toen werd het al eens MD5+Salt, daarna SHA256 met salt en nu dus bovengenoemde methode als laatste.
Er zijn natuurlijk altijd betere methodes om je website te beschermen, maar soms moet je ook het belang van de gegevens afwegen in plaats van je overmatig te beveiligen. Ik vind het altijd wel een interessant onderwerp en ben ook zeker geïnteresseerd in de implementaties van anderen.

[Voor 7% gewijzigd door TheNephilim op 12-10-2011 10:45]

[Cartman!]

PBKDF2 ziet er interessant uit, direct geimplementeerd in ons CMS Algoritme op Whirlpool, iteraties op 10.000 en de key length op 128 lijkt me prima voorlopig.

[Ram0n]

Priet schreef op woensdag 12 oktober 2011 @ 10:15:
[...]
Het punt is dat door het gebruik van de salt de standaard rainbow-tables niet meer gebruikt kunnen worden

Dit hangt volgens mij nog wel af van de salt; als ik de userID als salt erachter plak is de kans groot dat een rainbow table alsnog "aardbei10" oplevert als collision, dan is het voor de hacker wel duidelijk dat 10 de salt was en aardbei het originele wachtwoord. Dan is het wel een unieke salt per gebruiker, maar je hebt toch aan één table genoeg.

Natuurlijk is het dan belangrijk om op te merken dat er dus meerdere collisions mogelijk zijn, maar uit ervaring met een uitgebreide rainbow table test weet ik dat daar vrijwel altijd de originele string uitkomt en niet een andere, toevallige collision.

[begintmeta]

...

[Voor 100% gewijzigd door begintmeta op 12-10-2011 15:26]

[Priet]

Ram0n schreef op woensdag 12 oktober 2011 @ 13:43:
Dit hangt volgens mij nog wel af van de salt; als ik de userID als salt erachter plak is de kans groot dat een rainbow table alsnog "aardbei10" oplevert als collision, dan is het voor de hacker wel duidelijk dat 10 de salt was en aardbei het originele wachtwoord. Dan is het wel een unieke salt per gebruiker, maar je hebt toch aan één table genoeg.

Que?

Niet volgens deze methode:

code:

salt = hash(username)
hash = hash( hash(plain_password) + salt)

[Ram0n]

Priet schreef op woensdag 12 oktober 2011 @ 15:47:
[...]

Que?

Niet volgens deze methode:

code:

salt = hash(username)
hash = hash( hash(plain_password) + salt)

Klopt, maar dat is slechts 1 methode. Vaak wordt het als volgt toegepast:

code:

hash = hash(plain+salt)

Ik heb het uiteraard over dat geval. Natuurlijk zijn er veel veiligere manieren zoals die van jou (en zo doe ik het ook), maar je ziet maar al te vaak dat het zoals hierboven wordt toegepast.

[Voor 16% gewijzigd door Ram0n op 12-10-2011 15:53]

[ReenL]

Dit hangt volgens mij nog wel af van de salt; als ik de userID als salt erachter plak is de kans groot dat een rainbow table alsnog "aardbei10" oplevert als collision, dan is het voor de hacker wel duidelijk dat 10 de salt was en aardbei het originele wachtwoord. Dan is het wel een unieke salt per gebruiker, maar je hebt toch aan één table genoeg.

Als je niet standaard sha1 of md5 gebruikt, maar gewoon sha512 * 10000 of iets dergelijks kun je met zekerheid zeggen dat er (nog) geen rainbow table voor bestaat. En als je hem kan vinden, dan doe je het toch 10001 of 9999 keer?

Als je dan toch bang bent voor rainbow tables, dan kun je het userid ook met nullen aanvullen. 00000010 is dan weer prima als salt.

Natuurlijk is het dan belangrijk om op te merken dat er dus meerdere collisions mogelijk zijn, maar uit ervaring met een uitgebreide rainbow table test weet ik dat daar vrijwel altijd de originele string uitkomt en niet een andere, toevallige collision.

Ja dat komt omdat een rainbow table gemaakt is op basis van waarschijnlijkheid. Het is doelloos om een rainbow table te maken van binaire input of van woorden van 80 tekens. Verschillende typen input maken de kans op collision hoger.

Ik heb het uiteraard over dat geval. Natuurlijk zijn er veel veiligere manieren zoals die van jou (en zo doe ik het ook), maar je ziet maar al te vaak dat het zoals hierboven wordt toegepast.

Deze methode is niet veiliger, zie ook mijn reactie eerder. Je hashed maar 2 keer een gpu kan dit makkelijk brute forcen in reele tijd.

Bedenk ook dat GPU's elk jaar sneller worden, waardoor je dus steeds zwaardere processen moet maken.

[Ram0n]

ReenL schreef op woensdag 12 oktober 2011 @ 19:11:
[...]
Deze methode is niet veiliger, zie ook mijn reactie eerder. Je hashed maar 2 keer een gpu kan dit makkelijk brute forcen in reele tijd.

Dat is dan ook niet waar ik op doelde, dat was enkel de manier waarop je de salt toepast. Of de gpu dit snel kan is irrelevant in dat opzicht, dat is niet het punt dat ik probeerde te maken. Simpelweg hash(plain+salt) maakt rainbow tables niet overbodig, daar ging het om.

Je opmerkingen over het 1000 keer toepassen van een hashfunctie ben ik het ook mee eens, maar ook daar heb ik toch niets over gezegd? Ik kaartte juist het probleem aan dat men vaak slechts één keer hashed, en dan nog met een onveilig gebruik van de salt (en MD5).

[Voor 22% gewijzigd door Ram0n op 12-10-2011 19:35]

[ReenL]

We zijn het gewoon eens , want het enige wat ik probeer te zeggen is, dat als je goed hashed er geen rainbow table voor beschikbaar is en de lengte van de salt dus niet uitmaakt. Als het gegeven is dat er rainbow tables zijn van de methode die je gebruikt is een langere salt beter omdat de rainbowtables dan onbruikbaar zijn, echter is het probleem van gpu brute forcing niet kleiner geworden. Daarom zei ik (misschien wat kort door de bocht) "deze methode is niet veiliger".

Gewoon een andere manier van uitdrukken dus .