Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 138 reacties

Meer dan 42 miljoen wachtwoorden van gebruikers van meer dan dertig datingsites liggen op straat. De wachtwoorden, die niet waren versleuteld, zijn afkomstig van Cupid Media, dat voor verschillende doelgroepen datingsites heeft opgericht.

De 42 miljoen plaintext-wachtwoorden werden aangetroffen op dezelfde server als die waar gestolen wachtwoorden van Adobe en PR Newswire werden aangetroffen, zo schrijft beveiligingsjournalist Brian Krebs op zijn weblog. Cupid Media heeft meer dan dertig niche-datingsites, bijvoorbeeld voor een bepaalde religie, etniciteit of nationaliteit. Tegenover Krebs heeft Cupid Media toegegeven dat het slachtoffer van een aanval is geworden.

De wachtwoorden waren niet versleuteld, wat wordt beschouwd als een doodzonde op het gebied van beveiliging en bedrijven op grote boetes kan komen te staan. Aanvallers zouden nu bijvoorbeeld kunnen inloggen op andere diensten waar leden van de datingsites dezelfde wachtwoorden gebruiken. Ook is de database, met 42 miljoen e-mailadressen, een goudmijn voor spammers.

Omdat de wachtwoorden onversleuteld zijn, wist Krebs een analyse te maken van de meestgebruikte wachtwoorden. Het populairste wachtwoord blijkt '123456' te zijn, gevolgd door '111111' en '123456789'. Het populairste niet-nummerieke wachtwoord is 'iloveyou', gevolgd door 'lovely' en 'qwerty'. Eerder concludeerde Tweakers al dat veel van zijn leden een slecht wachtwoord hebben.

Moderatie-faq Wijzig weergave

Reacties (138)

Lexa.nl slaat vandaag de dag ook hun wachtwoorden plain-text op. Tenminste, dat moet wel, anders zou het niet mogelijk moeten zijn om je wachtwoord achteraf te kunnen bekijken in je instellingenmenu.
tja, of plain-text of encrypt-decrypt, dat laatste koopt je hoogstens wat tijd als je database gejat is :)
Hier een hele lijst met bedrijven die je wachtwoord als plaintext oplsaan, of een manier hebben om het terug te halen.
http://plaintextoffenders.com/
Offtopic:
Dat lijkt me wel, als je die affiliates bekijkt dat "verbleekt" zwarte piet als het om rascime gaat.

Ontopic:
Erg voor de hand liggende wachtwoorden, griezelig dat nog steeds op veel plekken deze niet gehashed en/of gesalt worden.

Edit: typos

[Reactie gewijzigd door FrankAlexander op 20 november 2013 08:33]

Daarom gebruik ik ze ook voor sites welke ik niet vertrouw. Dan zien ze een gebruikersnaam en qwerty ofzo staan en doe ik er niks mee. Een stukje veiligheid zonder veilig te zijn.
En dat is waarschijnlijk ook de reden waarom die databases stampes vol staan met dit soort "meest gebruikte" wachtwoorden.
Veel mensen/bots zijn dus blijkbaar wel zo slim om iets simpels te doen om even rond te snuffelen naar mooie (naakt) foto's of bots die mensen strikken voor een vliegtuig ticket.

Bij Adobe en Oracle heb ik zo ook wel 20 accounts met @mailinator.com en 123456 omdat ze een account vereiste om iets te downloaden.
Ontopic:
Erg voor de hand liggende wachtwoorden, griezelig dat nog steeds op veel plekken deze niet gehashed en/of gesalt worden.
Edit: beter op z'n plek op Argantonis in 'nieuws: Miljoenen plain text-wachtwoorden van datingsites liggen op straat'

[Reactie gewijzigd door Argantonis op 20 november 2013 08:57]

offtopic: Eigenlijk moeten we de zeikerds terug pakken en de pieten wit maken, zeker ook racistisch? ahahah

Ontopic: toevalig uit het oude tweaker artikel, heb zelf 13 karakters! kmaak er wel 15 van dan! xD toch opvallend groot verschil in accounts, alhoewel ik geen woorden heb als wachtwoord noch een patroon in mijn wachtwoord. Denk? dat ik wel goed zit.

Heb ik het verleden ook op soort gelijke manier mezelf proberen te hacken (zoals beschreven in ouder artikel), het zou je verbazen hoe easy het is!.
Misschien moet je de betekenis van "racisme" een keer opzoeken...
Wat is er racisitisch aan om een partner te zoeken die een specifieke achtergrond heeft?
Dat iemand het liefst een bepaald "type" heeft, wil nog niet zeggen dat daarmee alle andere types als minderwaardige mensen gezien worden. Of is het tegenwoordig ook al racistisch om een voorkeur te hebben voor Chinees eten, maar Ghanees niet te lusten?

Kom op zeg, we blijven wel allemaal individuele mensen met individuele voorkeuren. Gelukkig maar.
Wat is er racisitisch aan om een partner te zoeken die een specifieke achtergrond heeft?
Dat iemand het liefst een bepaald "type" heeft, wil nog niet zeggen dat daarmee alle andere types als minderwaardige mensen gezien worden. Of is het tegenwoordig ook al racistisch om een voorkeur te hebben voor Chinees eten, maar Ghanees niet te lusten?

Kom op zeg, we blijven wel allemaal individuele mensen met individuele voorkeuren. Gelukkig maar.
Ik heb het niet specifiek over de bepaalde landen maar over de optie meet "Black" singles. But nevermind, offtopic

[Reactie gewijzigd door FrankAlexander op 20 november 2013 08:53]

Interracial singles viel me op.. Hoe gaat dat in z'n werk dan? :P
Simpel - dat zijn de singles van een bepaalde ethniciteit (bijvoorbeeld Kaukasisch) die aangegeven hebben dat ze een niet-Kaukasische partner zoeken.
Ik heb het niet specifiek over de bepaalde landen maar over de optie meet "Black" singles.
Ik zie het probleem niet, als je als zwarte liever een date hebt die ook zwart is, waarom zou dat dan rascitisch zijn? Voor blanken idem dito. Is het dan ook rascistisch als ik als blanke graag een zware date wil (of andersom)? Of sexistisch als ik alleen naar vrouwelijke dates zoek? Deze sites voorzien gewoon in een behoefte, als jij een leuke zwarte dame of kerel zoekt, dan heb je niks aan alle profielen van blanken of aziaten of wat dan ook. Een voorkeur voor dates met vergelijkbare achtergrond lijkt me voor de meeste mensen doodnormaal, en ja, daar is ethniciteit (en daaraan gekoppeld bijna automatisch huidskleur) een heel belangerijke factor in.
Het verbaast me dat in deze tijden toch nog zo vaak blijkt gewerkt te worden met plain-text paswoorden. Elke ontwikkelaar, technisch designer, architect weet ondertussen toch al lang dat dit werkelijk not done is? Wie blijft dit soort fouten maken?

Het is toch niet zo moelijk om encryptie toe te voegen en wachtwoorden op die manier op te slaan? Natuurlijk moet je dan een wachtwoord reset systeem voorzien en geen simpele wachtwoord retrieval, maar als het daar werkelijk op aankomt...

