Twitter sloeg wachtwoorden door bug onversleuteld op

Twitter waarschuwt dat het door een bug wachtwoorden tijdelijk onversleuteld opsloeg in interne logs. Hoewel de dienst geen aanwijzingen heeft dat de logs door onbevoegden zijn benaderd, luidt het advies dat iedere gebruiker zijn wachtwoord moet wijzigen.

Twitter meldt de bug 'recent' ontdekt te hebben. De dienst meldt niet hoeveel wachtwoorden onversleuteld waren opgeslagen en hoelang ze als zodanig in de interne logs stonden. Twitter maakte recent bekend in totaal 267 miljoen maandelijks actieve gebruikers te hebben.

Omdat Twitter geen aanwijzingen heeft dat zijn servers door onbevoegden zijn binnengedrongen of dat de logs misbruikt zijn, heeft de dienst wachtwoorden geen reset gegeven. Het bedrijf raadt gebruikers als voorzorgsmaatregel aan 'te overwegen' om hun wachtwoorden te veranderen, ook bij diensten waar ze hetzelfde wachtwoord gebruiken, mocht dat het geval zijn.

Twitter deed de mededeling donderdagavond. De eerste donderdag van mei is door sommige partijen uitgeroepen tot Password Day, om mensen bewust te maken van het hebben van een goed wachtwoordbeleid.

Reacties (117)

[Luftbanana]

De betreffende email van Twitter:

Twitter

Hi @**********

When you set a password for your Twitter account, we use technology that masks it so no one at the company can see it. We recently identified a bug that stored passwords unmasked in an internal log. We have fixed the bug, and our investigation shows no indication of breach or misuse by anyone.

Out of an abundance of caution, we ask that you consider changing your password on all services where you’ve used this password. You can change your Twitter password anytime by going to the password settings page.

About The Bug

We mask passwords through a process called hashing using a function known as bcrypt, which replaces the actual password with a random set of numbers and letters that are stored in Twitter's system. This allows our systems to validate your account credentials without revealing your password. This is an industry standard.

Due to a bug, passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again.

Tips on Account Security

Again, although we have no reason to believe password information ever left Twitter's systems or was misused by anyone, there are a few steps you can take to help us keep your account safe:

1. Change your password on Twitter and on any other service where you may have used the same password.
2. Use a strong password that you don't reuse on other services.
3. Enable login verification, also known as two factor authentication. This is the single best action you can take to increase your account security.
4. Use a password manager to make sure you're using strong, unique passwords everywhere.

We are very sorry this happened. We recognize and appreciate the trust you place in us, and are committed to earning that trust every day.

Team Twitter

[CH4OS]

Wel dan weer jammer dat men in het bericht vervolgens gaat aangeven om welk hashing encryption algoritme het gaat. Dat had mijns inziens niet gehoeven en het merendeel van de gebruikers zal toch ook niet begrijpen wat het is.

Niet dat bcrypt nu zo makkelijk terug te halen is (op het moment geloof ik zelfs niet), maar door prijs te geven welke sloten op je deuren zitten, is het wel interessanter voor kwaadwillenden geworden en gebruikers zijn door deze nalatigheid van Twitter wel de dupe geworden hiervan.

[Reactie gewijzigd door CH4OS op 23 juli 2024 06:11]

[GrooV]

Nee bedrijven moeten juist open zijn over hun security en hoe ze met onze wachtwoorden omgaan. Op dit moment (en dat zal nog wel even zo blijven) is bcrypt een van de veiligste algoritmes die er zijn, en dat hoeft niet geheim te zijn. Daarnaast heeft bcrypt gewoon een prefix waardoor je bij het zien van de hash al weet dat het bcrypt is. Zie eerst maar eens binnen te komen bij Twitter en dan kan je pas druk gaan maken over welk algoritme ze gebruiken (wat je dan al ziet door de prefix)

Er zijn tegenwoordig veel te veel data lekken en ook in 2018 maken sites nog gebruik van brakke algoritmes of uberhaupt plain-text wachtwoorden. Dat twitter juist aangeeft een van de beste algoritmes te gebruiken siert ze alleen maar

Security through obscurity is geen security

[Anoniem: 167912]

Security through obscurity is geen security

ik hoor dat hier wel vaker, maar ik zie werkelijk niet in waarom iedereen al zijn beveiligingsmaatregelen zomaar openbaar moet maken.
Een bank zegt toch ook niet welke fabrikant de kluizen maakt en waar de beveiligingscameras hangen?
Er is niets mis met een extra beveiliging die niet openbaar gemaakt wordt.

[GrooV]

Je vergelijkingen slaan nergens op maar goed. Bij een bank hangen gewoon zichtbare camera's, en kom met een bak geld aan en de bank verteld graag welke maatregelen ze nemen.

Bij de FED in New york krijg je zelfs een rondleiding door hun gouddepot en onze waarde transport auto's zijn hartstikke herkenbaar.


Twitter en Github laten maar een klein stukje van hun beveiliging zien, er zijn nog ontelbare andere maatregelen. Juist dit stukje is relevant voor ons

[Reactie gewijzigd door GrooV op 23 juli 2024 06:11]

[supersnathan94]

onze waarde transport auto's zijn hartstikke herkenbaar.

Laat dat nou net een puntje zijn waar ik dan van denk misschien is dat niet zo slim. Laat daar security through obscurity nou net wel handig kunnen zijn. Ik denk dat veel van ons “The Italian Job” wel kennen. Als ze daar security through obscurity wel goed hadden gedaan was de film heel anders afgelopen .

[Jerie]

Als is mosterd na de maaltijd.

Iedere maatregel heeft consequenties. Waardetransport aanduiden als zodanig heeft voor- en nadelen.

[Bor]

Onzin. Een bank verteld je ook niet in detail welke risocobeperkende maatregelen en security measures er zijn. Detailplannen geven informatie weg waar een eventuele aanvaller gebruik van kan maken.

Dat is waardetransport herkenbaar is is een security maatregel en ook de Fed laat zijn maatregelen echt niet allemaal zien. Wat jij als publiek krijgt te zien is maar een beperkt deel.

[Reactie gewijzigd door Bor op 23 juli 2024 06:11]

[GrooV]

Twitter laat toch ook niet alles zien, waar gaat deze discussie over zeg

