Flipboard geeft wachtwoorden reset na maandenlange servertoegang door criminelen

De persoonlijke gegevens van miljoenen Flipboard-gebruikers liggen potentieel op straat. Internetcriminelen hadden ruim negen maanden toegang tot het systeem van het sociale medium. Het is niet duidelijk om hoeveel gebruikers het precies gaat.

Dat meldt het bedrijf in een blogpost. De hackers zouden gebruikersnamen, e-mailadressen en wachtwoorden buit hebben gemaakt. Ook zouden er tokens voor externe applicaties die aan Flipboard zijn gekoppeld zijn weggesluisd.

Flipboard zegt dat het nog onderzoekt hoeveel gebruikers precies getroffen zijn door de hack. Uit voorzorg zijn de wachtwoorden van alle gebruikers van het platform gereset. Gebruikers moeten dat veranderen zodra zij Flipboard weer openen. De wachtwoorden van gebruikers die vóór 14 maart 2012 een wachtwoord hebben aangemaakt of gewijzigd, werden gehasht met het inmiddels onveilig geachte sha-1. Nieuwe of gewijzigde wachtwoorden zijn met bcrypt gehasht en salted.

Flipboard zegt dat criminelen tussen 2 juni 2018 en 23 maart 2019 in de systemen van het bedrijf zaten. Dat zou ook op 21 en 22 april van dit jaar zijn gebeurd. Flipboard zegt daar niet bij of het gaat om dezelfde personen.

Reacties (40)

[snah001]

Mijn wachtwoord van mijn Flipboard account is niet gereset ondanks het beweerde in het artikel.
Zonet nog gecontroleerd.

[xiphoid]

Mijn wachtwoord van 2012 doet het nog prima, oof.

[snah001]

Ben er al achter hoe het zit.
Op je device ben je meestal constant ingelogd al gebruik je de app niet altijd.
Pas als je uitlogt en weer inlogt wordt je verzocht een nieuw wachtwoord in te stellen.

[xiphoid]

Ik had het niet eens meer ge-installeerd.

[Ossebol]

Mmm. Ik begrijp niet zo goed waarom je sha1 blijft handhaven. Zou het niet beter zijn geweest de oude wachtwoorden, die dus onveilig zijn, te resetten, zoals plan: Filters onthouden - Development-iteratie #130?

[svenslootweg]

Resetten is daarvoor niet eens noodzakelijk. Je kunt simpelweg alle bestaande oude hashes nogmaals hashen met de nieuwere hash, en bij de eerstvolgende login beide algoritmes toepassen ter verificatie en dan een nieuwe hash direct van het wachtwoord genereren. Dan zitten ook de oude, lang-ongebruikte wachtwoorden achter het nieuwe hashing-algoritme, zij het met een extra tussenstap.

[monotype]

Ter verduidelijking:
Het hashen met een nieuw algorithme van bestaande SHA1 hashes is GEEN oplossing als de SHA1 hashes al gelekt zijn - het kan alleen helpen migreren als de SHA1 hashes nog niet gelekt zijn.

Als de SHA1 hashes gelekt zijn dan kan er (bij gebrek aan salting) een bijpassend wachtwoord opgezocht worden en ligt dus in essentie het leesbare wachtwoord op straat.

Dit leesbare wachtwoord kan door criminelen dus ook gebruikt worden om in te loggen en het wachtwoord te veranderen tenzij er aanvullende authenticatiestappen worden gebruikt die dan geen gebruik mogen maken van gegevens die de crimineel ook al had kunnen hebben. Bijvoorbeeld: Als er een verificatievraag gesteld wordt en de crimineel heeft al eerder toegang gehad tot de database met antwoorden dan is die verificatievraag zinloos geworden.

[DJMaze]

Als bcrypt meer dan 9 maanden geleden was ingevoerd, dan was dat dus VOORDAT ze uitlekte.
Dan is @svenslootweg zijn antwoord correct.
Echter heb ik niemand dat zien doen.

Zelf worstelde ik met het feit dat MySQL het niet ondersteund en php nog niet native, en dan was 5.000.000 accounts aanpassen een dagtaak.
Heb toen op de oude hashes sha256 gezet.

