DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
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?
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?
een wachtwoord onthoud je of schrijf je op je pinpas naast je pincode
Supra Groningam Nihil
Postjubilea: 10.000 15.000 20.000 25.000
Sit jou kop in die koei se kont en wag tot die bul jou kom holnaai
Wat niemand je vertelt over de bioindustrie, geen bloed maar feiten
Postjubilea: 10.000 15.000 20.000 25.000
Sit jou kop in die koei se kont en wag tot die bul jou kom holnaai
Wat niemand je vertelt over de bioindustrie, geen bloed maar feiten
of je slaat hem op in je telefoon onder de naam P. Code of B. Ankpas
Supra Groningam Nihil
Postjubilea: 10.000 15.000 20.000 25.000
Sit jou kop in die koei se kont en wag tot die bul jou kom holnaai
Wat niemand je vertelt over de bioindustrie, geen bloed maar feiten
Postjubilea: 10.000 15.000 20.000 25.000
Sit jou kop in die koei se kont en wag tot die bul jou kom holnaai
Wat niemand je vertelt over de bioindustrie, geen bloed maar feiten
Je hebt waarschijnlijk meer geluk op stackoverflow of eventueel Tweakers.
Bijvoorbeeld http://stackoverflow.com/(...)re-your-salt-strings
of http://stackoverflow.com/(...)-authentication-data
Bijvoorbeeld http://stackoverflow.com/(...)re-your-salt-strings
of http://stackoverflow.com/(...)-authentication-data
fotografie FTW
Van wachtwoorden sla je eigenlijk alleen de hash op, waarbij je bij voorkeur gebruikmaakt van een algoritme in de SHA-familie. SHA-256 wordt veelgebruikt. Een verouderd algoritme, welke nog steeds wel veel gebruikt wordt, is het MD5 algoritme. De kans op zogenaamde collisions is bij laatstgenoemde echter groter. Dit houdt in dat de kans dat twee verschillende strings een zelfde hash opleveren groter is.
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.
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 [..]
You know, I rather like this God fellow. He’s very theatrical. A little pestilence here, a plague there... Omnipotence...got to get me some of that.
Gewoon in het password field, geconcateneerd met de hash. Hier zijn conventies voor, bijv $5$<salt>$<SHA256 hash>
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...
You know, I rather like this God fellow. He’s very theatrical. A little pestilence here, a plague there... Omnipotence...got to get me some of that.
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:
You know, I rather like this God fellow. He’s very theatrical. A little pestilence here, a plague there... Omnipotence...got to get me some of that.
|
|