[Anoniem: 167912]

Waarom mijn vergelijkingen nergens op zouden slaan is me niet heel duidelijk, maar als je toch niet in security through obscurity gelooft zit je er vast niet mee in om me je paswoord en pincode te geven?

[Anoniem: 80910]

Ik snap wel dat twitter dat meldt. bcrypt hashen met een random salt en een cost van 11 of 12 waarschijnlijk. Bruteforcen op een match is kosten technisch onrendabel. en zeg nou zelf het is twitter, niet je bankrekening die geplunderd kan worden...

[AJM94]

Dus, ik 'hack' jouw Twitter account en verspreid er kinderporno mee.

Ik denk dat je de consequenties onderschat. Het is een stukje identiteitsdiefstal waarmee je geconfronteerd wordt op het moment dat het gebeurt.

[Anoniem: 656038]

Ik denk niet dat raxon de consequenties onderschat, ik denk eerder dat jij onderschat wat het volgens hem technisch onrendabel maakt.

Je gaat geen wachtwoord kraken dat encrypted is op deze manier.
En al zeker geen twitter account.

Niet omdat het theoretisch niet kan, maar omdat het ver van realistisch is.

[AJM94]

Ik reageer op het "zeg nou zelf het is Twitter", niet op het technisch onrendabele aspect

Ik zeg met "op het moment dat het gebeurt" ook niet dat het realistisch is.

[Reactie gewijzigd door AJM94 op 23 juli 2024 06:11]

[Bensimpel]

Laat er nou tegenwoordig een president zijn die zomaar een oorlog kan starten op twitter.

[gorgi_19]

Zeggen dat er beveiligingsmaatregelen zijn, welke het zijn en dat ze ge-audit is meer dan logisch; in het bedrijfsleven is het ook een vrij gangbare zaak om dit te vragen. Hoe ze exact in detail geimplementeerd zijn is een ander verhaal.

Een bank zegt wel dat de kluis van een tijdslot voorzien is en dat er beveiligingscamera's zijn. Ze vertellen niet hoe het tijdslot precies werkt of waar de camera's hangen.

[Cergorach]

waar de beveiligingscameras hangen?

In een aantal gevallen moeten ze dat zelfs aangeven waar die hangen.

Men is hier inderdaad heel erg van "Security through obscurity is geen security", alleen is het "niet alleen". Als je een onbekend bagger systeem gebruikt is het onveiliger dan een bekend goed systeem te gebruiken. imho is het nog veiliger om een onbekend goed systeem te gebruiken. Het probleem is echter dat de meeste bedrijven niet de kennis en expertise in huis hebben om in technisch detail de kwaliteit te kunnen evalueren en te testen en moet men de leverancier maar geloven op de mooie blauwe ogen. Daarom kan men in veel gevallen niet zeggen of een onbekend systeem goed of bagger is...

En dan mag je nog zo een prachtig mooi beveiligd slot op je voordeur hebben zitten, maar als men vervolgens je raam in gooit komt men alsnog binnen... Inbreken op systemen is meestal niet de sloten op de voordeur gebruiken, maar via andere wegen binnenkomen om vervolgens een 'bug' te introduceren die er voor zorgt dat de deur niet meer op slot kan of de wachtwoorden onversleuteld opslaat...

[CH4OS]

Het gaat mij erom, dat als je niet bekend maakt hoe je sloten werken, meewerkt aan de ketting van de beveiliging, die is immers zo sterk als de zwakste schakel.

Doordat nu bekend is dat bcrypt gebruikt wordt, hoeft men voor aanvallen zich alleen te richten op bcrypt als men inloggegevens bemachtigd buiten de genoemde logs om.

Overigens dienen bedrijven dankzij de GPDR aan te geven hoe men om gaat met hun gebruikersinformatie, dat hoeft niet in details te zijn, vertellen welk encryptie methode gebruikt wordt is dan wat mij betreft een overbodig detail en volstaat het door te zeggen dat wachtwoorden met een sterke encryptie versleuteld is.

[Reactie gewijzigd door CH4OS op 23 juli 2024 06:11]

[GrooV]

Succes met het kraken van bcrypt!

Doe even een nieuws submit als het gelukt is!

[gorgi_19]

Ook opslaan in alleen bcrypt is onvoldoende, hoewel het nog redelijk niet doorgedrongen is.
bcrypt werkt alleen vertragend, maar bij een lek moet nog steeds iedereen zijn wachtwoord gaan aanpassen. De kans dat random je username / password gebruikt wordt is kleiner.

Daarnaast worden wachtwoorden als 12345 nog steeds veel gebruikt; mensen zijn nog steeds slecht in het verzinnen van wachtwoorden ondanks de vereisten. Zie bijvoorbeeld https://www.troyhunt.com/...ble-and-other-statistics/ Oftewel: brute forcen aan de hand van een password list moet wel wat succes opleveren.

