Quali rischi devo considerare quando si cripta lato server invece che lato client?

Si dice di voler utilizzare la crittografia lato server per limitare l'esposizione al malware lato client. Non ha senso. Se ci sono malware o spyware sul client, in questo modo si viene eliminati in entrambi i casi. Crittografia sul server non aiuta, dal momento che i dati continuano a esistere in chiaro sul client, e così il malware / spyware lato client può acquisire i dati in chiaro.

Penso che tu debba rivisitare le tue esigenze e il tuo approccio. Se sei preoccupato per il malware lato client, posso vedere solo due opzioni: (1) garantire che i dati sensibili non raggiungano mai il client in chiaro o (2) implementare le difese per ridurre la probabilità di malware sul lato client. Crittografare sul lato server non aiuta molto.

L'invio dei dati dal client al server e quindi la crittografia sul server ha tutti i rischi per la sicurezza della crittografia lato client, oltre ad alcuni rischi aggiuntivi:

• Se il server viene compromesso o se uno qualsiasi degli account dei dipendenti viene compromesso, l'utente malintenzionato ottiene l'accesso ai dati. (Twitter è stato schiacciato da quest'ultimo: molte società sono state colpite dal primo.)

• Dato che tecnicamente hai la possibilità di decrittografare i dati, significa che puoi essere soggetto a citazioni, mandati o richieste da parte delle forze dell'ordine per decifrare i dati se vogliono / hanno bisogno di accesso. Se sei una piccola operazione, questo potrebbe non essere un grosso problema, ma a una grande operazione, questo potrebbe iniziare a creare dei costi di conformità per te.

• Se l'attaccante può attaccare un attacco man-in-the-middle (ad esempio, attaccando un utente che si connette su wifi aperto), e se i client dell'utente tramite avvertimenti cert SSL, l'utente malintenzionato può accedere ai dati sensibili.

Uno dei vantaggi della crittografia lato server è che consente di eseguire la gestione delle chiavi sul lato server, riducendo l'onere per gli utenti. Ad esempio, se gli utenti perdono o dimenticano le loro chiavi, puoi recuperarle per loro.

Un altro possibile vantaggio della crittografia lato server è che la finestra temporale in cui i dati esistono sul lato client in chiaro può essere ridotta, il che potrebbe ridurre l'esposizione alle violazioni dei dati se, ad esempio, il computer client viene rubato o perso. Tuttavia questo vantaggio può essere abbastanza modesto nella pratica e potrebbero esserci soluzioni migliori a questo problema (ad esempio, la crittografia a disco intero).

Inizierò con un semplice sistema di autenticazione.

Chiedete all'utente il suo login / password, che invierete al vostro server. Nel server, hai cancellato la password per confrontarla con il database (non parlerò qui dell'importanza di eseguire l'hashing di una password e di usare salt & pepper).

No, utilizzando una connessione non crittografata (SSL), qualcuno tra l'utente e il server può leggere i dati trasmessi (noto come attacco Man In The Middle) e conoscere la tua password utente.

Per questo, è possibile utilizzare una connessione SSL per proteggere l'utente dalla lettura durante l'invio di dati al server. È il modo migliore finora (ancora, non parlerò della limitazione di SSL qui).

Ma un'altra alternativa può essere fatta. Puoi inserire la password usando md5 / sha direttamente nel browser dell'utente e inviarti l'hash. Esistono alcune librerie Javascript per questo. Ma devi ricordare che non tutti i tuoi utenti avranno javascript abilitato (tranne che tu li costringi a usarlo). Inoltre, utilizzando questo metodo, non sarai in grado di aggiungere sale e pepe senza compromettere la sicurezza generale.

Inoltre, non dimenticare che questo non ti proteggerà contro keylogger, trojan e altri. Solo attacchi MitM.

Ora, per il caricamento del file. Il caricamento file predefinito dei browser, intendo <input type="file" /> , non invierà dati crittografati. Se si desidera farlo, è necessario implementare un sistema Java o Flash per caricare file che crittografano i dati prima di inviarli alla rete. Di nuovo, questo non proteggerà i tuoi utenti se hanno un virus sul loro computer.

Ricorda che l'ideologia tra client < - > server è la loro relazione tra loro. Non puoi proteggere il tuo utente dall'avere virus, puoi solo migliorare la sicurezza nel collegamento tra client < - > server e anche il tuo server.

Ora, se vuoi proteggere il tuo server per il caricamento di codice dannoso, la sicurezza del lato client sarà inutile. Non puoi mai fidarti di ciò che gli utenti ti manda. Anche se costruisci l'applicazione html più sofisticata, qualcuno sarà in grado di inviarti dati senza usare questa app.

Tutto quello che devi fare è migliorare la sicurezza sul tuo server: controlla se il file inviato è di tipo corretto controllando che sia il mimetype (con lo strumento giusto, non solo l'estensione!). Rifiuta sempre i file che possono essere eseguiti (.exe, .sh, ecc.) E altro ancora, accertati di cosa fare con questi file. (Puoi consentire il caricamento di file .php, ma devi metterli in una directory in cui non possono essere eseguiti da una posizione remota!)