Memorizzazione di password generate dal server

Il rischio intrinseco nelle password è che gli utenti sono cattivi nella scelta di password valide e tendono a riutilizzare le password. In uno scenario come questo, sembra che la password generata dal sistema non sia mai stata inviata all'utente. Non controlli la loro password sul lato Facebook. Ti interessa solo l'autenticazione con il sistema di Facebook. I rischi sono significativamente più bassi, a meno che tu non condivida la password generata dal sistema con l'utente, a quel punto tutte le puntate sono disattivate.

Seguendo buone pratiche di sicurezza, dovresti ancora hash le password (mai memorizzarle in testo non crittografato, a meno che non ci siano validi motivi tecnici per non farlo, o se disponi di altri controlli compensativi per proteggere tali password) e cambiarli regolarmente. Dovresti avere un meccanismo per generare nuovi token con Facebook, quindi potresti programmare un processo per farlo automaticamente ogni 30 giorni circa ...

Una domanda interessante, ecco come vorrei affrontare questo problema (si noti che tutti questi passaggi sono teorici).

NEWAPP, come lo descrivi, non è una forma di un sito Web, ma un'APP, quindi supporrò che tu abbia esecuzione di codice sull'host del client e abbia accesso all'ID hardware del dispositivo.

La complessità e l'usabilità dipenderanno dalla sicurezza coinvolta, e un tale design potrebbe sembrare non eccessivamente facile da usare. L'idea di base è utilizzare l'id dell'hardware (stringa univoca per ogni dispositivo) come seme per generare una coppia di chiavi pubblica + privata e memorizzarla sul dispositivo client. La verifica dell'identità dell'utente viene eseguita firmando i messaggi tra client e server con una chiave corretta.

Ci sono 3 scenari di base per l'utilizzo di un tale progetto:

1. L'utente crea un account e il suo dispositivo genera la coppia di chiavi e invia la chiave pubblica al server, insieme all'ID hardware iniziale. Il server genera un nome utente eseguendo l'hashing della chiave pubblica con l'id dell'hardware come salt. Questo nome utente viene inviato al client e archiviato localmente.
2. L'utente aggiunge un nuovo dispositivo all'elenco autorizzato e verifica la sua identità e proprietà dell'account tramite un canale laterale, sia esso email, sms, richiesta da in-app. Ad esempio, l'utente immette un indirizzo email associato all'account e riceve un'e-mail con una stringa univoca generata dal server. L'utente copia questa stringa in NEWAPP, che lo identifica, e viene avviata una procedura simile alla creazione di un nuovo account (la nuova chiave pubblica aggiunge una nuova chiave, senza rimuovere quella precedente).
3. Un utente accede da un dispositivo autorizzato, il server e il client utilizzano PKI per trasmettere e firmare diversi messaggi casuali per verificare l'identità del client e l'utente è autenticato.

In questo modo, il client sarebbe in grado di accedere solo dopo aver autenticato il suo dispositivo e non sarà necessaria alcuna password. Potresti anche consentire una maggiore sicurezza e consentire ai client di utilizzare una passphrase per la loro coppia di chiavi.

Questo design è vulnerabile al furto di id o chiavi hardware da parte di malware, ma questa è una storia completamente diversa.