Je ziet dat de bcrypt hashes nu soms ook al versleuteld worden; een lek van een database betekent dan niet dat gelijk al je hashes op straat liggen. Neem bijvoorbeeld dropbox, (https://blogs.dropbox.com...ly-stores-your-passwords/); zij hashen eerst een wachtwoord met Sha512, dan bcrypt, dan encrypten ze de hash met AES. Op deze wijze zorgen ze voor een voldoende 'sterk' wachtwoord voor bcrypt. Bovendien hebben ze nog een extra sleutel nodig om het wachtwoord te ontsleutelen.

[Reactie gewijzigd door gorgi_19 op 23 juli 2024 06:11]

[MadEgg]

Slechte passwords worden niet teniet gedaan door wat voor manier van hashing dan ook. 12345 is een slecht wachtwoord, altijd. Ook voor Dropbox. Het wachtwoord wordt er niet sterker van door er eerst SHA512 overheen te gooien.

SHA-512 voor bcrypt voegt ook weinig toe op zich. Je zou gewoon het aantal iterations voor bcrypt omhoog kunnen gooien. Het enige wat je ermee bereikt is dat je iets weerbaarder bent indien er onverhoopt een zwakheid in brcypt ontdekt wordt.

Natuurlijk is het bij elk lek aan te raden om wachtwoorden aan te passen, ook bij bcrypt. De kans dat de passwords eruit gehaald worden is wel vrij miniscuul - dat krijg je alleen voor elkaar bij zwakke wachtwoorden via brute forcen. Of als er ooit een zwakheid in brcypt wordt ontdekt. Op dit moment is daar geen aanleiding toe.

[gorgi_19]

Toch is er wel degelijk een verschil.

De versleuteling die ik bedoel maakt het, bij een lek, een stuk lastiger om het juiste wachtwoord te achterhalen. Een dictionary attack rechtstreeks op het wachtwoord is dan immers niet meer mogelijk.
SHA vertraagt bcrypt; AES voorkomt rechtstreekse dictionary aanvallen op de hash.

Slechte wachtwoorden kan je natuurlijk wel gewoon op de site uitproberen. Om hier 'bescherming' tegen te bieden moet een site het aantal pogingen 'beperken', of door een account te blokkeren, of door iedere poging steeds 'langer' te laten duren.

[MadEgg]

SHA vertraagt bcrypt, maar bcrypt heeft al een parameter om hem te vertragen. SHA toevoegen maakt het dus nodeloos complex, je kunt ook gewoon het aantal iteraties van bcrypt verhogen.

AES voegt wel íets toe, namelijk een extra wachtwoord die gekraakt moet worden, de sleutel van de AES-encryptie. Als de server gehackt is heb je daar alsnog niets aan want als je toch al toegang hebt kun je net zo goed de AES-sleutel ook kapen die leesbaar op de server aanwezig moet zijn omdat anders de applicatie niet functioneert. Maar als alleen de inhoud van de database uitlekt is AES wel een extra laag.

Al met al is het vrij beperkte symptoombestrijding. Lange wachtwoorden vereisen, dat zou helpen. Minimaal 12 karakters, dan kun je het met brute force wel aardig vergeten. En dan voegt die AES-versleuteling ook effectief niets extra's meer toe.

[_Pussycat_]

>> Daarnaast worden wachtwoorden als 12345 nog steeds veel gebruikt

Vaak komen die wachtwoorden bij leaks naar buiten. Maar dat zijn dan wachtwoorden die op, blijkbaar, onveilige sites gebruitk worden. Vaak heb ik daar ook slechte paswoorden; als bv. iemand mijn "online gratis TV kijken" account (zattoo.de) hackt boeit het me echt niet. Zodoende vraag ik me af welk deel van de gelekte paswoorden met opzet slecht was.

[gorgi_19]

Als ik kijk op https://haveibeenpwned.com/PwnedWebsites , zijn er toch best een aantal bekende / grotere sites:

Van LinkedIn, Dropbox, maar ook BitLy (9 miljoen), Comcast (600k), Disqus, imgur,
Open CS:GO

[_Pussycat_]

Ja, da's helaas waar. Mijn theorie is trouwens te testen. Je zou kunnen onderzoeken hoevaak slechte wachtwoorden op "grotere" (c.q. serieuzere) sites gebruikt worden, en hoe vaak op minder serieuze.

Vrijwilligers?

[Reactie gewijzigd door _Pussycat_ op 23 juli 2024 06:11]

[supersnathan94]

Die vrijwillegers kun je gewoon vinden bij HIBP of via gotcha.pw.

Statistieken op die datasets zeggen genoeg.

[CH4OS]

Vandaar dat ik in mijn eerste post al aangaf dat voor het moment bcrypt irreversible is, of las je daar gemakshalve overheen?

Ook voor bcrypt en alle andere encryptions gaat het immers een kwestie van tijd zijn, dat algoritme bestaat immers ook al bijna 20 jaar intussen.

[Reactie gewijzigd door CH4OS op 23 juli 2024 06:11]

[GrooV]

Je zegt zelf dat aanvallers bcrypt kunnen “kraken” en "richten" (wat op dit moment niet mogelijk is)

Verder is een hash geen encryptie! En het zou fijn zijn als je niet steeds je reactie inhoudelijk wijzigt

[Reactie gewijzigd door GrooV op 23 juli 2024 06:11]

[CH4OS]

Bij alle hashing en encryption algoritmen heb je kans op collisions, maar bij bcrypt is dat wel vele malen kleiner dan bijvoorbeeld bij MD5, SHA-1 en SHA-2. Ik zeg overigens ook nergens dat men bcrypt kan kraken. Ik zeg dat bcrypt voor het moment irreversible is, volgens mij is dat iets heel anders.

Toen ik mezelf bedacht dat een hash geen encryptie is, heb ik mijn bericht erop aangepast inderdaad, de wereld vergaat daar toch niet mee? Dus ik zie niet in waarom ik mijn bericht dan niet zou mogen wijzigen. Jij kan jouw bericht dan toch ook wijzigen? Ik zie er echt het probleem niet van.

Zo te zien heb je zelf ook inhoudelijk jou bericht gewijzigd, dus waarom zou ik dat niet mogen?

[Reactie gewijzigd door CH4OS op 23 juli 2024 06:11]

[joppybt]

Bij alle hashing en encryption algoritmen heb je kans op collisions, maar bij bcrypt is dat wel vele malen kleiner dan bijvoorbeeld bij MD5, SHA-1 en SHA-2

Volgens mij is de kans op collisions bij een hash alleen afhankelijk van het aantal output-bits. Bij bcrypt is dat 184 bit, bij SHA-256 bijvoorbeeld 256 bit. Er is dus bij SHA-256 minder kans op collisions dan bij bcrpyt.
Het enige verschil is dat je met bcrypt misschien langer aan het rekenen bent om een collision te vinden.

Bij een encryptie heb je trouwens helemaal geen collisions.

[Luftbanana]

In de email van Github, na hun recente bug, gaven ze ook aan welke sloten ze op hun deuren hebben zitten:

Hi there,

During the course of regular auditing, GitHub discovered that a recently introduced bug exposed a small number of users’ passwords to our internal logging system, including yours. We have corrected this, but you'll need to reset your password to regain access to your account.

GitHub stores user passwords with secure cryptographic hashes (bcrypt) [emphasis mine]. However, this recently introduced bug resulted in our secure internal logs recording plaintext user passwords when users initiated a password reset. Rest assured, these passwords were not accessible to the public or other GitHub users at any time. Additionally, they were not accessible to the majority of GitHub staff and we have determined that it is very unlikely that any GitHub staff accessed these logs. GitHub does not intentionally store passwords in plaintext format. Instead, we use modern cryptographic methods to ensure passwords are stored securely in production. To note, GitHub has not been hacked or compromised in any way.

You can regain access to your account by resetting your password using the link below:

[Reactie gewijzigd door Luftbanana op 23 juli 2024 06:11]

[StefanJanssen]

Erg opvallend dat bij beide bugs de wachtwoorden in plain text in de logs komt te staan rond dezelfde tijdsperiode...

Ik vind GitHubs manier om de wachtwoorden zelf te resetten een stuk beter dan wat Twitter doet, die mensen aanraad om het wachtwoord te resetten.

[Luftbanana]

De gebeurtenis bij Github kan natuurlijk (en zal waarschijnlijk) een trigger geweest zijn waardoor Twitter ook loganalyses heeft uitgevoerd.

[__fred__]

Neuh, dat is het niet, wij zijn in het kader van de AVG / GDPR door al onze processen aan het gaan om te kijken welke data waar opgeslagen wordt. Dit betekent dat wij ook logfiles hebben geanalyseerd en bijvoorbeeld Application Insights hebben doorgelicht.

Voor een nieuw product (gelukkig nog in ontwikkeling) had een offshore programmeur met 1 regel code de request / response bodies in de telemetry geduwd. Erg fijn om de requests te kunnen inspecteren, maar nogal rottig in het kader van de AVG.

En dan was dit nog een erg lompe violation, ik zal maar even mijn mond houden over de tientallen kleinere "probleemgevallen" die we in andere applicaties tegenkwamen omdat application insights out of the box standaard echt een heleboel trackt (inclusief dependent SQL queries bijvoorbeeld).

[Reactie gewijzigd door __fred__ op 23 juli 2024 06:11]

[Foxpat]

Volgens mij zijn bcrypt hashes wel redelijk makkelijk te herkennen, dus mocht je deze hashes bemachtigen dan weet je toch al dat het bcrypt is. De hash string begint namelijk altijd met een bcrypt revisie en format in de vorm van bijvoorbeeld $2y$.

[Anoniem: 420148]

Wat een onzin toch weer, en nog +1tjes vangen op een tech site ook. Aantonen welke encryptie je gebruikt maakt je onveilig? Ja, zo werkt dat. Mijn deur is van hout en mijn sleutel van metaal. Ben ik nu meer kwetsbaar omdat het online staat?

Is een bedrijf een keer transparant over hacks/leaks/bugs, krijg je dit soort opmerkingen...

[CH4OS]

Wat een onzin toch weer, en nog +1tjes vangen op een tech site ook. Aantonen welke encryptie je gebruikt maakt je onveilig?

Ik zeg niet dat je jezelf daarmee gelijk helemaal onveilig maakt, maar een verstandige keuze om het wel bekend te maken vind ik het ook niet, doordat je dan kwaadwillenden tips geeft, terwijl je dat eigenlijk niet wilt. Dus ja, wellicht is dat een stukje security through obscurity, maar an sich is dat een stukje wat dan niet zo erg is om dat in security through obscurity te hebben.

Mijn deur is van hout en mijn sleutel van metaal. Ben ik nu meer kwetsbaar omdat het online staat?

Een encryption algoritme is natuurlijk niet het materiaal in de analogie, maar de gebruikte techniek in de sleutels zelf. Om in de analogie te blijven; de ene sleutel werkt met gleufjes en karteltjes, een ander sleutel / slot met puntjes en karteltjes, om wat voorbeelden te noemen.

[robvanwijk]

Ik zeg niet dat je jezelf daarmee gelijk helemaal onveilig maakt, maar een verstandige keuze om het wel bekend te maken vind ik het ook niet, doordat je dan kwaadwillenden tips geeft, terwijl je dat eigenlijk niet wilt. Dus ja, wellicht is dat een stukje security through obscurity, maar an sich is dat een stukje wat dan niet zo erg is om dat in security through obscurity te hebben.

Als je beveiliging niet sterk genoeg meer is als iedereen weet dat je bcrypt gebruikt, dan was ie ook niet sterk genoeg voordat je dat vertelde.

Ergens heb je een punt, maar je ziet een belangrijk detail over het hoofd: het is heel makkelijk om wachtwoord-beveiliging fout te doen. Dus als iemand zegt "die informatie is geheim", dan heb ik nul idee of ie wachtwoorden plain text in zijn database gooit en "beveiligt" door een sterk wachtwoord voor zijn root user te hebben, of dat ie echt precies weet waar ie mee bezig is en ze inderdaad zo veilig mogelijk opslaat. Door te zeggen welke methoden gebruikt worden, is het opeens wel mogelijk om de uitspraak "wij gaan op een veilige manier met wachtwoorden om" op waarde te schatten.

Een encryption algoritme is natuurlijk niet het materiaal in de analogie, maar de gebruikte techniek in de sleutels zelf. Om in de analogie te blijven; de ene sleutel werkt met gleufjes en karteltjes, een ander sleutel / slot met puntjes en karteltjes, om wat voorbeelden te noemen.

En zoals Foxpat geheel terecht opmerkt: iedereen met een heel klein beetje verstand van zaken (of toegang tot Google...) ziet meteen dat een hash een bcrypt hash is. Net zoals elke inbreker meteen ziet of bij een bepaald slot een sleutel met puntjes of met gleufjes hoort.

[CH4OS]

Dank voor de verduidelijking!

[Anoniem: 420148]

En bcrypt is nog niet eens de sleutel of het slot in dit verhaal. Er komt zoveel meer bij kijken dan enkel het algorithme weten, dat het niet uitmaakt of je die prijsgeeft, tenzij je een of ander oud middel gebruikt om je encryptie te doen.

[Lagonas]

Erg goed dat ze het gemeld hebben, maar ik snap totaal niet waarom ze het niet geforceerd resetten. Zelfs als er geen tekenen zijn dat ze buitgemaakt zijn vind ik dit onverantwoordelijk.

[Stoelpoot]

Helaas is het voor een platform als Twitter niet wenselijk om bij elke poep en scheet een wachtwoordreset te forceren. Veel gebruikers kunnen amper een wachtwoord onthouden, laat staan een nieuwe bedenken.

[Anoniem: 738905]

Die mensen die dat niet kunnen moet je helpen en het afdwingen. Bij jou op het werk moet je waarschijnlijk ook elke maand een nieuw wachtwoord voor elke dienst / inloggen gebruiken? Bij mijn werkgever in iedergeval wel en nadat bij een controle een keer bleek dat bijna iedereen de naam van zijn partner / kind / huisdier opgaf mag het wachtwoord ook niet op een vorig wachtwoord e.d. lijken. Dat is in het begin irritant, maar nu kan iedereen ermee overweg, zelfs de collega's die hier echt moeite mee hadden.

Ik heb voor elke dienst nu een wachtwoord, ik heb ook twitter en denk: prima, niks aan de hand, dit wachtwoord gebruik ik nergens anders voor.

[Stoelpoot]

Nee, bij mij op het werk kennen we de aanbevelingen van het NIST wat juist geen periodieke verplichte wijziging bevat. Dan krijg je namelijk wachtwoorden als MijnComplexeWachtwoord201805, wat ik volgende maand verander in MijnComplexeWachtwoord201806.

En omdat het een stuk lastiger is om elke maand een voldoende complex wachtwoord van tussen de 10 en 16 tekens te onthouden, ga je dan dus juist van die simpele wachtwoorden gebruiken. Overigens lijken de namen van kinderen en honden vaak helemaal niet op elkaar, dus de maatregel die naar aanleiding daarvan was ingesteld slaat compleet de plank mis.

Bij jouw werkgever zijn het overigens een stuk minder mensen dan de volledige userbase van Twitter

[MadEgg]

en nadat bij een controle een keer bleek dat bijna iedereen de naam van zijn partner / kind / huisdier opgaf mag het wachtwoord ook niet op een vorig wachtwoord e.d. lijken. D

En hoe ga je dat doen als de wachtwoorden netjes, zoals het hoort, gehashed zijn opgeslagen? Je kunt dan alleen zien dat het wachtwoord gelijk is aan het vorige, niet of het erop lijkt. Kun je dat wel zien dan worden de wachtwoorden onveilig opgeslagen.

[Anoniem: 454358]

en wat gebeurd er dan? Ze nemen een verplicht wachtwoord als naamzoon1, volgende maand naamzoon2 etc, nog steeds door iedereen te raden. Als het wachtwoord van maart bekend (bijv naamzoon3) en dat werkt in juli niet meer, dan zou ik naamzoon6 eens proberen

[core_dump]

Het enige wat je hiermee afdwingt is een Post-It wachtwoordbeheerder..

Periodiek resetten van wachtwoorden is een achterhaald principe, gebaseerd op schijnveiligheid.

[MadEgg]

Als het vanuit het werk is zou je een verplichting tot het gebruik van een degelijke password manager moeten toevoegen natuurlijk. Post-It's gebruiken zou wel tot een serieuze berisping moeten leiden.

Periodiek resetten van wachtwoorden is een achterhaald principe, gebaseerd op schijnveiligheid.

Niet mee eens. Zolang het juist uitgevoerd wordt verhoogd het daadwerkelijk de veiligheid. Een sequentie van 'test1', 'test2', 'test3' etc is inderdaad schijnveiligheid. Elke X maanden een compleet ander willekeurig password, beheert in een fatsoenlijke password manager voegt wel veiligheid toe.

[Reactie gewijzigd door MadEgg op 23 juli 2024 06:11]

[The Zep Man]

Wat ik onverantwoordelijk vind is dat ze geen loganalyse hebben toegepast om te kijken van welke accounts wachtwoorden plain text zijn gelogged. Dan hoef je alleen die accounts aan te schrijven/daar af te dwingen dat het wachtwoord gewijzigd wordt. Nu creëert men veel paniek om iets wat mogelijk niets is.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 06:11]

