Cripta i dati utente quando accedono con Facebook, Gmail, ecc

Naviga le tue risposte
5

Ho creato un sistema di accesso . L'utente può accedere tramite:

  • utilizzando una normale email / password (briptata).
  • utilizzando un servizio come Facebook, Gmail, ecc.

Fin qui tutto bene. Ora voglio memorizzare le informazioni sensibili (credenziali ftp) nel database in modo sicuro. Questo è molto facile per i primi utenti: quando l'utente accede con la propria email / password, la password viene sottoposta a hash con uno (predefinito) salt per verificare l'autenticazione e con un'altra salt per ottenere un hash strong X.

Quindi uso questo hash X come password per crittografare i dati sensibili che l'utente desidera archiviare. In questo modo, l'accesso completo al codice e al database NON compromette i dati dell'utente. *

C'è un modo per raggiungere un livello di sicurezza simile per gli utenti che accedono con un servizio che intrinsecamente non ha password per cominciare? Altamente raccomandato per essere una seccatura sul lato server e non aggiungere ulteriore complessità per l'utente. Queste sono tutte le opzioni che posso vedere con i loro problemi:

  1. Richiede che ogni utente, anche Facebook / Gmail / ecc., scriva e ricordi una password. Questo è di nuovo il principio che mi ha fatto integrare quei servizi in primo luogo.

  2. Utilizzare una password di crittografia univoca sul sito, lato server. Voglio proteggermi dall'accesso completo al codice e al database, quindi nessuno (compresi gli sviluppatori / gli amministratori / ecc.) Può sfruttare questi dati privati.

  3. Utilizza alcuni dati specifici dell'utente. Questo sarebbe l'id di Facebook dell'utente, per esempio. Potrebbe essere recuperato semplicemente facendo una ricerca per la loro email in fb, quindi non sicuro.

posta Francisco Presencia 09.01.2014 - 23:13
fonte

2 risposte

2

Stai chiedendo di generare dati segreti da un'unica fonte non segreta. Non può essere fatto in quelle condizioni esatte. Hai bisogno di una 'fonte di segretezza'. Puoi provare a scoiattare una chiave in un file di configurazione, magari crittografata con un'altra chiave, oppure puoi spostare alcuni aspetti su una macchina diversa e sicura, come usare un modulo di sicurezza hardware (HSM) per ospitare la crittografia e le chiavi. Ma non puoi creare un segreto ri-creabile da un insieme finito di dati e aspettarti che un aggressore non sia in grado di replicare la tua abilità.

    
risposta data 10.04.2014 - 20:52
fonte
0

La tua domanda sembra essere: "Voglio memorizzare in modo sicuro le password degli utenti, ma in modo reversibile". Questo in pratica significa che vuoi implementare DRM (sul tuo server), che è fondamentalmente impossibile, specialmente in uno scenario di libreria ad uso comune.

Avresti bisogno di un server / servizio separato e disconnesso per archiviare le credenziali dell'utente e quel server dovrebbe solo essere accessibile tramite un'API che gestisca richieste come:

  • "Salva $ ftp_user_and_password per $ user_id"
  • "Carica $ these_files su FTP per $ user_id"

Il server dovrebbe essere altrimenti disconnesso completamente dalla tua app (e non accessibile ad altre richieste in arrivo). Questo è simile a - per esempio - gestione della carta di credito.

Inoltre: hai detto che la tua vera necessità è proteggere le credenziali FTP fornite dall'utente.

Oltre ad altre misure di sicurezza, sarebbe molto più sicuro forzare gli utenti a creare un nuovo utente FTP per il tuo servizio, utilizzando le credenziali generate sul tuo server ("Crea un nuovo account utente FTP con username = my_service , password = long_random_string ").

Ciò significa che gli utenti non ti daranno semplicemente la loro password FTP "comune" (che probabilmente utilizzeranno anche per altri account) che potrebbe causare molti problemi se i tuoi dati dovessero essere accessibili da una terza parte malintenzionata - tu può semplicemente inviare per e-mail tutti gli utenti e chiedere loro di revocare l'accesso all'account utente FTP specifico del servizio. (Se hai perso la password "comune", molti utenti (sicuramente più di zero) probabilmente non cambiano la loro password (FTP) comune perché sarebbe troppo scomodo.)

Dovresti ancora pensare a proteggere la password specifica del servizio, ma lo scenario peggiore sarebbe molto più gestibile.

    
risposta data 13.01.2014 - 15:21
fonte

Leggi altre domande sui tag

Cosa fare se un fornitore non assegna un CVE per una vulnerabilità di riconoscimento? DOS alternativa sicura per ritardare la risposta a un utente malintenzionato con sleep ()?