⚠️ ACCEDI CON GOOGLE: i rischi del Single Sign On (SSO)

Immaginate di svegliarvi una mattina, di controllare il cellulare e di vedere un messaggio della banca. Nel messaggio c'è scritto: "Autorizzata operazione internet per €300". Scorrete più in alto nei messaggi e ne vedete altri. In tutto qualcuno ha fatto acquisti sulla vostra carta per circa €2.000. Il sito su cui sono stati fatti gli acquisti è sempre lo stesso, è un sito che voi usate ogni tanto. Immediatamente vi collegate per annullare l'ordine, ma qualcuno lo ha già annullato e si è fatto rimborsare gli importi su un'altra carta. Tutto questo è stato fatto a vostro nome, entrando sul sito con le vostre credenziali. Il problema è che voi su quel sito non avete mai creato un account specifico. Avete cliccato su "Accedi con Google" e avete inserito quelle credenziali. Ben presto capite che il malintenzionato che vi ha rubato i soldi è entrato in qualche modo in possesso delle vostre credenziali Google, che voi usate praticamente ovunque. In pratica è come se avesse in mano le chiavi per entrare in ogni sito e applicazione che usate. Oggi usiamo praticamente tutti le opzioni "Accedi con Google" Facebook, con Apple. È un sistema di accesso molto comodo e innovativo e tendenzialmente sicuro. Di certo un colosso come Google sarà più bravo a proteggere le credenziali degli utenti rispetto a un sito web cinese scrauso, giusto? Tuttavia anche questo sistema nasconde dei pericoli che non possiamo assolutamente sottovalutare, ma per capire bene perché dobbiamo partire dall'inizio. Ciao a tutti e benvenuti in questo nuovo video. Siamo ormai tutti abituati a vedere nei siti web la comoda opzione "Accedi con Google". Eppure sarei pronta a scommettere che tutti, almeno una volta, cliccando su "Accedi con Google" ci siamo chiesti: ma sarà la scelta giusta? La scelta più sicura? Oggi daremo una risposta definitiva a questa domanda, ma prima, come sempre, dobbiamo fare un passo indietro. La nostra storia inizia alla fine degli anni '80, quando i primi computer fanno il loro ingresso nelle aziende. È una vera e propria rivoluzione, a cui però è difficile adattarsi, soprattutto a causa di un grosso problema: le password. Ogni singola cosa richiede una password. Il login nel computer richiede una password, l'accesso al database richiede una password, l'accesso ai singoli file richiede una password, la stampante richiede una password, e ricordarsele tutte è veramente complicato. Le soluzioni più adottate per risolvere questo problema sono due, entrambe dei capolavori di furbizia. 1: appiccicare sul computer dei bei post-it con scritte tutte le credenziali in modo da non perderle mai. E 2: usare la stessa password dappertutto, possibilmente semplice da ricordare, tipo 1234 o magari proprio password. Mi viene da ridere perché questi erano gli anni '80 e come cosa poteva pure essere giustificata, ma ancora nel 2025 la password usata dal Louvre è Louvre. Quindi abbiamo imparato veramente poco. Comunque, visto che queste due soluzioni non erano sicuramente l'ideale, dei ricercatori dell'MIT decidono di idearne una migliore che chiameranno Kerberos. Il nome viene dalla mitologia greca, fa riferimento a Cerbero, il cane a tre teste che custodisce l'ingresso dell'Ade. Un guardiano insomma. Kerberos serviva a semplificare l'accesso all'interno dei sistemi aziendali. Immaginate per un attimo di andare a una fiera per cui serve un biglietto nominativo. Quando entrate, Gli addetti vi chiedono il biglietto e anche un documento di identità per verificare che siate effettivamente voi gli intestatari del biglietto. Una volta entrati vi avvicinate a un padiglione, ma per entrare vi chiedono ancora di vedere il biglietto e il documento. Volete comprare una cosa e alla cassa vi chiedono per l'ennesima volta di vedere il biglietto e il documento. Vi passa un po' la voglia di andare alle fiere, no? Ecco, la situazione nei sistemi aziendali prima di Kerberos era questa. Immaginate invece di entrare in fiera, di essere identificati dagli addetti che controllano biglietti biglietto e documento e poi vi consegnano un braccialetto. A quel punto potete girare tutta la fiera e fare qualunque cosa semplicemente mostrando il braccialetto ai vari addetti. Qualunque riferimento al Lucca Comics è puramente casuale. Kerberos comunque funziona esattamente così: il dipendente fa login una sola volta all'inizio della giornata inserendo username e password, il sistema centrale di Kerberos verifica le credenziali e se sono corrette rilascia un ticket digitale crittografato, cioè in nostro braccialetto. Questo ticket ha una durata limitata, solitamente qualche ora o al massimo l'intera giornata. Quando l'utente deve accedere a un altro servizio nella rete, per esempio la stampante o il database, non deve reinserire la password. Il suo computer presenta semplicemente in automatico il ticket Kerberos. Il servizio di destinazione controlla che il ticket sia valido, che sia firmato correttamente dal server centrale, che non sia scaduto, e se è tutto a posto concede l'accesso. Kerberos era il primo vero esempio di SSO o Single Sign-On, il sistema alla base dei moderni "Accedi con Google" e simili, che consiste nel permettere a un utente di utilizzare un singolo set di credenziali per accedere a svariate applicazioni. Ancora oggi, ogni volta che in azienda, dal vostro computer aziendale Windows, vi autenticate e poi accedete a cartelle condivise, stampanti, applicazioni interne e così via, state usando in qualche forma la tecnologia Kerberos. Ma c'era un problema: Kerberos funzionava bene all'interno di un'organizzazione, di una rete chiusa, ma quando arrivò Internet la situazione cambiò completamente. Con la diffusione di Internet negli anni '90 il problema delle password aumentò in modo esponenziale. Non si trattava più solo di accedere a servizi aziendali interni, tutti gestiti da un'unica organizzazione. L'esigenza era diventata quella di accedere a siti web completamente diversi, gestiti da aziende differenti sparse per il mondo. Microsoft fu tra i primi a tentare una soluzione con Microsoft Passport, lanciato nel 1999. Microsoft Passport permetteva all'utente di autenticarsi su Microsoft ed avere accesso in questo modo anche a siti di terze parti. La stessa cosa che succede oggi con Accedi con Google, ma con una differenza fondamentale: Passport era un sistema completamente proprietario e chiuso. Non esistevano standard aperti che altri potessero riadattare. Se volevi implementare questo sistema sul tuo sito dovevi per forza passare da Microsoft, non potevi scegliere un'alternativa. Per un'azienda significava legarsi mani e piedi a un singolo fornitore per qualcosa di assolutamente critico, cioè l'autenticazione dei propri utenti. Anche il contesto storico non aiutava perché Microsoft in quegli anni era vista come un monopolio aggressivo che cercava di controllare ogni aspetto del web. Quindi molte aziende, specialmente i competitor, non erano esattamente entusiaste all'idea di mettere in mano a Microsoft l'identità digitale di tutti gli utenti. Passport non decollò mai davvero, ma servì a capire che il futuro dell'SSO, quindi del Single Sign-On, sarebbe passato da un'altra strada: quella degli standard aperti e condivisi che tutte le aziende potevano decidere di implementare. Nel 2002 una partnership fra varie aziende, fra cui la IBM, portò alla nascita dello standard chiamato Security Assertion Markup Language o SAML. Le aziende in quel momento avevano iniziato a usare internet, quindi non avevano più bisogno solo di accedere alla stampante che si trova nella stanza della Luisa, quella delle risorse umane. Avevano bisogno di accedere al Dropbox dell'azienda, al software che usano per le fatture e così via. Kerberos aveva risolto il problema della connessione interna all'azienda e allo stesso modo il SAML risolse il problema per la connessione ai servizi internet. L'utente entrava nel proprio computer del lavoro con le proprie credenziali. Una volta autenticato, il server aziendale emetteva un documento XML firmato digitalmente che diceva: questa persona è Mario Rossi, ha fatto login alle 10:32 e questi sono i permessi che ha. Quando l'utente voleva accedere alla mail aziendale o a un portale internet, il documento XML veniva consegnato automaticamente al relativo sito web. Il SAML era lo standard che diceva: computer, emetti questo documento fatto in questo modo; sito web, accetta il documento fatto in questo modo. Sostanzialmente stabiliva come le due parti dovevano comunicare fra di loro, dava una serie di regole. Funzionava molto bene, quindi divenne rapidamente lo standard di riferimento per le aziende, permettendo per esempio ai dipendenti di una multinazionale di accedere a servizi cloud esterni usando le credenziali aziendali interne. Il problema è che era un servizio molto sicuro, molto robusto e per questo anche molto pesante. Andava benissimo per le aziende, ma non poteva diventare lo standard di riferimento per i comuni cittadini. Un primo tentativo di creare uno standard simile per l'utente medio arrivò nel 2005 grazie al programmatore Brad Fitzpatrick che ideò OpenID. La sua idea partiva dal presupposto che su determinati siti, tipo Yahoo, quando un utente si autentica, si registra, ha una pagina personale. Questa pagina personale sarà raggiungibile a un determinato indirizzo, che presumibilmente sarà qualcosa tipo yahoo.com/mario-rossi. Noi potremmo considerare questo indirizzo come una specie di carta di identità e usarlo per autenticarci anche in altri siti. Ad esempio, voglio comprare qualcosa su eBay ma non mi va di creare un account? Inserisco il mio indirizzo yahoo.com/marerossi, eBay mi rimanda alla pagina di Yahoo, faccio il login direttamente dentro Yahoo e eBay mi dice: "Ok, puoi entrare, mi fido di Yahoo, quindi se hai un account lì per me va bene". Come vedete era molto simile a quello che oggi succede con Accedi con Google. Il problema era che L'idea era buona, ma il funzionamento per l'utente medio era complicato da capire. La realtà era che tu entravi su eBay, il sito ti diceva: ok, dammi il tuo OpenID. E tu dicevi: e che cacchio è un OpenID? E perché devo andare a inserire questo indirizzo super complicato yahoo.com eccetera eccetera quando mi basterebbe mettere email e password? E quindi questo sistema finì per non essere molto utilizzato. C'era però un'azienda che stava tenendo d'occhio questa idea, che aveva intuito perché non stava funzionando e aveva deciso di entrare a gamba tesa nel mercato. E questa azienda era Facebook. Facebook era in crescita, al momento della registrazione chiedeva agli utenti tutta una serie di dati, poteva tranquillamente essere usata per identificare le persone quando volevano accedere ad altri servizi. Nel 2008 venne lanciato quindi Facebook Connect, che fu una vera rivoluzione. Improvvisamente su centinaia di siti comparve un pulsante blu con scritto "Accedi con Facebook". Cliccavi, si apriva Facebook, inserivi le tue credenziali, venivi riportato al sito ed eri dentro. Facilissimo. E voi ora direte: perfetto, quindi Facebook lancia questa cosa, altre aziende come Apple e Google lo copiano, tutti i siti inseriscono i vari pulsanti "Accedi con Google", "Accedi con Facebook", eccetera, e la storia finisce qui, giusto? Sbagliato, perché nel frattempo stava succedendo un'altra cosa. Facciamo un micro passo indietro e torniamo al 2006. Twitter sta crescendo rapidamente e il suo programmatore di punta, Blaine Cook, si trova di fronte a problema apparentemente irrisolvibile. Gli utenti e le società dietro ad altre grandi applicazioni spingevano per una maggiore integrazione fra i servizi. Ad esempio, sono sulla pagina web del giornale New York Times, sto leggendo un articolo molto interessante e penso: cavolo, piacerebbe proprio a mia zia Gina questo articolo! Allora cosa faccio? Lo pubblico su Twitter e taggo mia zia Gina. Ma aspetta, però per fare questo il New York Times ha bisogno di interagire con il mio profilo Twitter e pubblicare qualcosa a mio nome. E perché possa entrare nel mio profilo dovrei dargli nome utente e password che uso su Twitter? Non esiste. Perché cosa succede se per sfiga il New York Times viene hackerato? Succede che l'hacker scopre anche le mie credenziali di Twitter, perché io le ho date al New York Times. Serviva un modo per superare questo problema. Bisognava creare un sistema che concedesse l'accesso al New York Times ma senza dargli le credenziali, e solo per permettergli di condividere quell'articolo. Cook inizia a ragionarci con un team di altri esperti provenienti anche da altre aziende, fra cui Google, e insieme giungono a una conclusione: era ora di separare autenticazione e autorizzazione. Facciamo un attimo di ordine perché questi due concetti vengono spesso confusi fra loro, ma in realtà indicano due cose molto diverse. L'autenticazione si ha quando dimostro al sistema che io sono io. Quando prendo il mio cellulare, apro l'app della banca e metto la mia impronta, sto dicendo alla banca "Tranquilli, sono proprio io, sono Veronica Paolucci, la titolare del conto." L'autenticazione si ha anche, ad esempio, quando entriamo su Gmail. Stiamo dicendo a Gmail che siamo proprio noi a entrare e a leggere la posta in arrivo. Con l'autorizzazione invece noi deleghiamo qualcuno a fare qualcosa e gli diamo il permesso di farlo, lo autorizziamo appunto. Torniamo all'esempio della banca. Se io compro qualcosa su Amazon e inserisco i dati della mia carta, può comparirmi l'avviso che devo autorizzare il pagamento. Apro l'app della banca che mi dice: guarda che Amazon sta cercando di prelevare questi soldi, sei d'accordo? Io metto la mia impronta e in questo modo dico: sì, sono d'accordo. E la banca autorizza Amazon a prelevare il denaro. Amazon non si sta fingendo me, non sta cercando di autenticarsi nell'app della mia banca, sta chiedendo il permesso, o meglio l'autorizzazione, a prelevare dei soldi per conto mio. E sono io utente autenticato a dargli il permesso di farlo. Se non tenessimo separati questi due concetti, autorizzazione e autenticazione, e quindi potesse fare qualcosa solo chi è autenticato, se non ci fosse quindi la possibilità di dare una delega a qualcuno, io per fare un acquisto su Amazon dovrei prima dargli l'accesso completo al mio conto corrente, al mio home banking, perché ogni attività passerebbe dall'autenticazione, ed è una cosa impensabile. In questo modo invece io autorizzo Amazon a fare una singola attività, e se Amazon prova a fare altre cose, il permesso viene negato. L'autorizzazione che ti ho dato è esclusivamente per prelevare i €32,99 necessari a finalizzare l'acquisto della mia nuova tavoletta per il water con luci notturne e sistema di abbassamento automatico. Non puoi prelevare altri soldi. Il team di esperti voleva raggiungere proprio un risultato di questo tipo. Voleva che il New York Times potesse condividere l'articolo sul mio profilo Twitter senza avere il permesso di fare nient'altro altro sul mio profilo e soprattutto senza aver bisogno di conoscere le mie credenziali. Nel 2007 viene rilasciata la prima versione di OAuth, Open Authorization, che permetteva al servizio X di accedere ai miei dati sul servizio Y senza aver mai bisogno di conoscere la password. Per farvi capire meglio, immaginate di essere iscritti in una palestra che dà a ogni cliente 3 armadietti personali con una chiave unica che li apre tutti e 3. 3. Arrivate in palestra e mettete il portafoglio in un armadietto, il cellulare in un altro e degli asciugamani di riserva nel terzo. Iniziate ad allenarvi e arriva da voi un tizio che conoscete solo di vista e vi chiede se potete prestargli un asciugamano perché lui si è scordato il suo. Voi avete due scelte: o gli date la vostra chiave passepartout, però così rischiate che lui apra anche gli armadietti in cui ci sono portafoglio e telefono, oppure trovate un altro modo. Quindi andate dalla ragazza della reception che ha le chiavi di tutti gli armadietti e vi fate dare una chiave specifica che apre solo l'armadietto degli asciugamani. In questo modo state autorizzando il vostro conoscente ad aprire solo quello specifico armadietto e solo per prendere un asciugamano, niente di più. OAuth funziona così. Non hai bisogno delle chiavi complete del proprietario per accedere al servizio, ti basta una piccola chiave che dica: questo sistema può accedere a quest'altro per fare questa specifica cosa e sei a posto. Dal punto di vista tecnico, il meccanismo di OAuth si basa su un token, un pezzettino di testo. Io dico al New York Times di condividere un articolo sul mio profilo Twitter, il mio browser gli dà un token di autorizzazione, che è un bigliettino con scritto in pratica: il New York Times ha il diritto di entrare sul profilo Twitter di Veronica Paolucci e pubblicare l'articolo che parla delle migliori tavolette per battere. Il New York Times va da Twitter con questo bigliettino, Twitter lo legge, mi chiede: ma Tu sei d'accordo? Metti le credenziali se sei d'accordo. Io metto le mie credenziali Twitter e Twitter dice al New York Times: ok, sei a posto, puoi entrare, ma guarda che ti tengo d'occhio perché l'unica cosa che puoi fare è pubblicare questo articolo sulle tavolette per PC. Mi piace perché la mia spiegazione tecnica è tutto meno che tecnica, quindi se c'è qualcuno che ha voglia di lasciare un commento spiegando più nel dettaglio come funziona questa parte, fatelo, così pino il commento a beneficio di tutti. Nel glorioso 2008 quindi abbiamo Facebook, Facebook Connect che ci semplifica l'accesso ai siti, OAuth che ci permette una maggiore integrazione fra i vari servizi e Rockstar Games che fa uscire il gioco GTA IV. Si può essere più felici di così? Secondo alcuni programmatori sì, si poteva essere più felici. Ad esempio unendo la tecnologia alla base di Facebook Connect con la tecnologia alla base di OAuth. Ci si era resi conto infatti che i siti avevano iniziato a usare OAuth che teoricamente serviva solo ad autorizzare il sito abilitato a fare determinate cose per autenticare gli utenti. Il ragionamento che facevano gli sviluppatori dei siti web era: "Ehi, se posso chiedere a Google o a Twitter il permesso di leggere il profilo dell'utente e ottenere nome e email, posso usarlo anche per autenticare le persone sul mio sito." Così iniziarono a implementare pulsanti tipo "Accedi con Google", "Accedi con Twitter", eccetera. Cliccando il sito generava un token o auth che non serviva a fare chissà che cosa, semplicemente chiedeva a Google: "Dammi nome e email di questa persona, Google mi chiedeva di inserire le mie credenziali per autorizzare questa richiesta, poi dava l'ok al sito. Il sito leggeva il mio nome e la mia mail e diceva: perfetto, per me puoi entrare. In pratica, tutto il casino fatto per separare autenticazione da autorizzazione, perché non potevano coesistere le due cose insieme, venne totalmente vanificato da sviluppatori che cercavano il modo più rapido e veloce per aiutare gli utenti a entrare nei loro Di fatto prendevano un token nato per l'autorizzazione e lo usavano per l'autenticazione. Non era un problema enorme di per sé, ma si voleva comunque rendere il tutto migliore e più pulito. Per cui, vedendo che c'era l'esigenza di unire autorizzazione e autenticazione, i ricercatori idearono un nuovo standard chiamato OpenID Connect. Era sostanzialmente un matrimonio fra il vecchio OpenID e il nuovo OAuth. E finalmente, adesso sì, siamo arrivati all'Accedi con Google come lo conosciamo oggi. Vediamo come funziona. Entriamo su un sito qualunque, per esempio eBay, visto che abbiamo fatto quell'esempio, e clicchiamo Accedi con Google. Come vedete, posso scegliere fra varie cose e io farò Accedi con Google. Il sito mi rimanda a una pagina speciale che ha vari parametri nell'URL, che come vedete è lunghissimo. A noi interessano alcune parti in particolare, quindi andiamo ad analizzarlo. Innanzitutto inizia con accounts.google.com perché banalmente sto facendo l'accesso con Google. Se avessi cliccato su accedi con Facebook avrei visto facebook.com in questo punto. Poi vedo sign in perché sto cercando di accedere, appunto, e vedo anche account chooser perché ero nella pagina che permette di scegliere gli dire quale account voglio utilizzare per fare l'accesso. Dopodiché abbiamo la parte di client ID, che sostanzialmente è il codice che identifica eBay. È come se eBay dicesse: ciao Google, sono eBay, mi riconosci? Ho questo codice che è quello che mi identifica. Dopodiché abbiamo la parte redirect URI che eBay usa per dire a Google: guarda, quando Veronica Paolucci ha finito di fare l'accesso con te, rimandala a questa pagina qui. A che pagina vengo rimandata? A signin.ebay.it. Quindi diciamo torno nella pagina di login Ebay. La parte response_type uguale code serve a dire che cosa vuole Ebay. Ebay vuole un codice di autorizzazione, quindi gli dice il tipo di risposta che voglio da te è code, un codice. Poi abbiamo lo scope, che è l'ambito della richiesta. Cosa sta chiedendo Ebay? Cosa vuole Ebay da Google? Lo dice qua: voglio OpenID, cioè voglio che tu mi autentichi l'utente, Voglio la sua email, c'è scritto email, e voglio il suo profilo, quindi il suo nome, le sue informazioni base. Lo state è un codice casuale segreto che genera eBay e che serve a prevenire gli attacchi di tipo cross-site request forgery, che ormai conoscete tutti alla perfezione perché ne abbiamo parlato qualche settimana fa. Dopodiché ci sono alcuni parametri come tipo continue, eccetera, che dicono come Google gestirà la richiesta. Basta. La magia di questo sistema, la cosa che unisce tutti i puntini di quello che ci siamo detti finora, è che abbiamo detto che OpenID Connect unisce autorizzazione e autenticazione, giusto? Sono due concetti difficili da capire, ma che in realtà noi vediamo in azione con i nostri due stessi occhi. Perché questa è la pagina di autenticazione, è la pagina che dice a eBay chi sono e serve ad autenticarmi sul sito. Quando clicco, arrivo nella pagina invece di autorizzazione con cui Google mi chiede: guarda, eBay vuole sapere queste cose, vuole ad esempio il tuo nome e la tua foto del profilo, vuole il tuo indirizzo email, gliele posso dire oppure no? E infatti qua sopra che cosa vediamo? Ingrandisco un po', vediamo la famosa scritta Auth, quindi siamo proprio nella pagina in cui ci viene richiesta l'autorizzazione. Se siete commossi lo capisco, è veramente molto bello tutto tutto ciò. Ora che abbiamo le idee chiarissime su come funziona Accedi con Google, è ora di passare alla domanda fondamentale del video, cioè: è un sistema sicuro? È più sicuro Accedi con Google o l'accesso con email e password? La risposta, se seguite il canale da un po', la conoscete già: nessuno dei due è sicuro. Non esiste niente di sicuro. Detto questo, i due sistemi hanno problemi diversi, quindi a seconda delle nostre esigenze e di quello che dobbiamo fare, possiamo scegliere di optare per uno oppure per altro. Il problema principale dell'accesso con email e password è che non sappiamo quanto siano sicure le nostre credenziali all'interno di quel sito. Magari sono in un database scritte in chiaro e appena un hacker riesce a infilarsi nel sistema se le frega tutte. Accedere con Google risolve questo problema perché io non do mai al sito le mie credenziali. Su di me salva solo un token che dice che ho fatto accesso con Google. Il problema di fare accedi con Google è che se uno riesce a mettere le mani sulle mie credenziali Google potrà accedere praticamente ovunque come se fosse me. E come fa a mettere le mani sulle mie credenziali? Hackerare Google e prenderle dal loro database? È una mission impossible secondo me. Ma può semplicemente convincere me a dargliele, ad esempio con una mail di phishing ben costruita, magari che sembra provenire da eBay e in cui c'è scritto: attenzione, sono stati fatti dei tentativi di accesso strani sulla piattaforma, Quindi ti preghiamo di rifare l'accesso cliccando su questo link. Aprite il link e vi trovate davanti una pagina che sembra legittima, quindi inserite la vostra mail e la vostra password di Google che finiscono dritte dritte nelle mani dei malintenzionati. Pensate sia una cosa difficile da fare? Io ho fatto un esperimento, ho chiesto a Claude, che è un'intelligenza artificiale molto usata per il coding, di crearmi una pagina uguale ad Accedi con Google. Lui me l'ha fatto in tipo 3 secondi, come vedete. Poi io sono stata talmente pigra che anziché prendere questo codice, copiarlo, incollarlo, salvarlo come HTML, eccetera eccetera, gli ho scritto rendimelo un file scaricabile. Lui me l'ha fatto, quindi potevo scaricarlo direttamente da questo pulsante. E vi faccio vedere qual è il risultato. Il risultato è questo. Allora, a parte il logo di Google che è evidentemente fasullo e il link qua in alto che non c'entra nulla con quello che abbiamo visto è una pagina praticamente perfetta e l'ho fatta in un minuto e mezzo con l'intelligenza artificiale. Quindi sì, fregarci le credenziali è molto facile. Come ci difendiamo? Ci sono per fortuna vari modi. Il primo è implementare ovunque l'autenticazione a più fattori. In questo modo, se un malintenzionato ha in mano le mie credenziali Google e prova a inserirle, Google gli dice: "Ok, però per confermare che sei tu clicca sulla notifica che ho inviato al tuo telefono." Il malintenzionato non ha accesso al mio telefono, si spera. Io vedo la notifica, dico no, non sono io, non confermo, e lui non può entrare. Il secondo ovviamente è non autorizzare gli accessi che non riconosciamo. Il terzo è prestare attenzione ai dettagli, come al link in alto nella barra di ricerca. Abbiamo visto che aspetto deve avere. Se c'è qualcosa che non ci torna in pieno, nel dubbio non fidiamoci. Il quarto è: se mi arriva una mail come quella che ho descritto, quella di eBay che dice che appunto c'è da rifare l'accesso, nel dubbio anziché cliccare sul link link, io chiudo la mail, vado sul sito e controllo. Piuttosto, se devo rifare l'accesso, lo faccio direttamente dal sito. Queste regole base ci aiutano a evitare che ci rubino le credenziali di Google. Oltre a queste, possiamo adottare altre accortezze per rendere più sicuro l'utilizzo di questo sistema. Intanto, quando un sito o un'applicazione ci fa fare accedi con Google o con Facebook, insomma quello che vogliamo, prestiamo attenzione a cosa vuole ottenere come autorizzazioni. Presente quella pagina che dice questo sito vuole accedere a il nome, eccetera eccetera. Se io sono sul sito www.tavoletteperwater.com e il sito mi chiede l'autorizzazione a vedere il mio nome, il mio indirizzo email, la mia foto profilo, il mio Drive, le mie mail, i miei contatti in rubrica, insomma inizia a essere un po' troppa roba, no? Forse è meglio non mettere in mano a questo sito tutto il mio universo Google. In questi casi, se proprio voglio autenticarmi su quel sito, tornerò indietro e mi registrerò con email e password. Almeno quello che inserisco è l'autorizzazione che che vuole posso monitorarle. Se pensate che questa sia un'ipotesi molto improbabile, aspettate di sentire quello che è successo con Google Docs nel 2017, quando un milione di utenti in meno di un'ora è stato fregato proprio dall'uso sbagliato di Accedi con Google. Ma di questo ne parliamo la prossima settimana. Un'altra cosa che mi sento di consigliarvi è di diversificare. Se uso per tutto Accedi con Google, il giorno che Google viene attaccato fregato, o bind down, o mi rubano le credenziali, sono fregato. Meglio usare per alcune cose accedi con Google, per altre accedi con Facebook, per altre email e password. L'ultima cosa è: prestate attenzione agli alert che vi inviano i provider, quindi Google, Facebook, eccetera. Se Google ci invia una mail con scritto "è stato rilevato un accesso dal Vietnam", non ignoriamo la cosa, cambiamo subito le credenziali, impostiamo l'autenticazione a più fattori se non ce l'abbiamo già, Insomma, proteggiamoci. Bene, come sempre spero che il video di oggi vi sia piaciuto. Fatemi sapere nei commenti cosa ne pensate, se usate accedi con Google oppure no, se avete altri dubbi scriveteli nei commenti e non perdetevi i video della prossima settimana in cui vedremo come anche Google può essere ingannato. A presto!