[pBook]

Misschien zijn niet alle logs beschikbaar meer en zijn ze bang dat juist die ooit gelekt zijn.

[The Zep Man]

Misschien zijn niet alle logs beschikbaar meer en zijn ze bang dat juist die ooit gelekt zijn.

Dan was die bug wel heel lang opgemerkt (één logcyclus), wat nog kwalijker is.

[robvanwijk]

Misschien zijn niet alle logs beschikbaar meer en zijn ze bang dat juist die ooit gelekt zijn.

Ik mag hopen van niet; juist als ze bang zijn dat er iets is uitgelekt zou het onverantwoord zijn om die passwords niet te resetten (en ja, als je niet weet welke precies, dan zul je dat voor alle accounts moeten doen; shit happens).

[True]

Je kunt het wel gemakkelijk op een 'bug' gooien. Anno 2018 weten zelfs de minder technische mensen van een bug af, alleen heeft het idee van en bug de toon alsof je er niets aan kan doen. Ik vind dit zelf grove nalatigheid van Twitter, zoiets als dit moet gewoon niet meer kunnen. Het lijkt alsof ze er goed vanaf komen.

[cyspoz]

Ik snap zelf niet hoe dit een bug kan zijn. Het is niet dat hiervoor ergens false stond i.p.v. true. Dit is toch gewoon by design of mis ik iets?

