Sterkste hash-type tegenwoordig

[ONiel]

Hey

Ik vroeg me af wat tegenwoordig de sterkste hash-type is voor het beschermen van paswoorden. Moet je wel even weten dat ik niet op zoek ben naar een one-way hash-type zoals MD5, maar eerder naar een hash-type dat werkt met een paswoord (dat je versleuteling opheft met een paswoord).

En, is er dan ook een manier of bibliotheek om deze hash-type in Python te gebruiken?

Bedankt!

[Matthijz98]

Voor bestands encryptie kan je het best AES/Rijndael gebruiken voor wachtwoord hashing SHA-256
Er is vast wel een manier om deze in phython te gebruiken.
Een hashing algoritme werkt meestal met een key dit is vaak een gehashed wachtwoord op die manier is je key lekker lang 512 of groter.

[photofreak]

Je encryptie is zo sterk als hoe moeilijk het is om de encryptiesleutel te bemachtigen. Dus als je back-end code en je SQL db gestolen worden heb je als nog niks aan je AES crypto. Zonder one-way hashing is het vragen om problemen.

[CyBeR]

Matthijz98 schreef op maandag 02 november 2015 @ 19:22:
Voor bestands encryptie kan je het best AES/Rijndael gebruiken

Prima.

voor wachtwoord hashing SHA-256

Nee. SHA256 is veel te snel uit te rekenen. Je wilt voor wachtwoorden iets wat moeilijk uit te rekenen is, wat neer komt op heel veel berekeningen doen. PBKDF2 of bcrypt met een groot aantal rounds bijvoorbeeld.

[johnkeates]

Je zoekt dus helemaal geen hashing maar encryptie. Handig om even te onthouden.

Qua implementatie is een goede PBKDF2 of bcrypt prima. Over het algemeen moet je bij een implementatie rekening houden met veel meer dan slechts een algoritme, waardoor het eigenlijk beter is om een bestaande goed onderhouden bibliotheek te gebruiken.

[Brilsmurfffje]

Een hash is een omzetting van een string tekst naar een getal
Encryptie is het beveiligen van een string tekst.

Als ik jou was zou ik eens hier beginnen:
https://pypi.python.org/pypi/simple-crypt

[begintmeta]

Als het je niet om een hash gaat maar om encryptie is een one time pad al tijden het beste, maar dan moet je dat wel goed kunnen implementeren.

[Boudewijn]

Ja maar dat is zo impraktisch dat je het zelden ziet. Ik zou sowieso inderdaad een bestaande geteste implementatie gebruiken van een goed algoritme. Je algoritmekeuze laat je afhangen van je eisen en wensen.

De implementatie zelf schrijven is ontzettend leuk maar ik zou een eigen implementatie nooit zelf vertrouwen. Je moet heel veel goed doen, en 1x iets fout doen is al einde oefening qua security. En zelf zien of je iets fout hebt gedaan is niet helemaal triviaal bij cryptospul.

[begintmeta]

Een otp zou ook niet aan de wensen van ts voldoen, tenslotte kan je dan geen wachtwoord vrij kiezen.

Waarom eigenlijk de grote nervositeit rond eigen implementaties van bekende, 'goedgekeurde' systemen?

[Nvidiot]

begintmeta schreef op woensdag 04 november 2015 @ 11:55:
Waarom eigenlijk de grote nervositeit rond eigen implementaties van bekende, 'goedgekeurde' systemen?

Omdat je bijvoorbeeld aan timing kunt zien wat er gebeurt in het algoritme en op basis daarvan genoeg informatie hebt om de key te achterhalen. Een goede implementatie zal extra berekeningen uitvoeren om het altijd even lang te laten duren. En zo zijn er nog veel meer van dit soort voorbeelden te bedenken waarom het niet verstandig is om zelf een bekend algoritme te implementeren.

[begintmeta]

side-channel attacks zijn natuurlijk altijd lastig inderdaad, zeker ook omdat effecten van (combinaties van) bepaalde hardware (of compilers/software) lastig te kennen is, maar wat betreft Reijndael s hier natuurlijk al vanaf voordat het AES was over gepubliceerd. In hoeverre bekende implementaties tegenmaatregelen hebben tegen welke side-channel attacks is vaak ook niet makkelijk helder te krijgen (meen ik me te herinneren), bij een eigen implementatie is dat makkelijk

[ Voor 7% gewijzigd door begintmeta op 04-11-2015 12:25 ]

[Compizfox]

ONiel schreef op maandag 02 november 2015 @ 19:01:
Moet je wel even weten dat ik niet op zoek ben naar een one-way hash-type zoals MD5, maar eerder naar een hash-type dat werkt met een paswoord (dat je versleuteling opheft met een paswoord).

Alle hashfuncties zijn per definitie one-way.

