- Obligātā ieviešana ir pastāvīga: Izstrādātājiem, kuri nekonfigurē 2FA līdz noteiktajam termiņam, tiek bloķēta tīmekļa darbību veikšana un liegta piekļuve organizācijas krātuvēm.
- Atkopšanas kodi ir jūsu glābšanas riņķis: 16 ģenerētie atkopšanas kodi ir vienreizlietojami. Nekavējoties saglabājiet tos šifrētā seifā vai bezsaistes fiziskā izdrukā.
- Git paroles vairs nedarbojas: HTTPS Git push komandas nevar pieņemt interaktīvus 6 ciparu kodus. Jums jāizmanto SSH atslēgas vai ierobežotas darbības jomas personiskās piekļuves marķieri (PAT).
- Kriptogrāfiskā pēdējā iespēja: Ja pazaudējat tālruni un kodus, varat pierādīt īpašumtiesības, parakstot identitātes izaicinājumu, izmantojot iepriekš reģistrēto lokālo SSH privāto atslēgu.
GitHub obligātās 2FA politikas pārskats un drošības pamatojums
Vēsturiski kompromitēti izstrādātāju akreditācijas dati izraisīja katastrofālas programmatūras piegādes ķēdes ievainojamības. Plaši zināmi incidenti — piemēram, event-stream, ua-parser-js, ctx un colors.js pārņemšana platformās npm un PyPI — parādīja, ka viens nozagts konts var apdraudēt simtiem tūkstošu pakārtotu komerciālu un kritisku infrastruktūras projektu.
Uzbrucēji iegūst akreditācijas datus, izmantojot globālos akreditācijas datu pildīšanas sarakstus, pikšķerēšanas infrastruktūru un inficētas izstrādātāju atkarības. Tā kā programmatūras inženieri ikdienā darbojas ar root vai administratīvo piekļuvi pirmkodam un CI/CD izvietošanas konveijeriem, koda iesniedzēju aizsardzība kļuva par starptautiskās infrastruktūras drošības jautājumu.
Reaģējot uz to, GitHub ieviesa daudzpakāpju vispārēju prasību, kas nosaka divfaktoru autentifikāciju visiem koda iesniedzējiem, pakotņu izdevējiem, uzņēmumu lietotājiem un organizāciju dalībniekiem:
- GitHub tīmekļa saskarne pāriet piespiedu bloķēšanas režīmā, liedzot koda izmaiņu pārskatīšanu (pull request), komentāru rakstīšanu un krātuvju administrēšanu, līdz tiek pabeigta 2FA iestatīšana.
- Uzņēmumu organizācijas, kas ievieš 2FA, automātiski atstādina prasībām neatbilstošus dalībniekus, nekavējoties atņemot rakstīšanas piekļuvi un atceļot krātuves privilēģijas.
- Automatizētie darba plūsmas konveijeri, npm pakotņu publicēšanas atslēgas un detalizētas krātuves atļaujas tiek iesaldētas, līdz tiek autentificēta konta drošības atbilstība.
Soli pa solim: TOTP autentifikatora savienošana pārī
Lai gan GitHub atbalsta SMS, mobilā tālruņa paziņojumus un aparatūras atslēgas, RFC 6238 TOTP autentifikatora lietotne (piemēram, Google Authenticator, Bitwarden, 2FA-Tool) ir zelta standarts neatkarībai no pakalpojumu sniedzējiem un bezsaistes uzticamībai:
1. darbība: Pārejiet uz autentifikācijas iestatījumiem
Piesakieties pakalpojumā GitHub. Noklikšķiniet uz sava profila iemiesojuma augšējā labajā stūrī ➔ Settings. Kreisajā navigācijas sānjoslā sadaļā "Access" atlasiet Password and authentication.
2. darbība: Skenējiet QR kodu un saglabājiet neapstrādāto Base32 noslēpumu
GitHub parāda optisko QR kodu līdzās teksta saitei: "enter this text code instead".
A3J5N2O9...). Saglabājiet to savā šifrētajā paroļu pārvaldniekā. Šī burtciparu sēkla ļauj atkārtoti iegūt autentifikācijas marķierus jebkurā ierīcē, ja tālrunis tiek bojāts.
3. darbība: Ievadiet 6 ciparu kodu, lai apstiprinātu
Noskenējiet kodu ar mobilo autentifikatoru. Ievadiet ekrānā redzamo mainīgo 6 ciparu numuru GitHub verifikācijas ievades laukā un noklikšķiniet uz "Continue".
Atkopšanas kodu arhivēšanas standarti un kriptogrāfiskā higiēna
Pēc veiksmīgas TOTP savienošanas pārī GitHub nekavējoties parāda modālo logu ar 16 ar defisi atdalītiem heksadecimālajiem marķieriem (piemēram, d4a2b-98f12). Šī modālā loga aizvēršana bez pastāvīgas dublēšanas ir visbiežākais iemesls, kāpēc izstrādātāji neatgriezeniski zaudē piekļuvi savam kontam.
1. Tikai vienreizēja lietošana: Katrs atkopšanas kods tiek neatgriezeniski anulēts pēc tā pirmās izmantošanas TOTP koda vietā.
2. Galvenā autoritāte: Atkopšanas kods aizstāj trūkstošo aparatūru un nodrošina tūlītēju piekļuvi kontam.
3. Nulles zināšanu servera hešēšana: GitHub glabā šos kodus kā neatgriezeniskus vienvirziena kriptogrāfiskos hešus. GitHub atbalsta inženieri nekādos apstākļos nevar atgūt vai izlasīt jūsu sākotnējos kodus!
Ieteicamā trīs līmeņu aukstās glabāšanas stratēģija:
Lejupielādējiet github-recovery-codes.txt un pievienojiet to savam GitHub ierakstam programmā 1Password, Bitwarden vai KeePassXC, izmantojot no Argon2id atvasinātas galvenās atslēgas.
Saglabājiet teksta failu ar VeraCrypt šifrētā bezsaistes USB zibatmiņā, kas ir atvienota no vietējiem tīkliem un mākoņkrātuves sinhronizatoriem.
Izdrukājiet fizisku papīra kopiju, ielaminējiet to aizsardzībai pret mitrumu un droši noglabājiet fiziskā mājas seifā, lai pasargātu no attālajiem informācijas zagļiem.
Rezerves autentifikācijas metodes: SMS pret piekļuves atslēgām un GitHub Mobile
GitHub atļauj konfigurēt sekundāros rezerves mehānismus. Pārskatiet mūsu drošības analīzi par pašreizējiem autentifikācijas vektoriem:
| Metode | Izturība pret pikšķerēšanu | SIM kartes maiņas ievainojamība | Novērtējums un praktiskais lietojums |
|---|---|---|---|
| Piekļuves atslēgas / FIDO2 drošības atslēgas | Absolūta (WebAuthn izcelsmes piesaiste novērš starpniekservera pikšķerēšanu) | Imūna | ⭐⭐⭐⭐⭐ Galvenais ieteikums (YubiKey / Touch ID) |
| TOTP autentifikatora lietotne | Mērena (ievainojama pret reāllaika apgrieztajiem starpniekserveriem) | Imūna | ⭐⭐⭐⭐ Universāls bāzes līmenis (nulle savienojamības atkarības) |
| GitHub Mobile pašpiegādes apstiprinājums | Mērena (nepieciešama 2 ciparu numura pārbaudes uzvedne) | Imūna | ⭐⭐⭐⭐ Lieliska ikdienas ērtība |
| SMS verifikācijas atkāpšanās | Nulle (nešifrēta SS7 signalizācija, viegli pārtverama) | Augsts risks | ⭐ Nav ieteicams augsta profila uzturētājiem |
Termināļa Git darba plūsmas: SSH atslēgas, PAT un 2FA mijiedarbība
Pēc 2FA aktivizēšanas izstrādātāji ikdienas koda nosūtīšanas laikā bieži saskaras ar šādu termināļa kļūdu:
fatal: Authentication failed for 'https://github.com/username/repo.git/'
Tehniskais pamatojums: Git protokols nespēj apstrādāt interaktīvus 6 ciparu TOTP dialogus. Tāpēc GitHub neatgriezeniski deaktivizēja tiešu konta paroles autentifikāciju HTTPS Git pieprasījumiem, kad ir aktīva 2FA.
Izmanto publiskās atslēgas kriptogrāfiju (ieteicams: ed25519). SSH savienojumi autentificējas, izmantojot vietējās kriptogrāfiskās privātās atslēgas, un pilnībā apiet tīmekļa 2FA bez biežām akreditācijas datu uzvednēm.
Ja HTTPS pārsūtīšana ir obligāta, pārejiet uz Settings ➔ Developer settings ➔ Personal access tokens, lai ģenerētu marķieri ar noteiktu darbības jomu. Kad CLI tiek prasīta parole, konta paroles vietā ielīmējiet PAT.
SSH veikto izmaiņu parakstīšana pret autentifikāciju: Ņemiet vērā, ka SSH atslēgas izmantošana krātuvju klonēšanai un nosūtīšanai atšķiras no kriptogrāfiskās izmaiņu (commit) parakstīšanas. Varat izmantot to pašu Ed25519 atslēgu pāri, lai parakstītu izmaiņas ar komandām git config commit.gpgsign true un git config gpg.format ssh, ģenerējot pārbaudītas autora nozīmītes vietnē GitHub līdzās stingrai 2FA piekļuves kontrolei.
Avārijas atkopšana: bloķētu kontu atbloķēšana bez 2FA
Katastrofālā situācijā, kad 2FA tālrunis ir pazudis un atkopšanas kodu dokuments ir pazaudēts, GitHub piedāvā pēdējo kriptogrāfisko glābšanas riņķi: SSH atslēgas paraksta izaicinājumu.
Pārbaudiet savu GitHub TOTP noslēpumu lokāli
Pirms apstiprināt iestatīšanu, pārbaudiet savu neapstrādāto Base32 slepeno virkni rīkā 2FA-Tool. Visi heši tiek aprēķināti lokāli, izmantojot pārlūkprogrammas Web Crypto, bez pārsūtīšanas uz serveri.
📚 Saistītās drošības rokasgrāmatas
Droša 2FA kontu pārsūtīšana starp viedtālruņiem, izmantojot bezsaistes QR kodus un Cloud Sync.
Kā atgūt piekļuvi Google, Microsoft, Steam, Binance, Apple un Discord.
No RFC 4226 līdz RFC 6238: matemātiskā heša apcirpšana, desinhronizācija un ieviešana tīmeklī.