Als je als gebruiker dan ook nog eens hetzelfde wachtwoord gaat gebruiken (ook niet veilig, maar eindgebruikers weten soms niet beter) dan kan je toegang tot vele andere sites ineens ook gecompromitteerd zijn. Of wanneer je een systeem hebt dat uitgedokterd kan worden aan de hand van dit ene wachtwoord, idem.

Ik ken al jaren mijn eigen wachtwoorden niet meer, dankzij keepass. Als ik zaken als dit lees ben ik daar heel tevreden mee.
Het verbaast me dat in deze tijden toch nog zo vaak blijkt gewerkt te worden met plain-text paswoorden. Elke ontwikkelaar, technisch designer, architect weet ondertussen toch al lang dat dit werkelijk not done is? Wie blijft dit soort fouten maken?

Het is toch niet zo moelijk om encryptie toe te voegen en wachtwoorden op die manier op te slaan? Natuurlijk moet je dan een wachtwoord reset systeem voorzien en geen simpele wachtwoord retrieval, maar als het daar werkelijk op aankomt...

Als je als gebruiker dan ook nog eens hetzelfde wachtwoord gaat gebruiken (ook niet veilig, maar eindgebruikers weten soms niet beter) dan kan je toegang tot vele andere sites ineens ook gecompromitteerd zijn. Of wanneer je een systeem hebt dat uitgedokterd kan worden aan de hand van dit ene wachtwoord, idem.

Ik ken al jaren mijn eigen wachtwoorden niet meer, dankzij keepass. Als ik zaken als dit lees ben ik daar heel tevreden mee.
Het grappige is dat het tegenwoordig juist niet zoveel meer uitmaakt of je nou plain-text opslaat of niet. Tenminste, niet voor het merendeel van de gebruikers. Die hebben toch zulke slechte korte wachtwoorden dat het irrelevant is of je ze encrypt of niet, want ze zijn binnen no time te kraken. Zie voor achtergrond http://arstechnica.com/se...at-out-of-your-passwords/

Eigenlijk is encryptie alleen nog erg van belang voor de mensen die hun passwords laten genereren op werkelijk random manier en daarbij ook nog eens een password van flinke lengte kiezen. Maar dat zijn dan ook weer de mensen die het mínst getroffen zijn als er een keer ergens een database op straat ligt, want dan hergebruiken ze vaak het password toch al niet omdat ze ergens een password store hebben.
Als je echt verstand hebt van beveiligingsalgoritmes zou je zulke uitspraken niet maken. Je algoritme moet er juist voor zorgen dat zelfs het kortste simpelste wachtwoord nog zo gesalt en gestretchd wordt dat (zolang de aanvaller geen toegang heeft tot de code die de hash genereerde) de aanvaller na het decrypten van het wachtwoord nog op zijn hoofd zit te krabben wat er allemaal mee gebeurd is.

Denk bijvoorbeeld aan het genereren van een extra reeks getallen die plaintext worden opgeslagen bij het (gehashte) wachtwoord. Aan de hand van deze getallen kan je dan karakters manipuleren, extra karakters toevoegen of de plaatsen van de karakters veranderen. Elke user heeft zijn eigen getallenreeks, dus rainbow tables zijn nutteloos.

Het klinkt heel simpel, maar met een bruteforce komt een hacker dan niet ver genoeg meer. Hij zal toch zelf even moeten puzzelen om erachter te komen wat je met zijn wachtwoord gedaan hebt voor je het ging hashen. Je algoritme is namelijk onbekend. Natuurlijk vindt de aanvaller de oplossing vroeg of laat, maar tegen de tijd dat de puzzel compleet is ben jij er allang achter dat je database gehackd is. Dan heb je natuurlijk alle wachtwoorden gereset, je algoritme aangepast en je gebruikers netjes een e-mailtje gestuurd.
Punt is, als je wachtwoord dusdanig kort en simpel is, dan maakt al die encryptie waar je het over hebt allemaal niet uit. Het maakt helemaal niets uit wat er allemaal wordt gedaan met het wachtwoord, of deze verbouwd en extra gehashed wordt.

Als je password 6 karakters is met alleen lowercase tekens, dan is dat binnen no-time ge-bruteforced. Je gaat dus helemaal niet decrypten, maar gewoon proberen.

Wil je echt effectief hacken tegengaan, dan zal je op z'n minst bepaalde eisen aan het wachtwoord moeten stellen, of een bepaald beleid tegen bruteforce moeten voeren (IP's adressen tijdelijk blocken na een aantal mislukte pogingen bijv).
Wat een onzin. Als je m'n post goed doorleest snap je dat bruteforcen geen zin heeft bij voldoende key stretching en salting.

Als elke user unieke salts en aanpassingen krijgt, dan zullen twee hashes van twee verschillende gebruikers met hetzelfde wachtwoord niet hetzelfde zijn. Als de hashes allemaal gebruteforced worden, dan is het voor de hacker alsnog een raadsel wat het originele wachtwoord nu was. Hij zal daarvoor toch echt jouw zelfverzonnen key stretching-algoritme uit moeten vogelen.

Bruteforce-programma's zijn niet bestand tegen onbekende zelfgeschreven algoritmes. Ze werken alleen voor bekende algoritmes, simpelweg omdat ze dan zelf elke mogelijke string kunnen hashen en deze proberen te matchen.
Sorry hoor, maar die hashes maken allemaal geen hol uit als je via de frontend applicatie (dezelfde waar de user dus zelf op inlogt) een bruteforce bot loslaat op het formulier. Je hebt dan ten slotte het ongehashte wachtwoord geraden. Hoe dat dan op de achtergrond gehashed wordt, maakt helemaal niets uit.

Om te verduidelijkheden, ik had het over dit stukje:
Het grappige is dat het tegenwoordig juist niet zoveel meer uitmaakt of je nou plain-text opslaat of niet. Tenminste, niet voor het merendeel van de gebruikers. Die hebben toch zulke slechte korte wachtwoorden dat het irrelevant is of je ze encrypt of niet, want ze zijn binnen no time te kraken.
Als je wachtwoord inderdaad dusdanig kort en simpel is, kan je gewoonweg via het eigen systeem bruteforcen. Daarna werd er gezegd dat je maar een paar keer zou mogen proberen om te in te loggen. Daar wordt maar vanuit gaan, dit is een website die grove fouten maakt als password in plaintext op te slaan. Het zou mij verbazen als er wel een beveiliging tegen bruteforce aanwezig is.
Hierdoor zou een kort wachtwoord (omdat ze waarschijnlijk ook geen sterk wachtwoord opdringen) makkelijk te raden zijn. Of het wachtwoord dan versleuteld is of niet, maakt dan nog vrij weinig uit.
Het staat al in het nieuwsartikel dat er geen encryptie aanwezig is. En of er wel of geen brute force beveiliging is maakt in deze discussie dus al niet meer uit. De vraag was, maakt encryptie een verschil: zeker. Je moet alleen ook het aantal logins limiteren, dat is alles. Een doorsnee checklist voor beveiliging heeft dit er al lang in staan.
Mijn excuses, ik ging er vanuit dat je het had over het bruteforcen van een gehackte wachtwoordenlijst, gezien de inhoud van het artikel. Je hebt gelijk - als je via de frontend probeert te bruteforcen hoef je het algoritme ook niet te raden.

