Approccio personalizzato per proteggere le password in chiaro / nomi utente nella tabella del database?

4

Sto creando un'app per consentire agli utenti di registrarsi, connettere i loro numerosi account e-mail (come Gmail) al sito e consentire attività relative alle e-mail ... come inviare una e-mail (per favore non chiedi o dì "oh l'utente può semplicemente andare ai suoi client di posta o alla scheda di Gmail per farlo!", lo so lo so.) Si potrebbe dire che sto facendo un client di posta online. Ho provato ad esplorare come ThunderBird, Outlook o il client di posta di Apple gestiscono le credenziali di accesso, ma non riesco a capirlo.

L'approccio:

Quando inviano il login e la password dell'email per la prima volta alla mia app, facciamo quanto segue:

  1. salvi il nome utente e la password con un codice da 30 a 40 caratteri (diverso per ogni utente)
  2. usa la crittografia AES-256 (nome utente e password hanno chiavi diverse memorizzate altrove)
  3. quindi memorizza il nome utente crittografato e la password crittografata

Sono a conoscenza delle teorie, degli approcci riconosciuti dal settore per utilizzare gli hash unidirezionali e le numerose librerie open source, ma la mia app deve inviare le credenziali di posta elettronica dell'utente, ad esempio ogni volta che desidera inviare un'email.

Ecco un esempio di output del record delle impostazioni e-mail di un utente memorizzato nel database (usando Rails):

#<EmailSetting id: 10, user_id: 3, 
username: "{\"v\":1,\"adata\":\"\",\"ks\":256,\"ct\":\"E1M3+Eza9w5yNIoBVS...", 
password: "{\"v\":1,\"adata\":\"\",\"ks\":256,\"ct\":\"8N/Ylh7IGiHKDz1QM7...", 
outgoing_server: "smtp.gmail.com", 
incoming_server: nil, 
email_connection_type: nil, 
outgoing_port: 587, 
outgoing_authentication_type: "plain">

Mi piacerebbe assicurarmi che, se questo database fosse mai compromesso, potrei proteggere l'utente nel miglior modo possibile fornendo un servizio.

Domanda : è abbastanza strong da proteggere le credenziali di accesso e-mail? C'è qualcosa che potrei dimenticare nella protezione della tabella del database?

    
posta Matthew Chan 21.09.2015 - 02:34
fonte

1 risposta

1

Come fornitore di servizi, non dovresti mai, mai archiviare le password in modo che possano essere recuperate. Confrontarsi con un client di posta è un pessimo modo di pensarci, e non tiene conto della prospettiva di un attaccante. Compromettere un'installazione di Thunderbird ottiene solo un attaccante uno o un paio di serie di credenziali. Compromettere il tuo servizio potrebbe portare a un utente malintenzionato l'intero cliente basa le credenziali.

Come altri commentatori hanno sottolineato, ora hai il compito di proteggere la password impostata. Se questo è compromesso e l'accesso al DB è possibile, hai ora trapelato TUTTI i tuoi clienti nomi utente e password di Gmail. Se hai molti clienti, questa è una miniera d'oro. Non sottovalutare il potere di attaccanti dedicati.

Come sottolinea Stephen Touset, dovresti utilizzare l' API di Gmail , che non funziona t rivelare le password, ma usa token revocabili usando il framework OAuth2 . Se tu fossi stato compromesso, i token potrebbero essere tutti revocati. Ciò non è possibile se l'utente malintenzionato fosse in grado di ottenere tutte le combinazioni nome utente / password.

    
risposta data 20.07.2018 - 17:41
fonte