Cosa posso fare per aumentare la sicurezza della mia app sulla base di un segreto condiviso?

Question

Cosa posso fare per aumentare la sicurezza della mia app sulla base di un segreto condiviso?

#1 da (1 voti)
#2 da (0 voti)

2

Sto lavorando a un'app che verrà eseguita su una TV degli utenti e con un'app mobile companion.

Volevo presentare un codice QR ai miei utenti dall'app TV, che viene poi scansionata dalla videocamera dell'app compagno. Inizialmente pensavo di codificare un UUID v4 nel codice QR e usarlo come segreto condiviso tra le due app. Questo valore identifica in modo univoco quel particolare dispositivo TV.

Una volta che i segreti condivisi sono stati scambiati, le app si collegano al mio server tramite prese web e ascoltano / emettono eventi per quell'UUID. Non ci sarebbero altre password o nomi utente. Questa comunicazione sul socket Web verrebbe eseguita utilizzando WSS / TLS.

Questo servizio è un sistema di trasporto di messaggi molto semplice tra l'app mobile e l'app TV. Non ci sono database, nessun utente, ecc. Tutti i messaggi passano direttamente.

Quanto pessima idea è questa? Se il segreto condiviso è quasi impossibile da indovinare, mi sembra abbastanza sicuro a prima vista. C'è comunque potrei renderlo più sicuro?

Un'idea che avevo era di usare qualche forma di TOTP . Quel sistema si basa anche su un segreto condiviso, ma usa un componente basato sul tempo per modificare il segreto prima di scambiare / confrontare. Ciò impedirebbe l'esposizione del mio vero segreto e impedirebbe attacchi di replay. Tuttavia, per la mia applicazione, avrei bisogno di una finestra temporale molto più ampia del tradizionale TOPT, in quanto vorrei che questa chiave fosse valida per più di qualche secondo.

secret-sharing

posta mmcdole 25.09.2015 - 04:28

fonte

2 risposte

Leggi altre domande sui tag secret-sharing

Che cos'è "Intentionally misting Intelligence Artificiale per creare un risultato fuorviante"? La specifica della versione della libreria (Java pom.xml, Python's requirements.txt, ecc.) è fondamentalmente insicura?

score 1 · Answer 1

Questo è un problema risolto da OAuth 2 e Open ID Connect (OIDC). Suggerirei caldamente di crearlo piuttosto che inventare il proprio protocollo. Date un'occhiata alla OAuth workflow dispositivo 2 (Google ha una descrizione eccellente) .

Innanzitutto, aiuta a dividere l'autenticazione dall'autorizzazione. L'autorizzazione è ciò che si desidera ottenere (ad esempio autorizzando la TV). Se il flusso di lavoro di autenticazione richiede il login o no, o coinvolge più fattori è qualcosa che dovrebbe essere considerato separato dal flusso di lavoro dell'autorizzazione e potrebbe essere qualcosa che si desidera configurare.

Il diagramma seguente delinea il flusso di lavoro del dispositivo OAuth 2.

TV app                                    Server
   |                                        |
   |----------- request code -------------->|
   |<------- url & auth code (QR) ----------|
   |                                        |
   |   code             mobile     user     |
   |-- & url --> user --> app --> login? -->|
   |                                        |
   |---------------- poll ----------------->|
   |<-------------- token ------------------|
   |------- use token to register --------->|

Il codice di autenticazione può essere in forma di barre che le scansioni utente con l'applicazione mobile, oppure può semplicemente essere un codice che l'utente dovrà digitare manualmente nella loro applicazione mobile.

Nella suddetta link di Google, ciò che essi descrivono come ID del dispositivo può essere l'UUID che lei ha citato, ma potrebbe anche essere una stringa casuale generato saldamente associato con la vostra applicazione.

Esistono linee guida in OAuth 2 e OIDC per l'utilizzo dei segreti condivisi, necessari solo per proteggere le credenziali. Nel flusso di lavoro di cui sopra in quanto l'applicazione mobile è responsabile per l'autenticazione, si ha la possibilità di utilizzare un segreto condiviso con il server (noto anche come client riservata) o meno (anche conosciuto come un cliente pubblico).

La questione se hai bisogno di autenticazione dipende da dove risiede il tuo server. Se si trova su Internet, si consiglia l'autenticazione: molte librerie / applicazioni server OAuth 2 consentono di integrarsi con vari account di social media, pertanto potrebbe non essere così doloroso come si potrebbe pensare. D'altra parte, se il server risiede nella rete domestica locale dell'utente, forse l'autenticazione non è necessaria.

Ci sono molte librerie OAuth 2 / OIDC client e server che ti semplificheranno la vita. Per quanto riguarda il server, puoi persino utilizzare le applicazioni server (ad esempio Keycloak ) con funzionalità sportive come TOTP per migliorare la sicurezza.

score 0 · Answer 2

Come indicato, il tuo approccio userebbe la stessa chiave (dal momento che non usi una directory chiave) per tutte le app. Quindi ottenere la chiave da un dispositivo utilizzando l'app consentirebbe la decrittazione dei messaggi crittografati dei messaggi inviati da tutti i dispositivi che utilizzano quell'app. Dovresti rispondere alle seguenti domande:

Come vengono generati i tasti?
Qual è il parametro di sicurezza previsto (lunghezza della chiave in bit)?
Quanto è facile recuperare la chiave dall'app?

Incorporare la chiave in un codice QR non è sicuramente una buona idea in quanto può essere facilmente recuperata dalla sua forma codificata. La chiave deve essere conservata segreto .

Invece di un algoritmo di crittografia / autenticazione domestico, è molto più consigliato utilizzare un approccio di sicurezza comprovato come TLS.