Salt opslaan

[4Real]

Als je wachtwoord en andere zaken wilt encrypten dan is het handig om een salt te gebruiken, zodat deze sterker versleuteld worden en moeilijker zijn om via bruteforce aanvallen te kraken.

Maar nu vraag ik mij af, waar sla je deze salt veilig op? Ik kan mij voorstellen dat user specifieke salts voordeel hebben, omdat je dan niet één maar meerder hebt en kans dat de global salt wordt gestolen en gebruikt wordt om wachtwoorden te kraken kleiner wordt, maar waar sla je deze dan op? In de database in het zelfde records als de wachtwoord gegevens? bv: UserID, UserName, Password, Salt ?

Dan kan ik mij nog voorstellen dat een gecombineerde aanpak handig kan zijn: Global salt + wachtwoord + user salt
Op deze manier kun je een aardig sterk wachtwoord maken waar je zelfs nog niets hoeft bang te zijn dat één van je salt's wordt gestolen, maar de kans blijft altijd bestaan dat beide in handen komen.

Hoe kun je er voorzorgen dat deze zaken zo goed mogelijk op worden geslagen?


_{Voor de Fok!kers hier, ja het is een kopietje, maar ben ook benieuwd naar de experts. Niet gezegd dat er bij Fok! geen experts zitten, maar andere experts}

[alienfruit]

ik sla wachtwoord op als wachtwoord:salt of middels een aparte wachtwoord en salt kolom in de tabel

[ Voor 7% gewijzigd door alienfruit op 14-11-2012 13:15 ]

[STW]

Global Salt gebruiken is eigenlijk 'useless. Op het moment dat ze je database te pakken hebben kan je ervan uit gaan dat de Salt ook aan de hackers bekend is. Een 'bruteforce' aanval op je wachtwoorden is dan net zo snel als zonder Salt.

Salten moet dus gebeuren per gebruiker. Elke user heeft zijn eigen salt. Deze kan zonder al te veel problemen in de database opgeslagen worden bij de user gegevens. De hashing functie gebruikt deze salt de user salt om het wachtwoord te controleren.

Soms wordt de Salt ook achter het wachtwoord geplakt. Een soort van 'obfuscation'. Persoonlijk vind ik dit geen goede aanpak. Security door obscurity....