Maar zoals enkele andere tweakers al zeggen: frontend bruteforcing is het eerste waar je jezelf tegen indekt, zowel in de software (CAPTCHAs, blokkeren van accounts na X pogingen) als in de netwerkconfiguratie (DDoS-beschermingen en botdetecties).
Front-end bruteforce is gewoon nooit een issue. Het probleem is altijd alleen maar dit soort gelekte databases.
Ik denk dat je eens met een serieuze crypto onderzoeker zou moeten praten om te onderzoeken hoe moeilijk het *echt* is om zelfgebrabbelde algoritmes te achterhalen die door iemand zonder enige geavanceerde cryptokennis gemaakt zijn (gegeven een db met miljoenen entries).
Hoe wil je dat bruteforcen? Als je het hash/encryptie algoritme niet hebt. En je hebt als website gewoon een limit op het aantal keren dat je mag proberen.
Hoe wil je dat bruteforcen? Als je het hash/encryptie algoritme niet hebt.
Gewoon zoals ik zei, proberen. Je zet er een bot op die alle mogelijke woordcombinaties (beginnend met de meest gebruikte) in een inlogform gaat zitten tikken. Is je password maar een paar karakters lang zonder bijzondere tekens, heb je maar een paar minuutjes de tijd nodig.
En zo maakt de encryptie/hash algoritme dus geen hol uit (dat is juist een beetje het idee van bruteforcen).
En je hebt als website gewoon een limit op het aantal keren dat je mag proberen.
Daar ga je maar blind vanuit :) we praten hier over een website die password in plaintext op slaat, he?

[Reactie gewijzigd door Zoop op 20 november 2013 12:39]

Nee de discussie ging inmiddels over of hash/encrypten etc. als principe uitmaakt. Dat maakt het dus wel degelijk.
De hackers hadden hier gewoon toegang tot de database, die zijn dus helemaal niet bezig met een login formulier... Ze genereren allerlei md5 hashes en kijken of die overeenkomen met de wachtwoorden.
Een fatsoenlijke password hash (bcrypt bijvoorbeeld) heeft ongeveer een halve seconde nodig om te encrypten. Dat is dus 120 mogelijkheden per minuut. Dan duurt het wel iets meer dan een paar minuutjes om zelfs korte wachtwoorden te raden.
Ik ben het niet helemaal met je opmerking eens. Op zich helpt salten e.d. wel, je maakt het namelijk moeilijker om een wachtwoord te achterhalen, toch lukt het uiteindelijk wel. Ook met een user salt, lukt het je uiteindelijk. Je kan alleen niet gebruik maken van een rainbow table principe.

Met je eigen encrypty algoritme maak je het ook moeilijker, maar zodra ze toegang tot je code hebben is dat ook gebeurd. Om die reden zijn ook onomkeerbare hashing methodes ontstaan..
Als je echt verstand hebt van beveiligingsalgoritmes zou je zulke uitspraken niet maken. Je algoritme moet er juist voor zorgen dat zelfs het kortste simpelste wachtwoord nog zo gesalt en gestretchd wordt dat (zolang de aanvaller geen toegang heeft tot de code die de hash genereerde) de aanvaller na het decrypten van het wachtwoord nog op zijn hoofd zit te krabben wat er allemaal mee gebeurd is.

Denk bijvoorbeeld aan het genereren van een extra reeks getallen die plaintext worden opgeslagen bij het (gehashte) wachtwoord. Aan de hand van deze getallen kan je dan karakters manipuleren, extra karakters toevoegen of de plaatsen van de karakters veranderen. Elke user heeft zijn eigen getallenreeks, dus rainbow tables zijn nutteloos.

Het klinkt heel simpel, maar met een bruteforce komt een hacker dan niet ver genoeg meer. Hij zal toch zelf even moeten puzzelen om erachter te komen wat je met zijn wachtwoord gedaan hebt voor je het ging hashen. Je algoritme is namelijk onbekend. Natuurlijk vindt de aanvaller de oplossing vroeg of laat, maar tegen de tijd dat de puzzel compleet is ben jij er allang achter dat je database gehackd is. Dan heb je natuurlijk alle wachtwoorden gereset, je algoritme aangepast en je gebruikers netjes een e-mailtje gestuurd.
Het is wat gechargeerd gezegd natuurlijk en ik gebruik ook Bcrypt uiteindelijk. Maar je moet toch toegeven dat ik wel een punt heb. Het uiteindelijke probleem zit hem niet in hoe je passwords opslaat want alle zwakke passwords kan je uiteindelijk vinden. Het probleem zit hem wél in zwakke en hergebruikte passwords. Als er weer ergens een database met passwords is gevonden waarvan de meesten te herleiden zijn naar een plaintext versie en 't ook nog te koppelen valt aan een naam of e-mailadres dan is het ook prima mogelijk om die informatie weer te gebruiken om in te loggen op 1000 andere websites.

Verder een beetje onnodige opmerking, die eerste.
Eigenlijk is encryptie alleen nog erg van belang voor de mensen die hun passwords laten genereren op werkelijk random manier en daarbij ook nog eens een password van flinke lengte kiezen. Maar dat zijn dan ook weer de mensen die het mínst getroffen zijn als er een keer ergens een database op straat ligt, want dan hergebruiken ze vaak het password toch al niet omdat ze ergens een password store hebben.
Akkoord dat die het minst getroffen zijn - maar naar die mensen heb je sowieso toch ook een verplichting rond het bewaken van hun persoonlijke gegevens?

Inderdaad, ik zal bij de minst geïmpacteerden zijn wanneer de wachtwoorden van een site waar ik een account heb op straat liggen. Maar evengoed kunnen met de wachtwoorden ook een boel van mijn persoonlijke gegevens op straat liggen.

Bedankt voor de link naar het artikel trouwens, ziet er interessant leesvoer uit. Ik ga dit vanavond eens doornemen.
Akkoord dat die het minst getroffen zijn - maar naar die mensen heb je sowieso toch ook een verplichting rond het bewaken van hun persoonlijke gegevens?

Inderdaad, ik zal bij de minst geïmpacteerden zijn wanneer de wachtwoorden van een site waar ik een account heb op straat liggen. Maar evengoed kunnen met de wachtwoorden ook een boel van mijn persoonlijke gegevens op straat liggen.

