KLM bevestigt datalek bij accounts in Flying Blue-spaarprogramma

Luchtvaartmaatschappijen KLM en Air France bevestigen dat kwaadwillenden mogelijk privégegevens van Flying Blue-klanten hebben ingezien. Er zouden geen betaalgegevens zijn buitgemaakt, zeggen de maatschappijen.

KLM: veilig lang wachtwoord? Mag niet

Het datalek is gemeld bij de Autoriteit Persoonsgegevens en bij de Franse evenknie CNIL, bevestigt de maatschappij aan Tweakers. "We betreuren deze situatie", aldus woordvoerder Caroline van der Veeken. Het is onbekend om hoeveel klanten het ongeveer gaat. Volgens de luchtvaartmaatschappij zijn er geen paspoort- of creditcardgegevens buitgemaakt. Wel kunnen het telefoonnummer, het mailadres en de laatste transacties van klanten zijn ingezien.

De meldingen van klanten verschenen sinds vrijdag online. Daaruit bleek al dat KLM de wachtwoorden van klanten had gereset om ongeoorloofde toegang te voorkomen. Klanten konden via Wachtwoord Vergeten op de site een nieuw wachtwoord aanmaken. De luchtvaartmaatschappij heeft getroffen klanten op de hoogte gesteld.

KLM staat bij zijn Flying Blue-accounts geen lange wachtwoorden toe; ze moeten tussen acht en twaalf karakters lang zijn. Minder lange wachtwoorden zijn doorgaans makkelijker te kraken, ook als ze hoofdletters en symbolen bevatten. Het is onbekend hoe het datalek heeft kunnen gebeuren; KLM zegt niets over de oorzaak.

Reacties (114)

[Pompi]

Wat ik in dit bericht wel mis en Het Parool wel meldt is dat de getroffen personen dit weekend blijkbaar al een bericht hebben gehad

KLM waarschuwde dit weekend leden van Flying Blue dat hun gegevens mogelijk zijn buitgemaakt na ‘verdacht gedrag door een ongeautoriseerde entiteit’, jargon voor digitale dataroof.

[...]Volgens het bericht aan getroffen klanten zijn er geen creditcardnummers of betaalgegevens gelekt.

Waardoor je een beetje kan concluderen of je wel of niet getroffen bent, door te zien of je de mail gehad hebt. Hadden ze dit ook niet aan alle klanten moeten melden zodat mensen hun gegevens in de gaten konden houden?

En ook dat alleen van getroffen klanten de toegang geblokkeerd is, dit artikel lijkt beetje te zeggen alsof het voor alle klanten is.

Van de getroffen klanten is de toegang tot Flying Blue geblokkeerd.

[Reactie gewijzigd door Pompi op 22 juli 2024 13:36]

[SunnieNL]

Ben wel benieuwd inderdaad of KLM weet om welke accounts het gaat en alleen hen hebben ingelicht. Want ik heb geen email gezien, en kan nog inloggen met mijn oude wachtwoord.

[Csotranme]

Blijkbeer weten ze dat inderdaad. Anders hadden ze alle deelnemers wel een mail gestuurd lijkt me.

Mijn nieuwsgierigheid blijft dan wel hoe ze dan precies aan die gegevens gekomen zijn en hoe KLM zo zeker weet dat er niet meer op straat ligt.

Als ik FB/KLM was geweest had ik sowieso iedereen een mail gestuurd en iedereen zn wachtwoord laten resetten maarja dat is een afweging die ze dan maken...

[Barsonax]

Als ze dan ook gelijk even complexe wachtwoorden toestaan ipv deze stil te truncaten

[KoffieAnanas]

Zonder de precieze situatie te kennen, kan ik me voorstellen dat het veld in de database is ingesteld op een string met een bepaald aantal max karakters, zeg 32. Dan staat er geen expliciete truncate in de code. Als je dan een wachtwoord langer dan 32 karakters opgeeft, dan slaat de database alleen de eerste 32 karakters op. Een slordigheidje in het ontwerp, maar het hoeft in dat geval geen bewuste beslissing te zijn geweest van de programmeur/ontwerper.