Het is allemaal kosten/baten vanuit management, maar wie krijgt nu de schuld?

[monotype]

Als bcrypt meer dan 9 maanden geleden was ingevoerd, dan was dat dus VOORDAT ze uitlekte.
Dan is @svenslootweg zijn antwoord correct.

Inderdaad, en dat was de reden dat ik begon met "Ter verduidelijking"

Zelf worstelde ik met het feit dat MySQL het niet ondersteund en php nog niet native, en dan was 5.000.000 accounts aanpassen een dagtaak.
Heb toen op de oude hashes sha256 gezet.

Als je een hash-op-hash gebruikt voor migratie zal dat waarschijnlijk nooit 'native' door MySQL ondersteund worden, dus je als je je met dit soort migraties bezig houdt zul je sowiso iets in je eigen authenticatielogica moeten 'hacken'. Als die logica geschreven is in PHP, dan ben je inderdaad afhankelijk van wat PHP biedt. Er zijn echter ook andere mogelijkheden - niemand houdt je tegen om vanuit PHP een externe authenticatie-provider te gebruiken. Heeft ook andere voordelen.

Het is allemaal kosten/baten vanuit management, maar wie krijgt nu de schuld?

Sja. Management is niet makkelijk - op basis van incomplete informatie over kosten, waarschijnlijkheden en potentiele impact besluiten nemen... Ik zou zeggen: het management moet diep adem halen, constatteren dat de verkeerde keuzes zijn gemaakt en er van leren, maar helaas is de reflex anders.

[Ossebol]

Kun je dit uitleggen? Want ik neem aan dat je dan de sha1 niet meer opslaat, want die is onveilig. Hoe logt een gebruiker dan in? Een wachtwoord hashen met bcrypt is iets anders dan een hash opnieuw hashen. Dat levert een ander resultaat op. Hierdoor kan een gebruiker dus niet meer inloggen, toch?

[Fabbie]

Pas bcrypt toe op alle wachtwoorden in je database.
- Gebruiker logt in. (gebruiker met sha1 wachtwoord)
- bcrypt hasht het wachtwoord en controleert het met het opgeslagen wachtwoord.
- Komt niet overeen (2 opties, oud wachtwoord of verkeerd wachtwoord)
- Pas sha1 en bcrypt toe op het wachtwoord.

Komt het wel overeen? Dan was dit een oud wachtwoord en kun je nu het nieuwe wachtwoord met alleen bcrypt opslaan.

[fridiot]

Deze aanpak is goed om te migreren tussen hashing methods, maar lijkt mij niet heel handig als de hashes zijn gelekt. Totdat een gebruiker met zijn originele wachtwoord inlogt kan de gelekte sha1-hash als wachtwoord gebruikt worden om in te loggen.

[mjz2cool]

Als je die sha1 hash kunt gebruiken om in te loggen hebben ze toch echt een ander probleem. De inlogfunctie hasht als het goed is het wachtwoord, en vergelijkt deze hash met de opgeslagen hash in de database. Het hele idee van de hash is juist dat je er niets aan hebt als je eraan kunt komen.

Wel is sha1 niet meer veilig genoeg, en als je daar dus het wachtwoord uit kunt halen kun je dus inloggen. Maar dit probleem heb je toch, hoe je het ook migreert. De enige manier om dit te voorkomen is door de wachtwoorden te resetten.

[Xirt]

Je zou ook consistentie toe kunnen passen en SHA1 gewoon kunnen handhaven voor nieuwe wachtwoorden: de extra rekentijd voor SHA1 volgens mij verwaarloosbaar.

Alle oude wachtwoorden in de database hoeven dan alleen opnieuw opgeslagen te worden na BCRYPT toe te passen, omdat deze al in SHA1 stonden. Voor alle nieuwe wachtwoorden eerst SHA1 toepassen en dan BCRYPT eroverheen gooien.

[Annihlator]

Ik vraag mij af of het wel verstandig is een reeds gehasht iets opnieuw te hashen op een andere manier. zou je via die weg niet onbedoeld een zwakte kunnen integreren?

[Xirt]