Bedankt voor de link naar het artikel trouwens, ziet er interessant leesvoer uit. Ik ga dit vanavond eens doornemen.
Je hebt gelijk hoor, ik pleit er ook zeker niet voor om alles in plaintext op te slaan. Je wil ook zeker dat de mensen die wél moeite doen dan ook beschermd zijn. Ik wilde gewoon even dit punt maken over dat gebruikers hier ook bewust van moeten zijn en dat encryptie geen eindoplossing is.
Het valt me op dat dit soort artikelen altijd gaat over wachtwoorden die simpelweg gehashed worden met MD5 of SHA1. Er wordt nooit gebruik gemaakt van een salt. Zijn er ook soortgelijke artikelen van hackers die wachtwoord met salt kraken? En hoe succesvol zijn ze dan?
Het valt me op dat dit soort artikelen altijd gaat over wachtwoorden die simpelweg gehashed worden met MD5 of SHA1. Er wordt nooit gebruik gemaakt van een salt. Zijn er ook soortgelijke artikelen van hackers die wachtwoord met salt kraken? En hoe succesvol zijn ze dan?
Dat wordt in dat artikel juist heel goed uitgelegd (op pagina 2 en 3)
En nog zijn er mensen die niet geloven in wachtwoord kluisjes zoals Keepass. Zelf gebruik ik keepass al jaren, zpu niet meer terug willen! Om de haverklap worden databases gehackt. Met keepass maak ik voor elke site een ander wachtwoord aan. Maar wachtwoorden plain txt opslaam? Daar zou je echt gestraft voor moeten worden. Komop!
Hoewel ik keepass ook gebruik, zijn er IMO drie grote nadelen aan.
1) Hoe weet je zeker dat er geen backdoor in zit? Een kluis met wachtwoorden is wel het summum van de doelwitten. Waarom zouden de ontwikkelaars van dit programma niet bedreigd worden door de Russische Maffia?
2) Wat als je geïnfecteerd bent met malware die tussen het keypass programma en de input / output van dit programma gaat zitten?
3) Als er datacorruptie ontstaat in de database is het jammer maar helaas. Of, wat logischer is, als je per ongeluk de file wist is het ook balen. Dus naast de file zou het beter zijn om deze ook af te drukken.
De antwoorden:
1) Dat weet je nooit zeker maar Keepass is open source en de ontwikkelaar houdt je niet tegen als je een audit van de code wilt doen.
2) Dat is inherent aan lokaal geinstalleerde software. Je zult zelf je PC malwarevrij moeten houden.
3) Nooit van backups gehoord?
Voor vraag 2 heeft Keepass het volgende: http://keepass.info/help/v2/autotype_obfuscation.html

Is dit 100000000% veilig? Niks is 100000000% veilig. Maar je filtert hiermee filter je heel erg veel keyloggers er uit.
Je vergeet het belangrijkste: met KeePass introduceer je wederom een 'single point of failure'. Als een hacker het wachtwoord van jouw KeePass-database weet te achterhalen, heeft ie echt toegang tot alles.

De kans is bovendien miniscuul dat je voor de KeePass-database zelf een wachtwoord kiest met voldoende entropy. Tenslotte wil je dat wachtwoord wél kunnen onthouden.
Je vergeet het belangrijkste: met KeePass introduceer je wederom een 'single point of failure'. Als een hacker het wachtwoord van jouw KeePass-database weet te achterhalen, heeft ie echt toegang tot alles.
Dan moet hij niet alleen het wachtwoord van de Keepass-DB weten te achterhalen, maar er in eerste instantie ook al zijn handen op weten te leggen.
De kans is bovendien miniscuul dat je voor de KeePass-database zelf een wachtwoord kiest met voldoende entropy. Tenslotte wil je dat wachtwoord wél kunnen onthouden.
Waarom zou die kans minuscuul zijn? Uiteindelijk moet je slechts 1 antwoord meer onthouden, dat zou toch moeten lukken denk ik. :)
Je vergeet het belangrijkste: met KeePass introduceer je wederom een 'single point of failure'. Als een hacker het wachtwoord van jouw KeePass-database weet te achterhalen, heeft ie echt toegang tot alles.
Ik ben er niet zo bang voor dat een hacker het wachtwoord weet te achterhalen mbv brute force, wel voor een backdoor.
De kans is bovendien miniscuul dat je voor de KeePass-database zelf een wachtwoord kiest met voldoende entropy. Tenslotte wil je dat wachtwoord wél kunnen onthouden.
Dat acht ik veel reëler. We zijn tenslotte maar mensen. Daarom zei ik ook dat het verstandig is om een afdruk te maken van de wachtwoordendatabase.
Mijn ww van keepas is eenvoudig, die kan je gelijk krijgen hoor, geen probleem.

Daarna mag je op zoek in mijn fotomap naar de betreffende image en bijbehorende keyfile.

( beide zelfs online te bereiken, voor noodgevallen staan ze op een NAS van een kennis )
Maar zonder de 3 afzonderlijke bestanden wordt het lastiger.

< één spof is er btw wel bij mij, aangezien ik relatief lui ben, heb ikop mijn phone quickunlock aanstaan, een kort ww om hem na de eerste ontgrendeling te openen, ik voel me redelijk safe, maar ook hier natuurlijk kwetsbaarheden, gelukkig hoef ik geen kernkoppen te besturen, of een datingsite >
En zo kan je dagenlang argumenten en tegenargumenten opbrengen.

Ik gebruik keepass op mijn android-devices & ipad, en een portable versie in mijn dropbox.
De database staat in dropbox en sync'd met gdrive online & offline.

overal en altijd toegang op diverse manieren.
Vooral handig om de lange en lastig te onthouden passwords te maken en gebruiken
Iedere discussie bevat argumenten en tegenargumenten. Daar draait een discussie toch om?

Ik vind die drie argumenten valide en ik denk dat meer mensen ook daadwerkelijk meer zouden moeten uitzoeken wat software nou precies allemaal doet. Dit argument wordt natuurlijk een nog groter issue bij SaaS, maar dit is wel offtopic aan het worden.
hah dit dus.
en met keepass en de schijnveiligheid die erme komt... hoeft iemand die toegang tot je shit wilt hebben het wel heel erg makkelijk gemaakt.
je hele beveiliging heeft dan gewoon een single point of failure... endat is sowieso fout.
en wat dan? want zonder keepass kan je er zelf ook niet bij.
Gebruik een lange wachtwoord voor keypass en maak een afdruk van de database. Meer kan je niet doen volgens mij.
Mja, toch. Single point of failure is gewoon kut. Heb ik zelf ook wel hoor met mijn wachtwoorden systeem :P

1 ww voor mijn echt belangrijke shit, en daar 4-6 verschillende uitvoeringen van.
1 voor mijn belangrijker shit en ook 4-5 versies hiervan (ondanks dat tweakers daar niet onder valt, gebruik ik wel zo'n ww ervoor dankzij de eisen....erg vervelend, niet dat ik de beveiliging hier slecht vertrouw, maar het is _maar_ een nieuws site, die van mij beetje een lvl 2 password eist)
en een standaard ww die ik vrijwel overal gebruik wat me weinig interesseert, vrienden enzo weten dit ww ook van mij.

Maar mocht ik mijn lvl 1 ww vergeten, zal ik nooit meer bij mijn outlook/gmail kunnen komen omdat geheime vraag/antwoord totale onzin zijn :P en beide hun recovery email adressen is de andere. En als ik daar niet bij kan, kan ik ook niet bij de rest mocht ik die ww's vergeten. Maar mijn ww's zitten in mijn hoofd en gezien ik alsnog bijna overal andere ww's gebruik en andere nicknames, voor mijn gevoel iig minder risico dan een oplossing als keepass oid.
Misschien omdat die zogenaamde kluisjes gewoon schijnveiligheid is? en ik weet niet hoe het met jou zit, maar ik zit vaak niet achter dezelfde computer waar keepass op draait..

Maar mbt plaintext ben ik het wel met je eens..
Ik ken ook een manier om zelfs zonder keepass veilig te werken. Laat voor iedere sessie een nieuw wachtwoord genereren via de "Ik ben mijn wachtwoord vergeten" optie.

Overigens ben ik zelf fervent Keepass gebruiker en nagenoeg iedereen in mijn omgeving ook.
Het is toch niet zo moeilijk om een lastig wachtwoord te bedenken?

Zo heb ik vroeger deze gebruikt:
D3k4tkr4btd3Krull3nv4nd3tr4p!

Mocht een bepaalde website niet meer dan 18 characters per wachtwoord accepteren, dan gooi je hem door de helft..

Heel moeilijk om te kraken, het is makkelijker om veel typfouten te maken, dat klopt :)

