image

Twitter vraagt alle gebruikers om wachtwoord te wijzigen

vrijdag 4 mei 2018, 09:27 door Redactie, 12 reacties

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)
04-05-2018, 09:32 door Anoniem
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.
04-05-2018, 11:57 door Anoniem
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.

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:
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.
04-05-2018, 14:46 door Krakatau - Bijgewerkt: 04-05-2018, 15:29
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.

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.
05-05-2018, 20:20 door Anoniem
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.

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.
05-05-2018, 22:02 door Anoniem
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.
05-05-2018, 23:11 door Krakatau - Bijgewerkt: 05-05-2018, 23:12
Door Anoniem:
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.

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?
06-05-2018, 16:02 door Anoniem
Door Krakatau:
Door Anoniem:
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.

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.
06-05-2018, 21:34 door Krakatau - Bijgewerkt: 06-05-2018, 21:36
Door Anoniem:
Door Krakatau:
Door Anoniem:
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.

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.

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.

Welk probleem?
06-05-2018, 23:36 door Anoniem
@Krakatau
Om dit topic met een constructief antwoord af te sluiten: SRP is zo'n antwoord voor het probleem.
http://srp.stanford.edu/whatisit.html
https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.