Twitter vraagt alle gebruikers om wachtwoord te wijzigen
Twitter heeft alle gebruikers gevraagd om hun wachtwoord te wijzigen, aangezien wachtwoorden door een bug onversleuteld in een intern logbestand werden opgeslagen. Volgens Twitter zijn er geen aanwijzingen dat de gegevens zijn gestolen of door iemand zijn misbruikt.
Toch zijn alle gebruikers uit voorzorg gevraagd een ander wachtwoord in te stellen. Twitter maakt gebruik van het bcrypt-algoritme om wachtwoorden te hashen. Door een fout werden de wachtwoorden naar een intern logbestand geschreven voordat het hashingproces was voltooid. Twitter zegt dat het de fout zelf heeft gevonden en alle wachtwoorden heeft verwijderd. Ook worden er maatregelen doorgevoerd om te voorkomen dat een dergelijke fout zich opnieuw kan voordoen.
Reacties (12)
Tja... Ik heb geen Twitter en dit mag toch eigenlijk niet gebeuren in 2018.
04-05-2018, 10:11 door
Briolet
Door een fout werden de wachtwoorden naar een intern logbestand geschreven voordat het hashingproces was voltooid
Dan heeft Twitter nog meer niet op orde. Wachtwoorden behoren op de cliënt zelf gehashed te worden. Het plaintext wachtwoord hoeft dan helemaal niet over het internet te gaan en kan dan ook nooit 'per ongeluk' in een logbestand terecht komen.
Door Briolet:
Dan heeft Twitter nog meer niet op orde. Wachtwoorden behoren op de cliënt zelf gehashed te worden. Het plaintext wachtwoord hoeft dan helemaal niet over het internet te gaan en kan dan ook nooit 'per ongeluk' in een logbestand terecht komen.
Door een fout werden de wachtwoorden naar een intern logbestand geschreven voordat het hashingproces was voltooid
Dan heeft Twitter nog meer niet op orde. Wachtwoorden behoren op de cliënt zelf gehashed te worden. Het plaintext wachtwoord hoeft dan helemaal niet over het internet te gaan en kan dan ook nooit 'per ongeluk' in een logbestand terecht komen.
Misschien zelf iets daadwerkelijk gaan onderhouden dan alleen je theoretische gelul.
Alles wat je hierboven zegt heeft totaaal geen invloed als je ergens de authenticatie debug logs weg schrijft.
04-05-2018, 12:22 door
Krakatau
Door Briolet:
Dan heeft Twitter nog meer niet op orde. Wachtwoorden behoren op de cliënt zelf gehashed te worden. Het plaintext wachtwoord hoeft dan helemaal niet over het internet te gaan en kan dan ook nooit 'per ongeluk' in een logbestand terecht komen.
Door een fout werden de wachtwoorden naar een intern logbestand geschreven voordat het hashingproces was voltooid
Dan heeft Twitter nog meer niet op orde. Wachtwoorden behoren op de cliënt zelf gehashed te worden. Het plaintext wachtwoord hoeft dan helemaal niet over het internet te gaan en kan dan ook nooit 'per ongeluk' in een logbestand terecht komen.
Met JavaScript kan dat. Echter sommigen hier zijn sterk gekant tegen alle gebruik van JavaScript op websites.
04-05-2018, 13:05 door
Briolet
Door Anoniem: Misschien zelf iets daadwerkelijk gaan onderhouden dan alleen je theoretische gelul.
Niets theoretisch. zie ook: https://en.wikipedia.org/wiki/Digest_access_authentication
SMF forumsoftware doet dat volgens mij standaard. Het wachtwoord cliënt-side hashen, vervolgens salten met session ID en dan pas over het internet.
Ook mijn Synology NAS en IP camera's doet hetzelfde bij een browser inlog.
JavaScript is bij mij een must op een website. Je kunt er kwaad mee, maar ook dingen veiliger maken.
Ook deze site werkt niet zonder JS. Het is een essentieel onderdeel om überhaupt de captcha in te kunnen vullen bij een anonieme post. Alle anonieme posters gebruiken dus JS.
Door Briolet:
Niets theoretisch. zie ook: https://en.wikipedia.org/wiki/Digest_access_authentication
SMF forumsoftware doet dat volgens mij standaard. Het wachtwoord cliënt-side hashen, vervolgens salten met session ID en dan pas over het internet.
Ook mijn Synology NAS en IP camera's doet hetzelfde bij een browser inlog.
Door Anoniem: Misschien zelf iets daadwerkelijk gaan onderhouden dan alleen je theoretische gelul.
Niets theoretisch. zie ook: https://en.wikipedia.org/wiki/Digest_access_authentication
SMF forumsoftware doet dat volgens mij standaard. Het wachtwoord cliënt-side hashen, vervolgens salten met session ID en dan pas over het internet.
Ook mijn Synology NAS en IP camera's doet hetzelfde bij een browser inlog.
Groot voordeel van client-side hashen is dat het plaintext password nooit op de server terecht komt. Waarmee zoiets als dit (Twitter) niet KAN gebeuren.
Door Briolet: JavaScript is bij mij een must op een website. Je kunt er kwaad mee, maar ook dingen veiliger maken.
SPA's (Single Page Apps) zijn de toekomst. Volledig JavaScript.
Door Krakatau:
Groot voordeel van client-side hashen is dat het plaintext password nooit op de server terecht komt. Waarmee zoiets als dit (Twitter) niet KAN gebeuren.
Groot voordeel van client-side hashen is dat het plaintext password nooit op de server terecht komt. Waarmee zoiets als dit (Twitter) niet KAN gebeuren.
Client side hashen???? Ik hoop niet dat jullie programmeurs zijn.
Aan degene die zichzelf als echte programmeurs beschouwen laat ik het verder over om uit te zoeken
waarom je dit NOOIT moet doen.
Door Anoniem: Tja... Ik heb geen Twitter en dit mag toch eigenlijk niet gebeuren in 2018.
Ooit een manager gehad die naar aanleiding van een (onbenullig) foutje in een e-mail eiste dat we voortaan 100% foutloos werk zouden leveren. Ik heb er wel smakelijk om moeten lachen.
Altijd leuk om iemand aan te herinneren als ze zelf een foutje maakt, maar daar had ze niet het geschikte humeur voor.
Mensen maken nu eenmaal fouten. Machines maken fouten. Quantum en zo, en volle maan en shit happens. Dus ja, beter zouden er helemaal geen fouten gemaakt worden maar in die wereld leven we niet.
Eigenlijk maar gelukkig want vaak ontstaan door foutjes ook weer de mooiste dingen, nieuwe diersoorten zoals wij bijvoorbeeld. En soms moet iedereen eventjes zijn Twitter wachtwoord vervangen, het zij zo. Een mooie gelegenheid om gelijk 2 factor authentication in te stellen.
Door Anoniem:
Client side hashen???? Ik hoop niet dat jullie programmeurs zijn.
Aan degene die zichzelf als echte programmeurs beschouwen laat ik het verder over om uit te zoeken
waarom je dit NOOIT moet doen.
Door Krakatau:
Groot voordeel van client-side hashen is dat het plaintext password nooit op de server terecht komt. Waarmee zoiets als dit (Twitter) niet KAN gebeuren.
Groot voordeel van client-side hashen is dat het plaintext password nooit op de server terecht komt. Waarmee zoiets als dit (Twitter) niet KAN gebeuren.
Client side hashen???? Ik hoop niet dat jullie programmeurs zijn.
Aan degene die zichzelf als echte programmeurs beschouwen laat ik het verder over om uit te zoeken
waarom je dit NOOIT moet doen.
Vertel! (Ik ben nooit te oud om te leren.)
N.B.: (a) natuurlijk moet je HTTPS óók gebruiken en (b) natuurlijk moet je op de server nogmaals hashen, zoals gebruikelijk bij een ontvangen plaintext password (want je wil ook bij client side hashing niet dat client supplied password data zomaar worden opgeslagen). Dat had je toch wel begrepen denk ik?
Door Krakatau:
Vertel! (Ik ben nooit te oud om te leren.)
N.B.: (a) natuurlijk moet je HTTPS óók gebruiken en (b) natuurlijk moet je op de server nogmaals hashen, zoals gebruikelijk bij een ontvangen plaintext password (want je wil ook bij client side hashing niet dat client supplied password data zomaar worden opgeslagen). Dat had je toch wel begrepen denk ik?
Door Anoniem:
Client side hashen???? Ik hoop niet dat jullie programmeurs zijn.
Aan degene die zichzelf als echte programmeurs beschouwen laat ik het verder over om uit te zoeken
waarom je dit NOOIT moet doen.
Door Krakatau:
Groot voordeel van client-side hashen is dat het plaintext password nooit op de server terecht komt. Waarmee zoiets als dit (Twitter) niet KAN gebeuren.
Groot voordeel van client-side hashen is dat het plaintext password nooit op de server terecht komt. Waarmee zoiets als dit (Twitter) niet KAN gebeuren.
Client side hashen???? Ik hoop niet dat jullie programmeurs zijn.
Aan degene die zichzelf als echte programmeurs beschouwen laat ik het verder over om uit te zoeken
waarom je dit NOOIT moet doen.
Vertel! (Ik ben nooit te oud om te leren.)
N.B.: (a) natuurlijk moet je HTTPS óók gebruiken en (b) natuurlijk moet je op de server nogmaals hashen, zoals gebruikelijk bij een ontvangen plaintext password (want je wil ook bij client side hashing niet dat client supplied password data zomaar worden opgeslagen). Dat had je toch wel begrepen denk ik?
@Krakatau
Zodra je client-side gaat hashen, wordt de hash effectief het wachtwoord.
Dit maakt attacks veel makkelijker.
Als er dan een keer een systeem gecompromitteerd wordt heeft de aanvaller al direct alle hashes en omdat jij in deze configuratie de hash alleen naar de server hoeft te sturen zijn alle accounts gecompromitteerd zelfde impact als deze in plaintext stonden.
Dat is de reden dat in de industrie de geaccepteerde wijze is: Door de server bcrypt/pbkdf2 passwords hashen en opslaan.
Er zijn technieken in opkomst om dit probleem anders aan te pakken.
Maar dat is niet client-side hashen.
Door Anoniem:
@Krakatau
Zodra je client-side gaat hashen, wordt de hash effectief het wachtwoord.
Dit maakt attacks veel makkelijker.
Door Krakatau:
Vertel! (Ik ben nooit te oud om te leren.)
N.B.: (a) natuurlijk moet je HTTPS óók gebruiken en (b) natuurlijk moet je op de server nogmaals hashen, zoals gebruikelijk bij een ontvangen plaintext password (want je wil ook bij client side hashing niet dat client supplied password data zomaar worden opgeslagen). Dat had je toch wel begrepen denk ik?
Door Anoniem:
Client side hashen???? Ik hoop niet dat jullie programmeurs zijn.
Aan degene die zichzelf als echte programmeurs beschouwen laat ik het verder over om uit te zoeken
waarom je dit NOOIT moet doen.
Door Krakatau:
Groot voordeel van client-side hashen is dat het plaintext password nooit op de server terecht komt. Waarmee zoiets als dit (Twitter) niet KAN gebeuren.
Groot voordeel van client-side hashen is dat het plaintext password nooit op de server terecht komt. Waarmee zoiets als dit (Twitter) niet KAN gebeuren.
Client side hashen???? Ik hoop niet dat jullie programmeurs zijn.
Aan degene die zichzelf als echte programmeurs beschouwen laat ik het verder over om uit te zoeken
waarom je dit NOOIT moet doen.
Vertel! (Ik ben nooit te oud om te leren.)
N.B.: (a) natuurlijk moet je HTTPS óók gebruiken en (b) natuurlijk moet je op de server nogmaals hashen, zoals gebruikelijk bij een ontvangen plaintext password (want je wil ook bij client side hashing niet dat client supplied password data zomaar worden opgeslagen). Dat had je toch wel begrepen denk ik?
@Krakatau
Zodra je client-side gaat hashen, wordt de hash effectief het wachtwoord.
Dit maakt attacks veel makkelijker.
Nee want het client hashen is alleen bedoeld om te voorkomen dat een plain text wachtwoord op de server terecht komt. Zoals al eerder vermeld: op de server behandel je een ontvangen client side hashed waarde gewoon zoals je normaliter een ontvangen plaintext password zou behandelen.
Door Anoniem: Als er dan een keer een systeem gecompromitteerd wordt heeft de aanvaller al direct alle hashes en omdat jij in deze configuratie de hash alleen naar de server hoeft te sturen zijn alle accounts gecompromitteerd zelfde impact als deze in plaintext stonden.
Dat is de reden dat in de industrie de geaccepteerde wijze is: Door de server bcrypt/pbkdf2 passwords hashen en opslaan.
Dat is de reden dat in de industrie de geaccepteerde wijze is: Door de server bcrypt/pbkdf2 passwords hashen en opslaan.
Daarom stond erbij dat je (a) https moet (blijven) gebruiken en dat je (b) gewoon moet blijven hashen op de server. Gezien je reactie hierboven heb je dat niet gelezen? Of niet begrepen?
Door Anoniem: Er zijn technieken in opkomst om dit probleem anders aan te pakken.
Maar dat is niet client-side hashen.
Maar dat is niet client-side hashen.
Welk probleem?
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Specialiseer je in Forensisch ICT
Online informatieavond 19 november
Wil jij je specialiseren in digitaal forensisch onderzoek? Je kennis verbreden en tech-nische vaardigheden ontwikkelen? Ontdek de cursus- en opleidingsmogelijkheden van Hogeschool Leiden:
- Bachelor Informatica Forensisch ICT (deeltijd)
- Master Digital Forensics (vol- en deeltijd)
- Module Mobile Forensics
- Module Data Analytics
Interesse? Meld je aan!
Chief Information Security Officer
Utrecht heeft jou nodig! Als Chief Information Security Officer speel jij een cruciale rol in de bescherming van de digitale informatie van de gemeente Utrecht. Als geen ander weet jij welke dreigingen er zijn en kun je deze vertalen naar risico's die de gemeente en haar inwoners lopen. Solliciteer nu!
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
