È sicuro utilizzare un meccanismo di autorizzazione stateless in cui la password di cancellazione è memorizzata sul portachiavi?

Which drawbacks do you see?

Gli svantaggi che vedo hanno principalmente a che fare con ciò che non è esplicitamente affermato nella domanda piuttosto che ciò che è esplicitamente affermato. In generale, non hai indicato quale tipo di aggressore ti interessa proteggere? Un utente malintenzionato ficcanaso su una rete locale? Un aggressore locale?

The client provides an email and password and saves the clear password on the Keychain of iOS and using some alternative for Android.

Ok, quindi supponiamo di non essere preoccupati per un aggressore / processo locale (stessa macchina) che ha già dato in pegno il nostro telefono. Se eravamo preoccupati per questo tipo di attacco potremmo anche usare un dispositivo fisico MFA (fob RSA o altro). In questo caso non sono particolarmente preoccupato per i dati a riposo sul telefono ...

The server checks the password strength if it's deemed strong enough the user is created on DB.

Come è arrivata la password dal client al server? Se passa da client a server su https, le cose dovrebbero andare bene. Se viene inviato non criptato, allora questa è una cosa negativa .

Come fa il server a fare il controllo? Qual è la password controllata contro ? Il server non deve memorizzare una copia in chiaro della password, piuttosto il server deve solo memorizzare un hash crittograficamente strong della password (basta usare bcrypt).

Inoltre, il server sta facendo il controllo della forza ogni volta? Perché? Solo hash e confronta con l'hash memorizzato.

The server generates a JWT token and returns it to the client. The token has an expiration time of 15 minutes.

Ancora una volta, tutti i dati in transito dovrebbero essere crittografati, compreso ovviamente il token JWT. In base all'aggiornamento, utilizziamo HTTPS finché il canale TLS è veramente sicuro e non dovrebbe esserci un problema (dato che stiamo ignorando un aggressore locale come sopra).

D'altro canto, se esiste la possibilità che il token JWT possa essere rubato, si applicano alcune altre considerazioni. Ad esempio, è necessario assicurarsi che la chiave utilizzata per firmare il token JWT sia sufficientemente complessa in modo che non possa essere forzata bruta.

Sign in

When the client receives an HTTP 401 from the server it means a login is required. So the app accesses to the Keychain and gets the email & password and sends it to the server (no user intervention needed).

Il client si connette solo a un server conosciuto? Come viene identificato il server? È solo tramite un nome di dominio? Che cosa fa a qualcuno il dominio o il pasticcio con il file hosts? Inoltre, e se ci fosse un uomo-in-the-middle che manda indietro 401, riceverà quindi l'e-mail e la password come farebbe il server?

Aggiornamento : in base ai commenti, viene utilizzato HTTPS.

Come tale, il client e il server comunicano utilizzando un canale protetto tramite TLS. Il server (impostato dall'utente, presumibilmente) invia un certificato al client. Questo certificato contiene informazioni che identificano il server e la chiave pubblica del server. Tuttavia, non vi è alcun motivo per cui ci si debba fidare di questo certificato a meno che non sia firmato da una parte di cui ci si fida (e il cui certificato è già incorporato nel trust store del dispositivo client, utilizzato per controllare la firma). Ad esempio, il certificato del server potrebbe essere intercettato e sostituito da un aggressore MITM.

Pertanto, per avere un canale HTTPS sicuro è necessario che il certificato del server sia firmato da una terza parte che è già nota e attendibile dal computer client. Ad esempio, per Apple è disponibile un elenco di parti attendibili ( link ).

Poiché anche tu stai (presumibilmente) scrivendo l'app del cliente, potresti anche incorporare il certificato o la chiave pubblica conosciuti nell'app stessa e confermare il certificato del server rispetto al certificato incorporato. Questo è chiamato pinning del certificato.

Puoi anche considerare l'utilizzo di HTTP Strict Transport Security per aumentare ulteriormente la sicurezza dell'applicazione.

Questa è una domanda ben fatta, e come la stessa domanda pone, anche gli esperti avranno opinioni diverse nel contesto di inquadrature assolute / astratte di sicurezza.

Naturalmente la realtà sfumata è che non esistono "assolutamente sicuri", solo vari gradi di insicurezza, i cui intervalli possono essere più o meno appropriati in ogni specifica situazione specifica.

In assenza di ulteriori informazioni, alcune domande del punto di partenza per aiutare il brainstorming / modellazione delle minacce:

• Quali dati proteggono queste credenziali?

  A un'estremità dello spettro, l'app potrebbe essere un gioco, le credenziali che proteggono lo stato di gioco non sensibile. Dall'altro lato, le credenziali potrebbero proteggere le informazioni mediche sensibili.

• Chi sono i tuoi utenti?

  I tuoi utenti sono persone poco sofisticate che potrebbero utilizzare la stessa password su molti servizi, incluso il tuo?

  I tuoi utenti potrebbero essere membri di un gruppo identificabile che potrebbe essere più o meno soggetto ad avere i loro dispositivi compromessi / cercati / clonati (ad esempio giornalisti, personale aziendale di alto livello)?

• Che cosa potrebbe accadere ai singoli utenti e alla tua comunità a seguito di un compromesso?

  Un attore che compromette l'account di un utente sotto questa app può compromettere altri utenti o rubare denaro o eseguire altri danni costanti e costanti?

Hai un'idea.

L'unico pensiero aggiuntivo è che una password è fondamentalmente una credenziale particolarmente potente che dovrebbe funzionare ovunque da qualsiasi dispositivo in qualsiasi momento.

Un'alternativa all'archiviazione della password sul dispositivo consiste nel generare un token a lungo termine, specifico del dispositivo, da salvare sul dispositivo anziché nella password e utilizzato per eseguire nuovamente l'autenticazione solo da quel dispositivo. Questo token non deve essere un token "refresh" monouso, a volte le applicazioni eseguono l'hash della password un numero elevato di volte e lo usano.

Sicuramente il supporto per qualsiasi schema di autenticazione aggiuntivo richiede una complessità aggiuntiva. Le circostanze possono aiutare a determinare se ne vale la pena. In situazioni più sofisticate, gli scenari di compromesso possono avere stime di probabilità e stime di perdita, insieme agli intervalli di sviluppo, manutenzione e supporto, e i metodi Monte Carlo possono essere utilizzati per migliorare l'intuizione sul fatto che singoli bit di complessità offrano protezioni riducendo il rischio e perdita - che possono valere i costi a lungo termine.

Buona fortuna!