[Barsonax]

Mijn punt is dat het juist wel een bewust aandachtspunt had moeten zijn. Als developer is assumption the mother of all fuckups.

En wat CodeCaster al aangeeft dit is heel verdacht en het zou zo kunnen dat die wachtwoorden plain text in een tabel staan wat best kwalijk is. Nu is dat geen aanname maar een hypothese:).

Ik hoop eerlijk gezegd dat het gewoon de validatie code zelf is die iets te enthousiast met de string omgaat.

Nog wel even los van dat de maximale lengte niet echt bepaald lang was. Zeker geen 32 maar eerder ergens onder de 16.

[Reactie gewijzigd door Barsonax op 22 juli 2024 13:36]

[CodeCaster]

Wachtwoorden worden gehasht opgeslagen, de hash heeft ongeacht de input dezelfde lengte.

Als het wachtwoord niet gehasht wordt, is dat bewuste incompetentie van iedereen die bij het systeem betrokken is geweest. Als je een database gebruikt die stil truncatet, ook.

[Stpan]

We kennen de architectuur niet goed en weten niet welke databanken zijn binnengedrongen en buitgemaakt.

De KLM zal hier vanuit strategisch belang geen details over prijsgeven en cybercriminelen niet wijzer te maken dan ze zijn.

Het zou ook kunnen dat dit hele 'binnendringen' eigenlijk inhoudt dat een medewerker zijn user account is misbruikt, en er daarom nooit meer data buit kan zijn gemaakt dan waar die ene KLM medewerker toegang toe had.

Zo krijg je bij de KLM een andere klantenservice als je via 'award miles' tickets boekt dan wanneer je 'gewoon' betaald hebt. Als de 'award miles' medewerker zijn inloggegevens zijn losgepeuterd of geraden door een derde partij, dan hoef je de accounts van klanten die nog nooit een ticket hebben geboekt op Award Miles ook niet te blokkeren.

(Met de aanname dat de KLM de user account management zo inricht dat het ene team geen toegang heeft tot betaalstatus en gegevens, en de ander niet tot airmiles balans en met airmiles geboekte vluchten en vice versa)

Die medewerker zal heus de wachtwoorden niet hebben kunnen inzien. Maar wel de email addressen en flyingblue klantnummers, waarmee je kunt inloggen. Als de 3e partij deze verworven inloggegevens weet te combineren met wachtwoorden die mensen vaak hergebruiken, is het beter om je klanten het wachtwoord te laten resetten (hoewel dat nog geen garantie is dat de klant niet een ander makkelijk te raden if eerder gebruikt password kiest). Maar dat hoeft dus niet voor alle gebruikers, als die 'derde entiteit ' überhaupt nooit bij andere klantengegevens heeft kunnen komen.

[Reactie gewijzigd door Stpan op 22 juli 2024 13:36]

[mduijm]

Ik heb een mailtje van ze gehad en moest mijn wachtwoord bij KLM updaten. Wat vreemd was dat ik met oude ww wel op de FB pagina kon inloggen.

Wachtwoord gereset en idd ik wilde aanpassen naar 16 karakters. Maar dat pakte hij niet. Ik vind 12 echt te weinig.

[Csotranme]

Andere media benoemen niet eens dat niet alle accounts getroffen zijn.

Ik was al aan het zoeken maar ik heb geen mail gehad... Ik kan er dus blijkbaar vanuit gaan dat mijn account niet getroffen is.

Uit voorzorg toch maar even mijn wachtwoord resetten....

[b12e]

Ik heb de mail inderdaad ook gehad vorige week. Het kwam me een beetje over alsof specifiek mijn account getroffen was.

Screenshot: https://imgur.com/a/yn0i1k8

[phizzie]

Dank voor het delen. Het is alsnog wel schrikbarend om te zien dat met deze gegevens er duidelijk high-potentials uitgevist kunnen gaan worden voor spearphishing.