Je moet niet gaan voor gemakzucht, dit zorgt voor onveilige wachtwoorden / slecht beveiligde personalia. Zo heb ik dan ook het idee dat dit voor het meest grote gedeelte gaat om ''gratis'' dating websites, waarin mensen zowel een alternatief e-mail adres hebben gebruikt een makkelijk wachtwoord omdat ze er niet dagelijks gebruik van maken en deze anders vergeten.. Ik durf te wedden dat van deze 42 miljoen accounts er erg veel zijn 80% met een onvolledig profiel? :)

[Reactie gewijzigd door Dr.Root op 20 november 2013 09:15]

Of je plakt drie makkelijk te onthouden, lange woorden die niets met elkaar te maken hebben aan elkaar als wachtwoord. Dat is voor jezelf makkelijk te onthouden, maar lastig te kraken, aangezien de woorden niets met elkaar te maken hebben, en door de combinatie van de drie heb je gelijk een lang wachtwoord.

De truc is om een voor jezelf makkelijk te onthouden, maar voor een ander lastig te kraken wachtwoord te verzinnen.

De meeste mensen hebben zoiets van "Shit, straks vergeet ik m'n wachtwoord." en vullen daarom eentje in die niet alleen makkelijk te onthouden is, maar onbedoeld ook makkelijk te kraken.
Precies, zoals deze cartoon van Xkcd illustreert: http://xkcd.com/936/
Dictionary attack? ;)
gewoon wachtwoord zoals in die xkcd nemen en een (heel) kleine aanpassing eraan doen.
Vervangen van letters in een woord door cijfers of leestekens kan ook meegenomen worden in een dictionary attack. Dat maakt het wachtwoord dus niet sterker...
ik doelde eerder op random salting eraan toevoegen (en niet achteraan bv je geboortedatum..)
eerder ergens random achter een bepaalde letter een serie'tje van verschillende letters, cijfers, symbolen die alleen voor jouw logisch zijn. (of niet logisch, maar onthoudbaar als je niet weet wat je zou kunnen gebruiken)

[Reactie gewijzigd door SmokingCrop op 20 november 2013 21:14]

Dat klinkt inderdaad beter en maakt het wachtwoord sterker. Wanneer dan ook nog iets meeneemt waardoor elke website een ander wachtwoord krijgt maar je ook nog gemakkelijk kunt onthouden zit je redelijk safe. Niet 100% safe maar wel heel wat beter dan hetzelfde wachtwoord voor elke site.
Ik zal mijzelf absoluut geen expert noemen op het gebied van passwords en security, maar ik vond dit artikel erg inzichtelijk:

How the Bible and YouTube are fueling the next frontier of password cracking van arstechnica

Edit: Mijn conclusie: ook aan elkaar geplakte woorden zijn tegenwoordig steeds gemakkelijker te kraken. Goed nadenken over je wachtwoorden, met variaties in tekens en cijfers en nooit dezelfde gebruiken is dus belangrijk, belangrijker dan correcthorsebatterystaple overal gebruiken.

[Reactie gewijzigd door Hafermaut op 20 november 2013 10:58]

ik niet, mensen gaan daardoor gewoon een (of een paar) woord(en) uit een woordenboek nemen die langer is dan die Tr0ub4dor &3 en die wordt dan gewoon even relatief vlug via een dictionary attack gehacked..
Alsof er tegenwoordig naast een dictionary attack ook niet alle standaard modificaties (e vervangen door 3, a door 4, o door 0) mee geprobeerd worden. Dat is makkelijker te pakken met een dictionary attack dan 4 random woorden.

Ik neem even het engelse woordenboek als voorbeeld, volgens oxford bevatte dit 171474 woorden op dit moment in gebruik. Geen datum alleen helaas. Stel men zou ook een attack doen met alle standaardletters veranderd door cijfers, dat is een verdubbeling, dus 342948 mogelijkheden. Dan heb je de meeste huidige "wachtwoorden" tegenwoordig al gehad. Dat is belachelijk weinig. Dit is een hele grove schatting, er zullen ook woorden zijn waarbij het niet nodig is, of woorden waarbij mutaties mogelijk zijn zoals de eerste e wel vervangen door een 3, en de 2e niet maar het is een goede eerste indicatie.

4 random woorden daarintegen, dat zijn 1714744 mogelijkheden. Oftewel: 864555972455529320976 mogelijkheden. Sterker nog, dat is substantieel veel meer dan de entropy die XKCD geeft voor Tr0ub4dor &3, 228 is namelijk 268435456 mogelijkheden.

Nu kan je natuurlijk uit de oxford dictionary minder populaire woorden gaan filteren en daarmee je attack space verkleinen, maar dat houd in beide gevallen stand.
uiteraard, ik bedoelde eigenlijk ook geen logische aanpassing, dat had ik even vergeten te zeggen :P (bv. niet een e vervangen door 3, maar gewoon achteraan (of ergens anders) iets random/enkel voor jouw logisch toevoegen -> beetje zoals salting eigenlijk)

[Reactie gewijzigd door SmokingCrop op 20 november 2013 13:33]

Vergeet niet dat 1 tot 4 nummers toevoegen aan het einde ook een veel gebruikt iets is, zelfs voor account names. 171474 met de nummers 0 tot 9999 erachter geplakt zijn in totaal nog steeds maar 171474 * 10000 = 1714740000 verschillende mogelijkheden. (er even van uit gaande dat mensen geen voorloop nullen gebruiken wat ze niet snel zullen doen). En ik durf te wedden dat een dictionary + getal aan het einde ook een redelijk standaard methode is.

Het artikel wat Argantonis hierboven aanhaalt bevestigt eigenlijk dit vermoeden. Letters door nummers vervangen, nummers toevoegen alle verschillende passwords onder 6 tekens worden allemaal makkelijk binnen het uur eruit gepikt. Zelfs wanneer gehashed.
lol, je moet dan ook geen nummertjes gewoon toevoegen eh.
"iets wat enkel voor jouw logisch is" & "daarom niet gewoon achteraan".
Ik heb zelf mijn vriendin via een datingsite leren kennen. Mijn reden was niet de wanhoop maar dat ik iets anders zocht dan ik kom vinden in het uitgaansleven.

Je vult wat vragenlijsten in en krijgt dan matches voorgeschoteld. Nu heb ik een hele leuke Canadese vriendin die mij inmaakt met super mario, een muzieksmaak (en kennis) waar je u tegen zegt en daarbovenop fylosofisch is. Drie zaken die ik (onbewust) erg kan waarderen in een partner, zo blijkt. Ik raad iedereen aan om zich over het stereotype heen te zetten en het eens te proberen. Je zal er geen spijt van krijgen! Ik ben al meer dan 2 jaar samen en het bevalt iedere dag beter.