Welke hash het beste is, hangt een beetje af voor je doel. Voor HMACs is tegenwoordig SHA-256 vrij standaard. Voor het hashen van passwords wil je, zoals CyBeR al uitlegt, iets tragers hebben zoals bcrypt.

Als je de "versleuteling wil opheffen met een paswoord" dan ben je niet opzoek naar een hashfunctie, maar naar een symmetrisch encryptiealgoritme. Dat is iets totaal anders, maar in dat geval is de keuze ook vrij simpel: namelijk AES.

[ Voor 17% gewijzigd door Compizfox op 04-11-2015 12:26 ]

[ELD]

begintmeta schreef op woensdag 04 november 2015 @ 11:55:
Waarom eigenlijk de grote nervositeit rond eigen implementaties van bekende, 'goedgekeurde' systemen?

Omdat de meeste fouten ontstaan in de implementatie van "proven" algoritmes en methodieken. Om als "amateur" dit zelf te implementeren loop je mogelijk een groter risico op het maken van fouten.

[Firefly III]

-

[ Voor 99% gewijzigd door Firefly III op 23-10-2016 15:11 . Reden: Leeg vanwege privacy. ]

[begintmeta]

Er zijn hash-algoritmes met verschillende doelen, soms is het handig als ze snel te berekenen zijn (voor verificatie van integriteit bijvoorbeeld) soms is het handiger als ze minder snel te berekenen zijn (voor het als hash opslaan van wachtwoorden bijvoorbeeld) SHA heeft eerder het eerste als doel, en is dus vrij snel uit te rekenen.

[ Voor 4% gewijzigd door begintmeta op 04-11-2015 15:50 ]

[CyBeR]

JCE schreef op woensdag 04 november 2015 @ 15:41:
[...]

Hoe kom je hier precies bij? Doel je op het gebruik van rainbow-tables? Of heb je een methode om SHA2 collisions snel en efficiënt te berekenen?

Nee, dat gaat om het brute-forcen van je wachtwoord, zowel in-service (door de service te bombarderen met probeersels) als achteraf mocht je de hash te pakken krijgen. Een SHA-whatever is heel snel uit te rekenen waardoor je er honderdduizenden tot miljoenen (met GPU) per seconde kunt proberen. Dat wil je terug dringen en dat doe je bijvoorbeeld door de hash gewoon 5000 keer uit te voeren. PBKDF2 en bcrypt hebben dat soort overwegingen al ingebouwd zitten.

[ELD]

CyBeR schreef op woensdag 04 november 2015 @ 15:48:
[...]

Nee, dat gaat om het brute-forcen van je wachtwoord, zowel in-service (door de service te bombarderen met probeersels) als achteraf mocht je de hash te pakken krijgen. Een SHA-whatever is heel snel uit te rekenen waardoor je er honderdduizenden tot miljoenen (met GPU) per seconde kunt proberen. Dat wil je terug dringen en dat doe je bijvoorbeeld door de hash gewoon 5000 keer uit te voeren. PBKDF2 en bcrypt hebben dat soort overwegingen al ingebouwd zitten.

Een "SHA-whatever" is dan ook vaak de gekozen hash binnen een PBKDF2 implementatie, dus volgens mij praten jullie langs elkaar heen.

[CyBeR]

ELD schreef op woensdag 04 november 2015 @ 16:15:
[...]


Een "SHA-whatever" is dan ook vaak de gekozen hash binnen een PBKDF2 implementatie, dus volgens mij praten jullie langs elkaar heen.

PBKFD2 gebruikt inderdaad SHA-1 als HMAC maar laat je dat een paar duizend keer doen om het proces te vertragen.

[HyperioN]

begintmeta schreef op woensdag 04 november 2015 @ 15:46:
Er zijn hash-algoritmes met verschillende doelen, soms is het handig als ze snel te berekenen zijn (voor verificatie van integriteit bijvoorbeeld) soms is het handiger als ze minder snel te berekenen zijn (voor het als hash opslaan van wachtwoorden bijvoorbeeld) SHA heeft eerder het eerste als doel, en is dus vrij snel uit te rekenen.

Dat is niet waar.
SHA-1 is wel degelijk ontworpen als veilig hashing-algoritme, vandaar ook de naam: Secure Hash Algorithm.
Dat geldt overigens voor alle hashing algoritmes. Het zou ook een beetje gek zijn om een hashing-algoritme te introduceren waarvan je op voorhand al weet dat het gemakkelijk kraakbaar is.
De twee categorieën die jij benoemt bestaan dus niet. Althans, niet in de vorm zoals jij ze voorstelt.
Je zou verschillende hashing algoritmes wel kunnen opdelen in de twee categoriën: gekraakt en niet gekraakt.