Een duidelijk voorbeeld waarom je misschien ook verschillende mailadressen kunt inzetten.

[RobbieB]

"KLM staat bij zijn Flying Blue-accounts geen lange wachtwoorden toe; ze moeten tussen acht en twaalf karakters lang zijn. Minder lange wachtwoorden zijn doorgaans makkelijker te kraken, ook als ze hoofdletters en symbolen bevatten."

Dit is mijns inziens een schoolvoorbeeld van nalatigheid en zou alleen al genoeg moeten zijn om een fikse boete van de AP te rechtvaardigen.

[CH4OS]

Maar 32x een 1 als wachtwoord is óók geen definitie van een veilig wachtwoord. Met andere woorden: een lang wachtwoord, meer dan 12 tekens is niet oer definitie veiliger.

[Reactie gewijzigd door CH4OS op 22 juli 2024 13:36]

[Teun!]

Desondanks denk ik dat 32x1 veiliger is dan 8-12 x1 zeg maar. 12 karakters is wel echt ontzettend achterhaald. Zelf rapporteer ik dit altijd als een bug als ik dit tegenkom. Kan niet met opzet zo zijn, toch . Erg frustrerend, tegenwoordig moet je op zn minst tot 100 karakters toelaten mijn inziens.

[Reactie gewijzigd door Teun! op 22 juli 2024 13:36]

[mjtdevries]

Bij hoeveel banken heb je het al moeten rapporteren?
Want toen ik lange wachtwoorden ging gebruiken ging dat overal goed, behalve bij de banken.

[Teun!]

Ik gebruik maar 2 banken waarvan ik er inderdaad bij 1 een melding heb gedaan (ING) vanwege korte wachtwoorden en (in elk geval toendertijd, én geen fatsoenlijke 2fa). Wel een tijdje geleden overigens

[PikachuNL]

Heb ik toen ook gemeld bij de ING, op twitter weliswaar. Support agent vond mij maar een rare snuiter met m'n lange wachtwoorden.

[CH4OS]

KLM is ook niet de enige die een maximale lengte aan het wachtwoord stelt. SkyShowtime heeft hetzelfde probleem en zo zijn er nog wel meer diensten die dit (helaas) doen. Vervolgens ook allerlei randzaken dichtzetten, waardoor autofill vanuit password managers bemoeilijkt wordt e.d.

[mcmd]

De langste wachtwoord dat ik gebruik heeft 96 karakters. Meeste veel minder. Vind je het echt nodig dat je minstens tot 100 karakters moet toestaan? Zelf vind ik een ondergrens van 32 karakters acceptabel.
Eigenlijk is het beter om een minimum kwaliteit van een wachtwoord te vragen. Keepass heeft een voorbeeld algoritme om dit te meten. Voor bank accounts zou je dan een beter kwaliteit wachtwoord moeten hebben dan bijvoorbeeld hier bij tweakers. Maar goed, dat is uiteindelijk ook niet waterdicht, blijft moeilijk.

[ApexAlpha]

Als alle andere variabelen gelijk zijn is een langer wachtwoord beter. Dat is gewoon juist en deze limitatie bij KLM is erg slordig.

[mjtdevries]

Het is vooral erg vreemd. Waarom zou je een wachtwoord kunstmatig tot maar 12 karakters limiteren?
Wie bedenkt zoiets?

Overigens zullen de meeste mensen kortere wachtwoorden gebruiken en het lijkt me ook niet de oorzaak van het datalek. Dus waarom daar zoveel aandacht voor?

Of een wachtwoord nu lang of kort is. Na een beperkt aantal foutieve inlogpogingen ga je een vertraging inbakken zodat iemand niet een wachtwoord kan brute-forcen.
En datalekken gebeuren meestal niet door het massaal brute-forcen van wachtwoorden.

[Reactie gewijzigd door mjtdevries op 22 juli 2024 13:36]

[ApexAlpha]

In grotere, oudere bedrijven heb ik dit nog wel eens gezien omdat het huidige programma vroeger (of nog steeds!) aangesloten moest worden op een ouder systeem, en dat daar dan de limitatie zat.