[The Zep Man]

user.property.username = "blaat";
user.property.password = "mijnwachtwoord";
user.property.firstname = "Blaat";
user.property.(...);

(...)

foreach property p in user.property { sendlog(p); }

Een simpel voorbeeld in semi-code. De foreach regel staat totaal ergens anders in de code, waarbij er daar geen indicatie is dat hiermee ook een wachtwoord wordt gelogged.

In werkelijkheid zal het een stuk complexer zijn geweest, maar dat maakt natuurlijk nog steeds geen goed excuus voor brak programmeerwerk en/of brakke configuraties.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 06:11]

[ipaqlinux48]

Sorry, maar wachtwoorden horen nooit of te timmer in plaintext te worden opgeslagen. Wachtwoorden salten met een sterke crypto randomizer en vervolgens hashen met bcrypt (> 10000 iteraties). Code die je voordien aanhaalde verwacht je in het onderwijs, maar toch niet "in the field".

[84hannes]

Sorry, maar wachtwoorden horen nooit of te timmer in plaintext te worden opgeslagen.

Wat @The Zep Man hier probeert aan te geven: wellicht werden de wachtwoorden niet bewust plain-text opgeslagen. Ze komen plain-text in het geheugen voor. Dat is volgens mij niet te voorkomen, want zonder iets in het geheugen te zetten kun je er geen bewerkingen op uitvoeren. Het probleem is dat het langer in het geheugen is gebleven dan nodig, en dat heel ergens anders een soort geheugendump is gemaakt: iets wat wel geschikt was voor geheugen, maar niet voor opslag, is toch van het geheugen naar opslag gekopieerd. Fout? Zeker. Een bug? Vind ik wel.