Nu ontopic; dit was overigens via OkCupid, dus ik gok dat mijn wachtwoord ook op straat ligt. Gelukkig altijd unieke wachtwoorden gebruikt voor de services. Heb overigens nog niks ontvangen van OkCupid over deze hack..
Alleen al de suggestie van "wanhoop" vind ik een sterk verouderd vooroordeel omtrent online dating. 10 jaar terug vonden veel mensen dat, nu is bijvoorbeeld zowat 1/3e van mijn vriendengroep via online dating aan hun partner gekomen.

Ikzelf ben al voorzien (op de klassieke manier) maar ik vind online dating nu juist een superieure optie. Zonder deze optie ben je zowat op pure toevalligheid aangewezen op het vinden van een partner. Ook weet je niet of iemand vrijgezel is en je kunt praktisch niet "filteren" op eigenschappen, hoe koud dat ook klinkt.
Hier ook een ouderwetse dater ( en hiermee getrouwd ), en zonder spijt.
Maar ik zou me er zeker in verdiept hebben als ik op zoek zou zijn.

Maar dan inderdaad een "goed aangeschreven" lokatie, geen 10$ all you can eat ;)
Ik ken diverse mensen die hun huidige relatie beter voor elkaar hebben hierdoor, dan daarvoor, met de toevallige hits offline.

[Reactie gewijzigd door FreshMaker op 20 november 2013 17:33]

Kan mijn reactie niet editen via de Tweakers iOS app. Bij deze: OkCupid valt niet onder deze sites. Ben ik blij om! Wel een aanrader overigens! :)
Aan wat cptMayday en Fledder2000 zeggen wil ik nog toevoegen dat dating-sites voor mensen met een niet-traditionele sexuele voorkeur (LGBTetc) één van de weinige goede opties zijn om een partner te vinden. Als iemand die homo is een partner 'door toeval' probeert te vinden, is de kans namelijk zeer groot dat iemand waar hij/zij in geïnteresseerd is, valt op het 'verkeerde' geslacht. Gay-bars en dergelijke zijn al helemaal niet voor iedereen weggelegd.
Verschil met tweakers en vele dating sites is dat inloggen niet altijd op een bekende gebruikersnaam gaat. Dus is het daar iets minder gevaarlijk.

Hier kan je gewoon zien dat mijn inlognaam kevinp is mijn wachtwoord is in ieder geval geen 123456 ;).
Maar aangezien er ook bijbehorende emailadressen buitgemaakt zijn, gaat dat dus niet op. Hoeveel sites gebruiken niet het email adres als login naam? Bovendien heb je nu een prachtige set mailadressen van gebruikers waarvan je weet dat ze interesse hebben in het vinden van een partner. Prachtig om te spammen met Russian Brides e.d. dus!

[Reactie gewijzigd door ATS op 20 november 2013 09:32]

Klopt, maar wat ik bedoelde te zeggen is dat wachtwoorden als qwerty, 123456 veel gevaarlijker zijn bij een site met een gebruikersnaam die zichtbaar is en de inlognaam.

Immers staat niks me in de weg om ATS en qwerty te proberen. (behalve het gebrek aan behoefde en een moreel besef dat het fout is om te doen).
Je gaat je gang maar hoor :)
Ik gebruik een manager met lange random wachtwoorden. Succes met (handmatig) proberen met qwerty of 123456!
Al heb je wachtwoorden van een kilometer lang, als ze gewoon leesbaar zijn heb je er niks aan.
Is het dan spam of gerichte marketing? ;)
De inlognaam mag dan wel afwijken maar die wachtwoorden kunnen wel gebruikt worden voor brute-force aanvallen. De kans is immers groot dat iemand 1 van deze wachtwoorden heeft gebruikt.
Die kans is sowieso groot, want die populaire wachtwoorden worden op iedere website gebruikt.
Daarom doe ik altijd willekeurige letters cijfers hoofdletters en leestekens
Dat is inderdaad nog altijd het beste voorbeeld van hoe wachtwoorden inderdaad gebruikt moeten worden door mensen die geen wachtwoordkluizen hebben (of zelfs in combinatie met desnoods). Ik was dit plaatje alweer bijna vergeten haha :).
En tot die conclusie kan je alleen komen door eerst alle website te hacken om de wachtwoorden te achterhalen :)
Nee hoor. Er zijn genoeg wachtwoorden gelekt om uitspraken te kunnen doen over alle wachtwoorden, zonder ze allemaal gezien te hebben. De sample is groot genoeg.
123456 is eigenlijk *altijd* nummer 1 bij dot soort onversleutelde (of inadequaat versleutelde, met rainbow tables te bewerken) databases. Vermoedelijk omdat "6 characters minimum" vrij algemeen is als eis.
En toch wordt ik dood ziek van die eisen. Als ik voor iedere website een ander wachtwoord zou hebben dan zou ik er niet alleen een paar honderd moeten onthouden... ik zou ook moeten onthouden welk wachtwoord ik waar heb gebruikt.

Ook zou het wettelijk verplicht moeten zijn dat duidelijk en overzichtelijk op iedere website staat aangegeven hoe er wordt om gegaan met je gegevens. en dan niet in elle lange teksten maar gewoon welke encryptie het gebruikt en wat het doet door aanvallen ze klein mogelijk te maken.

Het is mij een raadsel of tweakers er wel alles aan doet om mijn gegevens veilig te houden. Er zou bijvoorbeeld een keurmerk kunnen zijn waar websites bij aangesloten zitten die eens per zoveel maanden controle krijgen om te kijken of de site nog wel voldoet en of netjes de updates gedaan worden. Zodat je als gebruiker weet dat er alles aan gedaan is om je gegevens veilig op te slaan.

Ik heb verschillende gradatie wachtwoorden voor verschillende websites. waarbij mijn bank wachtwoorden meer dan 15 tekens bevatten. dus wat dat betreft gebruik ik die wachtwoorden ook alleen voor mijn bank. maar het is onmogelijk om voor iedere website waarvoor je je weer moet aanmelden een ander wachtwoord te kiezen.

Het grootste probleem van deze eisen in mijn ogen is het niet kunnen gebruiken van je standaard wachtwoord. bij origin mag je namelijk geen leestekens gebruiken. nou ik wil juist een leesteken. dat is veiliger en die gebruik ik gewoon. dus nu heb ik voor origin weer een andere variant. Dan heb je sites die perse hoofdletters eisen en een leesteken. dan heb je websites die een hoofdletter eisen en je alleen bepaalde leestekens mag gebruiken. Zo krijg je zonder dat je het wil 10 tallen verschillende wachtwoorden en uiteindelijk resulteert het in steeds weer opnieuw opvragen van je wachtwoord omdat je het gewoon bij iedere site niet meer weet.