Bij ING kon je heel lang geen wachtwoord doen langer dan 20 tekens. Wie weet welk mainframe uiteindelijk daarvoor verantwoordelijk was...

[TheDragonNL]

Uit betrouwbare bron kan ik vertellen dat de beperking niet het mainframe was (max 100 posities), maar een zeer oude C-applicatie die maar 8 lang aan kon

[Zyppora]

Het punt is natuurlijk dat een dusdanig lage bovenlimiet op de lengte van het wachtwoord ronduit achterlijk is. Daar mag inderdaad best wat van gezegd worden. Mijn volgende vragen zijn dan meteen: wat is er verder nog mis? Zijn die wachtwoorden wel gehashed en gesalted opgeslagen? Zo ja, is dat wel met een veilig hashing algoritme gedaan? Hoe zit het met de admin pagina? Dat mensen vervolgens 12x of 32x een 1 als wachtwoord aanhouden, doet niets af aan de verplichting die dat systeem heeft voor de juiste beveiliging te zorgen.

Daarnaast kan het systeem natuurlijk afdwingen dat een gekozen wachtwoord een bepaalde entropie heeft, en dat 32x een 1 niet sterk genoeg is. Maar het feit dat ze wachtwoorden limiteren op 12 karakters vertelt me dat zoiets ook niet ingeregeld is, maar dat er puur gekeken wordt of er wel een hoofd/kleine letter en een cijfer in zit.

[CH4OS]

Sterker nog, het is (in elk geval in combinatie met PHP) betrekkelijk simpel om een "levend" systeem te maken die automatisch opnieuw de passwords opnieuw hashed en opslaat wanneer een nieuw/ander algoritme voor het hashen gebruikt wordt in PHP. Zie daarvoor password_hash() en password_verify() functies.

Bij een van mijn vorige werkgevers deze functie mogen implementeren toen de AVG geïmplementeerd werd.
Dat was bij dat bedrijf best een toverwoord om dingen geregeld te krijgen.

[C-asper]

Dat laten ze dan weer niet toe, zelfs zonder de limiet van 12 karakters

[Keypunchie]

Het gaat erom dat het mogelijk moet zijn om jezelf goed te beschermen.

Flying Blue is wat dat betreft erg mager, hoewel ze hebben geprobeerd dingen te verbeteren.

Vroeger was de beveiliging een 4-cijferige pincode, lol.

[jleijdekkers]

Als "1" het enige toegestane teken was, dan nee. Maar als je verder gewoon redelijk vrij bent qua wat je in mag vullen is 32x een 1 best een veilig wachtwoord.

[Cid Highwind]

Als het jou en handig idee lijkt 32x1 als paswoord te hagreren, is er vast een hacker die even handig is om zoiets op een lijst te zetten als eerst te proberen paswoorden bij hackpogingen.

Als ik een programma zou schrijven om dat te doen zou ik eerst dergelijke opties proberen voordat ik het programma complexere constellaties laat gokken.

Dat is de reden waarom het als onveilig wordt gezien en waarom een goede site of paswoordmanager nooit paswoorden van enkel getallen accepteert respectievelijk genereert, maar altijd letters en tekens toepast.

[Blokker_1999]

11111111111111111111111111111111 kan perfect een veilig wachtwoord zijn. Het heeft er sowieso de lengte voor. Maar wat dan vooral belangrijk wordt is: welke karakters sta je nog toe? Als je alles van karakters toestaat wordt het heel moeilijk om te gaan brute forcen daar je als aanvaller niet weet dat het wachtwoord uit een mogelijks onbekend aantal dezelfde karakters bestaat. Dat is waar het om draait uiteindelijk.

[paella]

Als je alleen brute-force aanvalt wel ja, maar een slimme hacker gaat natuurlijk ook voor de hand liggende wachtwoorden proberen buiten BF om.... dus 32x 1 is niet veilig.

[rik86]

Maar hoeveel voor de hand liggende wachtwoorden zijn er als je wachtwoord tussen de, pak 'm beet, 16 en 50 tekens moet zijn?

Als er niet op een makkelijke manier verschillende wachtwoorden geprobeerd kunnen worden, is zelfs 32x het zelfde teken best wel veilig.

[Jermak]

Moet je wel goed tellen en geen type fouten maken

[Kevinp]

32x1 als ww is behoorlijk oke. Maakt het echt uit of het heel complex is?

Want waarom zou je 32x1 gokken?

geautomatiseerd gokken gaat net zo snel met random tekens. Maar als je lengthe onbeperkt is wordt het wel erg lastig.

[pc-freakz]

Onjuist, een lang simpel wachtwoord is veiliger dan een kort complex wachtwoord.
Al is het beste natuurlijk lang en complex (mits dat te onthouden/via een password manager is).

De reden? Wachtwoorden worden geregeld d.m.v. brute force gekraakt. Korter is sneller. Tenzij je natuurlijk weet dat het allemaal cijfers zouden zijn, dan doet de lengte er niet toe in dit geval. Websites/apps die karakters limiteren zijn dus eigenlijk niet zo slim bezig, dat kraken is eenvoudiger omdat je karakters kan uitsluiten. Nog erger is een bepaalde set verplichten, een bepaald teken tussen karakter 4 en 7 bijv.

2e reden is dat een lang wachtwoord anders wordt verwerkt door bijvoorbeeld Microsoft Server. Het kapen van je wachtwoord via een geheugen dump of andere proces aanval is veel moeilijker als het een lang wachtwoord is. Lang als in groter dan 28 karakters waar dit vroeger bijvoorbeeld meer dan 14 karakters zou moeten zijn.

Grappige is wel weer dat zo een lang en complex wachtwoord ook met een pincode vrijgegeven kan worden bij o.a. Windows 10, 11 en bijvoorbeeld je iPhone of iPad (los van biometrie).

[Grauw]

Je vraagt je ook af wat de reden is voor zo’n restrictie. Net als beperkingen op welke tekens je mag gebruiken, wat je ook wel eens ziet. Ik snap niet waarom je dat zou doen.

Als ik het mij goed herinner was het wachtwoord bij Flying Blue vroeger geloof ik zelfs een vijfcijferige numerieke code. Daar zijn ze gelukkig wel van afgestapt.

[Reactie gewijzigd door Grauw op 22 juli 2024 13:36]

[C-asper]

Een beperking is er meestal omdat het database veld van een bepaalde lengte wordt voorzien. Al zou dat erop wijzen dat wachtwoorden in zijn geheel onversleuteld opgeslagen worden. Eens versleuteld krijgt eender welk wachtwoord een hash met meestal een gelijkaardige lengte, ongeacht de lengte van het wachtwoord. De beperking is dus totaal nutteloos, tenzij je het wachtwoord effectief onversleuteld zou bewaren.

[ultimasnake]

De maximale lengte op een database veld lijkt me echter ook niet logisch want er zijn, naar mijn weten, geen restricties op de lengte van je naam, e-mailadres etc. Als het een lengte restrictie is zouden ook die velden niet langer mogen zijn dan 12 tekens. Een harde limiet op basis van de software lijkt me hoe dan ook niet gezien haast elke database de mogelijkheid biedt om een veld uiteindelijk van meer tekens te voorzien, dat kon zelfs in Access

[Teun!]

Volgens mij komt die tekenbeperking van origine uit luiheid, om geen input sanitization toe te hoeven passen. Kan het fout hebben dus ben benieuwd wat anderen hiervan denken.

[johnbetonschaar]

Dat, en waarschijnlijk omdat de gedachte is dat mensen dan minder makkelijk te raden passwords kiezen en ze op die manier dus tegen zichzelf beschermd worden.

[djiwie]

Vermoedelijk een databaseveld wat niet langer is in combinatie met afwezigheid van hashes. Als er een hashfunctie (i.c.m. salt) gebruikt wordt maakt de lengte niet uit omdat de hash per definitie een vaste lengte heeft.