Ik ben geen security expert, maar als je door een BCRYPT over een hash te gebruiken een zwakte zou creeren dan denk ik dat we BCRYPT in twijfel zouden moeten trekken: BCRYPT zou veilig moeten zijn ongeacht input.

[Annihlator]

Opk precies iets waar ik niet heel veel van weet, maar een goed punt!

[mjz2cool]

Door het opnieuw hashen moet je eerst die 2e hash zien te ontcijferen. Voor die 2e hash is de eerste hash gewoon plain text data. Het heeft dus geen invloed op elkaar qua sterkte/zwakte.

[Annihlator]

Dat klinkt eigenlijk wel logisch idd als ik het zo bekijk

[LopendeVogel]

En de hacker die je wachtwoord heeft kan dit dus ook gelijk doen?

[mjz2cool]

De oude wachtwoorden waren met sha1 gehashed. Als je dan deze nog een keer hashed met een beter algoritme, heb je een compleet andere hash. Daarna check je bij het inloggen niet op de sha1 hash van het ingevoerde wachtwoord, maar met de nieuwe hash van de sha1 hash van dat wachtwoord. Als je dan ook meteen gelijk een nieuwe hash maakt van het wachtwoord, kun je de tijdelijke hash in de database vervangen met deze nieuwe hash.

[Xirt]

Dan moet je wel tot het einde der dagen deze code in je codebase houden, omdat er altijd mensen zijn die lange tijd / nooit inloggen en je dus heel lang / altijd met oude hashes in je database zit. Tenzij je deze natuurlijk op een gegeven moment opschoont (maar dat waarschijnlijk weer andere gevolgen; bijv. het niet langer beschikbaar / toegankelijk zijn van het account).

[RoestVrijStaal]

Dit gaat goed, totdat sha1 definitief niet ondersteund wordt door de programmeertaal en dito framework(s) waarmee je werkt.

Dus mag je zelf in de nabije toekomst een sha1-library onderhouden wil je op jouw manier verder gaan. Daar zit je hopelijk niet op te wachten

Oftewel, je opgeslagen hashes herhashen is een workaround.

Het liefst migreer je zonder dat de gebruiker het merkt door tijdens het login-proces -indien een succesvolle login- het gebruikte wachtwoord te hashen met een nieuwe hashmethode en na een bepaalde tijdspanne iedere gebruiker die nog niet gebruik maakt van de nieuwe hashmethode een wachtwoord-reset sturen of simpelweg de sha1-gehashte wachtwoord weggooien waardoor ze wel hun wachtwoord moeten resetten.

[Reactie gewijzigd door RoestVrijStaal op 22 juli 2024 23:17]

[3raser]

Ik moest even op de website van Flipboard kijken wat het precies was. Maar nu ik het logo heb gezien denk ik, stond dit niet standaard op veel Samsung telefoons?

Bijzonder dat deze hackers maandenlang ongestoord hun gang konden gaan. Ook wel bijzonder dat het criminelen worden genoemd en geen hackers. Is daar een bijzondere reden voor? Niet alle hackers zijn crimineel natuurlijk maar de term hackers zou in deze context iets beter passen lijkt me.

[Cergorach]

Ook wel bijzonder dat het criminelen worden genoemd en geen hackers. Is daar een bijzondere reden voor? Niet alle hackers zijn crimineel natuurlijk maar de term hackers zou in deze context iets beter passen lijkt me.

Inbreken op een computersysteem zonder toestemming is een misdrijf, dus ben je per definitie een crimineel als je dat doet.

@3raser Je linkt naar artikelen geschreven door drie verschillende schrijvers. Dit bron artikel heeft het niet over hackers of criminals, het bron artikel over het gijzelen van de MongoDB databases (welke ook door Tijs) is geschreven heeft het wel specifiek over hackers en alleen over crimineel gedrag. Tijs lijkt dus, als het bron artikel gebruikt maakt van de term hackers, gebruik te maken van hackers.

Net zoals hij dat in deze artikelen heeft gedaan:
nieuws: Criminelen downloaden 117.000 cv's van UWV via werkgeversaccount - up...
https://blog.malwarebytes...rcent-more-threats-in-q1/