Kunnen ze niet gewoon 1 account maken met de hoogst mogelijke veiligheid waarmee je op aangesloten websites kan inloggen. dat inloggen met facebook is op zich een leuk initiatief. Met een verificatie code per sms kun je zo veilig inloggen, en heb je toch maar 1 wachtwoord voor alle sites. je zou dan nog kunnen gaan voor het automatisch sturen van een sms als er op een account wordt ingelogd met je gegevens zodat je direct weet als er wordt ingelogd terwijl jij het niet bent en je een link in de sms krijgt dat wanneer je erop klikt je gelijk je account blokkeerd en er nergens meer mee kan worden ingelogd. al die accounts met al die wachtwoorden.... man o man het is niet meer bij te houden zo.
Het bespaart de NSA alvast veel werk ;-)
Aan de ene kant zou je inderdaad willen dat websites goede beveiliging hanteren en van sommige mag je dit zelfs eisen. Zo vind ik het bijvoorbeeld erg slecht dat iemand DigiD wachtwoord niet veranderd hoeft te worden. Zo heb ik al sinds omstreeks 2009 hetzelfde wachtwoord.

Echter aan de andere kant ben je deels verantwoordelijk voor je eigen digitale veiligheid. Ieder mens dat het nieuws leest ziet veel berichten voorbij komen over websites die gehacked worden en dat daardoor bepaalde informatie zoals wachtwoorden soms bloot komen te liggen. Dan is het ook aan jou om daarmee iets te doen, ik gebruik voor sommige websites waar ik slechts aangemeld moet zijn om iets te kunnen mijn bullshit e-mailadres en een simpel wachtwoord.

Maar voor andere sites waar het wel belangrijk is hanteer ik sterke en unieke wachtwoorden welke ik allemaal individueel opsla in een wachtwoordkluis.

Deze zijn zwaar beveiligd en erg makkelijk in gebruik en deze heb ik bijvoorbeeld op Dropbox staan zodat ik er overal bij kom. Een ander voorbeeld dan die BazzPsychoNut gebruikt is bijvoorbeeld: http://keepass.info/
JA ik snap je punt, maar mijn angst is juist dat deze sterke wachtwoorden, als deze dus opeens niet versleuteld blijken te zijn en ze komen door een hack op straat te liggen, zo sterk kunnen zijn als je wil, maar geen functie meer hebben.

Mijn vraag is welke site is veilig? Als ik me bij google aanmeld is dat veilig? Je zou verwachten van wel. Maar dat verwachtte ik toen der tijd ook van sony. dit gigantische bedrijf lekte per ongeluk zomaar even miljoenen creditcard gegevens. Je kunt eigenlijk geen enkele site vertrouwen... Maar als je je dus nergens meer veilig kan aanmelden... dan kun je tegenwoordig ook niets meer.
Het zal altijd een probleem blijven dat websites informatie opslaan die jij liever privé houdt en welke vervolgens gehacked (kunnen) worden. Dit is een risico in onze moderne internet maatschappij die ongetwijfeld zal blijven, daarom moet je kritisch blijven wat je online deel.

Het voordeel van een sterk en uniek wachtwoord hebben is tweezijdig;
(1) Indien een website niet zo lui is om het wachtwoord plaintext op te slaan dan zullen de krakers er een zware kluif aan hebben om jouw wachtwoord uiteindelijk te verkrijgen. Ik ben geen held in cyrptografie maar volgens mij neemt de tijd om het te kraken bijna expentioneel toe naarmate je x aantal bits toevoegd aan je wachtwoord. (dit is slechts een filosofische opmerking)

(2) Aangezien je een wachtwoordkluis gebruikt hoef jij je moeilijke 120 karakter lange wachtwoord niet te onthouden, daarom kun je dus unieke wachtwoorden gebruiken. Inderdaad ze weten dat jouw e-mailadres sygys@gmail.com is, maar aangezien jij voor sony.com alleen wachtwoord x gebruikt kunnen we wel bijvoorbeeld naar facebook gaan maar daar heb jij een ander wachtwoord. Dus dan hebben ze er alsnog niks aan.
Het lijkt mij dat als ze de database gehackt hebben en de wachtwoorden weten ze ook de bijbehorende emailadressen hebben. Hoezo dan minder gevaarlijk? Er zijn nog altijd te veel mensen die voor zoiets onbelangrijks als een datingsite hetzelfde wachtwoord gebruiken als voor hun email adres via waar een hacker zo ongeveer elk account en wachtwoord kan resetten van jou.
Een wachtwoord van een dergelijk site zou bij mij ook erg simpel zijn, een standaard wachtwoord voor low-risk websites. Pas wanneer iets serieus is voor mij zal ik een uniek en sterker wachtwoord maken.
Oja? En wat als iemand je account kraakt en bedreigingen gaat rondsturen naar de andere leden? Aangifte, bezoek van de politie, misverstand, gedoe, etc. Dat had je allemaal kunnen voorkomen door even een sterk wachtwoord te kiezen.

Ik heb voor iedere site een ander sterk, random wachtwoord dmv keepass.
Een simpel wachtwoord voor mij zal bestaan uit 10-12 tekens gemend met Uppercase, Lowercase, nummers en minstens één leesteken. Echter een website welke dat in plaintekst opslaat zal het niet bij helpen, ook zou ik daar geen echt e-mail adres gebruiken ( meer een wegwerp ) en geen tot weinig echte gegevens, want op dit moment zou een dergelijke site niet interseant en serieus zijn voor mij.
Er zijn hele volksstammen die dit soort wachtwoorden aanmaken, moeilijk te onthouden maar voor een computer maakt het niet uit...

Je kunt beter een langere wachtwoord zin maken met gemakkelijk te onthouden woorden die niet aan elkaar gerelateerd zijn, makkelijk te onthouden en een computer moet al wat meer werk verrichten om het te kraken.

Ter illustratie een cartoon van Xkcd, wel passend voor deze discussie: http://xkcd.com/936/

[Reactie gewijzigd door Bilbo.Balings op 20 november 2013 09:47]

Hoeveel van dat soort zinnen kun je onthouden? Ik denk dat het bij een stuk of 5 al ophoudt. Dus in de praktijk ga je dan toch op meerdere plekken dezelfde passphrase gebruiken. En hoe sterk is dat wachtwoord dan nog als de database van één van die sites op straat ligt?
Wanneer de database in plain text op straat ligt houdt alles op natuurlijk, daar helpt geen wachtwoord tegen...

Je kunt altijd nog de naam van de website opnemen in de wachtwoord zin, zal niet 100% bestand zijn tegen een slimme hacker maar wel tegen willekeurig proberen van buitgemaakte wachtwoorden.
Wat versta je onder low-risk ?

Ik vind dit high-risk. Dit zijn toch sites waar mensen meer informatie invullen dan op andere sites.
Denk maar aan je interesses, locatie waar je woont en soms zelfs adres etc. Deze sites zijn juist een goudmijn voor de spammers.
Nu zou ik me daar persoonlijk ( op dit moment ) mischien alleen aanmelden om te trollen, want ik ben niet serieus aan het daten, wanneer ik er interesse voor zou hebben en het serieus zou doen dan is het automatisch geen low-risk meer ;)
Precies. Ik heb ook 2 soorten wachtwoorden. Van sites waarvan ik verwacht dat ze er slecht mee omgaan, gebruik ik ook iets simpels. En datingsites zijn doorgaans hartstikke corrupt.
Ik gebruik voor een aantal PHP+mySQL sites momenteel een versleuteling van SHA512 van het gebruikerspaswoord in combinatie met een vaste salt van de website, alsook een aparte salt per gebruiker. Ik hoop dat dit voldoende is :)

