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?
Bijvoorbeeld http://stackoverflow.com/(...)re-your-salt-strings
of http://stackoverflow.com/(...)-authentication-data
Omdat een string (bijvoorbeeld een wachtwoord) altijd dezelfde hash oplevert, zul je in een tabel waar enkel gehashte wachtwoorden (dus zonder salt) opgeslagen worden, meerdere hashes vinden die hetzelfde zijn. Hieruit kun je concluderen dat die gebruikers dezelfde wachtwoorden hebben gekozen.
Om te voorkomen dat hackers aan de gang gaan met je database en met behulp van rainbow tables in korte tijd veel wachtwoorden buit kunnen maken (immers, als er 1 gekraakt is, geldt dit wachtwoord ook voor alle andere gelijke hashes!), kun je per gebruiker een salt toevoegen.
Een salt is een willekeurige string van karakters die aan het (ongehashte) wachtwoord worden geplakt, waarna de hash van deze combinatie wordt opgeslagen. De salt zelf mag gewoon onversleuteld worden opgeslagen bij het user record.
Omdat voor iedere gebruiker een andere salt geldt, zullen alle hashes verschillend zijn, ook als meerdere gebruikers hetzelfde wachtwoord hanteren. Kortom, als een hacker nu 1 wachtwoord kraakt, betekent dit niet automatisch dat van een x aantal anderen ook meteen het wachtwoord gekraakt is.
Lang verhaal kort: salts sla je op bij de rest van inloggegevens.
Dit is irrelevant. Iedereen mag de salts weten, aangezien je daar niets aan hebt, zelfs niet in combinatie met het gehashte wachtwoord (+ salt), omdat hashes een vorm van one way encryption zijn. Oftewel, van A naar B is makkelijk, van B naar A is onmogelijk.quote:Op woensdag 14 november 2012 12:47 schreef Pakspul het volgende:
[..] waar je zelfs nog niets hoeft bang te zijn dat één van je salt's wordt gestolen [..]
Juist met name de combinatie wachtwoord+salt wordt gehasht. En wordt er juist niet zomaar een salt aan een gehasht wachtwoord geplakt. Anders is het vrij eenvoudig de hash zonder salt er weer uit te filteren, waardoor het hele principe van een salt tenietgedaan wordt.quote:Op woensdag 14 november 2012 14:49 schreef Farenji het volgende:
Gewoon in het password field, geconcateneerd met de hash. Hier zijn conventies voor, bijv $5$<salt>$<SHA256 hash>
Of ik moet je verkeerd begrijpen, dat kan natuurlijk ook...
Joh, echt?quote:
[..]
Juist met name de combinatie wachtwoord+salt wordt gehasht.
Gezien je kinderachtige reactie heb ik je inderdaad verkeerd begrepen. Maar goed, niet iedereen is net als jij alwetend natuurlijk! Mijn welgemeende excuses!quote:
