Come implementare un "Remember me" su un'app mobile?

Mi piace il suggerimento di symcbean di creare un valore mappato casuale all'accesso che sia correlato all'account separatamente dal nome utente e dalla password. Per rispondere in modo specifico alla tua domanda, ci sono anche modi per crittografare i dati senza una chiave mappata statica. Prenderò in considerazione la generazione di una chiave utilizzando bit di informazioni univoci per il telefono e recuperabili tramite chiamate all'OS API.

Modifica : per volere di @DW, elaboro: L'UDID, il numero di serie e altre informazioni identificative possono essere di qualità e segretezza crittografica sufficienti senza accesso al telefono per impedire la decrittografia dei dati memorizzati. Tuttavia, l'accesso ai dati memorizzati implica probabilmente l'accesso al telefono. Pertanto, qualsiasi livello di sicurezza attraverso la crittografia locale del dispositivo è semplice oscurità.

Altri intervistati hanno suggerito di archiviare un valore casuale come è stato fatto nelle sessioni HTTP. Sembra che il richiedente originale non stia usando HTTP e non crede che questo metodo si applichi al suo software. Tuttavia, l'implementazione logica di memorizzare e trasmettere un valore casuale è applicabile a qualsiasi protocollo di trasporto. Lo consiglio vivamente.

In alternativa, le credenziali possono essere memorizzate sul telefono utilizzando la crittografia a chiave pubblica. L'applicazione può crittografare il nome utente e la password al momento dell'ingresso con la chiave pubblica del server. I dati di accesso sarebbero quindi illeggibili anche se il dispositivo fosse stato compromesso.

Laddove l'obiettivo è impedire il recupero delle credenziali di accesso, ritengo che l'uso di un identificatore temporale casuale sia il migliore. Ciò preclude qualsiasi problema relativo alla conservazione segreta e disponibile dei dati del server (una chiave privata). Se tale chiave fosse divulgata, la protezione è marginale a inutile. Se viene perso, l'app deve essere ridistribuita con una nuova chiave. Se i dati di accesso temporali sono stati persi, tutti sarebbero stati costretti ad accedere, ma non comporterebbe alcuna interruzione sensibile al servizio.