[lenwar]

Historisch gezien zou het voor de lengte een belastingding kunnen zijn. 12 karakters versleutelen/hashen is lichter dan 30 karakters versleutelen, maar dat is in de huidige tijd natuurlijk niet meer van toepassing.

De opslag in een database zou niet moeten uitmaken, aangezien de meeste applicaties wachtwoorden hashen, waardoor ze allemaal (even) ‘lang’ zijn. (Kort door de bocht)

Beperkingen op karakters is veelal een gemaksding. Het kan soms best een gedoe zijn om met alle speciale karakters rekening te houden. Spaties, accentjes, enz zijn gewoon vaak gedoe.
Heel veel diensten doen het. Zo laat de RFC voor SMTP toe dat je een spatie of tab in je e-mailadres mag hebben voor het apenstaartje.
De meeste mail programma’s gaan er goed mee om, maar probeer het maar met de registratie op een website. Prettige wedstrijd.

[ge-flopt]

Wat zou de gedachte gang zijn om voor zo'n korte wachtwoorden te gaan als bouwer van dit soort software?

[Ryen]

Het betreft vaak (zeer) oude software, die misschien qua vormgeving gemoderniseerd is, maar onder de motorkap niet. En zoals @C-asper hierboven ook al zegt doet dit vermoeden dat er niet of onvoldoende wordt versleuteld. Ook kan (oude) techniek niet altijd speciale karakters accepteren.

Natuurlijk had dit allang aangepast moeten worden, maar aangezien dit niet direct aan de business gerelateerd is is er vermoedelijk geen prioriteit aan gegeven. Slechte zaak.

[R4gnax]

Ach. Kan altijd nog erger.

Neem bijv. Ziggo en hun zakelijk Ubee modem. Bij consumenten die problemen ervaren met de feitelijk fabrieksdefecte ontwerpen v/d Puma chipsets in de Connectboxes, wordt die ook aan consumenten verstrekt, met een custom Connectbox-branded UI laagje er overheen gesmeerd.

Bij eerste inlog moet je daar een wachtwoord instellen. Als je daar iets invult wat langer is dan 12 tekens vreet ie dat als koek, maar onder de kap wordt het gewoon getrunceerd. (Alles na het 12e teken valt weg.)

Dat gebeurt niet als je dat zelfde lange wachtwoord weer opnieuw invult om in te loggen. Dan faalt je login gewoon. Ondanks dat je wachtwoord toch echt 'correct' was.

KLM heeft hier tenminste nog een nette user interface gemaakt die indrect toegeeft dat het prutsers zijn. Bij Ziggo's modem moet je toevallig maar net raden dat bovenstaande het probleem is. (Ik wist gelukkig dat die 8 of 12 tekens truncering 'een dingetje kon zijn' - dankzij oude ervaringen met bagger PHP websites uit de jaren 90 die hetzelfde probleem haddden.)

[Reactie gewijzigd door R4gnax op 22 juli 2024 13:36]

[MarcoC]

Dat is helemaal niet erger. Modems zijn niet toegankelijk vanaf internet en bevatten geen persoonsgegevens.

[R4gnax]

Gezien vanaf hoe slecht de implementatie is.
Niet vanaf hoe slecht de gevolgen kunnen zijn.

[mjtdevries]

Ik heb ditzelfde probleem bij meerdere publieke sites gehad. O.a. een grote Nederlandse bank.
Ook een site die zei dat mijn wachtwoord te kort was, terwijl ie dus te lang was.

[MarcoC]

Mijns inziens is alleen het tweede relevant. De eisen die je stelt aan je ontwerp volgen namelijk uit de mogelijke gevolgen als het misgaat.

[DedSec85]

Als een dergelijke boete dan ook eens bij de gedupeerden terecht zou komen wel ja.....
Een boete is leuk, maar de meeste bedrijven berekenen dat door in hun prijskaartje richting de klant.

[RobbieB]

