Az X (korábban Twitter) a twitter.com → x.com domainváltás következő lépéseként a hardveres biztonsági kulcsokat és passkey-eket is át akarta költöztetni az új címre. A terv papíron egyszerű volt: november 10-ig minden érintett felhasználónak újra kell regisztrálnia a YubiKey-ét vagy passkey-ét az x.com alatt. A gyakorlatban viszont sokaknál hibaüzenetek, végtelen újraregisztrációs hurkok és teljes fiókzárolás lett a vége, ezért a mérnököknek sürgősen vissza kellett tekerniük a változtatások egy részét.
Kontextus: miért kellett egyáltalán hozzányúlni a 2FA-kulcsokhoz?
A WebAuthn / FIDO2 alapú biztonsági kulcsok nem csak a felhasználóhoz, hanem konkrétan a szolgáltatás domainjéhez is kötődnek. Ez a „relying party ID”, vagyis az a név, amelyhez a kulcs kriptográfiai bizalmat társít. A Twitter-korszakban regisztrált kulcsok a twitter.com domainhez lettek hozzákötve, így az X teljes átállása x.com-ra azt jelenti, hogy a régi kulcsokat is új domainhez kell regisztrálni.
A TechCrunch már október végén jelezte: az X hivatalosan figyelmeztette a felhasználókat, hogy akik hardveres biztonsági kulcsot használnak kétfaktoros hitelesítésre, azoknak 2025. november 10-ig újra kell regisztrálniuk a kulcsot, különben a fiók zárolva lesz, amíg nem választanak másik 2FA-módszert vagy nem regisztrálnak új kulcsot az x.com alatt.
Idővonal: figyelmeztetés, határidő, botrány
Az események rövid idővonalon így néznek ki:
- 2025. október 27.: a TechCrunch beszámol arról, hogy az X a twitter.com domain visszavonása miatt újraregisztrációra kötelezi a hardveres 2FA-kulcsokat, határidőként november 10-et megadva.
- 2025. november 10.: lejár a határidő, a vállalat kommunikációja szerint ezután az érintett fiókokat zárolhatják, amíg a tulajdonosok nem lépnek.
- 2025. november 12.: megjelennek a tömeges felhasználói panaszok – sokan már nem tudnak bejelentkezni, mert a rendszer hibát dob, vagy végtelen hurokba kerül a kulcs újraregisztrálásakor. A TechCrunch és a Windows Central is arról ír, hogy az X „elszúrta” az átállást, és rengeteg felhasználót zárt ki.
A Windows Central szerint globális problémáról volt szó: a biztonsági kulcsot használó X-fiókok egy része egyszerűen nem tudta befejezni az újraregisztrációt, miközben a szolgáltatás részben le is lassult, vagy ideiglenesen elérhetetlenné vált.
Miért ennyire kényes a domainváltás a passkey-eknél?
A passkey és a YubiKey-szerű hardveres kulcs lényege, hogy a kulcs a böngészőben futó hitelesítési protokollon keresztül ellenőrzi: tényleg az a weboldal kér tőle aláírást, amelyre korábban regisztráltad. Ha a domain megváltozik, a kulcs nem fogja automatikusan „ugyanannak” a szolgáltatásnak tekinteni az új címet.
Az X biztonsági mérnökei szerint pont ezért kellett leválni a twitter.com alatt regisztrált kulcsokról: így megszüntethetők a domain-trükközések, és kriptográfiai szinten is tiszta lappal indulhat az x.com. A gondot az okozta, hogy a migrációs folyamat – vagyis a kulcsok átregisztrálása – a gyakorlatban hibásan lett megvalósítva.
Mi romlott el a nagy átállás közben?
A beszámolók szerint az érintett felhasználók egy része a következő jelenségeket tapasztalta a bejelentkezési folyamat során:
- A rendszer felszólította őket, hogy regisztrálják újra a biztonsági kulcsot vagy passkey-t az x.com alatt.
- A kulcs érintése után hibaüzenet jelent meg, vagy a folyamat egyszerűen újrakezdődött.
- Néhány felhasználó arról számolt be, hogy hiába tettek meg minden lépést, a rendszer újra és újra beléptette őket az újraregisztrációs folyamatba, miközben a fiókjuk gyakorlatilag használhatatlan maradt.
A Windows Central úgy fogalmaz: a biztonsági kulcsok újraregisztrálásánál jelentkező hiba miatt „milliókat érintő” sajátos leállásról beszélhetünk, hiszen maga az erősebb biztonsági opció vált a belépés legnagyobb akadályává. A TechCrunch cikke szerint az X mérnökei végül kénytelenek voltak visszavonni bizonyos változtatásokat, és részben visszatérni a korábbi konfigurációhoz, miközben a szolgáltatás fokozatosan helyreállt.
Mit lépett az X, és hol tart most a helyreállítás?
A hivatalos kommunikáció egyelőre szűkszavú, de a nyilatkozatok és a felhasználói beszámolók alapján nagyjából ez rajzolódik ki:
- Az X mérnökei észlelték, hogy a hardveres kulcsok és passkey-ek újraregisztrációs folyamata hibásan viselkedik, és tömeges kizárásokat okoz.
- A háttérben visszavontak bizonyos kódmódosításokat, illetve ideiglenesen lazíthattak a kulcsellenőrzés feltételein, hogy a felhasználók újra be tudjanak lépni.
- A szolgáltatás fokozatosan helyreállt, de a dominóhatás miatt sok fióktulajdonosnak manuálisan kellett új 2FA-beállításokat létrehoznia vagy más hitelesítési módszert választania.
Az ügy rávilágít arra is, hogy egy ennyire kritikus infrastruktúra-változtatást (domaincsere + 2FA-migráció) óvatosan, fázisokra bontva, részletes kommunikációval kellett volna bevezetni, például regionális A/B tesztekkel és hosszabb türelmi idővel.
Magyar szemszög: kit érinthetett nálunk a hiba?
Magyar nyelvű tech lapok eddig főleg az X korábbi adatvédelmi és biztonsági ügyeiről számoltak be; a konkrét biztonsági kulcs-átállás fiaskójáról egyelőre nem jelent meg külön hazai riport. Ez azonban nem jelenti azt, hogy magyar felhasználók ne lettek volna érintettek: azok a hazai IT-szakemberek, újságírók, kripto-kereskedők vagy aktivisták, akik tudatosan választottak YubiKey-t vagy passkey-t az X-fiókjukhoz, ugyanúgy szembesülhettek a kizárással.
Magyar szempontból a legnagyobb tanulság az, hogy ha erős, hardveres 2FA-t használsz, akkor is kell legalább egy biztonságos backup megoldás (például egy második kulcs, authenticator app, tartalék recovery-kódok), különben egy hibás friss