Blijkt dat het in PHP (vanaf v5.5) password hashing eigenlijk heel wat eenvoudiger kan geïmplementeerd worden... hopelijk motiveert dit de web developers een beetje om het te gaan gebruiken.

[Reactie gewijzigd door bvanaerde op 20 november 2013 11:06]

Ik kan er ook weinig van begrijpen, maar PHP 5.5 word nog weinig aangeboden als het goed is zit Ubuntu op 5.3 in 12.04, Debian op 5.4, in Freebsd staat PHP 5.5 gewoon in de ports tree. Ik heb gisteren een Arch server geïnstalleerd want die is ook altijd lkkr up to date.
Ik zie net ook dat er een compatibility pack wordt aangeboden voor webservers met een PHP versie lager dan 5.5 (maar waarschijnlijk wel vanaf 5.0). Geen excuus dus! :P

Ik heb eigenlijk in Ubuntu nog nooit de standaard webserver geinstalleerd, wel via XAMPP. Heel tevreden van, en je hebt meteen een recente versie.
Die compatibility library is voor PHP >= 5.3.7 (zie de README).
No offense maar er zijn in mijn mening een aantal dingen waar je zelf niet aan moet prutsen zonder er echt kennis van te hebben. Zeker niet als er kant en klare oplossingen voor zijn. Encryptie van data en hasing van passwords zijn daar twee dingen van.

Kijk maar naar whatsapp, die denken ook dat hun encryptie helemaal geweldig is terwijl het gewoon een paar dagen later weer gecracked is, iets wat supersimpel te voorkomen was als ze gewoon een standaard SSL oplossing zouden gebruiken. Maar nee...

Zelfde voor passwords opslaan, die oplossing van PHP v5.5 is leuk en een stap in de goede richting, maar er zijn al jaren classes beschikbaar die hetzelfde doen en wellicht zelfs nog wel beter. Waarom zoveel tijd in een eigen oplossing steken als er kant en klare oplossingen zijn die wellicht net zo veilig of waarschijnlijk nog wel veiliger zijn?
Waarom zoveel tijd in een eigen oplossing steken als er kant en klare oplossingen zijn die wellicht net zo veilig of waarschijnlijk nog wel veiliger zijn?
Mwa, ik weet wel waarom: Omdat niet duidelijk is welke oplossing de beste is van de zovele voorstellen die je online kan vinden.

Was ik er hier niet over begonnen, was ik niet terechtgekomen op jouw link. Waarvoor dank, lijkt me leuk leesvoer :P

Wat betreft de oplossing van PHP zelf: als ik snel even door de pagina op openwall lees, lijkt het me eigenlijk hetzelfde principe te zijn: bcrypt met variabele salt. Hierbij hoef je je nog niet eens zorgen te maken over de salt: deze wordt automatisch gegenereerd. Ook het feit dat je mettertijd de berekeningstijd kan opkrikken vind ik wel mooi gevonden.

Mij lijkt het dus een hele nuttige, en - voor de verandering - een heel eenvoudige toepassing.
No offence, maar zelfs al worden wachtwoorden gehashed. Als de hacker de tabel met wachtwoorden kan benaderen zal deze ook de salt wel kunnen achterhalen als het wachtwoord al gehashed is. Conclusie, beveiliging gaat verder dan alleen hashen en salten van je wachtwoorden
Een hash is in principe mathematisch onomkeerbaar. De enige reële manier is brute forcen en een rainbow table gebruiken. Bij gebruik van een goede hash + salt hoef je je de komende tijd geen zorgen te maken.
Hoe snel bouw je eigenlijk een rainbow table? Als je de salt weet, heb je dan snel een nieuwe gemaakt met dezelfde wachtwoorden + salt?
Normaal heeft ieder wachtwoord een andere salt. Dan zul je dus per user een rainbow table moeten opstellen i.p.v. per site. En als je dat dan toch moet doen, kun je net zo goed direct gaan brute-forcen, aangezien dat hetzelfde is.
Ondoenlijk dus, dit zou meerdere weken duren per wachtwoord met een stevig netwerk aan computers.
Ow, dat wist ik niet...een ander salt per wachtwoord! Ik ben ontwikkelaar en wil nog iets gaan doen in de toekomst met opslaan van wachtwoorden en het salt verhaal moet ik dan nog even goed bekijken, want nu vraag ik me af hoe je een salt bepaald dan voor een wachtwoord...
Een random string of getal van een teken of 16. Deze kun je gewoon als extra veld in je user table opslaan, dat is niet minder veilig. Plak er dan ook nog een salt achter die site wijd hetzelfde is, zodat je dit krijgt:

<Salt per user> + <Wachtwoord> + <Vaste salt>

Dwing daarnaast af dat wachtwoorden minimaal 7 tekens lang zijn, dan is ieder gesalt wachtwoord minimaal 87 tekens lang (16 voor de random salt, minimaal 7 voor het wachtwoord en 64 tekens vast salt).

Gebruik daarna een sterke cryptohash, minimaal SHA256, succes met brute-forcen. ;)

[Reactie gewijzigd door OverSoft op 21 november 2013 22:25]

je kan dit on-the-fly denk ik. Bij rainbowtables moet je vooraf al een idee hebben over de vorm vh wachtwoord, dit heb je nodig voor de 'reduction function' die je dus telkens afwisselt met het hashen.
Klopt. Als je de salts en hashing manier weet kan je een rain bow table opstellen, maar dit kost heel veel tijd. De beveiliging is ook niks anders dan het zo moeilijk maken dat de aanvaller het op geeft.
Veel gebruikte hash algo zijn SHA1 en MD5 als onderdeel van mysql/php. Dit is prima om te keren. Enige puzzel die rest is de salt, maar ook met duizenden wachtwoorden moet daar wel uit te komen zijn.
Alleen een normale (goede) beveiliging heeft een salt per wachtwoord, niet dezelfde voor de hele site.

Daarnaast zijn MD5 en SHA1 niet prima om te keren, hier is heel wat rekenkracht voor nodig of massale rainbow tables (vooral bij SHA1 zijn die er eigenlijk alleen tot een bepaald aantal tekens), als je nu (zoals het normaal hoort) voor of achter het wachtwoord de salt plakt (van pak em beet 32 tekens) en die hashed, is het eigenlijk ondoenlijk om dit te breken voor alle wachtwoorden. Zeker niet als ze ook nog eens een site-specifieke salt gebruiken, zodat wat er gehashed wordt eigenlijk dit is: SITESALT+WACHTWOORD+UNIEKESALT

Tuurlijk, je kan de wachtwoorden brute-forcen, maar dit zal dan per wachtwoord moeten gebeuren, en niet voor alle wachtwoorden ineens.
Mijn eigen framework gebruikt een salt voor de site (die bij install gegenereerd wordt) en een salt per gebruiker die van de gebruikersnaam afgeleid is. Veel plezier om dat te brute forcen. Ik verwacht dat de snelste oplossing een rainbow table opstellen voor die site is.
Ja, maar je kan de hash van een alfanumeriek wachtwoord van 6 karakters al in 40 seconden achterhalen met brute force... http://codahale.com/how-to-safely-store-a-password/

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True