Het is natuurlijk niet alleen een boete. De boete komt samen met verhoogd toezicht waarin de KLM onder andere met een oplossing voor deze tekortkomingen moet komen en aan moet tonen hoe ze de rest van de security op orde hebben.

De zichtbare boete is vaak maar een (klein) deel van de daadwerkelijke straf en werklast die een bedrijf na zo'n incident door een autoriteit krijgt opgelegd.

[Mathijs22]

Een boete is leuk, maar de meeste bedrijven berekenen dat door in hun prijskaartje richting de klant.

En welke andere inkomsten heeft KLM?

[daimo]

Dit was de reden waarom ik mijn account enkele maanden geleden heb opgezegd.

Had hen nog een bericht gestuurd om deze praktijk aan te klagen, maar uiteraard geen reactie op gekregen.

[SunnieNL]

Ze beperken ook nog de tekens die je kan gebruiken in het wachtwoord, waardoor het nog simpeler wordt

Tekens toegestaan:$ @ & + - / # _ ? !

[Malfoi]

Eens, zou niet meer toegestaan mogen zijn.

Echter is er bij KLM/AF de optie voor 2FA, dus een alternatief voor dat 12-tekens-tellende wachtwoord is er wel.

[kodak]

Het lijkt me sterk dat deze luchtvaartmaatschappijen zelf hun 'loyalty' diensten verzorgen. Dit soort diensten is meestal in handen van andere dienstverleners of bedrijven, waar bedrijven het kunnen inkopen of het laten verwerken. Het lijkt me dus dat er duidelijkheid nodig is waar het probleem kan zitten, niet alleen wie er eindverantwoordelijk is over de klantgegevens.

[b12e]

Ik ben er relatief zeker van dat Flying Blue inhouse wordt beheerd door de Air France-KLM groep en de gegevens ook door AFKL worden bewaard (AFKL de data controller).

Ik ken namelijk een aantal mensen die er rechtstreeks en onrechtstreeks aan bijdragen.

Wat wel uitbesteed wordt is het kunnen aankopen van miles of uitwisselen (omzetten) van punten naar miles met andere loyalty programs, dat wordt verzorgd door https://www.points.com/

[2right]

Was vroeger in house. Ik heb er wel eens gewerkt op project. Zaten toen ergens in kantoorgebouw langs ring Amsterdam. Was wel leuk met allemaal verschillende nationaliteiten die telefoon aannemen. Systeem leek verder redelijk simpel (toen nog oude terminal applicatie met windows schil eromheen voor de minder ervaren medewerkers).

[SunnieNL]

KLM blijft hoofdverantwoordelijk voor de diensten die zij leveren aan hun klanten. Wie de uiteindelijke automatiseerder erachter is maakt in dat geval niet zo veel uit. Dat is iets tussen KLM en hun supplychain. Daar hoort KLM afspraken over te maken en die hoort het ook te controleren.

[danda]

volgens mij hebben ze niet eens 2FA.... schandalig

[Plopeye]

Toch vreemd dat ik dus wel degelijk 2FA op mijn account heb. Bij inloggen op FB moet ik een per SMS gestuurde code ingeven.

Ik heb ook geen mail ontvangen...

Wel vraag ik mij af of ook mijn gegevens gecompromitteerd zijn.

[Pompi]

Volgens Het Parool hebben alleen getroffen mensen bericht ontvangen, dus trek je eigen conclusie of je gegevens gecompromitteerd. Ik houd even slag om de arm, want wie weet zijn ze nog bezig met berichten te sturen, al zou iedereen het dit weekend al gehad moeten hebben.

[b12e]

Da's geen 2FA.

Sinds kort kan je inloggen met username+wachtwoord of met een TOTP code die via email of SMS wordt bezorgd.

De TOTP code is geen aanvulling op je wachtwoord, maar een alternatief voor.

https://imgur.com/a/IQ8Ep5v

[Reactie gewijzigd door b12e op 22 juli 2024 13:36]

[Malfoi]

Jawel, ik gebruik 2FA bij KLM/FA. Via sms of via e-mail, je hebt de keus.