[robvanwijk]

Dat is volgens mij niet te voorkomen, want zonder iets in het geheugen te zetten kun je er geen bewerkingen op uitvoeren.

Nu tegenwoordig nagenoeg elke browser javascript heeft zou je toch wel kunnen voorkomen dat de server ooit een plaintext wachtwoord ziet? Als je aan het onsubmit event van je formulier een stukje code hangt dat het (daadwerkelijke, door de gebruiker ingegeven) wachtwoord alvast hasht (en een extra property op true zet, zodat de server weet dat ie een extra stap moet doen als die property op false staat, zodat gebruikers met een script blocker toch in kunnen loggen), dan lijkt het erop alsof elke gebruiker die hash als password gebruikt. Mocht dat ooit uitlekken, dan heeft de site zelf daar niets aan (daar kun je immers met die hash inloggen), maar dan liggen in elk geval niet alle wachtwoorden op straat als Twitter (of gisteren deze zelfde bug bij Github) per ongeluk iets teveel gegevens logt. Of zie ik nu iets over het hoofd waardoor dit niet of nauwelijks nuttig is?
Voor de duidelijkheid: de server moet deze hashes natuurlijk hetzelfde behandelen als gewone wachtwoorden: door bcrypt of iets dergelijks halen voordat het de database ingaat.

[84hannes]

Ik ben geen expert, maar ik heb hier ook over nagedacht. Als ik het goed begrijp wil jij:

• Gebruiker voert (plain text) wachtwoord in in browser, ww1
• Browser hashed ww1 -> ww2
• ww2 wordt verstuurd naar server
• server hashed ww2->ww3
• server vergelijkt ww3 met database en geeft toegang als deze overeenkomen

Het enige dat nu kan lekken is ww3 (bij bijvoorbeeld een databaselek) en ww2 (bij bijvoorbeeld een log-fout-en-lek). Nu stel jij dat het lekken van ww2 niet erg is omdat je ww1 nodig hebt. Maar wat als ik een kleine aanpassing maak in mijn browser/het user-side javascript dat de ww1->ww2 conversie doet? Dan stuurt mijn browser ww2 naar de server en kan ik alsnog inloggen, zonder ww1 te kennen.

maar dan liggen in elk geval niet alle wachtwoorden op straat als Twitter

Let op: ze liggen niet op straat, ze staan mogelijk in een logbestand waar niet veel mensen bij kunnen. Dat is niet goed, maar veel beter dan wachtwoorden die 'op straat' liggen.

[robvanwijk]

Bedankt voor de samenvatting, dat was inderdaad een stuk leesbaarder dan mijn versie!

Nu stel jij dat het lekken van ww2 niet erg is omdat je ww1 nodig hebt. Maar wat als ik een kleine aanpassing maak in mijn browser/het user-side javascript dat de ww1->ww2 conversie doet? Dan stuurt mijn browser ww2 naar de server en kan ik alsnog inloggen, zonder ww1 te kennen.

Nee, de site zelf heeft er inderdaad niets aan. Maar met "ww2" kan een aanvaller niet inloggen bij andere diensten waar die gebruik hetzelfde "ww1" gebruikt heeft (en laten we eerlijk zijn; hergebruik van wachtwoorden komt nog steeds ontzettend veel voor). Hiervoor is het natuurlijk wel nodig dat het een gesalte hash is, dat was ik in mijn vorige post vergeten te vermelden.

Let op: ze liggen niet op straat, ze staan mogelijk in een logbestand waar niet veel mensen bij kunnen.

Je hebt gelijk: "mogelijk op straat komen te liggen".

[MadEgg]

Het voorbeeld is onjuist - The Zep Man slaat het idd in plain text op of laat de hashing over aan de database.

Ik zie het eerder foutgaan in bijvoorbeeld web request logs:

[200] /twitter/login (parameters: {'username': 'madegg', 'password': 'test123'})

of in stacktraces waarbij de parameters zichtbaar zijn:

com.twitter.user.User.setPassword(password = "test123")


Het plain-text wachtwoord wordt nu eenmaal op bepaalde momenten door de server verwerkt. In ieder geval bij het inloggen en bij het instellen van een nieuw wachtwoord. Als op dat moment de logging onjuist wordt toegepast krijg je dit soort ellende.

[CH4OS]

Gezien het feit dat bcrypt gebruikt wordt voor passwords (zie Luftbanana in 'nieuws: Twitter sloeg wachtwoorden door bug onversleuteld op'), heeft Twitter alleen een (voor het moment irreversible) hashed password. Passwords kunnen dan alleen als 'plain text' in de logging komen wanneer iemand zich registreert of inlogt.
Anders krijg je enkel het encrypted password die eruit is ontstaan.

[Reactie gewijzigd door CH4OS op 23 juli 2024 06:11]

[M.l.]

Het is geen gek idee om deze functionaliteit te hebben in een ontwikkelomgeving. Dit moet echter wel op zo'n manier gedaan worden dat je het kan testen met de functionaliteit aan en daarna uit. Uiteindelijk moet het bij het uitrollen niet mogelijk zijn om te werken en daar is het vast mis gegaan. Ik denk dat ze als laatste stap handmatig de code er uit sloopten en dat dat een keer is vergeten. Les geleerd, voortaan voorkomen.

[gorgi_19]

Ook in een productieomgeving wil je veel gaan loggen (audits), zodat je bij problemen (van welke aard dan ook) een pad kan nabouwen wat er is gebeurd. Bij een hack kan je dan zo ook nagaan hoe het gebeurd is en wat er precies gebeurd is.

Logging wil je ook vrij vroeg in het proces doen; wat komt er binnen en wat zijn de resultaten? Ze zijn alleen vergeten om bepaalde zaken uit te sluiten in de logging. Op zich niet vreemd; logging is een andere verantwoordelijkheid dan verwerken van wachtwoorden en het zal me niet verbazen als dit op een heel andere plek opgelost wordt.

[Stoelpoot]

