Welk paswoord systeem kiezen / veranderen
Pagina: « vorige 1 2 3 4 volgende »
Toevoeging op 02/03/2019 00:29:40:
en toen bleef het stil ... jammer hoor
Zorg er dus voor dat het totale plaatje een hoge entropy heeft. Wat helpt is geen zwak hashing mechanisme gebruiken. Maar ook wachtwoord kiezen wat door een dictionary attack of een rainbowtable makkelijk te bruteforcen is
Immers zit het probleem van kraken van wachtwoorden niet meer in de weg, je bent al binnen.
Wachtwoorden hashen is enkel een onderdeel van iets wat kwaadwillende tegenhoud niets meer of minder.
Er moet nog altijd in het systeem een match zijn tussen iets uniek leesbaars en dat gehashte (geen idee of ik het goed schrijf) wachtwoord. Als daar een match is dan mag je pas verder. Je doet totaal niets meer met een wachtwoord. Als ik dan de keuze heb om strategisch te kiezen hoe ik mijn systeem ga inrichten dan word het toch meer de rompslomp er omheen dan enkel en alleen naar het wachtwoord en hashing kijken. :)
De discussie was kort samengevat verzand in de vraag of je beter MD5 of een nieuwere hashing-methode kunt gebruiken. Thomas geeft de voorkeur aan MD5. Ikzelf gebruik liever password_hash met bcrypt.
Ik kan zien dat je helemaal niets hebt meegekregen van wat ik probeerde over te brengen. Ook fijn dat je andere mensen woorden in de mond legt. En leuke poging om weer een reactie los te krijgen, al is het op een onderhandse manier.
Gewijzigd op 02/03/2019 19:33:36 door Thomas van den Heuvel
Laten we dan op z'n minst zeggen dat jij een pleidooi
Vat ik het zo dan wat beter/genuanceerder samen? Kun je je hier wel in vinden?
Wellicht moet ik de vraag nog wat anders stellen. Als je zelf programmeert, gebruik je dan MD5 als hashing-methode, of iets anders zoals bijvoorbeeld password_hash?
Gewijzigd op 02/03/2019 21:20:23 door Ozzie PHP
1) De aanvaller heeft geen directe toegang tot de database:
- Een wachtwoord achterhalen is nu alleen mogelijk door het te proberen. Dit kan systematisch ("a", "aa", enz - veel mogelijkheden), maar zal meestal aan de hand van een lijst met "bekende wachtwoorden" gebeuren ("woordenboek" - dit zijn er meestal maar "een paar miljoen").
- Het is aan de programmeur om hiertegen bescherming in te bouwen = een rem op een aantal pogingen per tijdseenheid per account, per IP-adres, enz. Dus bijvoorbeeld na 3x foutief even een paar minuten geen toegang. Voor een gewone gebruiker niet geheel overkomelijk, maar als je er een paar miljoen wilt proberen duurt het opeens veels te lang.
- De gebruiker kan zich hier tegen beschermen door gewoon een "niet standaard wachtwoord" te nemen (gewoon zo'n random gegenereerd geval, bijvoorbeeld via een wachtwoordmanager).
-> In dit geval maakt de gebruikte hashing methode geen enkel verschil tussen het wel of niet succesvol kunnen achterhalen van een wachtwoord. Je zou zelfs de wachtwoorden in plain-text op kunnen slaan. Het enige verschil wordt gemaakt door de programmeur en de gebruiker.
2) De aanvaller heeft wel direct toegang (of een kopie):
- Sowieso heb je nu een probleem, omdat er meestal wel meer data in die database stond, en die ligt nu ook allemaal op straat. Het is echter wel fijn als de wachtwoorden onbekend blijven, want dat voorkomt dat de aanvallers met de complete accountgegevens deze op andere sites kunnen gaan proberen ("Credential stuffing" - voor gebruikers die geen uniek wachtwoord hebben gebruikt), waar misschien nog veel meer is te halen.
- Een "bekend" wachtwoord, dat met MD5 is gehashed (zonder zout) is hierbij vrij eenvoudig te "decrypten" door het in een rainbow table op te zoeken.
- Een "bekend" wachtwoord dat met MD5 is gehashed, maar met een flinke portie zout, of elke andere "sterke" hashing methoden (zoals password_hash() gebruikt - gratis en voor niets met ingebouwd zout) zal alleen achterhaald kunnen worden door per hash alle bekende wachtwoorden te proberen (password_verify()). In plaats van een enkele opzoekactie moet je dus die "paar miljoen" wachtwoorden uit het woordenboek proberen. Als het zout per wachtwoord verschilt zul je ook nog per wachtwoord al die miljoenen wachtwoorden moeten proberen (als het zout vast is zou je eerst nog je eigen rainbow table kunnen maken). Dat is veel meer werk (rekenintensief), en kost dus veel meer tijd/inspanning/resources.
- Een "random" wachtwoord is in alle gevallen (MD5 met/zonder hash, of welke hashing dan ook) "niet te achterhalen".
Dus als de aanvaller toegang heeft tot je volledige database:
- Heb je sowieso een probleem.
- Maar je kunt het probleem voor je gebruikers (die wachtwoorden hergebruiken) beperken door de wachtwoorden goed te hashen. Enkel MD5 is hierbij geen serieuze oplossing ivm de vele beschikbare rainbow tables (maar dat geldt ook voor diverse andere hashing algoritmes, ook daar zijn rainbow tables voor). Je zult in alle gevallen zout toe moeten voegen, en evt. andere zelf gemaakte "hocus pocus" - als hetzelfde wachtwoord maar niet steeds dezelfde hash oplevert (voor verschillende gebruikers). De ingebouwde password_hash()+password_verfiy() functies doen dit allemaal voor je, zonder dat je er echt hard bij na hoeft te denken.
- Een gebruiker kan z'n probleem ten alle tijde beperken door "random", en unieke wachtwoorden per account te kiezen. Dat blijkt in de praktijk voor veel mensen lastig te zijn, maar wij als programmeurs kunnen ze daarbij helpen door minimale eisen aan een wachtwoord te stellen, en te controleren of ze geen gebruik maken van een "bekend wachtwoord" (bijvoorbeeld via haveibeenpwned.com).
-> Daarnaast moeten we natuurlijk in eerste instantie voorkomen dat de hele database op straat komt te liggen (algemene beveiliging van de database zelf, SQL-injectie, enz - nog meer dan genoeg mogelijkheden om een steekje te laten vallen).
Gewijzigd op 03/03/2019 08:44:39 door Rob Doemaarwat
Of ik nu het wachtwoord md5('welkom') heb of password_hash('welkom') maakt in feite echt niets uit.
Het is en blijft een zwak wachtwoord.
Ja, dan heb je gelijk dat als je sec in de database kijkt je makkelijker aan de md5() kunt herleiden dat "welkom" een bepaalde string oplevert.
Maar als ik weet dat je welkom gebruikt als wachtwoord is het net zo makkelijk te herleiden in password_hash(). Dat je daar iets meer moeite voor moet doen omdat password_hash() iets random oplevert heeft niets te maken met beter of slechter. Feit blijft dat het een zwakke schakel is.
En dat is precies wat Thomas hier aangeeft. Meer is het niet.
En dat maakt deze discussie meteen zinloos.
Je kunt niet stellen ik hash mijn wachtwoord op een bepaalde manier en dan is het veilig.
Dat doe je met het hele feest er omheen, en niet dat ene onderdeel wat je wachtwoord is.
Waarom zou je anders een nieuwere optie uitvinden om juist dat te voorkomen?
Vroeger hadden we zoiets als:
Code (php)
1
SELECT * FROM users WHERE username = 'bart' AND password = md5('welkom')
Dat leverde gewoon een match op klaar we konden verder.
Tegenwoordig moet je nog een hele berg code met if-jes eromheen bouwen om te kijken met password_verify() eventueel een update query om password_needs_rehash() te doen. En dat allemaal om het veiliger te maken.
Dat is toch puur sec gedaan om programmeurs verder na te denken over hoe een login systeem in elkaar zou moeten zitten.
Maar feit blijft dat als je gebruiker een zwak wachtwoord heeft dan blijft het een zwakke schakel.
Dan maakt de manier van hashing totaal niets uit.
EDIT
Rob heeft zo ongeveer de zelfde strekking zoals ik het zie :)
Maar die was me voor.
Gewijzigd op 03/03/2019 09:17:58 door Bart V B
Dus stel, iemand heeft als wachtwoord 'welkom' ... heeft het dan meerwaarde als ik daar nog een vaste salt aan toevoeg zodat het wachtwoord bijvoorbeeld 'welkom_!@@#$@^_' wordt? Is dat nog een maatregel die zinvol is?
Het antwoord is ja (het toevoegen van een salt heeft wel degelijk zin), maar een vaste salt wordt afgeraden.
In 1e instantie zou je denken van niet, omdat er al een random salt wordt toegevoegd. Maar als het wachtwoord 'welkom' is, dan is dat nog steeds (relatief) makkelijk te herleiden.
Voegt het in dit geval dan iets toe om naast die random salt nog een stukje "vast" toe te voegen, waardoor 'welkom' dus bijvoorbeeld 'welkom_!@@#$@^_' wordt? Want dat kun je dan toch niet meer achterhalen lijkt me? (even ervan uitgaande dat de "hacker" enkel je database te pakken heeft gekregen en niet je code (zodat hij dus niet kan zien dat de salt '_!@@#$@^_' is toegevoegd). Klopt mijn verhaal? Of is dit schijnveiligheid?
De vraag is wel of het de goede plek is om potentieel zwakke wachtwoorden daar, en op die manier, te pimpen. Ik zou zeggen dat de oorsprong van dat probleem elders ligt, en ook elders opgelost zou moeten worden, maar het is een interessant idee.
Ja, lijkt me inderdaad wel interessant. Je kunt gebruikers wel verplichten om bijv. hoofd- en kleine letters inclusief een getal en vreemd teken te gebruiken en een minimale lengte van x tekens, maar nog steeds kun je dan een wachtwoord krijgen als "aaaaaaa1!" wat prima aan de eisen voldoet, maar waarschijnlijk nog steeds vrij makkelijk te herleiden is. Als je het wachtwoord in de code wijzigt naar "aaaaaaa1!_!@@#$@^_" wordt dat een stuk lastiger (ervan uitgaande dat ze de code niet kunnen inzien).
Aan de andere kant, dit is in zekere zin nog steeds security through obscurity. Het is een bekend recept waar je een geheim ingrediënt (meer zout :p) aan toevoegt. Het zal ongetwijfeld helpen waarbij ook simpele wachtwoorden moeilijker te kraken zijn, maar het maakt de oplossing minder transparant en ook complexer (extra handeling tijdens password_verify()). Het is altijd beter om een compleet transparante oplossing te hebben zodat zelfs als die bekend is dat de constructie nog steeds veilig is.
Naar dit principe wordt ook verwezen in het artikel dat @Remco in zijn eerdere reactie linkte.
Maar het is toch nog steeds wel 'veiliger'? En met veiliger bedoel ik dan dat ALS je database zou worden gehackt, en enkel je database en niet de code, het vrijwel onmogelijk wordt om de boel te herleiden. Men zou dan immers dat extra beetje zout moeten kennen, en zolang men dat niet kent is het volgens mij een onmogelijke opgave. Van een 'welkom' kunnen we immers verwachten dat het in een rainbow table / dictionary voorkomt, maar van een 'welkom_geheim_zout@#$#@!##@!@#!@' lijkt me dat erg sterk.
Gewijzigd op 04/03/2019 17:15:47 door Ozzie PHP
Extra zout toevoegen is een idee. Je zou ook emailadres op een bepaalde plek neer kunnen zetten in de hash. Immers die is uniek per account als het goed is.
Andere mogelijkheid is, tijdens het registreren een controle uitvoeren of het wachtwoord een bekend wachtwoord is. Er zijn hele lijsten met bekende wachtwoorden te vinden op het net die je eventueel kan gebruiken voor deze controle.
Je kan ook afdwingen dat het uit een bepaalde tekenreeks moet bestaan zodat het nooit een bestaand woord kan worden. W3lj0m@1 kan wel en welkom01 niet. Het moet minimaal uit 8 tekens zijn en minimaal 1 hoofdletter bevatten, en minimaal 1 speciaal teken en 1 cijfer.
Dat extra zouten is goed, maar je gebruikers afdwingen om een fatsoenlijk wachtwoord te maken is in den beginnen nog beter.
In tegenstelling tot dit wachtwoord : Consilio_9145_Pactum
https://lowe.github.io/tryzxcvbn/
Ging me meer om de beeldvorming waar een controle zou moeten worden uitgevoerd om een sterk wachtwoord te maken.
Pagina: « vorige 1 2 3 4 volgende »