Edit: bij flyingblue.com dus, niet bij KLM of AF direct. I stand corrected.

[Reactie gewijzigd door Malfoi op 22 juli 2024 13:36]

[b12e]

Nee hoor, da's 1FA.

Je logt in met Email/password OF Email/OTP via SMS of email.

2FA zou aangeven dat je inlogt met wachtwoord + TOTP.

https://imgur.com/a/IQ8Ep5v

[Malfoi]

Oh ja, je hebt gelijk.

[Fab1Man]

Het gaat daar behoorlijk fout qua password policy. Qua speciale tekens zelf een restrictie welke tekens toegestaan zijn.

Tenminste 1 cijfer (0-9)
Tenminste 1 hoofdletter (A-Z)
Tenminste 1 kleine letter (a-z)
Tussen 8-12 tekens
Tekens toegestaan: @ $ & + - / # _ ? !

Mijn wachtwoord was niet gereset, ik kon dus met mijn oude wachtwoord net gewoon inloggen.

Tevens moet je je wachtwoord niet herhalen bij wijzigen, dus als je deze verkeerd opslaat heb je pech.
2FA is ook NIET mogelijk.

[Reactie gewijzigd door Fab1Man op 22 juli 2024 13:36]

[Pompi]

Volgens Het Parool zijn alleen getroffen klanten gecontacteerd en alleen bij hun is de toegang geblokkeerd. In mijn eigen comment verbaas ik mij er al over, want denk dat iedereen wel wil weten dat ze misschien hun data/gegevens even goed in de gaten moeten houden.

[Groningerkoek]

Het zal een afweging zijn, hoe moeilijker de wachtwoorden hoe meer mensen aan de telefoon dat ze niet meer bij hun account kunnen komen

[Malfoi]

Na het invullen van mijn gebruikersnaam/e-mail kwam automatisch de 2FA optie, óf sms óf e-mail met code. Lijkt me dus dat je dat wel aan kan zetten inmiddels.

Excuus, klopt niet. Gaat alleen op voor flyingblue.com, niet voor KLM/AF.

[Reactie gewijzigd door Malfoi op 22 juli 2024 13:36]

[djiwie]

Niet alle klanten zijn getroffen. Ik heb een actief KLM + FlyingBlue account maar geen mail gezien en kon nog met dezelfde credentials inloggen op KLM.nl. FlyingBlue heeft wel (op een lelijke manier) de login uitgezet.

[Timmy]

Ik heb inderdaad ook geen mail gehad maar voor de zekerheid wel mijn wachtwoord gereset.

Elders lees ik dat de mensen die wel een mail hebben gehad ook van Awardwallet gebruik maken. Wellicht is daar iets mis gegaan.

[jmvdkolk]

Zelf heb ik geen mail. Mijn zoon heeft wel een mail gehad en zijn wachtwoord moeten resetten. Hij liep ook gelijk tegen de restricties aan omdat zijn gegenereerde wachtwoord niet geaccepteerd werd.

Mijn zoon gebruikt geen Awardwallet (net nagevraagd).

[CyBeR]

FlyingBlue heeft wel (op een lelijke manier) de login uitgezet.

Als je bedoelt dat je met een sms-code moet inloggen, dat is al langer zo, maar geldt alleen voor de FB website en niet voor bijvoorbeeld klm.nl.

[djiwie]

Nee ik bedoel dat de login knop gewoon niet meer werkend is (of was eigenlijk, want ik zie dat het nu weer werkt). Die sms login was inderdaad al een tijdje.

[JPDeckers]

Vroeger had FlyingBlue een pincode van 4 cijfers. Dus 8-12 chars was al met al vooruitgang

[Snowpop]

Kan niet meer inloggen en registreren sinds een kwartiertje, misschien zijn ze toch iets aan het verbeteren achter de schermen...

[errox]

Dit soort bedrijven melden altijd "trots" dat er geen betalingsgegevens gelekt zijn. Nou, ik ben liever mijn (vervangbaar) creditcard nummer 'kwijt' dan mijn persoonsgegevens.