Stavo cercando un modo per rendere l'esperienza di autenticazione il più semplice possibile e questo progetto mi è venuto in mente, in cui Google utilizzava l'account registrato sul tuo telefono per accedere al tuo browser.
Ad ogni modo, dopo 4 anni, non l'ho visto diventare una cosa reale.
L'unico esempio a cui posso pensare è l'applicazione desktop di WhatsApp.
Mi stavo chiedendo se questo è collegato con alcuni problemi di sicurezza che non sto considerando.
Non vedo alcun problema di sicurezza con questo approccio, semplicemente utilizza una sessione già esistente (la tua sessione Google nel browser mobile) per approvare una richiesta di accesso per una nuova sessione.
Facebook fa qualcosa di simile - quando attivi 2FA si comporta come ci si aspetterebbe, ma se hai la loro app mobile ricevi una notifica e puoi approvare il login dall'app stessa senza nemmeno dover inserire un OTP nella pagina di accesso.
Penso che non sia decollato a causa di problemi di usabilità e svantaggi rispetto alle OTP standard. In entrambi i casi devi estrarre il telefono, ma con questo sistema devi anche scattare una foto del codice QR e quindi essere connesso a una rete per accedere all'URL. Il semplice vecchio TOTP è altrettanto sicuro ma privo di questi inconvenienti.
Infine, questo è finalizzato a contrastare il malware su macchine non attendibili, ma il problema è che, indipendentemente dal modo in cui accedi, il computer compromesso sarebbe comunque in grado di utilizzare e abusare del tuo account comunque, in quanto otterrà l'accesso a un account in sessione. Il modo in cui hai effettuato l'accesso non ha molta importanza se può ancora accedere e prendere tutti i tuoi dati personali.
Vedo un rischio per la sicurezza con la "richiesta di accesso approvata" senza codice QR, che viene utilizzata oggi, e cioè che l'approvazione di accesso non è in alcun modo legata alla sessione nel computer che si è utilizzato.
Ergo, se un utente è in qualche modo ingannato nell'accettare una richiesta di accesso che non è sua, l'account è compromesso.
Per prendere 3 esempi:
Esempio 1: se un utente effettua l'accesso, ma immediatamente prima, un utente malintenzionato tenta di accedere. L'utente riceverà una richiesta di accesso, penserà al suo "suo" login, ma in realtà sta approvando quella di un utente malintenzionato.
Esempio 2: un utente malintenzionato invia un'e-mail falsa. Fai clic sul link di questa email falsa e tieni indirizzato a una pagina HTML statica, che indica semplicemente all'utente di approvare l'accesso al telefono. Non appena viene caricata questa pagina HTML statica, l'utente malintenzionato lo rileva e tenta di accedere. Il problema con questo è che l'utente malintenzionato non ha bisogno di eseguire alcun codice o raccogliere alcuna informazione, il che significa che è possibile utilizzare pagine HTML completamente statiche. È improbabile che queste pagine generino avvisi nei sistemi anti-phishing e, inoltre, un altro problema è che l'utente malintenzionato può utilizzare un hosting anonimo non tracciabile, anche se l'hosting blocca completamente script / pagine dinamiche o persino un XSS non persistente riflesso. di qualche altra pagina, potrebbe essere usato per "ospitare" la pagina di phishing. Ciò significa anche che è improbabile che l'host rimuova il contenuto (ad esempio "Abbiamo bloccato i tag modulo e script in modo che nessuno possa ospitare il phishing qui in ogni caso").
Esempio 3: una variante dell'esempio 2, ma qui l'autore dell'attacco scrive direttamente nel corpo dell'email che per qualche ragione deve accettare la richiesta di accesso. Quindi l'utente malintenzionato carica una piccola immagine 1x1 per rilevare quando viene letta l'e-mail, quindi effettua il tentativo di accesso.
Per attenuare:
Richiedi che l'utente inserisca una sorta di "sfida" o "ID di sessione" per rispondere alla richiesta di accesso. In alternativa, ciò può essere fatto richiedendo all'utente di inserire un codice casuale nel telefono, ad esempio "Inserisci il codice 6236 nel telefono per approvare la richiesta di accesso" e quindi sul telefono viene visualizzato "Inserisci il codice visualizzato sullo schermo per approva: "+ inputbox. Anche un codice QR che deve essere scansionato è un'altra valida alternativa per garantire una connessione tra la richiesta di accesso al computer e la richiesta di accesso al telefono. Questo è in realtà ancora più sicuro, in quanto garantisce una linea di visuale tra il dispositivo di accesso e il dispositivo connesso.
O questo può essere fatto completamente fuori banda usando qualche challenge-response dove l'utente inserisce una sfida, poi questo viene calulato per quanto riguarda alcuni segreti memorizzati, quindi una risposta può essere mostrata sullo schermo del telefono, che deve essere inserito sul sito web per procedere.
Ecco perché uno schema basato su QR è più sicuro.
Leggi altre domande sui tag authentication phone qr-code