try
{
user.SaveChanges()
}
catch (DatabaseException e)
{
log(e);
log(user);
}

Oh wacht op dat moment was het wachtwoord soms unencrypted omdat er op dat punt ook een password reset kan plaatsvinden. Logging treedt heel vaak op als er foutmeldingen komen omdat er een server niet bereikbaar is oid. Als je dan ook het request logt, gaat het fout.

[1nsane]

It’s not a bug, it is a feature!

Je hebt inderdaad gelijk, gooi het maar weer op een bug terwijl er gewoon een zwik developers hebben zitten slapen.

Als je weet dat je aan het proggen bent aan de hashing pipeline en je al niet beseft dat als je logging aanbrengt vóór het algoritme dat daadwerkelijk het wachtwoord hasht, dan was het of verschrikkelijk dom, of een “bewussie”.

Ik begrijp dat waar er geprogrammeerd wordt, er fouten worden gemaakt en dat juich ik toe omdat je er sneller van leert maar voor dit soort dingen is een simpele OTAP straat en een pull-merge gebeuren met maar 4 ogen echt niet voldoende.

[MadEgg]

Het kan al héél vroeg misgaan. Als je inlogt bij Twitter zal jouw browser je password in plain text naar de server moeten sturen zodat die je wachtwoord kan controleren.

Als de webserver nu de requests logt inclusief de request body komt je wachtwoord in plain text in de logfiles terecht.

[Belgar]

Aan de andere kant neem je wel makkelijk aan dat het bij hetzelfde team zit. Dat is echter (vaak) niet gegeven.

Het team dat de implementatie heeft gedaan van de wachtwoordbeveiliging kan een perfect veilige code hebben afgeleverd, zonder logging. Twee kamers verderop zit het dev-ops team dat besluit om voor de profiling van alle pagina's een parser log te implementeren, of iets dergelijks, en die scraped vervolgens de passwords.

In de praktiek heb je logging bij je CDN, servers, parser en code laag. Het kan fout gaan bij elk van deze lagen. Ik zou zelfs zeggen dat de kans dat het fout gaat bij de hogere lagen groter is.

[Buzzinga]

"Omdat Twitter geen aanwijzingen heeft dat zijn servers door onbevoegden zijn binnengedrongen of dat de logs misbruikt zijn, heeft de dienst wachtwoorden geen reset gegeven"

Dit vind ik erg slordig. Ze komen er plots achter dat er een "bug" is (niet van de minsten dan ook nog), maar ze zijn er dan wel zeker genoeg van dat er verder niets gebeurd is waardoor ze het niet nodig vinden om verdere maatregelen te nemen zoals een verplichte reset.

[3dfx]

Ja exact, erg raar! Assumption is the mother of all fuckups

Maar misschien denken ze dat het gros van hun gebruikers niet snappen hoe ze een nieuw wachtwoord moeten aanmaken of zelfs verzinnen

[StefanJanssen]

Nu vraag ik mij af hoeveel mensen die een wachtwoord reset krijgen vanwege een lek ook daadwerkelijk een ander wachtwoord kiest.

[MrMarcie]

Iedereen, omdat je dan niet zelfde WW kan gebruiken.

[StefanJanssen]

Bij heel veel diensten maakt dit helemaal niks uit en zal het dus gewoon mogelijk zijn.

[MrMarcie]

Rare diensten dan.

[SunnieNL]

Tja als je dan vind dat ze iedereen een reset moeten geven, vind ik eigenlijk dat ze 2fa moeten verplichten voor iedereen. Is het hele probleem in 1x opgelost, ook als dit in de toekomst gebeurd.

[Calypso]

Dat is niet wat er staat of gecommuniceerd is. Er is gecommuniceerd dat er geen aanwijzingen zijn. In de praktijk houdt dat meestal in dat men de systemen doorgelicht heeft om te kijken of er ongeoorloofde toegang is geweest (auditinglogs bijv.) en er niets vreemds naar boven gekomen is. Maar je kunt niet zeggen dat het 100% zeker is, want 100% zeker kun je het nooit weten - er is altijd wel "iets" wat tegen die bewering in te brengen is.

[Buzzinga]

Uhm ja, dat is toch exact wat ik zeg?

[Raindeer]

Vraag aan password-opslag-experts: Wat zou een reden kunnen zijn om een password in plaintext weg te schrijven? Of andersom, waarom is de volledige keten van begin tot einde niet encrypted?

Misschien iets verder uitleggen: Als ik mijn password wijzig, dan moet er een hash+seed van het wachtwoord gemaakt worden. Waarom is het nodig dat het onversleutelde wachtwoord naar Twitter gaat? Ik kan toch op mijn pc een hash verzenden? Daar kunnen zij ook nog iets mee doen. Als ik dan inlog gaat het password nooit in plaintext van mijn PC?

Ik snap vast iets niet.

Ik kreeg een antwoord via een ander kanaal: Er is een techniek, genaamd SRP die een heel end in de buurt komt. Wil je het echt helemaal goed doen, dan moet je certificaten en dergelijke gaan gebruiken. Tekst staat hier: https://blog.powerdns.com...es-and-a-critical-review/

[Reactie gewijzigd door Raindeer op 23 juli 2024 06:11]

[Stoelpoot]

Omdat je dan geen controle uit kan voeren op de wachtwoordsterkte. Javascript kan worden uitgeschakeld in de browser.

[tszcheetah]

Als jij een "versleuteld" wachtwoord stuurt zoals je voorstelt, dan is de hash die je opstuurt simpelweg je plaintext wachtwoord geworden. Een kwaadwillende kan dan simpelweg het gehashte wachtwoord afvangen (of uit de logs lezen) en daarmee inloggen. En als je een zwak wachtwoord hebt ("123456") dan is het voor een aanvaller nog steeds net zo makkelijk om daar de hash van te maken en daarmee proberen in te loggen.

Het enige wat ik kan bedenken wat je met zo'n situatie wint, is dat als een gebruiker zijn wachtwoord op meerdere sites/diensten gebruikt, het oorspronkelijke wachtwoord zelf niet direct op straat ligt. Maar binnen 1 dienst is er dus praktisch geen verschil in veiligheid.

[MIster X]

Client-side-hashing heeft wel degelijk voordelen:

• Bij elke site/dienst wordt hetzelfde password anders opgeslagen (zoals je zelf al aangeeft). Gezien het aantal datalekken zou dat een hoop problemen kunnen voorkomen.
• De dienst zelf kent jouw wachtwoord niet. Wie zegt dat de programmeur van de website waar jij inlogt te vertrouwen is met jouw wachtwoord? Theoretisch kan jouw in plaintext verstuurde wachtwoord direct worden doorgestuurd naar zijn e-mailadres, zelfs als het wachtwoord daarna versleuteld wordt opgeslagen. Of wat als er op de site een onbetrouwbare npm-module wordt gebruikt?
• Client-side-hashing kan zo gebouwd worden dat er bij elk inlog een andere salt wordt gebruikt. Het gehashte wachtwoord is dus maar gedurende een beperkte tijd te gebruiken. Bovendien kan de hash worden gekoppeld aan het ip-adres. Nu is dat laatste uiteraard ook wel weer te faken, maar het aanvalsvlak wordt er in ieder geval door verkleint.

[NickThissen]

Waarschijnlijk zit er ergens een logger die http request data naar de log schrijft. Als ze niet actief actie ondernemen om passwords eruit te strippen (of bijvoorbeeld zorgen dat login requests juist niet in de log komen) dan zou het eenvoudig kunnen gebeuren dat de logs de passwords bevatten, bijv in de post body.

[CH4OS]

Mag hopen dat niet per HTTP-request de login gegevens verstuurd worden. Een sessie-id is tot daar aan toe.

[Reactie gewijzigd door CH4OS op 23 juli 2024 06:11]

[NickThissen]

Dat zeg ik toch ook niet? Als blind elke request gelogd wordt zonder filtering dan zullen dus ook login requests erbij zitten. Ik mag hopen dat die apart afgehandeld worden, op z'n minst het password veld eruit gestript, maar blijkbaar is dat ofwel niet gebeurd of niet goed genoeg.

[CH4OS]

Dankzij TLS/SSL wordt verstuurde versleuteld. In access logs zul je dergelijke info daardoor alleen versleuteld krijgen. Wellicht dat eea daarom in debuglogs zit. Wellicht is het zo'n log geweest, dat je eigenlijk alleen op een development omgeving wilt hebben.

[ZpAz]

Dat het versleuteld over het internet gaat betekend niet dat het op de server nog steeds versleuteld is, daar wordt het immers verwerkt.

Mogelijk was het iets als: "Alle inkomende requests en antwoorden van de server worden gelogd". En op dat niveau in de applicatie stack is er dan niet direct kennis van wat een request is, ze worden allemaal gelijk behandeld. Wat ze dan vergaten was een filter op bepaalde urls of velden toe te passen. Zodat deze of niet gelogd werden, of werden aangepast zodat het wachtwoord er uit gehaald wordt voordat er gelogd wordt.

[RoNoS]

Zelfde logsysteem als GibHub gebruikt?

[Luftbanana]

Ik dacht hetzelfde, na een soort dejavu-idee a.d.h.v. Twitter's email in m'n inbox.

Het zal waarschijnlijk niet aan het logsysteem liggen maar aan de "objecten" die worden gelogd. Indien jij of je bedrijf (niet persoonlijk, maar algemeen bedoeld) privacy-gevoelige gegevens verwerkt, is het altijd aan te raden om even te kijken of je niet zo'n zelfde bug in je systemen hebt zitten.

[Falco_]

Mooi dat bedrijven nu waarschijnlijk door GDPR kijken wat er daadwerkelijk in hun logs komt te staan.

[Stoelpoot]

Ik denk dat het eerder is omdat Github eerder met het nieuws kwam, en nu meerdere bedrijven het dus inderdaad controleren.

[110124]

Hier merk je maar weer dat je moet blijven oppassen wat er met je gegevens gebeurt, zelfs nadat je je account hebt verwijderd. Er is altijd wel een 'log', of een 'backup' hier of daar waar je gegevens te vinden zijn.

Erg netjes dat ze het zelf melden!

[Quacka]

Niet netjes, ze zijn het verplicht. Zeker een giga bedrijf (op gebied van persoonsgegevens) als Twitter.

Btw, mental note voor mezelf : ik moet toch eens een password manager gaan gebruiken in combinatie met onmogelijke wachtwoorden....

[Stoelpoot]

ik moet toch eens een password manager gaan gebruiken in combinatie met onmogelijke wachtwoorden....

Ja. Dat maakt dit soort zaken ook een heel stuk makkelijker. Niet meer nadenken over een wachtwoord, maar gewoon een knopje indrukken en je hebt een nieuw wachtwoord.

[PThijssen]

Melding van Twitter als je vandaag voor het eerst naar de site gaat:
" Houd je account veilig
Wanneer je een wachtwoord instelt voor je Twitter-account, gebruiken we een technologie om het onzichtbaar te maken voor iedereen in het bedrijf. We hebben recentelijk een bug ontdekt die wachtwoorden zichtbaar opsloeg in een intern logboek. We hebben deze bug verholpen en uit ons onderzoek is geen gebruik of misbruik van deze wachtwoorden door wie dan ook gebleken. Als extra voorzorgsmaatregel vragen we je toch om je wachtwoord te wijzigen op alle services waarop je dit wachtwoord hebt gebruikt. Meer informatie (https://blog.twitter.com/...our-account-secure.html)"

[Plainside]

Klinkt al het zelfde verhaal van GitHub laatst. Maar waarom Twitter niet geforceerd een wachtwoord reset doet snap ik niet. Ik neem aan dat je de veiligheid van je gebruikers zoveel mogelijk wilt beschermen. En geen aanwijzingen dat er geen inbreuk is geweest, betekent niet dat het niet gebeurt is.

Edit: Linkje

[Reactie gewijzigd door Plainside op 23 juli 2024 06:11]

[theduke1989]

Vooral Trump zijn wachtwoorden wil je toch wel graag weten.

America first #passwordbreach #passwordleaks #iamstupidontwitter #biggerisnotalwaysbetter

[Plainside]

^{Tja, als zijn account wordt gebreached dan krijgen we opeens redelijk tweets over de Amerikaanse politiek, zonder een oorlog te starten.}

Het blijft een serieus dingetje ik hoop toch echt dat ze het zo snel mogelijk hebben opgelost.