Inoltre, utilizzare la crittografia a chiave pubblica del trasporto (SSL o chiave PGP semplice incorporata nell'app) sia per l'accesso iniziale che per tutti gli altri dati di autenticazione possibili, indipendentemente dal nome utente e password o da un valore casuale.

Non memorizzare nome utente e password sul telefono.

Invece, ti suggerisco di seguire una delle seguenti strategie:

• Utilizza un cookie persistente. Questa è la soluzione facile. Se ci si connette a un sito Web, fare in modo che il server autentifichi l'utente la prima volta che accede e quindi imposta un cookie persistente sul telefono dell'utente contenente una stringa casuale a 128 bit (crittograficamente) associata all'account dell'utente. Ogni volta che l'utente avvia l'applicazione, quando contatta il server su HTTP / HTTPS, il client invierà il suo cookie permanente, che il server può utilizzare per autenticare il client. Idealmente, dovresti utilizzare HTTPS e utilizzare i cookie sicuri.

• Utilizza l'autenticazione con chiave pubblica. Questa è la soluzione più complicata. È possibile che l'applicazione telefonica generi la propria coppia di chiavi pubblica / privata. Quando l'utente accede per la prima volta, l'applicazione può inviare la chiave pubblica e il server può associare la chiave pubblica a quell'account. Ogni volta che l'utente avvia l'applicazione, l'applicazione può autenticarsi sul server utilizzando la chiave privata.

  • Ad esempio, se si utilizza la tecnologia Web, è possibile che il client generi un certificato autofirmato, si connetta al server utilizzando HTTPS e si autentichi utilizzando il relativo certificato cliente. Dovresti verificare se le visualizzazioni web su Android supportano bene i certificati client.

  • In alternativa, se ci si connette al server utilizzando il proprio protocollo personalizzato, eseguire il tunneling su SSL o TLS e utilizzare la funzione di certs client di SSL / TLS.

Non usare il nome utente / password per il token!

Se è possibile decifrare, c'è il rischio che venga decodificato. E anche se la maggior parte dei peolpe sa che non dovrebbero, usano le stesse password per più servizi - quindi anche se il tuo servizio non è particolarmente prezioso, hai la responsabilità di proteggere i passworsd dati a te.

Il modo di risolvere il problema è lo stesso della gestione delle sessioni HTTP - utilizzare un identificatore surrogato (che può mantenere lo stesso valore del cookie di sessione - ma con una durata più lunga) quindi mantenere una tabella di ricerca dell'identificatore surrogato, il utente a cui è stato rilasciato e il tempo di scadenza.

La seconda opzione di D.W. è meglio implementata con le seguenti correzioni & ulteriori dettagli:

• genera una coppia di chiavi sull'app, dopo che l'utente ha eseguito l'autenticazione con successo utilizzando il normale meccanismo di autenticazione e durante la sessione autenticata.
• genera un UUID sul telefono (non utilizzare l'ID del dispositivo integrato OS / API né altri identificatori univoci che possono essere recuperati da qualsiasi altra app), crittografarlo * e memorizzarlo (* vedere sotto per le migliori pratiche di crittografia per i dati delle app su un telefono cellulare.
• utilizza in modo programmatico una combinazione di UUID e alcuni dettagli di telefono disponibili, puramente un po '(anziché semplicemente concatenandoli) per generare un AppDeviceId che solo l'App conosce.
• invia la chiave pubblica + AppDeviceId al server su un canale protetto (SSL / TLS firmato da una CA veramente affidabile), senza compromessi, per registrare il dispositivo e la chiave pubblica.
• ora per la crittografia: genera una chiave di crittografia a livello di codice utilizzando una combinazione di un UUID (non quello che usi per rendere AppDeviceId) e alcuni dettagli telefonici disponibili, puramente unificati (anziché semplicemente concatenandoli). Se riesci a legare la password / pin del lockscreen del telefono è ancora meglio (su iOS questo viene fatto sotto il cofano con il portachiavi, l'utente infatti utilizza una password / pin lockscreen).
• memorizza l'UUID che hai creato per generare la chiave di crittografia nella memoria a cui è consentito "l'accesso" alla tua app (tenendo presente che un dispositivo rooted significa che qualsiasi app o utente può probabilmente accedervi comunque ... e questo è il punto più debole).
• crittografare e archiviare l'UUID creato per AppDeviceId e crittografare e memorizzare la chiave privata crittografata. Anche in questo caso, utilizza lo spazio di archiviazione a cui è consentito "l'accesso" alla tua app (tenendo presente che un dispositivo rooted significa che qualsiasi app o utente può probabilmente accedervi comunque).
• per autenticarsi in futuro l'app dovrebbe firmare un payload noto sia all'app che al server, ad es. AppDeviceId, utilizzando la chiave privata e invialo su un canale protetto (SSL / TLS ecc.) al server. Il server deve verificare la firma utilizzando la chiave pubblica.
• Se il server riceve mai un'autenticazione tentata, utilizzando un determinato AppDeviceId, che fallisce allora rimuove / cancella / dimentica la chiave pubblica registrata e blocca ogni ulteriore tentativo di autenticazione usando questo meccanismo di chiavi in mano fino a quando l'Utente non autentica usando un altro (tipicamente ) tecnica più sicura e collaudata (come il processo di autenticazione che stai aumentando con questo nuovo, o di persona con i documenti giusti, ecc.)
• l'aggiunta del limite di tempo sulla keypair è ancora migliore (attenua il dirottamento prolungato), in questo modo l'Utente deve autenticarsi usando una tecnica più sicura e collaudata di volta in volta.

In base a quanto sopra, ci vorrebbe la decompilazione e il reverse engineering del codice + accesso ai dati memorizzati sul dispositivo (accesso fisico al dispositivo O app maliziosa sul dispositivo rooted) + conoscenza del dispositivo (impronte digitali tramite qualche trucco o accesso fisico al dispositivo O al controllo di un'app sul dispositivo) per poter utilizzare quella coppia di chiavi e AppDeviceId per l'autenticazione.