Pas in 2005 (tien jaar na de introductie in 1995) zijn door onderzoekers methodes gevonden waardoor SHA-1 niet meer voldoet aan (met name) "Colission resistance" en "Preimage resistance":

Dat eerste betekent dat het moeilijk (lees: ondoenlijk met huidige technieken/hardware binnen afzienbare tijd) moet zijn om dezelfde hash te genereren uit verschillende messages.
Het tweede betekent dat het moeilijk (lees: ondoenlijk met huidige technieken/hardware binnen afzienbare tijd) moet zijn om de message te berekenen uit de hash.
Voor de puristen: ja dit is simplistisch weergegeven

Ook MD5, wat nu iedereen voor een fluitje van een cent kan decrypten, werd ook pas in 2004 (twaalf jaar na de introductie in 1992) gekraakt met een colission attack (wel werden in 1996 al andere ontbrekingen ontdekt).

Vanwege het pseudo-random karakter van cryptografische hashing algoritmes kan niet worden bewezen dat deze collision-bestendig zijn. Je kunt er dus van uitgaan dat ook de nieuwere algoritmes (wat jij nu "categorie 2" noemt) uiteindelijk gekraakt worden. Mede ook omdat hardware steeds sneller wordt.
Er zijn wel bewijsbaar veilige algoritmes mogelijk, maar die hebben weer andere praktische limitaties (zie hiervoor ook het wikipedia-artikel hieronder).

Bronnen en meer info, o.a.:
Wikipedia: Security of cryptographic hash functions
Wikipedia: Cryptographic hash function
Wikipedia: MD5
Wikipedia: SHA-1

[Cloud]

HyperioN schreef op woensdag 04 november 2015 @ 16:18:
[...]

Dat is niet waar.
SHA-1 is wel degelijk ontworpen als veilig hashing-algoritme, vandaar ook de naam: Secure Hash Algorithm.
Dat geldt overigens voor alle hashing algoritmes. Het zou ook een beetje gek zijn om een hashing-algoritme te introduceren waarvan je op voorhand al weet dat het gemakkelijk kraakbaar is.
De twee categorieën die jij benoemt bestaan dus niet. Althans, niet in de vorm zoals jij ze voorstelt.

Volgens mij bedoelt begintmeta dat ook niet zo.

De hashing-algoritmes zijn inderdaad niet met die verschillende doelen gemaakt maar de indeling kun je wel degelijk gebruiken hoor. De ene hash (SHA1) is op dit moment beter geschikt voor integriteitscontrole dan voor wachtwoord hashing. Dat SHA1 oorspronkelijk ook als 'secure' hash bedacht is doet daar op dit moment niets aan af. Niemand bedenkt opzettelijk een hashing algoritme dat eenvoudig te 'kraken' is inderdaad.

Overigens zijn PBKFD2 en dergelijke wel degelijk bedacht met passwordhashing als doel (het zit zelfs in de naam)

[begintmeta]

Wat is er niet waar aan, het is hooguit wat ongenuanceerd. Als naar bijvoorbeeld Keccak (uiteindelijk sha3) kijkt was een van de kritiekpunten dat men teveel de nadruk had gelegd op mogelijkheden voor snelle implementaties in hardware, en minder in software. Uiteindelijk moet men een compromis vinden dat past bij het doel, soms is hogere performance (in de zin van de tijd die een hash-berekening in beslag neemt (evt in een bepaald systeem)) nu eenmaal van belang. verder wil je natuurlijk inderdaad eigenlijk dat nooit collisions optreden, maar gesteld dat die kans bij twee algoritmes gelijk (of tenminste voldoende) wordt ingeschat, kan je dus afwegen wat belangrijker is (of of het zinvol is heel veel rondes toe te voegen). Als het er (gesteld dat het qua collisions wel goed zit) om gaat van message naar message digest te rekenen (om de integriteit van de message te controleren) is en zo groot mogelijke snelheid te verkiezen, als het erom gaat een message (een wachtwoord dus bijvoorbeeld) achter een message digest te verbergen, is een zo laag mogelijke snelheid te verkiezen.

'Men' is ook bezig met het selecteren van goede wachtwoordhashingalgoritmes:

https://password-hashing.net/report1.html

[ Voor 36% gewijzigd door begintmeta op 04-11-2015 16:57 ]

[HyperioN]

Okay, ja jullie hebben gelijk.
Het ging mij er inderdaad om duidelijk te maken dat SHA-1 niet gemaakt is als snel-maar-niet-zo-heel-veilig algoritme ;-). Ben wellicht wat doorgeschoten in mijn relaas.

Het klopt ook dat het altijd een afweging blijft tussen performance en cryptografische sterkte.

[Firefly III]

-

[ Voor 99% gewijzigd door Firefly III op 23-10-2016 15:11 . Reden: Leeg vanwege privacy. ]

[CyBeR]