Een goede bron van informatie is Troy Hunt ( http://www.troyhunt.com/ ). Hij schrijft hier veelvuldig over. Ik raad je aan om zijn post een grondig door te lezen.

[ Voor 3% gewijzigd door STW op 14-11-2012 13:18 . Reden: typo, url ]

[LiquidT_NL]

In principe is het bij per-user hashes niet echt van belang om deze te verstoppen: de enige reden dat je dat gebruikt is dat mensen niet met bijv. 1 rainbowtable al je wachtwoorden achterhalen.

Volgens mij is het meest veilig inderdaad nog een global salt te nemen(pepper noemen ze dat toch?), maar de implementatie kan op veel verschillende manieren. Het maakt in veel situaties niet uit, maar het is gewoon een extra verdedigings-lijn die niet zoveel tijd of moeite kost.

[ Voor 14% gewijzigd door LiquidT_NL op 14-11-2012 13:19 ]

[mithras]

Het draait niet om het feit dat je salt mogelijk gestolen wordt. Je wil het brute forcen tegengaan door user specifieke salts te gebruiken. Daarom is een site-wide salt ook eigenlijk niet zo zinvol.

Kijk bijvoorbeeld naar hoe bcrypt een "hash" genereert:
$2a$10$vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa

Hier is 2a het bcrypt algoritme (2a staat voor blowfish) en 10 de cost-factor (hier 2¹⁰). Vervolgens is vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa de combinatie van salt en cipher aan elkaar geplakt (in een soort van base64 encoding schijnt). De eerste 22 karakters van deze decoded-string is een salt, de rest is de cipher om mee te vergelijken. Zo heb je de volledige wachtwoord-informatie in één string geplakt.

Een voorbeeldje van php's CryptLib:

PHP:

$crypt = new CryptLib\CryptLib;
if (!$crypt->verifyPasswordHash($password, $hash)) {
    //Invalid Password!
}

Waarbij $password dus de user input is en $hash een hash zoals hierboven is getoond en in je database is opgeslagen.

[ Voor 3% gewijzigd door mithras op 14-11-2012 13:23 ]

[Rmg]

4Real schreef op woensdag 14 november 2012 @ 13:05:
Maar nu vraag ik mij af, waar sla je deze salt veilig op? Ik kan mij voorstellen dat user specifieke salts voordeel hebben, omdat je dan niet één maar meerder hebt en kans dat de global salt wordt gestolen en gebruikt wordt om wachtwoorden te kraken kleiner wordt, maar waar sla je deze dan op? In de database in het zelfde records als de wachtwoord gegevens? bv: UserID, UserName, Password, Salt ?

Gewoon als kolom in dezelfde records. 64bit salt en dan success met het bouwen van een rainbowtable of het bruteforcen van de wachtwoorden

[STW]

Rmg schreef op woensdag 14 november 2012 @ 13:26:
[...]


Gewoon als kolom in dezelfde records. 64bit salt en dan success met het bouwen van een rainbowtable of het bruteforcen van de wachtwoorden

Dat is het idee achter de Salt. Lees eens deze link door.

[4Real]

Salt (+pepper) gebruiken om bruteforce aanvallen af te slaan begrijp ik, maar stel (in het ergste geval) door in exploit in je database server komen ze achter je wachtwoorden + salt dan kunnen ze een brute force gaan uitvoeren door salt + wachtwoord combinaties te gaan testen.

Kun je dan nog truckjes gebruiken om dit nog moeilijker te maken door bijvoorbeeld een paar templetes van wachtwoorden te gebruiken. Bijvoorbeeld:

userID 1 = salt-p1 + pepper-p2 + wachtwoord + salt-p1 + pepper-p2
userID 2 = salt-p2 + pepper-p1 + wachtwoord + salt-p1 + pepper-p2

En zo kun je wel paar combies maken en deze dan per UserID toepassen? Ook al hebben ze dan alle informatie de combinaties er van maken het zo moelijk dat het bijna onmogelijk wordt om de combinatie te achterhalen.

_{Welk template je moet gebruiken kun je bijvoorbeeld door gebruik te maken van de modulo operator achterhalen.}

[Rmg]

STW schreef op woensdag 14 november 2012 @ 13:28:
[...]


Dat is het idee achter de Salt. Lees eens deze link door.

Mja dat zeg ik toch. Gewoon in een extra kolom, je kan het moeilijker maken maar het levert weinig op

Enige wat de link toevoegt hoe belangrijk een goeie wachtwoord policy is

[ Voor 27% gewijzigd door Rmg op 14-11-2012 13:35 ]

[alienfruit]

Precies, dat zeg ik toch ook

[STW]

Rmg schreef op woensdag 14 november 2012 @ 13:34:
[...]


Mja dat zeg ik toch. Gewoon in een extra kolom, je kan het moeilijker maken maar het levert weinig op

Enige wat de link toevoegt hoe belangrijk een goeie wachtwoord policy is

Niet alleen een wachtwoord policy, er wordt ook gekeken naar het hashing algoritme zelf. Daar ligt ook een kwetsbaarheid. Op het moment dat je miljarden wachtwoorden per seconde kan genereren omdat je hashing algoritme zo efficiënt (lees snel ) is worden ook goed gebouwde wachtwoorden kwetsbaar.

[Orion84]

4Real schreef op woensdag 14 november 2012 @ 13:34:
Salt (+pepper) gebruiken om bruteforce aanvallen af te slaan begrijp ik, maar stel (in het ergste geval) door in exploit in je database server komen ze achter je wachtwoorden + salt dan kunnen ze een brute force gaan uitvoeren door salt + wachtwoord combinaties te gaan testen.

Kun je dan nog truckjes gebruiken om dit nog moeilijker te maken door bijvoorbeeld een paar templetes van wachtwoorden te gebruiken. Bijvoorbeeld:

userID 1 = salt-p1 + pepper-p2 + wachtwoord + salt-p1 + pepper-p2
userID 2 = salt-p2 + pepper-p1 + wachtwoord + salt-p1 + pepper-p2

En zo kun je wel paar combies maken en deze dan per UserID toepassen? Ook al hebben ze dan alle informatie de combinaties er van maken het zo moelijk dat het bijna onmogelijk wordt om de combinatie te achterhalen.

_{Welk template je moet gebruiken kun je bijvoorbeeld door gebruik te maken van de modulo operator achterhalen.}

Natuurlijk kan je in je code allerlei truken toevoegen waardoor een aanvaller ook toegang tot je code moet hebben om een zinvolle aanval te plegen (of op een andere manier moet zien uit te vogelen wat er gebeurt). Maar als je database al gecompromitteerd is, dan is de kans natuurlijk aanwezig dat de aanvaller ook toegang heeft tot je PHP/ASP code.

Bovendien maken dit soort trucks je code er niet bepaald leesbaarder en onderhoudbaarder op en loop je dus meer kans op bugs.

Dan kan je beter naar bekende standaard mechanismes kijken om bruteforce aanvallen lastiger te maken. Zie dat artikel van Troy Hunt dat hierboven gelinkt wordt. Dan hoef je het niet zelf te implementeren (dus minder foutgevoelig) en ben je voor de veiligheid niet afhankelijk van het verborgen houden van je programmacode. Dan is het enkel nog een kwestie van het nieuws een beetje bijhouden om te zien of die standaardmethode nog voldoet of dat je wat nieuwers moet inbouwen.

[ Voor 8% gewijzigd door Orion84 op 14-11-2012 13:49 ]

[Tarilo]

Je mist het punt van een salt denk ik. De salt beschermt niet tegen het brute-forcen van een wachtwoord. Bij het brute-forcen van een wachtwoord probeer je alleen een collision te vinden, deze kan best anders zijn dan het oorspronkelijke wachtwoord. Dat maakt echter niet uit, want je bent alleen opzoek naar een rij tekens die dezelfde hash opleveren.

Het hele idee achter een salt is dat je niet in één keer een tabel kan uitrekenen waarin de collisions van heel veel wachtwoorden staan. Door voor iedere gebruiker een andere salt te gebruiken is dit niet mogelijk, zelfs hetzelfde wachtwoord zal dan bij een andere gebruiker een andere hash genereren.

Het hele idee van een salt is dus niet dat het een onbekend stukje informatie is om brute-force aanvallen in de weg te zitten. De salt zorgt er echter ervoor dat je niet in één keer een tabel kan uitrekenen, maar dat je voor elke gebruiker opnieuw moet rekenen.

[frickY]

STW schreef op woensdag 14 november 2012 @ 13:17:
Global Salt gebruiken is eigenlijk 'useless. Op het moment dat ze je database te pakken hebben kan je ervan uit gaan dat de Salt ook aan de hackers bekend is. Een 'bruteforce' aanval op je wachtwoorden is dan net zo snel als zonder Salt.

Een salt gebruik je niet zodat brute-forcen niet meer mogelijk is, maar zodat bestaande rainbow-tables nutteloos zijn.

Een salt hoeft niet geheim gehouden te worden

[Tarilo]

4Real schreef op woensdag 14 november 2012 @ 13:34:
Salt (+pepper) gebruiken om bruteforce aanvallen af te slaan begrijp ik, maar stel (in het ergste geval) door in exploit in je database server komen ze achter je wachtwoorden + salt dan kunnen ze een brute force gaan uitvoeren door salt + wachtwoord combinaties te gaan testen.

Wat maakt het trouwens uit dat de aanvallers achter het wachtwoord komen als je database al binnengedrongen is. Ze hebben dan immers al alle informatie.

Ja, dit is kort door de bocht, maar het is om aan te geven dat je je wellicht te druk maakt om één stukje informatie met weinig waarde. Terwijl de rest met veel meer waarde(NAW/CC gegevens) misschien al op straat ligt.

EDIT:
Iets te kort door de bocht verwoord blijkbaar. Ik bedoel te zeggen dat de TS zich niet druk moet maken over het feit dat de salt bekend is als zijn database gekraakt wordt.

[ Voor 10% gewijzigd door Tarilo op 14-11-2012 14:15 ]

[Orion84]

Omdat mensen die wachtwoorden mogelijk ook elders gebruiken. Bovendien kan het misbruiken van andermans account best tot grotere schade leiden dan alleen het lekken van info die toch al in de gelekte database stond.

Neemt niet weg dat de lagen van beveiliging die moeten voorkomen dat je database uberhaupt op straat komt te liggen inderdaad minstens net zo belangrijk zijn. Maar dat maakt het fatsoenlijk inrichten van je password storage nog niet zinloos.

Het is wel nog weer een extra reden om voor standaard oplossingen te gaan en niet een boel tijd en moeite te steken in een of ander eigen knutselwerk.

[STW]

Tarilo schreef op woensdag 14 november 2012 @ 13:59:
[...]

Wat maakt het trouwens uit dat de aanvallers achter het wachtwoord komen als je database al binnengedrongen is. Ze hebben dan immers al alle informatie.

Ja, dit is kort door de bocht, maar het is om aan te geven dat je je wellicht te druk maakt om één stukje informatie met weinig waarde. Terwijl de rest met veel meer waarde(NAW/CC gegevens) misschien al op straat ligt.

Hoeveel mensen hebben daadwerkelijk een apart wachtwoord voor elk account dat ze gebruiken? Als je er 1 hebt.....

[Cloud]

Tarilo schreef op woensdag 14 november 2012 @ 13:59:
[...]

Ja, dit is kort door de bocht, maar het is om aan te geven dat je je wellicht te druk maakt om één stukje informatie met weinig waarde. Terwijl de rest met veel meer waarde(NAW/CC gegevens) misschien al op straat ligt.

Maar juist een emailadres en een succesvol teruggehaald wachtwoord kunnen enorme schade aanrichten. Wij mogen dan wel overal verschillende wachtwoorden gebruiken maar het gros van de wereld doet dat helaas echt niet. Het blijft dus hoe dan ook erg belangrijk een goede methode voor password storage te gebruiken. Dat is vele malen belangrijker dan de NAW die er bij staat.

[Tarilo]

Ik besef heel goed dat mensen hun wachtwoord overal voor gebruiken. Het is dus ook bij een gelekte database van groot belang dat de wachtwoorden goed beveiligd zijn.

Ik heb echter het idee dat de TS denkt dat het wachtwoord de sleutel tot alle informatie is, terwijl die informatie zonder wachtwoord ook al lang op straat kan liggen. Ik wilde duidelijke maken dat je goede prioriteiten moet stellen en niet je wachtwoorden beveiligt om de rest van je informatie veilig te houden.

[Grijze Vos]

4Real schreef op woensdag 14 november 2012 @ 13:34:
userID 1 = salt-p1 + pepper-p2 + wachtwoord + salt-p1 + pepper-p2
userID 2 = salt-p2 + pepper-p1 + wachtwoord + salt-p1 + pepper-p2

Dat soort geintjes kunnen er bijna alleen maar voor zorgen dat je per ongeluk entropie uit je wachtwoorden haalt ipv toevoegt. En daardoor wordt het decrypten vaak makkelijker ipv moeilijker.

Als je bang bent dat je passwords gedecrypt worden gebruik je een zwaarder algoritme, dan ga je niet een rond wiel vierkant maken.

[We Are Borg]

Ik gebruik zelf een per userid unieke waarde: het emailadres. Waarom aparte salt generen en opslaan als je applicatie een emailadres van de user opslaat die uniek moet zijn.

[Gomez12]

4Real schreef op woensdag 14 november 2012 @ 13:34:
Salt (+pepper) gebruiken om bruteforce aanvallen af te slaan begrijp ik, maar stel (in het ergste geval) door in exploit in je database server komen ze achter je wachtwoorden + salt dan kunnen ze een brute force gaan uitvoeren door salt + wachtwoord combinaties te gaan testen.

Maar met salt per user is het brute-forcen beperkt tot 1 wachtwoord per totale brute force poging. Dat is simpelweg te kostbaar voor de meeste toepassingen.

Grijze Vos schreef op woensdag 14 november 2012 @ 15:49:
[...]
Dat soort geintjes kunnen er bijna alleen maar voor zorgen dat je per ongeluk entropie uit je wachtwoorden haalt ipv toevoegt. En daardoor wordt het decrypten vaak makkelijker ipv moeilijker.

Als je bang bent dat je passwords gedecrypt worden gebruik je een zwaarder algoritme, dan ga je niet een rond wiel vierkant maken.

Mwah, hangt een beetje van je toepassing af. Ik ken nog wel een paar toepassingen waar ze bewust de entropie verlagen om meer kans op een werkend wachtwoord te geven waardoor er minder kans is dat het werkende wachtwoord ook het 100% juiste wachtwoord is

De truc van hashen is juist dat het niet te decoden is, heb jij je entropie zo hoog gekregen dat er slechts 1 correct wachtwoord hoort bij 1 hash dan ben je teruggevallen/overgegaan naar een encoding.
En het is maar net de vraag of encoding wel is wat je hebben wilt (hashing is veiliger voor als je users hun wachtwoord op meerdere sites gebruiken, maar encoding is veiliger voor je eigen database)

Grappige variant die ik hierop ken is een site die bij <10 tekens hashing gebruikt met verlaagde entropie, bij >=10 en <20 werd er hashing gebruikt met verhoogde entropie en bij 20+ werd er encoding gebruikt.
Puur volgens de gedachte dat <10 veelal hergebruikt zou worden, <20 is twijfelgeval, 20+ is gebruiker die weet waar hij mee bezig is en dit is een eenmalig en/of gegenereerd wachtwoord.
En de uitkomst werd in 1 veld gedumpt en aan de hand van de lengte van de input werd er de methode gekozen..
Dan mag je als attacker 3 attack-plans gaan opzetten en de kans is vrij klein dat je op korte termijn een user-password vindt wat ook op andere sites werkt.

Dat is namelijk al een tijdje een "hot" ding, niet meer de grote sites direct proberen te kraken. Maar de kleine sites proberen te kraken en dan alle wachtwoorden van @hotmail.com te testen tegen hotmail om vandaaruit verder te attacken.
Hierdoor verschijnen er lijstjes op pastebin van 160 hotmail adressen + passwords, niet doordat ze direct hotmail gekraakt hebben maar doordat ze een kleine site gekraakt hebben en de mensen hetzelfde wachtwoord als voor hun hotmail gebruikten.

[ACM]

Gomez12 schreef op vrijdag 16 november 2012 @ 00:12:
Grappige variant die ik hierop ken is een site die bij <10 tekens hashing gebruikt met verlaagde entropie, bij >=10 en <20 werd er hashing gebruikt met verhoogde entropie en bij 20+ werd er encoding gebruikt.
Puur volgens de gedachte dat <10 veelal hergebruikt zou worden, <20 is twijfelgeval, 20+ is gebruiker die weet waar hij mee bezig is en dit is een eenmalig en/of gegenereerd wachtwoord.
En de uitkomst werd in 1 veld gedumpt en aan de hand van de lengte van de input werd er de methode gekozen..
Dan mag je als attacker 3 attack-plans gaan opzetten en de kans is vrij klein dat je op korte termijn een user-password vindt wat ook op andere sites werkt.

Waarom 3 attack-plans? Je hoeft je dan in eerste instantie alleen maar te richten op degenen met < 10 lengtes - dat is waarschijnlijk toch het leeuwendeel, zeker van degenen die dat simpele wachtwoordje ook ergens anders gebruiken... Het is dan alleen maar handig dat iemand anders dat al voor je voor-gesorteerd heeft bij het opslaan van de hashes, scheelt je weer tijd verspillen aan al die > 10 wachtwoorden die een stuk lastiger te brute-forcen zijn

En met een beetje mazzel is de encoding van de > 20 zo slecht gekozen dat het uiteindelijk makkelijker om te draaien is... want in tegenstelling tot wat jij stelt is het m.i. niet hetzelfde om iets te 'encoden' en om iets te 'hashen'. Die eerste doe je omdat je er van uit gaat dat je het een keer wilt 'decoden', die laatste doe je om een uitkomst te krijgen die je kan gebruiken om (bij voorkeur) onomstotelijk vast te stellen dat dezelfde invoer beschikbaar was als toen de hash gegenereerd werd.

Ik zie niet zo goed in wat het nut is van verlaagde entropie om alleen meer collisions toe te kunnen laten. Je moet dan alsnog wel heel erg lage entropie hebben om collisions met de standaard korte wachtwoordjes te hebben... Ook betekent het verlagen van de entropie mogelijk dat je eenvoudiger een hele groep wachtwoorden kunt testen en/of dat het weer eenvoudiger is terug te brute-forcen.
Omgekeerd gesteld: als jij een hit met de optie 'test123' hebt, dan is de kans erg groot dat het wachtwoord daadwerkelijk 'test123' was en niet iets veel ingewikkelders

Dat betekent bovendien ook dat je meer kans hebt dat brute-force inloggers via je eigen inlog-pagina een bruikbaar wachtwoord weten te vinden. Ongeacht of dat dan toevallig wel of niet het juiste wachtwoord was.

[ Voor 3% gewijzigd door ACM op 16-11-2012 08:25 ]

[creator1988]

We Are Borg schreef op donderdag 15 november 2012 @ 21:29:
Ik gebruik zelf een per userid unieke waarde: het emailadres. Waarom aparte salt generen en opslaan als je applicatie een emailadres van de user opslaat die uniek moet zijn.

Omdat je voor een salt:
1. Randomness wilt
2. Veel bytes wilt (f.e. als je hash 256 bytes lang is, waarom niet 256 bytes aan hash)

Voor een e-mailadres geldt beide niet.

---

En verder, wat ik heb geleerd, probeer niet slim te zijn met dit soort dingen. Pak PBKDF2 of bcrypt en klaar.

[ Voor 11% gewijzigd door creator1988 op 16-11-2012 13:03 ]

[Orion84]

creator1988 schreef op vrijdag 16 november 2012 @ 13:02:
[...]

Omdat je voor een salt:
1. Randomness wilt
2. Veel bytes wilt (f.e. als je hash 256 bytes lang is, waarom niet 256 bytes aan hash)

Voor een e-mailadres geldt beide niet.

Randomness is helemaal niet zo boeiend. Zo lang er maar geen standaard rainbowtables beschikbaar zijn die bruikbaar zijn.

Lengte kan evt. wel een probleem zijn, al betwijfel ik of er standaard rainbowtables zijn voor strings van 16+ tekens, want daar zit je al snel aan als je wachtwoord en e-mail adres achter elkaar gaat plakken. Maar de set aan rainbowtables groeit natuurlijk alleen maar, dus het is wel goed een punt om langere salts te willen gebruiken.

---
En verder, wat ik heb geleerd, probeer niet slim te zijn met dit soort dingen. Pak PBKDF2 of bcrypt en klaar.

Hier ben ik het wel volledig met je eens. Dergelijke standaard oplossingen zijn over het algemeen verreweg te prefereren boven eigen knutselwerk.

[Sebazzz]

Meest belangrijke punten voor het kiezen van een hashalgoritme zijn:
1. Het is niet gekraakt of als onveilig beschouwd (MD5 bijvoorbeeld)
2. Het berekenen van een hash is relatief traag (bijvoorbeeld liever een algoritme dat er 150 ms over doet dan een algoritme van 10 ms)

[Paul]

We Are Borg schreef op donderdag 15 november 2012 @ 21:29:
Ik gebruik zelf een per userid unieke waarde: het emailadres.

...en toen ging je gebruiker weg bij Ziggo omdat Tele2 een leuke aanbieding had: e-mailadres...

[Rmg]

Paul schreef op vrijdag 16 november 2012 @ 16:58:
[...]
...en toen ging je gebruiker weg bij Ziggo omdat Tele2 een leuke aanbieding had: e-mailadres...

Dan laat je de gebruiker zijn wachtwoord invoeren als hij zijn email adres wijzigt, hallo nieuwe hash

[Cloud]

Rmg schreef op vrijdag 16 november 2012 @ 16:59:
[...]
Dan laat je de gebruiker zijn wachtwoord invoeren als hij zijn email adres wijzigt, hallo nieuwe hash

Natuurlijk kun je er wat op verzinnen, maar feit blijft dat het onhandig is een veranderlijk veld te gebruik als salt. Genereer bij de aanmaak van het account gewoon een salt die nooit weer hoeft te veranderen. Veel beter

[leuk_he]

Op het eerste gezicht leek email adres mij ook handig.

Echter je misbruikt een veld dat er niet voor bedoeld is , wordt zo'n email adres toch onhandig. B.V. als je in de procedure om het email adres te wijzigen ook het oude email adres bewaard tot de nieuwe bevestigd is.

Net zo goed als als je niet je userid gebruikt, want dan kun je niet users renamen (denk aan merge met andere applicatie)

[Hydra]

Cloud schreef op vrijdag 16 november 2012 @ 17:02:
Natuurlijk kun je er wat op verzinnen, maar feit blijft dat het onhandig is een veranderlijk veld te gebruik als salt. Genereer bij de aanmaak van het account gewoon een salt die nooit weer hoeft te veranderen. Veel beter

Beter weet ik niet maar het lijkt me kwa implementatie gewoon een stuk meer straightforward in ieder geval.

[Cloud]

Hydra schreef op vrijdag 16 november 2012 @ 17:42:
[...]

Beter weet ik niet maar het lijkt me kwa implementatie gewoon een stuk meer straightforward in ieder geval.

Met beter, bedoel ik dus ook meer straight forward Door het emailadres te gebruiken denkt men slim te zijn en een veldje te besparen terwijl je je er alleen maar problemen mee op de hals haalt. Volstrekt onnodig, dus een minder goede oplossing. Zie ook het probleem dat leuk_he aankaart bijvoorbeeld en zo zal er ongetwijfeld nog meer te verzinnen zijn.

edit:

@Zoijar
... is the root of all evil

[ Voor 3% gewijzigd door Cloud op 16-11-2012 20:37 ]

[Zoijar]

Cloud schreef op vrijdag 16 november 2012 @ 20:13:
Door het emailadres te gebruiken denkt men slim te zijn en een veldje te besparen terwijl je je er alleen maar problemen mee op de hals haalt.

Premature optimization Grappig dat men 8 bytes wil besparen per gebruiker (hoeveel heb je er? een miljard?) en daarvoor bereid is de code ingewikkelder en minder makkelijk aanpasbaar te maken.

[pedorus]

Inderdaad, niet over nadenken, gewoon een bestaande implementatie van bcrypt (goed), PBKDF2 (nobody got fired for) of scrypt (cutting edge) gebruiken. Zie http://security.stackexch...rypt-for-password-storage voor een betere vergelijking.

Grappig trouwens dat op fok deze drie functies überhaupt niet genoemd worden.

[Megamind]

Toevallig was ik pas bezig met een eigen authenticatie.

Ik had voorheen (lang geleden) de salt genomen als user email address alleen is dat weer lastig als je die moet wijzigen (dat was PHP dus direct in de DB wijzigingen af en toe).

Nu in .NET deze oplossing gemaakt:

C#:

public static String Hash(String password, String salt1, String salt2)
{
    var saltBytes = Encoding.ASCII.GetBytes(salt1 + salt2);

    using (var rfc2898DerivedBytes = new Rfc2898DeriveBytes(password, saltBytes, 10000))
    {
        var hashedBytes = rfc2898DerivedBytes.GetBytes(64);
        var result = hashedBytes.Aggregate(String.Empty, (current, x) => current + String.Format("{0:x2}", x)).ToLower();
        return String.Concat(salt1, result, salt2).Hash();
    }
}

Waarbij Salt1 een random sha256 is (uit de DB) en Salt2 een pepper is die hardcoded staat in het project (ter voorkoming dat er bv een db export wordt gejat).

.Hash doet bytes Sha256'en, zo heb je de traagheid van PBKDF2 en omdat deze Sha1 gebruikt een Sha2 hash.

[ Voor 13% gewijzigd door Megamind op 17-11-2012 17:41 ]

[We Are Borg]

Zoijar schreef op vrijdag 16 november 2012 @ 20:32:
[...]

Premature optimization Grappig dat men 8 bytes wil besparen per gebruiker (hoeveel heb je er? een miljard?) en daarvoor bereid is de code ingewikkelder en minder makkelijk aanpasbaar te maken.

Wie zegt dat ik het doe om bytes te besparen? In mijn geval veranderd het emailadres nooit (zeg nooit nooit, maar kans is erg klein). Dus waarom een hash generen en opslaan als ik al een unieke waarde heb om mee te hashen? Is een random waarde van bijv 32 tekens zoveel beter dan [e-mail]? Voor een salt maakt dat niks uit

[Cartman!]

Omdat de salt een eigen functie heeft net als het e-mailadres.

Zelf heb ik laatst auth-adapters gemaakt voor bcrypt, pbkdf2 en scrypt. Voor de laatste heb je in php een extensie nodig helaas, meestal wil een hoster die niet installeren.

[pedorus]

We Are Borg schreef op zaterdag 17 november 2012 @ 21:25:
Is een random waarde van bijv 32 tekens zoveel beter dan [e-mail]? Voor een salt maakt dat niks uit

Precies, en het handige is ook dat je makkelijk kunt testen of iemand hetzelfde wachtwoord op meerdere plaatsen gebruikt. Oh, wacht

Megamind schreef op zaterdag 17 november 2012 @ 17:35:
Ik had voorheen (lang geleden) de salt genomen als user email address alleen is dat weer lastig als je die moet wijzigen (dat was PHP dus direct in de DB wijzigingen af en toe).

Nu in .NET deze oplossing gemaakt:

Waarom zou je niet een van de drie hierbovenstaande standaardfuncties gebruiken, en toch net ietsje anders te werk gaan wat het lastig te porteren maakt met de kans op andere foutjes?

[Megamind]

pedorus schreef op zondag 18 november 2012 @ 01:02:
[...]
Waarom zou je niet een van de drie hierbovenstaande standaardfuncties gebruiken, en toch net ietsje anders te werk gaan wat het lastig te porteren maakt met de kans op andere foutjes?

Hoe bedoel je? Ik gebruik PBKDF2 en Sha2 alleen gecombineerd.

Implementatie is een kwestie van goed unit testen met test vectors.

[joppybt]

Megamind schreef op zondag 18 november 2012 @ 10:38:
[...]

Hoe bedoel je? Ik gebruik PBKDF2 en Sha2 alleen gecombineerd.

Implementatie is een kwestie van goed unit testen met test vectors.

Met testen bereik je dat het antwoord klopt (wachtwoord al dan niet goedgekeurd). Ik geloof wel dat je dat goed krijgt.

Het is bij security-oplossingen altijd een veel groter probleem dat door eigen implementaties het netto resultaat vaak onbedoeld veel *minder* veilig is dan een standaard implementatie. Ik durf niet te zeggen dat jou oplossing dat probleem heeft maar volgens mij kun jij ook niet bewijzen dat het net zo veilig is.

[Megamind]

joppybt schreef op zondag 18 november 2012 @ 11:17:
[...]

Met testen bereik je dat het antwoord klopt (wachtwoord al dan niet goedgekeurd). Ik geloof wel dat je dat goed krijgt.

Het is bij security-oplossingen altijd een veel groter probleem dat door eigen implementaties het netto resultaat vaak onbedoeld veel *minder* veilig is dan een standaard implementatie. Ik durf niet te zeggen dat jou oplossing dat probleem heeft maar volgens mij kun jij ook niet bewijzen dat het net zo veilig is.

Klopt zeker, mijn security kennis is zeker niet voldoende hiervoor en waarschijnlijk is het meer security through obscurity.

[Devil]

Het makkelijkste voor PHP is denk ik een bcrypt implementatie te gebruiken. Het moeilijkste is nog het genereren van een salt van 22 tekens, verder is het een fluitje van een cent, omdat de output van crypt() ook direct als input kan dienen bij het verifiëren. Crypt prefixed de output output hash namelijk automatisch met het algoritme,de costfactor en de gebruikte salt. Een bij het controleren wordt als salt alleen de eerste 22 tekens van de input gebruikt. Geen extra veldje in de db nodig dus.

Password opslaan:
1: genereer salt van 22 tekens (a-Z0-9)
2: prefix salt met $2y$10$ (blowfish met costfactor 10 PHP 5.4)
3: sla output van crypt(password,salt) op in db

Password controleren:
1: hash (output van stap 3) ophalen uit db
2: crypt(password, hash)=== hash

Moeilijker is het niet.

[ Voor 14% gewijzigd door Devil op 18-11-2012 23:17 ]

[Barryvdh]

Voorbeeldje van implementatie, die ook random salt maakt, in php:
https://gist.github.com/1070401 (al raden ze vanaf 5.3.7 dus $2y aan, ipv 2a)

En ze hebben zelf ook door dat het niet altijd even makkelijk te gebruiken is, vandaar vanaf PHP5.5 een nieuwe api; https://wiki.php.net/rfc/password_hash, die zo te zien nu al te gebruiken is via https://github.com/ircmaxell/password_compat)

[ Voor 63% gewijzigd door Barryvdh op 18-11-2012 23:52 ]

[alienfruit]

Ik gebruik zelf het volgende om een salt te bepalen:

PHP:

   public static function generateEntropy() {
        // use mcrypt with urandom if we're on 5.3+
        if (version_compare(PHP_VERSION, '5.3.0', '>=')) {
            return mcrypt_create_iv(64, MCRYPT_DEV_URANDOM);
        }

        // otherwise try ssl (beware - it may slow down
        // your app by a few milliseconds)
        if (function_exists('openssl_random_pseudo_bytes')) {
            $entropy = openssl_random_pseudo_bytes(64, $strong);
            // use ssl only if it was using the strong algo
            if ($strong) {
                return $entropy;
            }
        }

        // try to read from the unix RNG
        if (is_readable('/dev/urandom') && ($handle = fopen('/dev/urandom', 'rb'))) {
            $entropy = fread($handle, 64);
            fclose($handle);
            return $entropy;
        }

        // Warning !
        // from here on, the entropy is considered weak
        // so you may want to consider just throwing
        // an exception to realize that your code is running
        // in an insecure way

        // try to read from the windows RNG
        if (class_exists('COM')) {
            try {
                $com = new COM('CAPICOM.Utilities.1');
                $entropy = base64_decode($com->GetRandom(64, 0));
                return $entropy;
            } catch (Exception $ex) {
            }
        }

        // last solution.. barely better than nothing
        return uniqid(mt_rand(), true);
    }

[TheNephilim]

Grappig om te zien, die verschillende manieren waarop mensen een salt gebruiken/inzetten/genereren/etc.

Toch ontgaat me de logica van een zichtbare salt even; als een hacker de password hash heeft en de salt die voor die hash gebruikt is. Beide in dezelfde tabel, beide buitgemaakt. Heeft dat geen enkele invloed op het makkelijker kraken van het wachtwoord, als de hacker zowel de hash als de salt heeft?

Het wil me niet lukken, kan iemand dat even in heldere taal uitleggen?

[Cloud]

Dat heeft inderdaad geen invloed op de poging van de hacker om het wachtwoord voor dát specifieke record te achterhalen

Echter, als de salt voor elke gebruiker anders is zullen rainbow tables vrijwel onmogelijk bruikbaar zijn (eigenlijk nooit). Daarnaast, mocht de hacker één wachtwoord succesvol weten te herleiden, dan is het onmogelijk om te zien of een andere gebruiker hetzelfde wachtwoord hanteert (want: andere salt). Zelfs als alle gebruikers 'test1234' als wachtwoord hebben, zal elke hash verschillen en dus apart van elkaar 'gebroken' moeten worden.

[ Voor 4% gewijzigd door Cloud op 19-11-2012 14:27 ]

[Hydra]

De user-salt is niet om het kraken van 1 specifiek wachtwoord makkelijk te maken. Als een hacker je DB heeft, heeft 'ie je code waarschijnlijk ook, dus zijn global en user salts toch wel bekend. De reden is dat je niet wil dat een hacker 1 gegenereerde hash tegen ALLE users uit je DB kan houden. Dus:

- geen salt: een hacker kan rainbow tables gebruiken
- global salt: een hacker kan geen rainbow tables gebruiken en moet een hash genereren voor elke brute-force attempt (aaaaa,aaaab, etc.) die hij tegen de HELE database kan houden
- user salt: een hacker kan geen rainbow tables gebruiken en moet een hash genereren voor elke attempt en ELKE USER.

Met een user salt moet een hacker veel meer werk doen om voor alle users in je DB de wachtwoorden te achterhalen.

Edit: crap! With stupid ^^

[TheNephilim]

Ah oké het begint door te dringen, thanks! Dus...

PHP:

$global_salt = "bijv-projectnaam";
$user_salt = "64-128-chars-dikke-salt";

hash('sha256', $global_salt.$password.$user_salt);

... is dus helemaal veilig. Goed het is dan even heel simpel zoals bovenstaand, maar voor mij een denkbare situatie.

De hacker heeft een collision nodig, maar je hebt aan de salts want je moet alles nog doorrekenen natuurlijk. Yup, het is me duidelijk!

[Hydra]

Als je een user-salt hebt is m.i. een global salt niet erg nuttig meer, maargoed.

SHA256 is niet veilig omdat het alsnog simpel te bruteforcen is. If in doubt, use bcrypt.

[Barryvdh]

Inderdaad, gewoon de standaard bcrypt gebruiken, of een implementatie daarvan waar mensen goed over na gedacht hebben (hoe je veilige salt maakt enzo)

In die RFC voor de nieuwe PHP functies voor hashing, staan ook aardig wat links/overwegingen waarom bepaalde dingen wel/niet veilig zijn, ook over het gebruik van een pepper (of globale salt), oa. dat er geen onderzoeken zijn die aangeven dat het uberhaupt veiliger is.

[Hydra]

Global salt is veiliger dan uberhaupt geen salt. Vergeet niet dat veel van deze documentatie volledig antiek is. Toen ik 10 jaar geleden met PHP aan de slag ging was het al zo dat je geen MD5 meer mocht gebruiken bijvoorbeeld. Men kwam erachter dat je met pregenerated rainbow tables wel bijzonder makkelijk hele databases kon onsleutelen en zodoende kwam met op het global salt idee, want bruteforcen was hoe dan ook niet mogelijk.

10 jaar later is bruteforcen van SHA een eitje en biedt ook een global salt geen enkele bescherming meer en wil je een algorithme dat moeilijk te bruteforcen is, en wil je bovendien niet dat je met 1 gegenereerde hash de hele database kunt checken. Vandaar bcrypt + user salt. Daarin is "geen SHA gebruiken" belangrijker dan "gebruik een user salt" IMHO.

[Megamind]

Global salt / pepper is toch eigenlijk wel logischer veilig?

Een hacker verkrijgt een database kopie, dit kan een simpele export zijn, hij heeft nu voldoende informatie om een rainbow table voor een user te maken.

Heb je een gobal salt dan zal de hacker eerst óók de broncode moeten hebben voordat hij een rainbow table kan maken.

[Cartman!]

Waarom zou je daarop gokken? Gewoon per user salt gebruiken met een stevige workfactor. Als iemand een dump van m'n hele tabel heeft kunnen maken zou ik uit gaan van het slechtse, dat diegene ook m'n code heeft.

[Voutloos]

Megamind schreef op maandag 19 november 2012 @ 17:23:
Een hacker verkrijgt een database kopie, dit kan een simpele export zijn, hij heeft nu voldoende informatie om een rainbow table voor een user te maken.

NEEN.

Nofi, maar t is al uitgebreid besproken in dit topic, 100 andere topics en t halve internet, dus dit soort reacties is imnsho behoorlijk kortzichtig.

[joppybt]

alienfruit schreef op maandag 19 november 2012 @ 11:54:
Ik gebruik zelf het volgende om een salt te bepalen:

PHP:

   public static function generateEntropy() {
....
    }

Goed bedoeld maar zo extreem random hoeft een salt helemaal niet te zijn, zie bijvoorbeeld http://security.stackexch...tter-how-random-a-salt-is

Als een hacker de hash te pakken heeft gekregen heeft hij hoogstwaarschijnlijk de salt ook wel te pakken. Dat die cryptografisch random is voegt dan niets meer toe.

Het enige wat belangrijk is dat hij *uniek* is en dat doen niet-cryptografische randomgenerators meestal ook wel goed.

[brambo123]

Ik heb het laatst mooie?/rare? oplossing gemaakt.

PHP:

$data = hash('sha384', $password, true);
$data .= hash('sha384', hexToStr($user_salt), true);
$data .= hash('sha384', $username, true);
$hash = hash('sha512', $data);

function hexToStr($hex)
{
    $string='';
    for ($i=0; $i < strlen($hex)-1; $i+=2)
        $string .= chr(hexdec($hex[$i].$hex[$i+1]));
    return $string;
}

(gebruik hexToStr omdat mijn user salt ook hex is)

de 'true' als 3e parameter in hash() zorgt er voor dat je raw bytes terug krijgt i.p.v. een hexadecimale string.
Bij sha384 is dat dus een 48 bytes i.p.v. hex string van 96 tekens.
$data geeft dus uiteindelijk 144 bytes die niet als normale string herkenbaar is.
Als je dat in een browser zou weergeven krijg je dus zoiets:

v„2{ ¥/ÎBÄpk<®Pà*dÊ¡jx"I¿èïÄ·ïËbUÑ–}şß ©Œ%è“htñ]“kÔK;“Øœ.‘)p¯µ½¤3†çßZ?æ^ÚS‹Kü,ıÂ[ÀÁ¦r.<QÙ”r¨Ûú¹²¸{c$ÚFAÛ2 Ÿó/,½™kR#xé¹ú½”#ê‚0

Hierdoor kun je niet echt makkelijk zien of het nou een geldige waarde is wat je terug krijgt.
Wordt het voor een hacker vast niet makkelijk van
Om ze het nog wat lastiger te maken kun je ook nog wat leuks met het opslaan in mysql.
I.p.v. het opslaan van een hex kun je ook raw bytes opslaan.
Hierdoor bespaar je de helft aan data en kun je niet zomaar een dump maken.
Dit kan simpelweg door:

SQL:

UPDATE `users` SET `password` = UNHEX('d41d8cd98f00b204e9800998ecf8427e')
SELECT HEX(`password`) as `hash` FROM `users`

Moet je wel de charset even op een bin type zetten, bijvoorbeeld ascii_bin of utf8_bin
Als je dan een dump maakt maakt mysql van alle onbekende tekens een ?
Even een voorbeeld:
Als je UNHEX('aabbccddeeff') opslaat in mysql en daar een gewone dump van maakt krijg je '??????'
Daar heeft hacker dus lekker niets aan
Maar als je in mysql HEX(`password`) doet krijg je gewoon 'AABBCCDDEEFF' terug.
Let wel op: php geeft hash lowercase terwijl mysql uppercase geeft.
Moet je 1 van beide dus even omzetten voor ze te vergelijken.

[Anoniem: 26306]

Een mooi staaltje van complete onzin. Je verknoeit de waarde van het hashing algoritme door er verkeerde dingen mee te doen. Drie losse hashes achter elkaar plakken en dat weer hashen? Ik kan me absoluut niet voorstellen dat het resultaat er sterker van wordt en vermoed sterk dat het averechts werkt en dat je de boel veel zwakker maakt.

Ik zie echt niet in waarom je niet gewoon salt+hash(salt+password) opslaat.

[RobIII]

^ Wat hij zegt, en:

brambo123 schreef op maandag 19 november 2012 @ 21:23:
Als je UNHEX('aabbccddeeff') opslaat in mysql en daar een gewone dump van maakt krijg je '??????'
Daar heeft hacker dus lekker niets aan

Een hacker die niet snapt dat Hex maar één mogelijke representatie van een zooi bits is verdient die term hacker niet; sterker: die kent de absolute beginselen van programmeren/hacken niet eens. Ik heb ook nooit begrepen waarom er pas in PHP5 een "raw parameter" bij de hashfuncties kwam (en waarom die default false is (maar dat zal wel backwards compatibility zijn)). Een hash levert gewoon een zooi bits/bytes op en doorgaans worden die in hex gerepresenteerd. Maar dat maakt verder geen kont uit; al zou je het schrijven in romeinse cijfers; de waarde die de string representeert is nog steeds hetzelfde.

[ Voor 41% gewijzigd door RobIII op 19-11-2012 21:43 ]

[joppybt]

RobIII schreef op maandag 19 november 2012 @ 21:34:
^ Wat hij zegt, en:

[...]
al zou je het schrijven in romeinse cijfers; de waarde die de string representeert is nog steeds hetzelfde.

Hoewel ik toch benieuwd ben hoe 0xd41d8cd98f00b204e9800998ecf8427e in Romeinse cijfers te noteren is

[ZpAz]

joppybt schreef op maandag 19 november 2012 @ 21:52:
[...]

Hoewel ik toch benieuwd ben hoe 0xd41d8cd98f00b204e9800998ecf8427e in Romeinse cijfers te noteren is

Karakter naar UTF-8 (of andere encoding naar keuze), kijken welke hex waarde het heeft in deze tabel en die naar decimaal. Het resultaat daarvan weer naar romeins en klaar.

[brambo123]

Normale string lijkt mij makkelijker met brute force dan raw bytes.
En een hash wordt als het goed is sterker met waardes tussen 0-255 i.p.v. alleen leesbare tekens.
Of lijkt dat nou alleen maar zo??

Het punt van opslaan in mysql bedoel ik wel echt letterlijk.
Als jij een simpele dump maakt krijg je ?????? in je dump file te staan.
Krijg je bv:
INSERT INTO `users` (`username`, `password`, `salt`) VALUES ('brambo123', ' ??Fj?n???|??x]??tf.?Nc@3?<?-x~y?????K/?-??\rro????B??qs??c', 'lTR?F?*?&?w?????');
Wat je dan moet is een dump maken met --hex-blob.
Maar met sql injecties moet je met HEX() functie gaan werken.
Wordt het toch niet bepaalt makkelijker van.
Het bespaart je in ieder geval de helft in opslag van je hashes t.o.v. hex string.

[Anoniem: 26306]

Ga je nou maar gewoon inlezen.

[joppybt]

brambo123 schreef op maandag 19 november 2012 @ 22:22:
Normale string lijkt mij makkelijker met brute force dan raw bytes.
En een hash wordt als het goed is sterker met waardes tussen 0-255 i.p.v. alleen leesbare tekens.
Of lijkt dat nou alleen maar zo??

Een hash van 20 raw bytes vergt als je die hexadecimaal opslaat 40 ('leesbare') bytes. Doordat deze versie dubbel zo lang is, is deze exact even sterk als de raw-versie (maar vergt inderdaad meer opslag)

Het punt van opslaan in mysql bedoel ik wel echt letterlijk.
Als jij een simpele dump maakt krijg je ?????? in je dump file te staan.
Krijg je bv:
INSERT INTO `users` (`username`, `password`, `salt`) VALUES ('brambo123', ' ??Fj?n???|??x]??tf.?Nc@3?<?-x~y?????K/?-??\rro????B??qs??c', 'lTR?F?*?&?w?????');
Wat je dan moet is een dump maken met --hex-blob.

Ja en? Als jij als eigenaar die dump hebt gemaakt doe je dat waarschijnlijk met de bedoeling hem ooit terug te lezen (backup restoren?). Als de hash niet terug te lezen is heb je er zelf ook niets aan. Als de hash wel terug te lezen is gaat jou argumentatie niet op.

Maar met sql injecties moet je met HEX() functie gaan werken.

Dat is toch wel het minste probleem van een hacker.

Wordt het toch niet bepaalt makkelijker van.
Het bespaart je in ieder geval de helft in opslag van je hashes t.o.v. hex string.

Het enige ware argument, hoewel zelden relevant met de schijven van tegenwoordig.

[brambo123]

@Cheatah
Dat is makkelijker gezegd als gedaan.
Probleem is dat er nog op veel sites staat dat MD5('password') sterk genoeg is.
Staan zo veel dingen op internet over global salt, user salt en de hash_hmac() functie in php.
Welke info moet je nou wel geloven en welke nou niet.
En mensen kunnen nou eenmaal niet zomaar onderscheiden of iets nou echt veiler is of dat het alleen maar zo lijkt.

@joppybt
Kijk, daar heb je gewoon wat aan.

[joppybt]

brambo123 schreef op maandag 19 november 2012 @ 22:57:
Staan zo veel dingen op internet over global salt, user salt en de hash_hmac() functie in php.
Welke info moet je nou wel geloven en welke nou niet.
En mensen kunnen nou eenmaal niet zomaar onderscheiden of iets nou echt veiler is of dat het alleen maar zo lijkt.

Maar dit geldt onverminderd ook voor alles wat je in dit topic en/of forum leest.

Ik ben bijvoorbeeld ook maar een hobbyist die van alles over het onderwerk 'security' leest en interpreteert en mijn mening 'vertrouw' je wel?

[Herko_ter_Horst]

Als je iets wilt aannemen, neem dan dit aan:

Basisbeginsel security: ga er vanuit dat ALLES(*) bekend is bij een aanvaller, BEHALVE het authentieke wachtwoord/key. AL HET ANDERE is security-through-obscurity (oftewel GEEN security).

(*) inclusief de gebruikte algoritmes, al je code, slimme truukjes, salt, pepper, het hele kruidenrek wat mij betreft, de geboortedatum van je moeder, de naam van je eerste knuffelbeest, etc, etc, etc.

HEX()/UNHEX() is echt pure onzin. Dit maakt het voor mensen onleesbaar, maar een scriptje maakt het echt geen hol uit. Kun je net zo goed Base64 er overheen halen...

[Paul]

Herko_ter_Horst schreef op maandag 19 november 2012 @ 23:40:
AL HET ANDERE is security-through-obscurity (oftewel GEEN security).

En hier rebelleer ik keer op keer op keer tegen

Ik begin mijn verhaal altijd met toegeven dat het voor iemand die door de obscurity heen kijkt inderdaad niks toevoegt, en je er dus niet op moet vertrouwen.

Echter: Er zijn heeeeeeeeel veel mensen die potentieel proberen binnen te komen, en het niveau van die mensen verschilt van persoon tot persoon. Hoe meer obscurity hoe kleiner de groep mensen wordt die het om te beginnen eens lukt om die database te bemachtigen (of de code), laat staan dat ze de wachtwoorden achterhalen.

Je kunt nog zo hard roepen dat obscurity niks toevoegt, andersom ga ik 'jou' niet de ip-adressen, poortnummers en username geven van mijn SQL-, web- of FTP-server: Het maakt de groep mensen die even komen kijken heel veel groter.

Alles inrichten zodat 'niemand' je last line of defense kan doorbreken en dan nul aandacht besteden aan de eerste (paar, tientallen, ??) verdedigingslinies zorgt er alleen maar door dat het erg druk wordt bij die laatste linie

[Orion84]

Behalve het buitenhouden van eenvoudige aanvallen kan het ook een middel zijn om aanvallers te vertragen, waardoor je monitoring en incident respons tools en processen meer kans hebben om tijdig het probleem te signaleren en te tackelen voordat de aanvaller zijn doel volledig bereikt heeft.

Een zwak algoritme gebruiken en dat denken op te lossen door het te verstoppen is inderdaad bijzonder onverstandig.

Daarnaast loop je met obscurity, zoals Herko terecht opmerkt, natuurlijk het risico dat je het ook voor jezelf complexer maakt, waardoor onderhoudbaarheid en kwaliteit achteruit gaan. En dat levert dan vervolgens natuurlijk weer security risico's op.

[leuk_he]

Orion84 schreef op dinsdag 20 november 2012 @ 09:46:
Daarnaast loop je met obscurity, zoals Herko terecht opmerkt, natuurlijk het risico dat je het ook voor jezelf complexer maakt, waardoor onderhoudbaarheid en kwaliteit achteruit gaan.

Obscurity , zoals niet standaard poorten, heeft als voordeel dat er minder mensen aan de poorten rammelen, zodat audit tools/logs wat minder ruis krijgen, zodat je meer kans hebt echte vreemde dingen daarin terug te kunnen vinden.

Obscuirty zoals in je eigen encryptie methode proberen uit te vinden is meestal geen goed idee.

[ Voor 8% gewijzigd door leuk_he op 20-11-2012 10:12 ]

[Standeman]

leuk_he schreef op dinsdag 20 november 2012 @ 10:10:
[...]


Obscurity , zoals niet standaard poorten, heeft als voordeel dat er minder mensen aan de poorten rammelen, zodat audit tools/logs wat minder ruis krijgen, zodat je meer kans hebt echte vreemde dingen daarin terug te kunnen vinden.

Obscuirty zoals in je eigen encryptie methode proberen uit te vinden is meestal geen goed idee.

Je moet jezelf ook wel enorm overschatten als je denkt iets beters te kunnen verzinnen dan bijv. Rijndael.Er zullen vast mensen zijn die dat kunnen, maar die moet je wel met een vergrootglas zoeken..

[ Voor 7% gewijzigd door Standeman op 20-11-2012 10:18 ]

[Cloud]

Inderdaad Er worden twee dingen door elkaar gehaald volgens mij. Je hebt obscurity, als in:

1. het de aanvaller zo moeilijk als mogelijk te maken een aanvalspoging te starten en/of deze te vertragen.
2. zelf slim te zijn door 'slimme' trucjes uit te halen met dingen waarvoor bewezen betrouwbare oplossingen verkrijgbaar zijn.

Nummer 1 is echt niet erg, daar schaar ik niet-standaard poorten bijvoorbeeld onder. Nummer 2 geeft echter een vals gevoel van veiligheid en is echt heel slecht. Toegegeven, als je niet heel slim bezig bent zou je ook kunnen denken dat je met 1 daadwerkelijk veiliger bent. Punt is, alles wat je met beveiliging doet moet weloverwogen zijn en denk absoluut nooit dat je slimmer bent dan je aanvallers.

Standeman schreef op dinsdag 20 november 2012 @ 10:17:
[...]

Je moet jezelf ook wel enorm overschatten als je denkt iets beters te kunnen verzinnen dan bijv. Rijndael.

En toch gebeurt het af en toe

[Hydra]

Cloud schreef op dinsdag 20 november 2012 @ 10:22:
Inderdaad Er worden twee dingen door elkaar gehaald volgens mij.

Precies, en niet alleen op Tweakers. Het bekende "Security through obscurity is no security" wordt vaak verkeerd uitgelegd. "Security through obscurity", dus letterlijk dat obscurity je beveiliging is, is verkeerd. Maar obscurity bovenop een degelijke security is niks mis mee aangezien het de aanvaller waarschijnlijk vertraagt.

[Woy]

Hydra schreef op dinsdag 20 november 2012 @ 12:39:
[...]


Precies, en niet alleen op Tweakers. Het bekende "Security through obscurity is no security" wordt vaak verkeerd uitgelegd. "Security through obscurity", dus letterlijk dat obscurity je beveiliging is, is verkeerd. Maar obscurity bovenop een degelijke security is niks mis mee aangezien het de aanvaller waarschijnlijk vertraagt.

Waarbij je nog steeds moet oppassen dat je niet iets doet dat de security verminderd. Meerdere malen Hashen lijkt bijvoorbeeld misschien een goed idee, maar zoals al eerder in het topic genoemd kan dat ook de security verminderen.

[Sleepkever]

Eigenlijk het enige gevaar voor password hashes tegenwoordig is brute forcen, er zijn wel methodes om dat bruteforcen te versnellen, maar makkelijk compleet omkeren doe je niet.

Hoe doet met dat, juist, door zo snel mogelijk, zo veel mogelijk hashes af te gaan. Als je dan een simpele hash zoals md5 pakt die gemaakt is om files van enkele gigabytes snel te kunnen hashen, dan ga je heel veel hashes in heel weinig seconden kunnen genereren -> resultaat, makkelijk te maken rainbow tables en dus makkelijk te brute forcen.

2 manieren om die brute force duratie te verlengen: hash vergroten zodat er meer mogelijkheden zijn, of de hash functie zwaarder maken.

Nu is er al verteld dat meerdere malen hashen geen goed idee is. Maar als hier goed naar gekeken wordt, is het dan niet veilig genoeg om te doen? Dat zou betekenen dat ipv enkele honderd duizenden hashes per seconden, je bij een hash functie die 10ms of 1ms duurt (voor een login op een webpage in mijn mening verwaarloosbaar) nog maar 100 of 1000 hashes per seconden kan genereren met een rainbow table. Waardoor dat niet meer practisch is.

Erg interessant leesvoer en PHP passwords "done right" voor zover ik als security leek kan zien is overgens hier te vinden: http://www.openwall.com/articles/PHP-Users-Passwords Zeker het lezen waard, en de bijbehorende library gebruik ik tegenwoordig standaard overal. Veel beter dan zelf een oplossing proberen te knutselen.

[LiquidT_NL]

Vertragen kan net zo goed door de hash functie 100x te herhalen, maar het schiet niet echt op. Gelukkig zijn bcrypt en soortgelijken volgens mij redelijk "zwaar", dus even makkelijk door die hashes heen knallen gaat dan niet zo makkelijk.

[PolarBear]

Herko_ter_Horst schreef op maandag 19 november 2012 @ 23:40:
Als je iets wilt aannemen, neem dan dit aan:

Basisbeginsel security: ga er vanuit dat ALLES(*) bekend is bij een aanvaller, BEHALVE het authentieke wachtwoord/key. AL HET ANDERE is security-through-obscurity (oftewel GEEN security).

(*) inclusief de gebruikte algoritmes, al je code, slimme truukjes, salt, pepper, het hele kruidenrek wat mij betreft, de geboortedatum van je moeder, de naam van je eerste knuffelbeest, etc, etc, etc.

HEX()/UNHEX() is echt pure onzin. Dit maakt het voor mensen onleesbaar, maar een scriptje maakt het echt geen hol uit. Kun je net zo goed Base64 er overheen halen...

Dan nog kan je beter defense in depth gebruiken (dus wel een salt + pepper). Elke goede beveiligingsmaatregel die je kan nemen moet je ook nemen wat bij betreft. Ook al ga je er van uit dat alles bekend is. Dus wel Salt + Pepper, maar ook zo veel als mogelijk service accounts gebruiken en rechten op de database/code beperken, SSL, PBKDF2 of bcrypt, goede IDS, log checking etc etc. Salt opslaan is maar 1% van alle maatregelen die je moet nemen om de veiligheid van je webapplicatie te vehogen.

LiquidT_NL schreef op dinsdag 20 november 2012 @ 13:21:
Vertragen kan net zo goed door de hash functie 100x te herhalen, maar het schiet niet echt op. Gelukkig zijn bcrypt en soortgelijken volgens mij redelijk "zwaar", dus even makkelijk door die hashes heen knallen gaat dan niet zo makkelijk.

Wikipedia: PBKDF2

[ Voor 14% gewijzigd door PolarBear op 20-11-2012 13:32 ]

[deadinspace]

Sleepkever schreef op dinsdag 20 november 2012 @ 12:53:
Hoe doet met dat, juist, door zo snel mogelijk, zo veel mogelijk hashes af te gaan. Als je dan een simpele hash zoals md5 pakt die gemaakt is om files van enkele gigabytes snel te kunnen hashen, dan ga je heel veel hashes in heel weinig seconden kunnen genereren -> resultaat, makkelijk te maken rainbow tables en dus makkelijk te brute forcen.

Met die "dus" haal je wat dingen door elkaar.

Brute force is iets anders dan gebruik maken van rainbow tables. Bij het gebruik van een rainbow table zoek je hashes op in je voorberekende tabellen en brute-force je die hashes dus niet. Dat is een belangrijk onderscheid, want het betekent dat hoe zwaarder de hashfunctie is, hoe aantrekkelijker rainbow tables worden (en dus hoe belangrijker een salt wordt).

2 manieren om die brute force duratie te verlengen: hash vergroten zodat er meer mogelijkheden zijn, of de hash functie zwaarder maken.

De hashfunctie zwaarder maken helpt inderdaad. De digest groter maken? Dat gaat niet helpen.

Het aantal outputs van een hashfunctie dat voorkomt wordt in dit geval niet zozeer beperkt door de outputgrootte, maar meer door het aantal mogelijke inputs. Als je duizend mogelijke wachtwoorden hebt, dan krijg je maar hoogstens duizend verschillende hashes. Het maakt daarbij niet uit of je hashfunctie nou een miljoen of een miljard mogelijke outputs heeft, het is het aantal inputs dat de bottleneck is.

Zelfs bij MD5 (2¹²⁸ mogelijke digests) en wachtwoorden van 19 karakters random (hoofd)letters, cijfers en leestekens op een US qwerty toetsenbord (minder dan 2¹²⁵ mogelijke wachtwoorden) is het aantal inputs de bottleneck. En met 2¹²⁵ zit je al ver buiten het bereik van wat realistisch aangevallen kan worden.

Begrijp me niet verkeerd, gebruik gerust sha256 of sha512. Maar de grotere digest maakt hiervoor niet zoveel uit (zeker niet vergeleken met de degelijkheid van een gemiddeld wachtwoord).

Nu is er al verteld dat meerdere malen hashen geen goed idee is. Maar als hier goed naar gekeken wordt, is het dan niet veilig genoeg om te doen?

Ja, als je het goed doet. Maar dat doen de meeste mensen helaas niet.

Daarom is het verstandig om zoiets niet zelf te maken, maar een goede implementatie van een bestaand schema (zoals bcrypt, scrypt, PBKDF2) te nemen. Dat is gemaakt door mensen die er verstand van hebben en precies over dat soort zaken nagedacht hebben.

Erg interessant leesvoer en PHP passwords "done right" voor zover ik als security leek kan zien is overgens hier te vinden: http://www.openwall.com/articles/PHP-Users-Passwords Zeker het lezen waard, en de bijbehorende library gebruik ik tegenwoordig standaard overal.

Ik heb er even vlug doorheen gekeken, en de inleiding ziet er degelijk genoeg uit

Veel beter dan zelf een oplossing proberen te knutselen.

QFT!

LiquidT_NL schreef op dinsdag 20 november 2012 @ 13:21:
Vertragen kan net zo goed door de hash functie 100x te herhalen, maar het schiet niet echt op.

Nee, dat kan niet zomaar zonder veiligheid te verliezen. Door gewoon de hash te herhalen verlies je onnodig entropie uit het wachtwoord.

100 keer herhalen schiet oveigens wel degelijk op, je maakt daarmee brute force 100 keer zo traag!

Gelukkig zijn bcrypt en soortgelijken volgens mij redelijk "zwaar", dus even makkelijk door die hashes heen knallen gaat dan niet zo makkelijk.

De hele reden dat key strengthening algoritmes als bcrypt zwaar zijn is omdat ze een deel van het hashing proces een instelbaar aantal keer herhalen. Het grote verschil is dat bij die algoritmes er goed over nagedacht is hoe dat veilig te doen (bijvoorbeeld door het originele wachtwoord bij elke iteratie mee te hashen).

[LiquidT_NL]

deadinspace schreef op dinsdag 20 november 2012 @ 14:07:

Nee, dat kan niet zomaar zonder veiligheid te verliezen. Door gewoon de hash te herhalen verlies je onnodig entropie uit het wachtwoord.

100 keer herhalen schiet oveigens wel degelijk op, je maakt daarmee brute force 100 keer zo traag!

Ik bedoelde dan ook om de hash 100 keer te herhalen, zonder de output van de iteratie te gebruiken als input van de volgende.

De hele reden dat key strengthening algoritmes als bcrypt zwaar zijn is omdat ze een deel van het hashing proces een instelbaar aantal keer herhalen. Het grote verschil is dat bij die algoritmes er goed over nagedacht is hoe dat veilig te doen (bijvoorbeeld door het originele wachtwoord bij elke iteratie mee te hashen).

Precies, daarom, beter iets als bcrypt.

Excuses als ik nogal n00b overkom, ben ook maar een hobbyist qua encryptie en ben nog sterk lerende.

[Cloud]

LiquidT_NL schreef op dinsdag 20 november 2012 @ 14:37:
[...]

Ik bedoelde dan ook om de hash 100 keer te herhalen, zonder de output van de iteratie te gebruiken als input van de volgende.

Dus als ik je goed begrijp, genereer je 100 keer dezelfde hash? Want dan blijven zowel input als output dus gelijk en is iteratie n niet afhankelijk van het voltooien van iteratie n-1. Dat kan wel, maar vertraagd alleen maar het inloggen. Als een kwaadwillende je DB heeft dan helpt je dat niet.

Bcrypt en verwante algoritmes gebruiken naast de oorspronkelijke input (dit is belangrijk) ook de output van de huidige iteratie. Dus als je voor bcrypt 100 iteraties opgeeft zal de kwaadwillende ook 100 moeten gebruiken omdat hij anders nooit op dezelfde hash uitkomt.

[Cartman!]

LiquidT_NL schreef op dinsdag 20 november 2012 @ 14:37:
[...]
Excuses als ik nogal n00b overkom, ben ook maar een hobbyist qua encryptie en ben nog sterk lerende.

Hashing en encryptie zijn dan ook 2 verschillende dingen, begrijp dat goed

[LiquidT_NL]

Cloud schreef op dinsdag 20 november 2012 @ 14:44:
[...]

Dus als ik je goed begrijp, genereer je 100 keer dezelfde hash? Want dan blijven zowel input als output dus gelijk en is iteratie n niet afhankelijk van het voltooien van iteratie n-1. Dat kan wel, maar vertraagd alleen maar het inloggen. Als een kwaadwillende je DB heeft dan helpt je dat niet.

Ik word hier helemaal verkeerd begrepen

Mijn post was dus een aanvulling op mijn eerdere:

Vertragen kan net zo goed door de hash functie 100x te herhalen, maar het schiet niet echt op.

Wat weer een reactie was op:

Nu is er al verteld dat meerdere malen hashen geen goed idee is. Maar als hier goed naar gekeken wordt, is het dan niet veilig genoeg om te doen? Dat zou betekenen dat ipv enkele honderd duizenden hashes per seconden, je bij een hash functie die 10ms of 1ms duurt (voor een login op een webpage in mijn mening verwaarloosbaar) nog maar 100 of 1000 hashes per seconden kan genereren met een rainbow table. Waardoor dat niet meer practisch is.

Dus ik ben het uiteraard helemaal eens met jullie!!!!

Cloud schreef op dinsdag 20 november 2012 @ 14:44:
[...]
Bcrypt en verwante algoritmes gebruiken naast de oorspronkelijke input (dit is belangrijk) ook de output van de huidige iteratie. Dus als je voor bcrypt 100 iteraties opgeeft zal de kwaadwillende ook 100 moeten gebruiken omdat hij anders nooit op dezelfde hash uitkomt.

Daarom zeg ik ook: als je de boel gaat vertragen, gebruik dan bcrypt: dat is trager EN veiliger. Althans, dat bedoelde ik met deze verneukte post:

Gelukkig zijn bcrypt en soortgelijken volgens mij redelijk "zwaar", dus even makkelijk door die hashes heen knallen gaat dan niet zo makkelijk.

Cartman! schreef op dinsdag 20 november 2012 @ 15:26:
[...]

Hashing en encryptie zijn dan ook 2 verschillende dingen, begrijp dat goed

Ja, ik bedoel dat ik hobbyist ben op het gebied van alles met beveiliging. Ik heb geen servers draaien en doe er ook geen werk in, maar ben altijd ontzettend benieuwd geweest naar hoe beveiliging precies werkt. Dus ik probeer mij ook eens in de discussie te mengen (zonder al te veel tegen schenen aan te trappen).

[Barryvdh]

Ik zit toch nog wat in dubio over de pepper (of global salt / prefix van wachtwoord). Ik snap dat het idee van een user-salt is dat je geen rainbowtables kan maken, maar er zijn wel lijsten van meestgebruikte wachtwoorden toch?
Stel je hebt 1000 veelgebruikte wachtwoorden, en je hebt een grote lijst met users/passwords, dan kan je relatief makkelijk die wachtwoorden controleren omdat je de salt hebt. Password1 staat er dan wel in, maar 20asdf!3e5_Password1 kan je niet zomaar terugvinden. (En als je wat verder gaat, dictionary attacks)
(Natuurlijk niet zo veilig als een goede password policy, en je kan je pepper ook verliezen, maar je zou zeggen dat het in de veiligheid niet minder maakt, tenzij het de hash makkelijker te breken maakt)

[Standeman]

Barryvdh schreef op woensdag 21 november 2012 @ 11:17:
Ik zit toch nog wat in dubio over de pepper (of global salt / prefix van wachtwoord). Ik snap dat het idee van een user-salt is dat je geen rainbowtables kan maken, maar er zijn wel lijsten van meestgebruikte wachtwoorden toch?
Stel je hebt 1000 veelgebruikte wachtwoorden, en je hebt een grote lijst met users/passwords, dan kan je relatief makkelijk die wachtwoorden controleren omdat je de salt hebt. Password1 staat er dan wel in, maar 20asdf!3e5_Password1 kan je niet zomaar terugvinden. (En als je wat verder gaat, dictionary attacks)
(Natuurlijk niet zo veilig als een goede password policy, en je kan je pepper ook verliezen, maar je zou zeggen dat het in de veiligheid niet minder maakt, tenzij het de hash makkelijker te breken maakt)

Punt is natuurlijk dat wanneer ze je database te pakken hebben (dus ingebroken zijn op je db-server), vaak ook je gecompilde code hebben. Door dit te decompilen en beetje speurwerk uit te voeren vinden ze echt wel je pepper. Je maakt het misschien ietsje moeilijker, maar bij lange na niet onmogelijk.

Sterker nog, vaak draaien db en webapp op dezelfde machine. Dan is het helemaal een koud kunstje om je pepper te achterhalen. Het maakt het er idd niet minder veilig op, maar slechts marginaal beter. Een goede hashfunctie en salt hebben een veel grotere impact wat betreft veiligheid.

Maar goed, ik ben wel een type die ze wil laten werken voor hun criminele praktijken, dus gebruik ik een salt, pepper en concateneer ik vaak ook nog een geboorte datum en e-mail adres (of ander user gerelateerd veld wat niet (vaak) veranderd) in de te hashen string.
Enige nadeel voor de gebruiker is dat deze zijn ww moet invoeren als hij de geconcateneerde velden wil veranderen (want dan heb je het originele ww nodig).

[ Voor 5% gewijzigd door Standeman op 21-11-2012 11:43 ]

[Orion84]

Standeman schreef op woensdag 21 november 2012 @ 11:39:
[...]

Enige nadeel voor de gebruiker is dat deze zijn ww moet invoeren als hij de geconcateneerde velden wil veranderen (want dan heb je het originele ww nodig).

Voor het wijzigen van het e-mail adres is dat geen nadeel, maar tamelijk noodzakelijk om te voorkomen dat iemand het adres van een ingelogde account op een publieke PC of zo kan kapen door het e-mail adres aan te passen en daarna een password reset uit te voeren.