Hier is dan weer enige inconsistentie:
nieuws: Gemiddeld losgeldbedrag stijgt door geavanceerdere ransomwarevarianten

Na anderhalve maand is dat wellicht redelijk consistent te noemen?

Wat andere schrijvers er van maken is natuurlijk geheel afhankelijk van de schrijvers.

[Reactie gewijzigd door Cergorach op 22 juli 2024 23:17]

[3raser]

Maar waarom werden diezelfde criminelen een paar dagen geleden dan nog gewoon hackers genoemd?

nieuws: Hackers vragen losgeld voor gijzelen 12.000 openbare MongoDB-databases

nieuws: Justitie VS klaagt Chinese hackers aan voor diefstal gegevens 78 milj...

Of criminele hackers...

nieuws: Criminele hackers persen Duits it-bedrijf af dat voor Oracle en Airbu...

[Reactie gewijzigd door 3raser op 22 juli 2024 23:17]

[SoufyanH]

Ja, dat is wat ik ook precies dacht. Die logo komt mij zo bekend voor. Begrijp alleen niet hoe dat het kan dat ze 9 maanden lang ongestoord hun ding hebben kunnen doen?

[Kevinp]

Als jij in zo'n systeem zit verzamel je ook zo veel mogelijk gegevens. En ga je proberen dit niet bekend te maken. Althans dat kan ik me voorstellen.

[SoufyanH]

Ja als hacker zou ik het zeker niet bekend maken, maar ik bedoel als bedrijf zijnde. Dan zou je er toch wel achter moeten komen dat er iemand in je systeem zit. Of de beveiliging is echt bar slecht.

[Dalyxia]

jup, op mijn oude Galaxy S5 zit het in de categorie, "ik wil het niet maar ik mag het niet van de telefoon verwijderen van samsung"

[stuiterveer]

Niet alle hackers zijn crimineel natuurlijk

En daar heb je je reden, de term "hacken" staat niet direct in verbinding met illegale activiteiten (dat de Van Dale dit wel met elkaar in verbinding lijkt te brengen is in mijn ogen zeer kwalijk). Lees vooral ook de toelichting op Wikipedia: https://en.wikipedia.org/wiki/Hacker

Om een (extreme) vergelijking te maken: tussen terroristische groeperingen zitten moslims, maar om direct ook alle moslims terrorist te noemen?

[Onno]

Flipboard herstelt wachtwoorden

zijn de wachtwoorden van alle gebruikers van het platform teruggezet

Dat lijkt me twee keer een verkeerde vertaling van "reset". Het lijkt nu alsof eerder ingestelde wachtwoorden weer gebruikt kunnen worden, maar dat is volgens de oorspronkelijke tekst dus juist niet zo: een wachtwoord resetten betekent dat het wachtwoord juist verwijderd wordt.

[TijsZonderH]

Ja dank, is aangepast. Beetje lost in translation zo

[SeismicCharge]

Er staat nog steeds "zijn de wachtwoorden van alle gebruikers van het platform teruggezet".

[Adhati]

Begrijp ik hier goed uit dat het artikel simpelweg gekopieerd en vertaald is, zonder er verder over na te denken of in ieder geval uit eigen inzicht te schrijven?

[Core2016]

Nee dat begrijp je niet goed.

[RVervuurt]

Geachte Redactie

[gunghir]

Oh die flipboard app. Die steeds op een ontzettend irritante manier terug komt op mijn galaxy edge 7. Denk dat ik hem wel 6 keer opnieuw moest uitzetten. Na elke grote update.

Mischien stoppen ze er nu wel mee.

[Tha]

Toch wel apart dit allemaal. ik ben een Flipboard gebruiker van het eerste uur en gebruik het meerdere malen per dag.
maar dit gaat er bij mij niet in. iemand nog een alternatief wat een beetje te doen is?

[o.verhie]

Ook ik had dat opdringerige Flipboard op mijn galaxy S7 staan. Betekent dit dat ik daar (ongevraagd) een account heb, onderwater gekoppeld aan een Google en/of Samsung account, of moet je dan in de app ook nog geregistreerd hebben?