Procedura per creare un sistema di autenticazione utente tra mobile e server

Non hai bisogno di metà di quelle parti. Aggiungendoli creerai solo un sistema più complicato, con più spazio per errori.

Potresti fare questo:

1. Utilizza blocco dei certificati sul dispositivo

   Ciò garantisce che il dispositivo stia parlando al tuo server e rende il lavoro molto difficile per qualsiasi terza parte che tenta di leggere il flusso di dati.

2. Utilizzando SSL, invia login e password al server

   È possibile saltare qualsiasi altro dato. Timestamp, frasi segrete, qualsiasi altra cosa è superflua. Potresti inviare un ID dispositivo, può essere utile per la contabilità, non per l'autenticazione. Non hai bisogno delle informazioni, lascialo fuori. L'utilizzo di SSL consente di inviare la password così com'è, senza crittografia, hashing o codifica. SSL crittograferà te, in modo trasparente.

3. Salva il nome utente in chiaro, cancelletto e salta la password

   L'hashing del nome utente non fornisce alcuna sicurezza e aumenta la tua difficoltà. La salatura e l'hashing della password aiuteranno i tuoi dati a sopravvivere più a lungo in caso di perdita di database. Basta selezionare il giusto algoritmo di crittografia e buoni sali. Questo sito è un ottimo riferimento per l'archiviazione delle password.

4. Utilizza i token con il tempo di scadenza

   Archivia i token sul database e inviali al client. Non è necessario modificare il token su ogni richiesta, è sufficiente vedere se il token corrisponde e non è scaduto. Ad ogni nuovo accesso, scadono i token più vecchi.

Non fidarti del cliente. Non importa quanto sia sicuro il codice cliente, qualcuno può romperlo. Tienilo a mente quando progetti la sicurezza del tuo sistema.

I passaggi da 1 a 3 sono obsoleti in quanto non forniscono alcuna sicurezza qui solo l'oscurità. Le credenziali non dovrebbero mai essere hardcoded (CWE 748).

Passaggio 4: buono, assicurati di eseguire il blocco dei certificati

Passaggio 6: come recupererai la password per un determinato nome utente se lo hai cancellato? Quale algoritmo stai usando?

Passaggio 7: Perché utilizzare AES, perché non generare un token casuale utilizzando un generatore casuale sicuro crittografico. Se usi AES mi fai pensare che il token sarà sempre lo stesso che ti rende vulnerabile a CWE-384.

I passaggi 8 e 9 sembrano buoni, è così che funzionano le sessioni.

Normalmente la tua applicazione non dovrebbe essere altro che un frontend per l'API serveride. Tutte le autorizzazioni e le autenticazioni devono essere eseguite sul server. Ciò richiederà all'utente di inserire la sua password ogni volta o di memorizzarla nella cache. Se si desidera salvare le credenziali sul dispositivo, queste saranno sempre recuperabili da un utente malintenzionato che ha accesso al dispositivo (a quel punto è comunque troppo tardi).

Quindi fondamentalmente un primo accesso non dovrebbe essere nient'altro che un utente che si registra come faresti con una normale applicazione web. Gli utenti creano una determinata password e nome utente. Questo è passato attraverso SSL al server.

Non ci sono quasi differenze tra applicazioni web mobili e normali quando si tratta di creare applicazioni sicure. Hai un'applicazione server e un'applicazione lato client. La differenza è che invece di usare un browser ora crei il front-end grafico, usato per rappresentare l'informazione, te stesso. Ma si applicano gli stessi principi.

I tuoi commenti:

Se un utente malintenzionato è in grado di ottenere l'accesso fisico o remoto a un dispositivo, non è più il dispositivo.

Lo sniffing SSL non esiste realmente. SSL / TLS è stato creato per impedire che si verifichi lo sniffing. Una cosa è assicurarsi che l'applicazione verifichi se i certificati SSL sono validi. Per informazioni ancora più sensibili, è necessario eseguire il blocco dei certificati.