Come attivare la 2FA per GitHub, GitLab e account developer
Una guida pratica per attivare l'autenticazione a due fattori su GitHub, GitLab e altri account developer: app di autenticazione, passkey, chiavi SSH e token.
Perché gli account degli sviluppatori sono bersagli ambiti
Per un attaccante, il tuo account GitHub o GitLab vale molto più di un normale accesso email. Può contenere accesso push a repository privati, chiavi di deploy, diritti di pubblicazione di pacchetti e percorsi diretti verso l'infrastruttura di produzione. Compromettendolo, l'attaccante eredita le tue autorizzazioni: non serve che indovini nulla, entra già dentro come te.
Ecco perché una singola password compromessa può essere così dannosa. I repository privati possono contenere file di configurazione, chiavi API e credenziali di database: un file .env dimenticato in un commit vale a volte più di un intero dump di password. Le pipeline CI spesso trasportano token cloud che possono avviare risorse o iniettare codice malevolo nelle build, e un token con scope ampio permette persino di modificare la pipeline stessa per nascondere le tracce. Gli attaccanti hanno usato account di maintainer rubati per pubblicare aggiornamenti con backdoor agli utenti a valle: chi installa il pacchetto compromesso riceve il codice ostile senza alcun avviso.
Il settore lo sa. GitHub richiede già l'autenticazione a due fattori per molti contributori attivi, e GitLab e altre piattaforme la incoraggiano fortemente. Attivarla ora, con calma e con un metodo di backup pronto, è molto meglio che farla in fretta quando diventa un obbligo o, peggio, dopo un incidente.
Infine, la sicurezza degli sviluppatori raramente è solo una questione personale. Il codice sorgente del tuo datore di lavoro e i progetti open-source che mantieni dipendono tutti dalle tue credenziali. Attivare il 2FA protegge colleghi, utenti e la tua stessa reputazione in un solo passo.
Scelta del secondo fattore
App di autenticazione (TOTP)
App come Google Authenticator, Authy o 1Password generano un codice di sei cifre ogni 30 secondi sul telefono. Funzionano offline, non costano nulla e sono molto più difficili da intercettare rispetto ai messaggi di testo. Per la maggior parte degli sviluppatori, questa è la base sensata.
Durante la configurazione, scansiona il QR code con l'app: se cambi telefono in futuro, usa la funzione di esportazione o trasferimento dell'app prima di disattivare il vecchio dispositivo, altrimenti i codici spariscono con esso. Un errore comune è salvare il QR code come screenshot nel rullino fotografico sincronizzato sul cloud: chiunque acceda a quel cloud ottiene il tuo secondo fattore.
Passkey e chiavi di sicurezza
Le passkey e le chiavi di sicurezza hardware usano una crittografia legata al dominio stesso del sito, quindi una pagina di phishing non può ingannarle facendole accedere. Sia GitHub che GitLab le supportano. Se i tuoi repository hanno un valore reale, registra una passkey o una chiave hardware come fattore principale e tieni un'app TOTP come riserva.
Registra almeno due fattori fin dall'inizio: se l'unico è una chiave USB smarrita, sei fuori dal tuo account finché non ne trovi una copia. Molti sviluppatori tengono una chiave di riserva in un cassetto di casa.
Codici SMS
I messaggi di testo possono essere dirottati tramite SIM swapping e dipendono interamente dalla sicurezza del tuo operatore. Usa gli SMS solo se non è disponibile nient'altro, e abbandonali appena puoi.
Codici di recupero
Quando attivi il 2FA, il sito offre un set di codici di recupero monouso. Generali, poi conservali offline: stampati su carta o nelle note sicure di un password manager. Se perdi il telefono senza averli, recuperare l'accesso diventa una lenta odissea con l'assistenza. Ogni codice vale una sola volta: se ne consumi uno, verifica quanti ne restano e rigenera il set quando si sta esaurendo.
Attivazione della 2FA su GitHub
Accedi, quindi vai su Settings > Password and authentication > Two-factor authentication e clicca su Enable two-factor authentication. GitHub ti chiederà prima la password: è normale, è una verifica per le modifiche sensibili all'account.
Registra un'app TOTP
GitHub mostra un codice QR. Scansionalo con la tua app di autenticazione (Aegis, 1Password, Google Authenticator e simili funzionano tutti), poi inserisci il codice a sei cifre generato dall'app per confermare. L'app ora genera un nuovo codice ogni 30 secondi.
Se non hai la fotocamera a portata di mano, clicca su setup key e inserisci manualmente la chiave segreta nell'app: il risultato è identico. Un errore comune è registrare il codice due volte in app diverse; non accade nulla di grave, ma hai un fattore duplicato inutilmente. Se il codice viene rifiutato, controlla l'ora sul telefono: un orologio errato invalida i TOTP.
Aggiungi una passkey o una chiave di sicurezza hardware
I codici TOTP possono essere oggetto di phishing. Dopo la configurazione, registra una passkey o una chiave di sicurezza hardware come secondo metodo nella stessa pagina delle impostazioni. Mantieni TOTP come riserva, non come unico fattore. GitHub ti chiede di registrare almeno due metodi proprio per evitare il blocco totale.
Scarica i codici di recupero
GitHub offre codici di recupero durante la configurazione. Scaricali e conservali offline — stampati o su un'unità crittografata, mai in un repository o in note sul cloud. Ogni codice funziona una sola volta e sono l'unico modo per rientrare se perdi tutti i tuoi secondi fattori. Segnalali come usati man mano, così sai quanti ne restano.
Token e chiavi SSH in seguito
Le chiavi SSH esistenti e i personal access token continuano a funzionare senza modifiche. I push HTTPS ora richiederanno l'autenticazione tramite browser o un token invece della password: se uno script o una pipeline usa HTTPS con password, smetterà di funzionare e va migrato a un token.
Abilitazione della 2FA in GitLab
In GitLab, seleziona il tuo avatar, scegli Preferenze, apri Account nella barra laterale sinistra, quindi fai clic su Abilita autenticazione a due fattori.
Abbinamento dell'app
Scansiona il codice QR con la tua app TOTP — Aegis, 1Password, Google Authenticator o simili — e inserisci il codice a sei cifre che genera per confermare l'abbinamento. I codici cambiano ogni trenta secondi, quindi se il timer sta per scadere attendi il successivo: un codice inserito pochi secondi prima del rinnovo viene spesso rifiutato. Se preferisci l'hardware, puoi registrare dispositivi WebAuthn come chiavi di sicurezza o passkey come secondo fattore dalla stessa pagina Account.
Salvataggio dei codici di recupero
GitLab mostra quindi un elenco di codici di recupero monouso. Ognuno funziona una sola volta, nel caso in cui perdessi l'accesso al tuo autenticatore. Scaricali, copiali o stampali e conservali in un luogo sicuro, ad esempio in un gestore di password. Puoi generare un nuovo elenco in seguito dalla stessa pagina, ma tieni al sicuro questo primo set: generare una nuova lista invalida quella precedente, quindi verifica di aver salvato la versione aggiornata prima di chiudere la pagina.
Cosa cambia per le operazioni Git
Una volta attivata la 2FA, la password del tuo account non funziona più per Git over HTTPS. Effettua push e pull usando invece un personal access token, oppure passa a una chiave SSH. Crea il token prima di abilitare la 2FA per non rimanere bloccato a metà del flusso di lavoro: senza credenziali valide, il push di un ramo importante fallisce proprio quando hai meno tempo per rimediare. Se usi più macchine, salva il token nel gestore credenziali di Git oppure copia le chiavi SSH su ciascun ambiente.
Chiavi SSH e token dopo il 2FA
Una volta attivato il 2FA, i push git basati su password smettono di funzionare. Passa i tuoi remote a SSH così il lavoro quotidiano non richiede più alcuna richiesta di password:
git remote set-url origin [email protected]:owner/repo.git
Genera una chiave SSH
Crea una chiave moderna protetta da una passphrase:
ssh-keygen -t ed25519 -C "[email protected]"
Copia il contenuto del file .pub nelle impostazioni delle chiavi SSH del tuo account (GitHub: Settings → SSH and GPG keys; GitLab: Preferences → SSH Keys). La passphrase viene memorizzata nella cache dal tuo SSH agent, quindi la digiti raramente.
Errore comune: generare la chiave senza passphrase. Una chiave senza passphrase è come una password scritta sul portatile — se il disco viene compromesso, l'attaccante ottiene l'accesso diretto. Un'altra trappola: caricare la chiave pubblica sbagliata e scoprirlo solo al primo push con un errore Permission denied (publickey); verifica con ssh -T [email protected] prima di procedere.
Token per script e CI
I personal access token sostituiscono le password per le chiamate API e le pipeline. Assegna a ogni token gli scope minimi che bastano — un token che può solo leggere repository pubblici non può fare push di commit dannosi.
Imposta una scadenza breve: un token senza scadenza che finisce in una cronologia di shell o nei log di CI resta valido per sempre. Se un token si espone in un log, revocalo immediatamente dalle impostazioni dell'account e rigeneralo.
Limita i danni potenziali
Preferisci i token fine-grained (GitHub) con ambito limitato a repository e permessi specifici, e usa le deploy key per singoli repository sui server. Se una credenziale con permessi ristretti finisce esposta, un attaccante ottiene molto meno che con il tuo account completo.
Altri account di sviluppatore che vale la pena mettere in sicurezza
I registry di pacchetti meritano la stessa protezione del tuo host Git. npm, PyPI e Docker Hub supportano tutti il 2FA, e npm lo richiede in alcuni casi, ad esempio per i manutentori dei pacchetti più diffusi. Un account di registry compromesso permette a un attaccante di pubblicare una versione manomessa del tuo pacchetto, che finisce poi su ogni macchina che lo installa. Su npm, attiva il 2FA prima di pubblicare e usa un automation token solo se pubblichi da CI: in quel caso il token sostituisce il codice TOTP, quindi custodiscilo come una password. Su PyPI imposta anche il campo Trusted Publishers con parsimonia, e ricorda che un nuovo dispositivo può richiedere di registrare di nuovo l'app di autenticazione.
Console cloud e provider CI
AWS, Google Cloud, Azure e i servizi CI come i segreti di GitHub Actions o le variabili di GitLab CI contengono spesso credenziali di deployment, accesso ai database e carte di pagamento. Attiva il 2FA sull'account della console, poi verifica quali job CI possono leggere i segreti: un workflow attivato da una pull request di uno sconosciuto non dovrebbe mai vederli. Sui cloud, proteggi anche l'account amministrativo principale, non solo gli utenti quotidiani.
La radice della fiducia
Due account contano più di tutti gli altri:
- Email — i reset delle password di quasi tutto passano da qui
- Password manager — contiene le chiavi di tutti gli altri account
Se uno dei due cade, un attaccante spesso può arrivare a tutto il resto tramite reset, con o senza 2FA. Proteggi entrambi con il secondo fattore più forte che possiedi, idealmente una chiave hardware o un'app di autenticazione invece degli SMS, e non riutilizzare mai le loro password altelsewhere. Conserva i codici di recupero della password manager offline: se perdi insieme telefono e accesso email, resti fuori.
Convivere con il 2FA giorno per giorno
Una volta attivato il 2FA, poche abitudini lo rendono indolore.
Proteggi i tuoi codici di recupero. Conserva in un password manager o stampane una copia e tienila in un posto sicuro. Non committarli mai in un repository — anche uno privato può trapelare tramite token, fork o un'impostazione errata. Se li stampi, trattali come una password fisica: niente cassetti della scrivania in ufficio, niente foto nello smartphone.
Registra un secondo fattore di backup. Aggiungi una seconda app TOTP o una chiave di sicurezza di riserva finché tutto funziona ancora. Un backup configurato dopo aver perso il telefono è un backup che non hai. Se usi una chiave di sicurezza, registrane due e tienine una in un luogo diverso dal portatile che usi ogni giorno.
Fai audit regolarmente. Ogni pochi mesi, controlla le sessioni attive e rimuovi i dispositivi che non usi più. Revoca chiavi SSH obsolete, personal access token e deploy key — le vecchie credenziali sopravvivono ai progetti per cui sono state create. Un promemoria nel calendario aiuta. Approfittane anche per verificare che la data nel telefono sia sincronizzata automaticamente: un orologio sbagliato è la causa più comune di codici TOTP rifiutati.
Se perdi tutto, contatta il supporto della piattaforma. Il recupero può richiedere giorni e implica dimostrare di essere il proprietario dell'account, quindi considera quella strada come ultima risorsa, non come piano. Prepara in anticipo i dati che potrebbero chiederti: email di registrazione, repository recenti, dettagli di fatturazione se presenti.
Due minuti di configurazione ora valgono più di una settimana di blocco dopo. Attiva il 2FA, salva i codici, vai avanti.
Condividi questa guida
Ultimi dal blog
Codice di verifica 2FA dimenticato: cosa succede, come recuperarlo
Cosa succede se non accedi più al codice di verifica 2FA? Codici di backup, flusso di recupero dell'account e passaggi preparatori per non ricaderci più.
Leggi di piùChecklist di sicurezza 2FA: 12 passi per blindare oggi i tuoi account
Una checklist di sicurezza pratica che copre la configurazione del 2FA, l'igiene delle password e le opzioni di recupero. Dodici passi concreti che puoi compiere oggi per blindare i tuoi account contro il takeover.
Leggi di piùLa storia del 2FA: dai token hardware alle passkey
Come l'autenticazione a due fattori si è evoluta dai token hardware da clip e dai codici SMS fino alle odierne passkey resistenti al phishing — e il perché di ogni passaggio.
Leggi di più