Come supportare la creazione sicura di un account utente su un'API esterna tramite un lavoro in coda?

Question

Come supportare la creazione sicura di un account utente su un'API esterna tramite un lavoro in coda?

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (0 voti)
#5 da (0 voti)

7

Quindi questa domanda sta esplorando sicurezza e crittografia e il problema potenzialmente non è stato riscontrato da molti. Le risposte possono essere teoriche. Lasciatemi delineare lo scenario ...

Il frontend di un sito Web viene gestito tramite un'API di back-end. Il back-end ha un endpoint che gestisce un modulo di registrazione generico con username e password . Sta usando SSL.
L'API di back-end gestisce la registrazione tramite una coda di lavori asincroni. La coda non restituisce le risposte al server API. È un'operazione di impostazione e dimenticanza per accodare la registrazione.
I lavori in coda vengono prelevati dai lavoratori. I lavoratori si occupano della creazione dell'account utente. Questi lavoratori hanno bisogno di accedere alla password utente in chiaro in modo che possano attivare una chiamata di registrazione API di terze parti con la password.

Quindi il vero nodo del problema è la sincronizzazione della password con l'API di terze parti senza rivelarla a occhi indiscreti. La coda pone il problema di non avere più accesso diretto alla password in chiaro dai dati POST globali, il che significa che deve essere memorizzato in qualche modo nella coda.

La coda può facilmente memorizzare la password con hash e copiarla direttamente nella tabella degli utenti. Questa soluzione non consente la sincronizzazione della password con l'API di terze parti, tuttavia, poiché è già crittografata. Mi sono divertito con la crittografia a due vie, ma sono completamente preoccupato di lasciare la password soggetta a decrittazione da parte di un utente malintenzionato.

Qualcuno può pensare a un modo sicuro per gestire questo scenario di sincronizzazione delle password?

La coda è un requisito e si presume che questo sia leggibile da chiunque abbia accesso al server. Le password non devono necessariamente essere sincronizzate; la password per l'API di terze parti potrebbe essere una derivazione dell'originale fintanto che esiste un mezzo sicuro per decifrare tramite l'utente che ha effettuato l'accesso senza fornire la propria password. Si tratta essenzialmente di simulare il Single Sign-On con un'API di terze parti che non supporta SSO.

authentication encryption

posta Corey Ballou 12.03.2013 - 21:25

fonte

5 risposte

Leggi altre domande sui tag authentication encryption

Utilizzo di OAuth 2.0 senza memoria token I file temporanei sono un problema quando si apre e si modifica un file 7z crittografato?

score 1 · Answer 1

Questo sembra abbattere semplicemente;

Ho una coda di lavoro contenente password in chiaro.
Vorrei impedire ad altri utenti del server di accedere a tali password.

Sembra che dovrebbe essere abbastanza facile, assumendo che "altri utenti del server" non significhi un account di superutente.

Quello che devi fare è ingegnerizzarlo in modo che il tuo link frontend <-> jobqueue agisca come un diodo, i lavori siano in grado di entrare, ma nessun dato può uscire dal job-job nella direzione del front-end.

Alcuni semplici esempi;

La coda dei lavori esiste in un database a cui il front-end non ha accesso. I dati sono crittografati con una chiave generata in fase di esecuzione.
La coda dei lavori esiste solo nella RAM in un processo contrassegnato come non rintracciabile (in Linux è necessario AppArmor e Credo che ciò sia possibile rimuovendo la capacità CAP_SYS_PTRACE )
La coda dei lavori non esiste: effettua le chiamate di back-end in modo sincrono.

Detto questo, fare qualsiasi cosa diverso dall'istante che ha le password in chiaro è antipattern imho.

score 0 · Answer 2

Dovresti usare bcrypt per cancellare la password e scartare il testo in chiaro non appena colpisce il server API del tuo frontend.

Per la password dell'API di terze parti, utilizzare un generatore di numeri pseudo casuali crittograficamente sicuro per creare una password casuale lunga che si archivia nel record utente. A seconda della sensibilità di questa API, è possibile crittografare simmetricamente la password dell'API prima di memorizzarla nel database. Ti suggerisco di utilizzare Keyczar per gestire la crittografia se desideri crittografare le password API.

score 0 · Answer 3

Quello che non capisco è perché stai propagando la stessa password all'API di terze parti. Quello non è il Single Sign-On. Questa è la stupidità della password singola.

Invece cancella la password e memorizzala. Quindi generare una password casuale per l'utente, una per accesso di terze parti. E firmare usando quello. In questo modo, solo le singole password del sito vanno in coda.

Osservando la tua domanda attuale: impossibile. Presumo che la coda dei lavori e le API di back-end siano sullo stesso server. Se non ti fidi della sicurezza della coda, non puoi davvero fidarti della sicurezza del backend. E devi memorizzare la password in qualche modo, da qualche parte in testo normale, o in un formato da cui il tuo server può estrarre la password in chiaro.

score 0 · Answer 4

Questa risposta è diversa dalle precedenti domande che suggeriscono di dover hash la password, memorizzarla in un database, ecc. Quelle soluzioni sono inutilmente complesse nella mia mente.

Se stai terminando frontalmente l'API di terze parti ovunque , puoi / seedare e cancellare la password manualmente e semplicemente inviare il blob hash al back-end. Un approccio potrebbe assomigliare a questo:

Hash la password con BCrypt / Scrypt con un salt
Invia l'hash al back-end come la password dell'utente e aggiornala quando l'utente cambia la password.
Utilizza la stessa soluzione di hash per i server Web di autenticazione

In altre parole, non inviare all'API di terze parti una password di testo chiaro, inviare loro un hash creato. Assicurati di ricreare questo formato di hash su ogni server web o webservice di convalida.

Quindi quando esegui il proxy delle richieste di autenticazione all'API di terze parti, prendi il PW cancellato HTTPS POST, hash / seed it, quindi invialo all'API per un'ulteriore convalida.

Questo approccio impedisce all'osservatore casuale della coda di impersonare un utente e il sale impedirà la creazione di una tabella arcobaleno.

score 0 · Answer 5

Aspetta, a meno che tu non abbia il kernel configurato per consentire a root di visualizzare qualsiasi memoria nel sistema, perché non usare solo pipe ()? È memorizzato solo nella memoria volitile, è sicuro all'interno del sistema e supporta sia il trasferimento sincrono che asincrono dei dati.

Se la coda serve solo per connettere i lavoratori direttamente all'API, sembra che non ci sarebbe alcun modo pratico per sfruttare il sistema.