Aanvallers stelen waarschijnlijk honderdduizend wachtwoorden bij Brabantia

De webshop van Brabantia, een fabrikant van huishoudelijke artikelen, is waarschijnlijk gekraakt. Daardoor zouden aanvallers waarschijnlijk toegang hebben gekregen tot naw-gegevens en wachtwoorden van klanten, al zijn die wachtwoorden wel gehasht.

Brabantia heeft klanten in een e-mail op de hoogte gesteld van de hack. Het is niet geheel duidelijk of de aanvallers toegang hebben gekregen tot klantgegevens, maar dat is wel waarschijnlijk, bevestigt directeur Ab van Houdt van Brabantia. "Men heeft pogingen gedaan om binnen te komen", aldus Van Houdt. "Waarschijnlijk hebben de aanvallers toegang gekregen tot namen, adressen en wachtwoorden."

Daarbij gaat het onder meer om de wachtwoorden van gebruikers, al zijn die wel versleuteld. "Ze zijn gehasht via md5 en voorzien van een salt", aldus Van Houdt. Hoewel het md5-hashing-algoritme inmiddels is achterhaald, maakt de salt het wel moeilijk voor aanvallers om wachtwoorden aan hashes te koppelen met behulp van zogenoemde rainbow tables.

Van Houdt wil niet zeggen hoeveel gegevens mogelijk zijn buitgemaakt. "Dat zou betekenen dat ik moet zeggen hoeveel klanten we hebben, en dat gaat me iets te ver", aldus Van Houdt. Het zijn er in ieder geval 'zeker wel honderdduizend', niet alleen in Nederland, maar ook een aantal andere Europese landen. "Dat zijn dus consumenten, en niet winkeliers, die ook bij ons inkopen", aldus Van Houdt.

Reacties (92)

[xrf]

MD5 is een slechte keuze voor wachtwoordhashing, niet vanwege de collissions maar omdat MD5 zo verdraaid snel is. (Net als SHA1, SHA2 en SHA3 trouwens.)

Salting beperkt de schade nog doordat – mits de salt daadwerkelijk uniek is – je voor elke mogelijk wachtwoord waarvan je wilt controleren of die overeenkomt met de hash die je probeert te breken, de hash van dit mogelijke wachtwoord opnieuw moet berekenen.

"Gewone" hashfuncties zijn echter nog steeds te snel. Voor goede hashing zou er een speciaal voor dit doel ontwikkelde langzame functie gebruikt moeten worden: PBKDF2 (goed), bcrypt (beter) of scrypt (best). (Uiteraard moet hierbij nog steeds een unieke salt worden gebruikt.)

Meer informatie: How to securely hash passwords? – Information Security Stack Exchange

[Reactie gewijzigd door xrf op 23 juli 2024 15:06]

[StarZ]

Tja dat is natuurlijk leuk als je een nieuw systeem maakt, maar tegen de tijd dat het systeem af is de methodiek alweer verouderd en het veranderen van de hash/encrypt vaak niet te doen is blijven veel sites hangen op md5.

[Echron]

In PHP (vanaf 5.5) zit een API ingebakken om te zorgen dat een wachtwoord altijd met de laatste/beste hashing methode gehashed is. Enigste vereiste is uiteraard dat de klant af en toe inlogt anders word het wachtwoord niet "herhashed"
Meer info: http://php.net/manual/en/book.password.php

Ook bij andere talen is zijn gelijkaardige implementaties mogelijk. Maar dan moet de ontwikkelaar er wel de moeite voor nemen natuurlijk.

[Reactie gewijzigd door Echron op 29 juli 2024 12:25]

[HerrPino]

Dat is inderdaad een goede optie, maar zoals je al zegt moeten mensen daarvoor wel regelmatig inloggen. Leuk voor o.a. Tweakers, waar mensen actief zijn, maar voor een webshop waar mensen slechts zeer incidenteel inloggen werkt het niet goed. Automagisch rehashen is dan weer geen optie omdat je dan het wachtwoord zou moeten opslaan :-) Misschien is een optie om een eigen hashing algoritme te gebruiken (lees: zeer kleine aanpassing op een bestaande)

[Tribits]

Tja dat is natuurlijk leuk als je een nieuw systeem maakt, maar tegen de tijd dat het systeem af is de methodiek alweer verouderd en het veranderen van de hash/encrypt vaak niet te doen is blijven veel sites hangen op md5.

Zodra een gebruik inlogt heb je het plain tekst password te pakken en kan je per gebruiker overstappen van MD5 naar een nieuw hashing algoritme. Alleen nog even een vlaggetje zetten in de database dat die gebruiker van het nieuwe hashing algoritme gebruik maakt.

Overigens verbaast het me altijd dat iedereen zich altijd blind staart op dat hashing na een site hack. De hacker heeft zo ongeveer root toegang gekregen tot je systeem dus bestaat er altijd een risico dat ze ook op andere manieren wachtwoorden achterhaald hebben, tussen HTTPS en hashing staat het wachtwoord immers plain tekst in het server geheugen. Tevens vertragen goede hashes de tijd die nodig is om een wachtwoord te kraken aanzienlijk, maar ook niet meer dan dat. Je kan als site dus na een hack de veiligheid van de wachtwoorden niet garanderen en zal alsnog de gebruikers moeten vragen een nieuw wachtwoord in te stellen.

