Autenticazione senza login e password nelle app mobili

Lavoro come professionista IT Security (IT Auditor), quindi posso rispondere per esperienza.

In primo luogo, definirò un token sicuro. Affinché il token di accesso sia sicuro: dovresti soddisfare quanto segue:

1. Il token scade a un certo punto
2. Il token non può essere modificato in transito tra client e server.
3. L'utente non può modificare il token.

Token expires at some point

Questo requisito è il più semplice. Si specifica una data in cui questo token non sarà più valido, sul lato server. Se la data del login > data di scadenza del token, quindi rifiuta il token come scaduto.

Token cannot be modified in transit between client and server

Dato che stai utilizzando TLS, (auspicabilmente versione 1.2 e aggiornamento a 1.3 quando finalizzato) questo problema dovrebbe essere risolto già. TLS fornisce riservatezza , assicurando che il token di accesso non sia divulgato senza autorizzazione a una terza parte.

User cannot modify the token

Questo requisito è il più difficile. Per accompagnarlo, è necessario utilizzare una firma digitale con PKI. Non utilizzare SHA 1 come funzione di hashing perché questo algoritmo è INSECURE. Applicando la funzione di hashing ai risultati del token di accesso in un digest di messaggi. Il digest del messaggio viene quindi crittografato utilizzando la chiave privata che solo l'utente conosce. Una volta decifrate le credenziali sul server utilizzando la chiave pubblica dell'utente, se il messaggio risultante corrisponde alle credenziali sul server, allora è garantito che nessuna modifica del token di accesso da parte dell'utente ha avuto luogo.

Il metodo di cui sopra garantisce la riservatezza C e I - Requisiti di integrità della triade della CIA di sicurezza. Il non disconoscimento (l'utente non può negare che siano le sue credenziali) è garantito anche perché la chiave pubblica dell'utente è in grado di decifrare il messaggio crittografato ricevuto.

Per rispondere ad alcune delle tue altre domande:

Should I encrypt the access token locally when stored?

Sì, dovresti. Quanto sopra riguarda i dati in transito, ma non a riposo . Se un hacker dovesse compromettere la macchina client locale, lui o lei può facilmente rubare un token di testo in chiaro e quindi impersonare il legittimo proprietario.

How should I encrypt?

Dovresti utilizzare un algoritmo di crittografia strong come AES o RSA. Scegli una lunghezza lunga della chiave (es: 256) per massimizzare la sicurezza.

Is this safe against a remote or local attacker?

Una cosa che posso pensare è che un utente malintenzionato riproduce il token di accesso come mascherato come client valido.
Per mitigare questo, puoi usare il timestamp. Un'altra opzione potrebbe essere quella di ottenere un nuovo token di accesso dal server dopo ogni richiesta.

What would be the best way of storing the access token locally? Should I encrypt it locally? How should I encrypt? Should I encrypt it in the server database?

Mantenere il token di accesso come valore crittografato nella memoria locale può funzionare. Non sono un esperto di app mobili, ma credo che tu abbia accesso a un database in app mobili. È possibile memorizzare i dati crittografati lì. Allo stesso tempo, mantenere il token crittografato sul server è anche una buona idea.

Is this safe against a remote or local attacker?

Per raggiungere gli obiettivi che hai citato, vuoi davvero che il token sia crittografato sul lato server con una chiave solo server. Per farla breve (er), questo è molto difficile da fare correttamente come uno sviluppatore alle prime armi .

Per fare ciò correttamente è necessario considerare le protezioni contro:

• Malleability - la capacità dell'utente di modificare (o estendere) il token, indipendentemente dal fatto che l'utente possa leggerlo o meno. In genere ciò avviene con un HMAC .
• Riproduzione : la capacità dell'utente (o di qualcun altro che ottiene l'accesso al token) di riutilizzare il token in un altro contesto. Questo può essere fatto con date di scadenza o più completamente con token monouso (che vengono aggiornati con ogni utilizzo), con ogni soluzione che richiede diverse risorse lato server.
• Decrittografie o correlazioni a forza bruta - basate su attacchi come tabelle arcobaleno . Questi sono in genere mitigati con sali e peperoni / padding.

Devi anche preoccuparti di ruotare regolarmente la chiave del server, mantenendo la compatibilità con le versioni precedenti dei token generati (ad esempio per le versioni precedenti della tua app) e aggiornando lo schema crittografico sottostante se c'è un compromesso (es. vuoi revocare tutti i token in sospeso in questo caso?).

Analisi finale

Se vuoi preparare il tuo schema personale, ti suggerisco di collaborare con qualcuno con uno sfondo di crittografia solido (e aggiornato). Consiglierei una soluzione in scatola, ma non sono a conoscenza di tutto ciò che è liberamente disponibile e realmente sicuro plug-and-play.