Creazione di un'app Web con voci di database MySQL crittografate?

Question

Creazione di un'app Web con voci di database MySQL crittografate?

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

9

Ho una certa esperienza nella creazione di siti Web basati su PHP con accesso a MySQL, memorizzazione di dettagli utente crittografati, ma tutti gli altri campi sono in chiaro. Il mio progetto più recente richiederà la memorizzazione di dati sensibili nel database.

Voglio configurare un sistema in cui un utente può accedere alle proprie voci e vedere i risultati in testo semplice, ma anche se fosse in grado di accedere a qualcun altro sarebbero stringhe crittografate e incomprensibili.

Ho un'idea di come ottenerlo, ma forse non è ottimale o esistono strumenti per farlo già in un modo più efficiente.

1.) Memorizza nome utente come testo normale e hash password con sha1 () o algoritmo di hashing migliore più sale casuale ecc.

2.) Prendere la password dell'utente (non quella con l'hash, ma quella digitata) e utilizzarla definire una chiave specifica per tale nome utente e password, che verrà quindi memorizzata come variabile di sessione. Dato che la chiave non viene mai memorizzata da nessuna parte tranne che nella testa dell'utente (nella forma in cui conosce la sua password in testo semplice, che verrà convertita in una chiave in qualche modo mescolandola con il suo nome utente e un po 'di sale, hashing, ecc. per accedere) questa dovrebbe essere una buona soluzione, giusto?

3.) Cifra o decifra tutti i dati di quell'utente con quella chiave.

A mio parere, anche se qualcuno ha ottenuto l'accesso al database e ha visto un elenco di nomi utente e password crittografati, non è stato possibile trovare la chiave specifica poiché non è memorizzata da nessuna parte. Pertanto, anche se l'accesso è stato acquisito, non è stato possibile decifrare il contenuto dei campi sensibili del database. Ovviamente sto costruendo dei modi per impedirgli di accedere comunque al database, ma come uno sforzo generale mi sembra una buona serie di passaggi.

Gli esperti possono commentare questo e offrire qualche consiglio? Grazie mille.

Ho postato questo nel forum programmers.SE e mi hanno informato che questa era una posizione migliore per la domanda. Più precisamente, perché non dovrei farlo da solo. Se è così allora quali alternative ci sono?

php encryption databases

posta Joey O 16.07.2013 - 15:40

fonte

2 risposte

Leggi altre domande sui tag php encryption databases

Apple Face ID è una buona funzione di sicurezza? Esistono altri modi per crittografare file diversi da TrueCrypt e BitLocker [chiuso]

score 5 · Answer 1

Ciò di cui stai parlando è una chiave derivata. La tecnica che descrivi viene spesso utilizzata per i sistemi ad alta sicurezza, sebbene raccomando ulteriormente di utilizzare la crittografia derivata una chiave dati. Ciò consente alla chiave dati di essere archiviata con più di una chiave derivata e limita l'uso della chiave derivata. Ciò consente la condivisione dei dati, i portachiavi e il recupero dell'account. Inoltre, tieni presente che la chiave derivata stessa è valida solo quanto la password, quindi le funzioni di derivazione delle chiavi lente e salate dovrebbero comunque essere utilizzate per garantire che le chiavi derivate dalla password non possano essere formate per tutte le password degli utenti contemporaneamente. p>

Le chiavi derivate tendono ad essere più deboli delle chiavi realmente casuali, quindi si desidera crittografare l'importo minimo possibile con esse. Se si cripta solo la chiave dati dell'utente, è possibile decodificare la chiave dati dell'utente e quindi memorizzarla nella sessione. Quella chiave veramente casuale può quindi essere utilizzata per crittografare e decifrare i dati dell'utente.

Un ulteriore miglioramento è associare le chiavi ai record e quindi crittografare quella chiave di registrazione con la chiave utente per consentire all'utente di accedere. Se si utilizza la crittografia asimmetrica qui, sarebbe possibile per un utente concedere l'accesso a livello record a un altro utente crittografando la chiave del record con la chiave pubblica dell'utente con cui si desidera condividere e aggiungendolo al portachiavi dell'altro utente.

Allo stesso modo, per il recupero dell'account, le chiavi dell'utente potrebbero essere crittografate con una chiave pubblica di ripristino. La chiave privata può essere tenuta offline o associata a un utente amministratore (con protezione della chiave derivata simile) e utilizzata dal servizio clienti solo quando è necessario per ripristinare un account.

score 0 · Answer 2

use it do define a key (…), which will then be stored as a session variable. Since the key is never stored anywhere except in the user's head (…)

Anche se temporaneamente, la chiave è memorizzata nel server (ad esempio un gestore di sessione di base utilizza file in / tmp, un dump di memoria di memcached potrebbe rivelare le chiavi anche dopo la scadenza). Dovresti verificare in che modo il server mantiene le sessioni per verificare che non (facilmente) dia via quelle chiavi.

Potresti voler ricodificare quel valore memorizzato nella sessione con un valore casuale del cookie. O non memorizzarlo affatto.

Bonus se si esegue tutta la crittografia sul lato client (usando javascript). Quindi il server mai vede i tuoi dati e quindi non può un utente malintenzionato che lo comprometta.

(Si noti che l'autore dell'attacco potrebbe ancora sostituire il codice legit con quello malevolo e attendere che l'utente acceda nuovamente al sito per rubare i suoi dati. Questo era già possibile prima)