[Reactie gewijzigd door Tribits op 29 juli 2024 12:25]

[Rafe]

Hoe weet je dat 'de hacker zo ongeveer root toegang heeft gekregen'? Is SQL-injectie (OWASP #1) niet waarschijnlijker? Dan gaat de rest van je verhaal niet op.

Wachtwoorden zal je altijd moeten resetten, dat klopt. Maar de goede, langzame hashes maken het kraken wel een stuk vervelender dan het kleine half uur dat nodig was in 2011 om meer dan de helft van de kleine 400.000 passwordhashes te kraken. MD5+salt is echt niet meer van deze tijd.

[Reactie gewijzigd door Rafe op 29 juli 2024 12:25]

[Tribits]

Hoe weet je dat 'de hacker zo ongeveer root toegang heeft gekregen'? Is SQL-injectie (OWASP #1) niet waarschijnlijker? Dan gaat de rest van je verhaal niet op.

SQL injectie is inderdaad waarschijnlijker, maar aan de andere kant bestaat er ook wel een kans dat een complete database dump voldoende informatie bevat om ook op andere manieren toegang tot een systeem te krijgen. Daarnaast is kwetsbaarheid voor SQL injectie ook gewoon een teken dat je beveiliging niet op orde is. Vaak begint een hack met 1 (relatief onschuldig) lek en gaat de hacker vanaf dat punt verder. Ik blijf nieuwsberichten als 'onze volledige database ligt op straat maar verder zijn onze systemen veilig' toch altijd met gemengde gevoelens lezen.

Wachtwoorden zal je altijd moeten resetten, dat klopt. Maar de goede, langzame hashes maken het kraken wel een stuk vervelender dan het kleine half uur dat nodig was in 2011 om 200.000 passwordhashes te kraken. MD5+salt is echt niet meer van deze tijd.

Tsja, maar wat is het effect ervan? Je hebt een betere verdediging tegen een hacker die de hashes bemachtigt en dat niet openbaar maakt. Meer tijd dus om de hack zelf te ontdekken als beheerder. In dit geval maakt dat weinig uit omdat nu toch alle wachtwoorden ongeldig zijn verklaard.

Rest de bescherming van gebruikers die dezelfde wachtwoorden op meerdere plaatsen gebruiken. Dat is voor gebruikers misschien wat verraderlijk omdat ze nu denken dat hun wachtwoorden veilig zijn terwijl de hacker op zijn dooie akkertje kan proberen wat wachtwoorden uit die hashes te destilleren en die op andere sites los te laten.

[DutchReaper]

Je kan bij systemen die live zijn een extra kolom toevoegen die aangeeft welke encryptie versie erop gebruikt word. Zodra er dan een gebruiker inlogd heb je zijn wachtwoord en kan je die weer opslaan met een nieuwere en veiligere methode.

[GeoBeo]

Maar hoe goed is scrypt dan eigenlijk nog, nu er extreem efficiënte gespecialiseerde machines (100'en malen beter dan de beste videokaarten) verkocht worden voor scrypt crypto coin mining?

Scrypt coin mining komt volgens mij neer op het kraken van scrypt hashes?

One Alpha Viper running at 90MH/s is roughly the equivalent of a hundred Radeon R9 290X cards running on reference clocks.

90MH/s staat voor 90 mega hashes per second. 90 miljoen bruteforce attacks per seconde dus op een wachtwoord?

[Reactie gewijzigd door GeoBeo op 29 juli 2024 12:25]

[xrf]

Ik weet niet precies wat het verschil is, maar volgens de makers van wachtwoordkraaktool oclHashcat gebruikt Litecoin een beperkte versie van scrypt – dus niet de volledige versie

[Verwijderd]

Ze gebruiken waarschijnlijk Magento (ik zie het in de HTTP headers dat ze MageBoost.nl gebruiken). Wat zwak dat Magento nog MD5 gebruik.t Zowel SHA-1, SHA-2 als SHA-3 zijn idd oneindig veel beter (vooral de laatste twee). Hoeveel moeite kost het nou om dit om te bouwen?

[Reactie gewijzigd door Verwijderd op 29 juli 2024 12:25]

[thomasmoors]

De mail die ik gisteren kreeg:

Beste klant,

Bij een reguliere veiligheidscontrole is ontdekt dat wellicht onbevoegde personen toegang tot onze website hebben verkregen in de afgelopen 24 uur. Hierbij waren mogelijk klantgegevens bereikbaar.

We willen benadrukken dat wij nooit creditcard- of bankgegevens opslaan en dat de mogelijk kwetsbare data beperkt zijn gebleven tot naam, (email)adres en orderdetails.

Uit voorzorg hebben we veiligheidsmaatregelen getroffen en alle wachtwoorden van gebruikersaccounts ongeldig gemaakt. Als u een account bij ons heeft, kunt u met uw bestaande gebruikersnaam een nieuw wachtwoord aanmaken om weer toegang tot uw account te krijgen.

Onze oprechte excuses voor dit ongemak. Als u vragen heeft kunt u contact opnemen met onze klantenservice: [e-mail]

Met vriendelijke groet,
Signature Tijn van Elderen
Tijn van Elderen

[drogeworst]

De gedachte komt bij mij op dat internet security eigenlijk niet meer haalbaar is tegenwoordig. Als de Amerikaanse overheid al gehackt word, wat kan een kleine webshop als brabantia nog doen?

Hier is toch geen kruid tegen gewassen?

[MrEddy]

Nou ja, de mannen die de NSA onderuit kunnen halen hebben meestal geen interesse in een database van 100.000 Nederlandse NAW gegevens. Als je die kennis hebt, kan je daar veel interessantere dingen mee proberen te krijgen.

[drogeworst]

Absoluut. Maar als webshop(je) moet je onderhand onderkennen dat je veiligheid van het systeem op geen enkele manier meer kan waarborgen.

Wellicht dat je als laatste stap je systeem onderbrengen in de cloud van Amazon of Google de enige oplossing is om hackers buiten de deur te houden. De enige betaalbare oplossing bedoel ik dan

[cappie]

Wellicht dat je als laatste stap je systeem onderbrengen in de cloud van Amazon of Google de enige oplossing is om hackers buiten de deur te houden.

Dat heeft absoluut geen zin als het probleem in de code van je website zit... problemen van deze aard heb je net zo goed bij een cloudhoster als Amazon of Google.. Vaak zie je dat bij dit soort hacks er gebruik gemaakt wordt van foutieve uploadscripts, SQL injectie of andere bekende problemen in de code (achtergebleven en onbeveiligde debug / development code van de wat mindere webshop developers).

Het enige wat je kunt doen is het de hackers zo moeilijk mogelijk maken door alles af te schermen en je code zo min mogelijk benaderbaar te maken voor hackers, door bijvoorbeeld afscherming van API's, het admin gedeelte van je website (Wordpress hacks anyone?) of custom importers/data mutators die "oeps" nog geen wachtwoord beveiliging hebben.

Wat je wel kunt doen is van tevoren een security test-suite draaien die in ieder geval de basics doorneemt en je site doorscannen op beveiligheidsrisico's.

Aan source te zien draaien ze een Magento webshop ("Mage.Cookies.domain" op de voorpagina broncode) en hebben ze in de basis hun beveiliging goed... de server is goed gefirewalled, niet benaderbaar met SSH, het admin-gedeelte van de site is geblokkeerd of in ieder geval hernoemd...

Het enige wat ik kan zeggen is 'shit happens'... gelukkig was het Magento; voor zover ik weet maakt Magento gebruik van salted passwords en zijn de wachtwoorden hierdoor niet tegen een rainbow table aan te houden waardoor de bezoekers van de site hoogstwaarschijnlijk helemaal geen risico lopen.

Wel netjes van het om het zo op te lossen in ieder geval... veel beter hadden ze het niet kunnen doen.

[Reactie gewijzigd door cappie op 29 juli 2024 12:25]

[drogeworst]

Achter de webshop van brabantia zit toch geen one man band die de beveiliging niet op orde heeft? Ik kan het mij bijna niet voorstellen. Daarvoor is brabantia weer te groot.

[cappie]

Groot, schmoot.. ze zijn geen Bol, Wehkamp of Amazon.. andere partijen die groter zijn worden ook gehacked.. groot zijn betekent niet dat je je zaken automatisch goed op orde hebt... het enige wat echt werkt is je code door een vulnerability suite trekken en scannen op bestaande exploits en bekende manieren van hacken (server hacks (bekende exploits), code/sql injection, etc.), maar zelfs dan nog kan het zijn dat je dingen over het hoofd ziet... één foutje in de code op de verkeerde plek en je kunt gehacked worden.

Het lijkt me trouwens niet dat de site 100% in-house ontwikkeld is; ze maken op z'n minst gebruik van freelancers, google maar eens op 'magento brabantia'.

My point being: externe programmeurs werken met deadlines en moeten hun projecten binnen de minst aantal uren opleveren.. voor het doen van goede security scans is een stuk expertise nodig + een hele berg uren en extra onkosten, en dat hebben de meeste magento bouwers zelf niet omdat 't niet hun core business is.

[Reactie gewijzigd door cappie op 29 juli 2024 12:25]

[Verwijderd]

Het is gewoon prijs / kwaliteit. Daarnaast verwacht je dat een programmeur security expert is, in mijn ogen toch echt een andere functie, systeembeheer is dat toch ook!

[twilex]

Een groot bedrijf betekent geenszins dat ze al hun zaken goed op orde hebben.

[FreshMaker]

Absoluut. Maar als webshop(je) moet je onderhand onderkennen dat je veiligheid van het systeem op geen enkele manier meer kan waarborgen.

Ik kreeg het verzoek om voor een kennis de webshop op te zetten, en te onderhouden.
"jij kent de weg op internet" waren zijn woorden daarbij, alsof hij me een plezier wilde doen.

Via een paar google's hem laten zien dat hij toch beter af is met een ( grotere ) partij die hem degelijk kan helpen, en garantie kan geven op 'veiligheid'
Ik kon hem dat niet bieden, die paar centen die hij er voor ( mij ) voor over had, wegen niet op tegen de verantwoording en uiteindelijke problemen.

[n8n]

Netjes dat je deze klant - met het risico dat ze een andere 'internetkenner' de opdracht geven - verwijst naar een bureau met de expertise. Daar kan menig webbedrijf wat van leren dat volmondig ja zegt op alles wat voorbij komt.

[drogeworst]

Kijk dat vind ik nog eens een eerlijke reactie.

Zo is het idd.

[eborn]

Daarnaast: Amazon regelt voor jou niet de beveiliging van de virtuele machine. Dat moet je toch echt zelf doen. Misschien dat bepaalde attacks automatisch worden ondervangen (wat ik betwijfel). Maar Amazon is toch echt maar een service provider en geen server manager.

[cappie]

Je had het niet beter kunnen verwoorden... de security van je website is voor 50% afhankelijk van de beheerder van de server en voor 50% van de bouwer van je website.

Hopelijk is dat niet 1 en dezelfde persoon, tenzij hij/zij echt briljant is, want daar is simpelweg teveel kennis voor nodig... ik zou die persoon in ieder geval niet willen zijn

[Reactie gewijzigd door cappie op 29 juli 2024 12:25]

[Armin]

De enige betaalbare oplossing bedoel ik dan

Eens!

Immers, juist dat alles zelf willen doen levert zaken op als anno 2015 nog MD5 als hash gebruiken. En zelfs als het een salt is, maakt dat nog niet veel uit, tenzij het wellicht een unieke salt per wachtwoord is natuurlijk. Maar dan nog is MD5 niet echt ideaal omdat het zo makkelijk uit te rekenen is met goedkope hardware.

Tegenwoordig verwacht je algorithmen als bcrypt of meervoudige hashes zoals PBKDF2. Die laatste heeft als voordeel dat je het door de tijd kunt updaten (sterker maken) zonder dat de gebruiker zijn wachtwoord hoeft te wijzigen.

Persoonlijk klop ik nergens meer mijn financiele gegevens in een kleine webshop, tenzij de betaling ge-outsourced is naar een groter bedrijf zoals PayPal of Amazon.

Maar goed, op zich is het gestolen worden van de gegeven bij Babrantia natuurlijk niet noodzakelijk een ramp als de gebruiker een uniek wachtwoord gebruikt heeft, en niet dezelfde als bij de email, facebook, etc. Ik ga er persoonlijk standaard vanuit dat alles wat ik inklop bij zo'n kleine site binnen 2 a 3 jaar gestolen is.

[SED]

Die kleine webshop gegevens kunnen waardevol zijn juist in het kader van een verdergaande phising gericht op specifieke gebruikers. Men kan zo veel relatief gemakkelijk toegankelijke data verzamelen en snel gerichte phising opzetten.
Stel je bent medewerker van defensie en ontvangt een mail van Brabantia waarin men melding doet dat het recent gekochte product gecontroleerd moet worden. Je wordt verleid tot he tinloggen op een website die zogenmaamd je serienummer controleert en voila.. je hebt een trojan. Of nog simpeler je moet een controleprogramma installeren dat meteen je computer besmet.. de mogelijkheden zijn eindeloos. Allemaal dankzij een simpel te verkrijgen gerichte dataset.
Matchen van interessante personen met die vele datasets die rondwaren en je hebt een eindeloze hoeveelheid potentieel zinvolle data.

[gjmi]

Nou ja, medewerkers van belangrijke instituten kopen ook bij kleine webshops. En aangezien mensen graag 1 wachtwoord hebben voor alles, of tenminste iets wat op elkaar lijkt....
Dus het is misschien juist wel interessant om data van "makkelijk" te hacken webshops te hebben.

[moijamie]

Gehacked worden heeft niks met de grote te maken. Tuurlijk de amerikaanse overheid heeft een groter budget voor de beveiliging, maar ze hebben ook veel meer te beveiligen. Een relatief kleine webshop kan heel makkelijk zich zelf beveiligen tegen 99,8% van de hacks die erop uitgevoerd gaan worden. Maar als jij die webshop laat maken door iemand met niet zo veel verstand over wat hij precies aan het doen is en zich niet beveiligd tegen SQLI,XSS,XSRF etc... is het kinder spel deze websites te hacken. Zelfde geld voor bedrijven die zijn website niet update en 10 jaar oude code maar lekker laat draaien want het werkt toch.

[Armin]

Verschil is wel dat die grote bedrijven doorgaans enkel gehacked worden door nation states of criminele bedrijven met budgetten van miljoenen. hacks zjin vaak maandenlang vorobereid en langzaam stap voor stap uitgevoerd. Niets of niemand is daar tegen bestand is al enige tijd het devies in de security wereld.

Enkel verschillende lagen van beveiliging met vooral 'inbraak detectie' om ze na de eerste of tweede laag te ontdekken zijn dan effectief. Ofwel, gevolgen beperken en tijd winnen zodat je het gat kunt dichten voor men bij de kroonjuwelen is.

Klein websites worden doorgaans gewoon gehacked via een niet gepatchde server of zo.

[cappie]

Er zijn complete bedrijven die security audits voor je kunnen doen waar ex-hackers of programmeurs in dienst zijn die weten hoe je exploits misbruikt... maar dat kost geld.. en dat geld moet je er voor over hebben als bedrijf zijnde.

[SED]

En dat helpt beslsist maar is weer een momentopname. Een programmaupdate later kan het speelveld alweer anders zijn.
Voorbeeld:
En je hebt net een dure pentest laten doen en dan komt de openssl bug uit.

Kortom, ook dat soort stappen geeft geen garanties: die bestaan niet.

[micje]

Inderdaad net een mailtje van Brabantia gehad. Ze hebben de wachtwoorden gereset; nu kan ik dus niet meer nagaan welk wachtwoord ik daar destijds heb gebruikt (gebruik tegenwoordig 1password, maar toen nog niet.), en welke email/password combi's kwetsbaar zijn.

Wel een vermoeden – ga mijn funda en trello wachtwoorden maar eens wijzigen in iets unieks.

[SED]

Jij bent dus kennelijk een van die gebruikers die hetzelfde wachtwoord gebruikt op verschillende sites.
Tip: http://veiligwachtwoord.uwpc.info/stappenplan.htm

[Miepermans]

Slim om hier dan te zeggen op welke andere soort sites je eenzelfde wachtwoord gebruikt.

Dit is nu precies het issue, Mensen ( ja ik generaliseer ) zien het gevaar niet van hetzelfde wachtwoord gebruiker, terwijl ze aan de andere kant vrij makkelijk zich uitlaten over waar een soortgelijk wachtwoord dan van toepassing kan zijn.

Ik heb vroeger altijd met een gradatie systeem gewerkt, sociale netwerken een relatief simpel password, bankzaken een moeilijk password en overheidszaken een nog moeilijker wachtwoord. Best een leuk systeem, maar als ik de logica hierachter kan bedenken kunnen kwaadwillenden dat ook.

Nu is het een gevalletje van password managers en een goed geheugen om kansloos lange wachtwoorden op te slaan. Dat kost in het begin misschien wat moeite, maar het geeft voldoening als je een 20 karakter wachtwoord uit je hoofd in kunt rammen. ( vroeger deed ik mijn 32 karakter lange wpa1 keys al uit het blote hoofd ).

[rijnsoft]

Namen en addressen zijn niet zo interessant. Ik kan je zo 1 miljoen namen en addressen leveren, zonder ook maar iets te hacken, die gegevens kun je overal vinden.

De fout, die veel webshop nog steeds maken, is dat ze klanten zelf wachtwoorden laten kiezen. Klanten zijn lui en gebruiken dus vaak dezelfde wachtwoorden. Als je de wachtwoorden dus weet te ontcijferen, en je hebt ook het mail adres, dan heb je wel iets krachtigs in handen. Ga ermee naar Facebook, Twitter, en je leert meer over de persoon. Dan kun je een geavanceerdere aanval op gaan zetten.

[Maruten]

Sorry, maar ik ken geen enkele dienst waarbij je niet je eigen wachtwoord mag kiezen. Niet overal hetzelfde wachtwoord gebruiken is toch één van de basisregels van internetgebruik, dus de verantwoording hiervoor zou altijd bij de gebruiker moeten liggen.

[prutsr]

Zelf als je iedereen een gegenereerd wachtwoord geeft schrijven ze dit op in een word documentje of kladblokje... gaat de veiligheid niet echt te goeden.
Voor mij geldt: 1 wachtwoord voor alle meuk & voor belangrijke dingen een ander WW voor alles

[cappie]

Ik snap niet dat mensen altijd zo moeilijk doen over wachtwoorden...

Wachtwoorden zoals HJk472fgG zijn door een computer zo te kraken maar door een mens niet te onthouden... je zou beter voor iedere site een uniek wachtwoorde kunnen verzinnen wat nog simpel te onthouden is ook:

• Tweakers.net: VeiligWachtwoordMet1GetalVoorTweakers.net?
• Gmail.com: IkHebGeenIdeeWatMijnGmailWachtwoordMet1GetalNuIs!
• ((recovery) mailboxes altijd uniek maken, dus ook niet volgens je eigen wachtwoord-schema)
• Facebook.com: VeiligWachtwoordMet1GetalVoorFacebook.com?
• Twitter.com: VeiligWachtwoordMet1GetalVoorTwitter.com?

Kijk voor de grap maar eens op https://howsecureismypassword.net/ en vul daar maar een wachtwoord in wat lijkt op het jouwe.. (of je echte wachtwoord als je gelooft dat websites alleen via HTTP requests data kunnen doorsturen) ... probeer daarna maar eens een van de bovenstaande wachtwoorden die ik net heb verzonnen

Ze mogen dan welliswaar belachelijk lang zijn, maar tevens ook vrijwel niet brute-force te kraken (tenzij je natuurlijk met dictionary combinations aan de slag gaat, maar dan nog.. in ieder geval een stuk veiliger dan die geboortedatum met 3 voorletters van je moeder).

[Reactie gewijzigd door cappie op 29 juli 2024 12:25]

[Armin]

Wachtwoorden zoals HJk472fgG zijn door een computer zo te kraken maar door een mens niet te onthouden

Juist niet. Jouw voorbeeld is 9 tekens, maar zou je dat 14 tekens of zo maken is het juist onmogelijk te kraken met computers, terwijl jouw lange wachtwoorden een fluitje van een cent zijn.

Bijvoorbeeld jouw "VeiligWachtwoordMet1GetalVoorTweakers.net?" is amper 10 tekens sterk, en met zijn voorspelbaar hoofdletter gebruik waarschijnlijk eerder gekraakt dan jouw 9-cijferig eerder voorbeeld.

Anno 2015 moet een wachtwoord niet voorspelbaar zijn. Computer gegenereerde random reeksen zijn het meest veilig mits ze een bepaalde minimale lengte hebben om brute force tegen te gaan. Afhankelijk van het gebruikte opslag-mechanisme spreken we dan in de orde van 10 a 14 tekens.

Dat is wellicht lastig te onthouden, doch niet zo lastig als je wellicht denkt. Na het een paar keer intoetsen kunnen de meest mensen dit soort reeksen verrassend goed onthouden. Niet veel anders dan zo'n lange zin.

Merk tenslotte op dat die lange zin, uiteindelijk gereduceert wordt tot een hash van doorgaans maar 160 bit en dus 20 tekens. Wachtwoorden langer dan 20 tekens geeft dus geen veiligheid, en zelfs een risico indien je zoals in jouw voorbeelden patronen gebruikt.

Voor de meeste mensen is het volgende advies veel belangrijker:
- gebruik unieke wachtwoorden. ja echt nooit password recycling!
- maak vooral de wachtwoorden van je email, facebook en bank sterk. Zet je over het 'moeilijk onthouden' heen want dat handjevol gaat echt lukken.
- al het andere is 12 tekens met niet al te veel patroon doorgaans genoeg mits je niet teveel private info in die accounts zet. Het patroon is het meest relevante, dus niet "MijnWoord1985!" want dat is effectief maar 4 tekens sterk.

[cappie]

Ondanks het feit dat mijn makkelijk leesbare wachtwoorden wellicht met een dictionary attack makkelijk te kraken zouden zijn vraag ik me af of je echt kunt zeggen dat een uniek wachtwoord per site makkelijker te kraken is dan een wachtwoord wat uit 14 random karakters bestaat...

Heb je voorbeelden van code + dictionary files die aantonen dat het ook daadwerkelijk slechter is om een zin bestaande uit meer letters te gebruiken dan een kortere reeks (korter dan 20 karakters) random karakters?

Ben wel benieuwd eigenlijk.. want alhoewel mijn eigen moeilijke wachtwoorden meer lijken op stukken van woorden in combinatie met bewegingen op het toetsenbord (moet ze altijd in m'n hoofd 'natypen' om er zeker van te zijn dat ik 't niet fout typ) en random cijfers en leestekens, ben ik wel op zoek naar een manier om gemakkelijker ook voor de wat minder belangrijke sites/services unieke wachtwoorden te gebruiken (zonder password manager).

[Armin]

echt kunt zeggen dat een uniek wachtwoord per site makkelijker te kraken is dan een wachtwoord wat uit 14 random karakters bestaat...

Ik denk ook niet dat dat waar is.

Maar dat zeg ik dan ook niet. Ik zeg dat een random 14 karakter wachtwoord (wat impliciet uniek is) moeilijker te kraken is dan jouw (eveneens unieke daar niet van) lange wachtwoorden omdat die laatste een patroon hebben.

Alles boven ruwweg 10-14 is onkraakbaar met brute force. Dus zodra je die lengte hebt moet je je gaan richten op andere zaken, in het bijzonder geen patronen. Jouw lange wachtwoorden hadden echter niet enkel patronen, maar ook nog eens makkelijke patronen en zijn dus aanzienlijk minder veilig dan je wellicht dacht.

Heb je voorbeelden van code + dictionary files die aantonen dat het ook daadwerkelijk slechter is om een zin bestaande uit meer letters te gebruiken dan een kortere reeks (korter dan 20 karakters) random karakters?

Ars Technica heeft een aantal artikelen gehad over password kraken, waarin vooral het punt naar buiten kwam dat men patronen gebruikte op basis van ervaring.

Alles wat jij kunt bedenken qua slim patroon heeft een ander ook al eens bedacht. En aangezien er al miljarden wachtwoorden gelekt zijn enkel de laatste 2 a 3 jaar, moet je er vanuit gaan dat die patronen al verwerkt zijn in wachtwoord krakers.

Uiteraard hoeft een wachtwoord enkel zo sterk te zijn als de data die er achter zit, dus zo'n verplicht 'onzin' uitcheck account bij een website, mag best een patroon hebben begrijp me niet verkeerd. Maar als het echt belangrijk is, is een lang genoeg, doch echt random wachtwoord verreweg superieur aan een veel langere zin met patronen zodat het makkelijker te onthouden is.

[Plopeye]

Wachtwoorden van 10 to 14 karakters zijn een eitje indien de salt ontbreekt...

Enkel als Bcrypt of Scrypt zijn gebruikt zou dit afdoende zijn. Deze methodes zijn nog steeds traag ook al gebruik je grafische kaarten. De meeste andere methodes zijn met een beetje grafische kaart in no time te brute forcen... 1,4 miljard hashes per minuut zijn dan geen probleem, met een lengte van 10 kan je zelf uitrekenen hoeveel mogelijkheden dat dit geeft en hoe lang het maximaal duurt bij 1,4 miljard per minuut... waarschijnlijk blijf je makkelijk binnen het uur... heb je een betere SLI opstelling dan kan het nog sneller...

[MadEgg]

Prima, dan rekenen we toch even uit hoe lang dat maximaal duurt?

10 karakters uit een set van 26 hoofdletters, 26 kleine letters, 10 getallen en 10 symbolen (dus 72 verschillende mogelijkheden per karakter) geeft met:

8 karakters: 72^8 = 722 biljoen combinaties
10 karakters: 72^10 = 374 biljard combinaties
12 karakters: 72^12 = 19 triljard combinaties
14 karakters: 72^14 = 10 quadriljoen combinaties

Ik ga er om het nog behapbaar te maken vanuit dat daar waar jij 1,4 miljard hashes per minuut schrijft, je 1,4 miljard hashes per seconde gebeurt.

Voor 8 karakters kom je dan op 722 biljoen / 1,4 miljard hashes per seconde / 86400 seconden in een dag = een kleine 6 dagen om ze allemaal te proberen.

Voor 10 karakters kom je dan op 364 biljard / 1,4 miljard / 86400 / 365 dagen in een jaar = 84.8 jaar

Voor 12 karakters: 19 triljard / 1,4 miljard / 86400 / 365 / 1000 jaren in een millenium = 439 millenia

Voor 14 karakters: 10 quadriljoen / 1,4 miljard / 86400 / 365 / 1000000000 jaren in een giga-annum: 2,27 Ga.

Succes met kraken. 8 karakters is haalbaar, 10 kun je vergeten maar is mogelijk in de toekomst nog wel te doen met fors betere hardware. Daarboven gaat het gewoon nooit wat worden.

[Armin]

Wachtwoorden van 10 to 14 karakters zijn een eitje indien de salt ontbreekt...

Indien een salt ontbreekt en met enkel een enkelvoudige hash gebruikt heb je gelijk dat het zwak is. Zeker als dat MD5 is. Maar het kraken zoals MaddEgg voorrekent (what's in a name ) is nog steeds aanzienlijk langer dan de tijd dat het duurt een eitje te koken indien er enige moeite gedaan wordt.

Nu zal men bij saltless hashes wellicht standaard tabellen gebruiken, maar daarom moet het ook computer genegereerd random zijn.

Dus indien er enige moeite gedaan is, zoals een meervoudige hash of een unieke salt, zit je met de reeks 10-14 normaal goed. Merk op dat ik express zo'n brede range gaf omdat het juist inderdaad afhankelijk van het gebruikte algorithme is.

[Reactie gewijzigd door Armin op 29 juli 2024 12:25]

[Teckna]

Uiteindelijk is een 8 tekens dat een wachtwoord gemiddeld lang is gewoon zo gekraakt. En dan is het gebruik van een (verschillende) passphrase altijd beter om mensen aan te leren dan een random wachtwoord te gaan onthouden.

Overigens komt er nog een shitstorm qua beveiliging aan zodra kwantumcomputers een feit zijn.

Tegenwoordig vul ik gewoon wat randoms in bij webshops ed. Ik maak wel gebruik van de password reset functie als ik het ooit weer nodig zou hebben.

[MadEgg]

Overdrijven is ook een vak. De snelheid waarmee je een wachtwoord kan kraken is afhankelijk van de lengte en het gebruikte algoritme. Er zijn voorbeelden van het kraken van 8-karakter-wachtwoorden in enkele uren, met eenvoudige algoritmes. Dat is dus sowieso al niet "zo gekraakt", en bovendien kun je bijvoorbeeld complexere algoritmes als blowfish gebruiken waardoor het aanmerkelijk langer wordt.

Gooi je er nog 1 a 2 karakters bovenop (~70x70 keer zo lang om te kraken dus), dan is het al helemaal niet haalbaar om met hedendaagse apparatuur te kraken. Tenminste, het is wel te kraken maar het is niet interessant tenzij je daarmee een enorme slag kunt slaan (de goudvoorraad van Nederland binnenharken of iets in die trant). Maak je het nog langer dan 10 karakters dan wordt het met wat voor apparatuur dan ook compleet onkraakbaar, er zijn dan gewoon té veel combinaties mogelijk.

Om dat met passphrases te evenaren moet je enorm lange zinnen gebruiken waarbij de woorden geen zin volgens maar compleet losstaand zijn.

[cappie]

Ok, heb je nog tips voor de gemiddelde computergebruiker dan om z'n wachtwoorden veilig te maken anders dan een apart wachtwoord voor z'n primaire email, bank, digid en facebook?

Want password managers maken 't ook gemakkelijker voor hackers.. net zoals zelfgebouwde oplossingen..

[Youckle]

Wanneer je niet overal het zelfde e-mailadres gebruikt, dan ben je ook lastiger te koppelen.
Gewoon een uniek e-mailadres per site bedoel ik.

[Reactie gewijzigd door Youckle op 29 juli 2024 12:25]

[EzMe]

Ik ga toch met cappie mee. Het is niet het type tekens wat een password moeilijk maakt maar de hoeveelheid daarvan. Deze cartoon legt het mijn inziens goed uit: http://xkcd.com/936/

[Armin]

Alleen is die cartoon dus achterhaald omdat ze aanneemt dat men brute force kraakt. Dat was 5 a 6 jaar geleden zo, maar tegenwoordig niet meer. Juist omdat mensen nu geleerd hebben langere wachtwoorden te gebruiken met een leesteken en een hoofdletter.

Probleem is namelijk dat mensen dat leesteken en en die hoofdletters vaak heel voorspelbaar doen. Via machine learning en statistische tabellen hebben de criminelen en hackers vastgesteld welke patronen vaak gebruikt worden, en hun methoden aangepast. Zij hebben de afgelopen paar jaar namelijk talloze password databases kunnen inzien en zo geleerd wat mensen als wachtwoord kiezen.

Als het écht veilig moet zijn is enkel it veilig: computer gegerereerd en minstens 10 a 14 tekens lang.

[rijnsoft]

Dat iedereen het doet en daarom goed zou zijn, wat jij een beetje lijkt te impliceren, lijkt mij geen correcte redenering. Er zijn zat dingen die iedereen doet, maar beter niet zou kunnen doen.

Ja, verschillende wachtwoorden kiezen zou je van gebruikers mogen verwachten, maar helaas, het gebeurt niet. En de complexiteit van de wachtwoorden valt ook vaak erg tegen. Website makers gaan gebruikers dan lastig vallen met allerlei regels waaraan een wachtwoord moet voldoen, en dat maakt het er niet makkelijker op.

Ik zeg niet dat ik een betere oplossing weet, zoals het wachtwoord voor de gebruiker kiezen, want dan zit je met het probleem hoe je dit wachtwoord bij de gebruiker krijgt. Een email is niet echt veilig te noemen. Op het scherm laten zien? Ook niet zo handig. Maar dat wachtwoorden ondingen zijn mag duidelijk zijn.

Banken hebben het, wat dat betreft, vaak beter voor elkaar. Zij gebruiken een stukje hardware (pasje, telefoon) om de gebruiker te indentificeren.

[Reactie gewijzigd door rijnsoft op 29 juli 2024 12:25]

[Adm.Spock]

Two-factor maakt het idd al een stuk lastiger, en is tegenwoordig vrij eenvoudig te implementeren via een pam module op de server.

[Verwijderd]

Snap de redenatie niet helemaal qua klanten aantal. Normaal ben je trots op de hoeveelheid klanten. Klinkt dan meer als een downplay poging.

[Verwijderd]

Snap de redenatie niet helemaal qua klanten aantal. Normaal ben je trots op de hoeveelheid klanten. Klinkt dan meer als een downplay poging.

Mogelijk dat het er minder zijn dan verwacht c.q. Brabantia zich wenst.

Deze opmerking

Het zijn er in ieder geval 'zeker wel honderdduizend', niet alleen in Nederland, maar ook een aantal andere Europese landen.

geeft me ook dat gevoel.

Op zich niets om over te schamen voor ene niet IT bedrijf waarvan veel kopers niet of weinig of het internet te vinden zullen zijn.

[Huaw]

Bedenk wel dat Brabantia veel offline verkoopt.
Ik zou bijv. Niet de moeite nemen om te kijken wat voor prullenbakken er zoal te koop zijn.
Dus het aantal acc's is zeker kleiner als het aantal klanten

[Rob_03]

Exacte cijfers zijn "helaas" cijfers die van invloed zijn op je onderhandelingspositie in verkoop.

'zeker wel honderdduizend' kan 1, 2 ,3 ... 9 zijn. Het is dan aan de inkopende partij om zelf te bepalen hoe "gevoelsmatig" populair een product is en of hij er wat mee wil doen en vooral tegen welke inkoop prijs.

Een AH, Blokker etc zal een hogere inkoopprijs accepteren als het gevoel is dat er een 800K webshop kopers zijn dan wanneer er een 110K zijn.

[MrEddy]

"Dat zou betekenen dat ik moet zeggen hoeveel klanten we hebben, en dat gaat me iets te ver"
Apart om dat niet gewoon te zeggen, ik zie niet wat daar zo vertrouwelijk aan is. Vervelend dat dit gebeurd, maar goed dat het duidelijk word verteld tegen de klanten.

[Viriya]

Een bedrijf is groter dan 1 persoon en misschien wilde hij wel graag Tweakers ten woord staan maar niet informatie delen dat gevoelig kan liggen.

[MrEddy]

Ik denk dat een directeur toch wel op de hoogte is van wat er wel en niet naar buiten mag worden gebracht.

[FreshMaker]

Klantenbestanden ( hoeveelheden ) is vaak vertrouwelijk/gevoelig , dat soort informatie kan ( geheime ) overname of fusiebesprekingen toch aardig in de weg staan.

Wij vertelden aan de telefoon tegen mensen, die zich niet konden melden op de juiste manier dat we 'zoveel 1000' klanten hebben, en dus niet op naam / adres mogen zoeken.
Vrij vlot erna werd toch wel duidelijk medegedeeld dat we dat niet meer mochten doen ...

[cappie]

Net wat hierboven al gezegd wordt, verkoopcijfers zijn bepalend voor inkoopsprijzen... het zal me verbazen als ze er veel meer of minder hebben maar dat niet willen zeggen vanwege afspraken met retailorganisaties... ik vind 't al heel wat dat ze uberhaupt iets zeggen over het aantal klanten.

[BaRF]

Ik heb in december een nieuw slotje besteld voor onze afvalbak, en ik heb geen mailtje gekregen. Wellicht dat niet alle klantgegevens zijn gestolen?

[cappie]

.. ik zie niet wat daar zo vertrouwelijk aan is..

Jij bent dan ook geen CEO, sales opperhoofd, CTO, of CSO bij Brabantia

[PixelPhobiac]

Clef en Passcard zijn wel wel interessante initiatieven.

[Rafe]

Of de FIDO Alliance U2F-usb sticks, oa door Yubikey gemaakt en onder ondersteund door Google en MS met Windows 10.

[mutley69]

Zelf hanteer ik een regel - elke site een apart wachtwoord - en geen systeem er in!

[RobinJ1995]

Security was dus niet in orde. Organisatie zelf verantwoordelijk stellen en schadevergoeding aan de gebruikers wiens gegevens gelekt zijn. Anders gaan organisaties blijkbaar nooit leren dat ze hun gebruikers de das omdoen als hun beveiliging niet in orde is.