JCE schreef op woensdag 04 november 2015 @ 19:08:
[...]

Dus wat je bedoelt, is het daadwerkelijk berekenen van hashes, en daarmee een wachtwoord proberen te vinden door alle combinaties uit te rekenen.

Nee. Dat is een rainbow table. Ik heb 't over brute forcen van wachtwoorden:

wachtwoorda
wachtwoordb
wachtwoordc
etc.

Dat is geen indicatie van de veiligheid van SHA-x en alleen relevant in de context van het zoeken naar wachtwoorden.

Wil je me nou boos maken? Dat is waar we 't hier over hebben.

Overigens is het al te voorkomen met het gebruiken van een salt.

Een salt doet wonderen tegen rainbow tables maar 100% helemaal geen ene donder tegen brute forces.

[Firefly III]

-

[ Voor 99% gewijzigd door Firefly III op 23-10-2016 15:10 . Reden: Leeg vanwege privacy. ]

[Anoniem: 562969]

Maroc denk ik.

[Boudewijn]

offtopic:
Het gaat om wiskundige/crypto hash .

[Eric_1993]

Als jullie zouden moeten kiezen tussen deze 3 hash algoritmes, welke zal dan de sterkste zijn volgens jullie?

- SHA-512
- Whirlpool
- SHA-256

[Henk007]

CyBeR schreef op woensdag 04 november 2015 @ 15:48:
[...]

Een SHA-whatever is heel snel uit te rekenen waardoor je er honderdduizenden tot miljoenen (met GPU) per seconde kunt proberen.

Dan ben je alsnog even zoet met het vinden van een collision, zelfs als je recente cryptoanalyse zou kunenn exploiten Wikipedia: SHA-2

[Boudewijn]

Eric_1993 schreef op zaterdag 07 november 2015 @ 21:25:
Als jullie zouden moeten kiezen tussen deze 3 hash algoritmes, welke zal dan de sterkste zijn volgens jullie?

- SHA-512
- Whirlpool
- SHA-256

joh doe even wat eigen initiatief aub

[Eric_1993]

Boudewijn schreef op zondag 08 november 2015 @ 11:37:
[...]
joh doe even wat eigen initiatief aub

Ik vraag alleen maar jullie mening...

[Boudewijn]

Eric_1993 schreef op zondag 08 november 2015 @ 15:29:
[...]


Ik vraag alleen maar jullie mening...

Nee je vraagt naar feiten, en feiten die vrij makkelijk te vinden zijn. Het klinkt mij als huiswerk in de oren.

[Eric_1993]

Boudewijn schreef op zondag 08 november 2015 @ 15:32:
[...]

Nee je vraagt naar feiten, en feiten die vrij makkelijk te vinden zijn. Het klinkt mij als huiswerk in de oren.

Niet iedereen is zo ervaren als jou. Bovendien is dit gewoon een forum om vragen te stellen. Dus hou aub je mening voor je. (Wat overigens geen antwoord is op mijn vraag)

[ Voor 13% gewijzigd door Eric_1993 op 08-11-2015 17:31 ]

[Baserk]

Opeens komt het Southpark karakter 'mr. Reality' in me op; "You're sad? That people are mean?"
Iemand heeft behoefte aan wat 'Safe Space'.

[begintmeta]

Eric_1993 schreef op zondag 08 november 2015 @ 17:25:
...
Niet iedereen is zo ervaren als jou. Bovendien is dit gewoon een forum om vragen te stellen. Dus hou aub je mening voor je. (Wat overigens geen antwoord is op mijn vraag)

Waarom geef je die drie opties als er wel wat meer mogelijkheden zijn? Je kan je ook afvragen of je hier op het forum een beter antwoord kan verwachten dan wat in algemeen beschikbare publicaties over de hashes te vinden is. Verder geef je geen specificatie van wat 'sterker' is.

[Boudewijn]

Eric_1993 schreef op zondag 08 november 2015 @ 17:25:
[...]


Niet iedereen is zo ervaren als jou. Bovendien is dit gewoon een forum om vragen te stellen. Dus hou aub je mening voor je. (Wat overigens geen antwoord is op mijn vraag)

Inderdaad. Maar waarom heb je deze 3 gevonden? Wat zijn hun sterke en zwakke punten en hun onderlinge verschillen?
En wat hebben die verschillen voor invloed op de 'sterkte'?

Als je die vragen zelf probeert te beantwoorden leer je wat en zijn mensen hier nog vriendelijker ook . Zelfs ik .

[begintmeta]

Aan BLAKE (een van de SHA-3 finalisten) is ook nog wat gesleuteld, en men heeft BLAKE2 geopenbaard, zou je ook kunnen overwegen bijvoorbeeld.

[ Voor 19% gewijzigd door begintmeta op 11-11-2015 18:58 ]