Best practices per salvare informazioni sensibili

Andrea1234567

Utente Attivo
234
29
Ciao, ho cercato su google ma opinioni in più non fanno mai male. Secondo voi quali sono le best practices per salvare informazioni sensibili su database.
A me serve in ambito web, uso PHP (a volte con laravel, dipende da cosa devo fare), lo dico anche se la domanda è più in generale e il linguaggio usato è indifferente per la risposta.
Grazie in anticipo.
 

cdtux

Utente Èlite
1,829
911
CPU
I7 3770
Scheda Madre
Asrock Z77 Extreme 4
HDD
Samsung 850 pro 250GB
RAM
Corsair Vengeance LP 16GB
GPU
Gigabyte GTX1060 6GB
Monitor
Dell U2412M
PSU
Seasonic Focus Plus 650
Case
Corsair Graphite 760T
OS
Debian / Ubuntu
Dai un'occhiata al sito owasp.
In generale per le password si salvano gli hash (bcrypt è ancora buono e soprattutto rodato).
Altri dati sensibili (tipo i numeri delle carte di credito) si possono invece criptare.
Il crypt/decript (per gli hash è uguale) costa risorse, quindi dev'essere un compromesso tra performance/usabilità e sicurezza.

Io comunque sono sempre dell'idea che quello che non c'è non può essere rubato, quindi nel db ci metto il minimo indispensabile.

Inviato dal mio Moto G (5) Plus utilizzando Tapatalk
 
  • Mi piace
Reazioni: Andrea1234567

Andrea1234567

Utente Attivo
234
29
Costa così tante risorse? Perché dovrei fare un gestionale per una piccola azienda commerciale e vedendo il loro vecchio gestionale hanno bisogno di inserire un macello di dati sensibili di clienti e altre aziende.
 

cdtux

Utente Èlite
1,829
911
CPU
I7 3770
Scheda Madre
Asrock Z77 Extreme 4
HDD
Samsung 850 pro 250GB
RAM
Corsair Vengeance LP 16GB
GPU
Gigabyte GTX1060 6GB
Monitor
Dell U2412M
PSU
Seasonic Focus Plus 650
Case
Corsair Graphite 760T
OS
Debian / Ubuntu
La sicurezza di un db dipende da quanto tempo si impiega a decifrarne i dati contenuti dopo che è stato"rubato", che poi è il caso peggiore..
Ovviamente il db è solo l'ultima cosa da mettere in sicurezza in un sito/webapp. Prima ci sono tante altre come xss, csrf, SQL injection, ecc..

Per il consumo di risorse si può fare l'esempio di bcrypt e il suo round:
Con un round di 12 si possono ricavare (molto approssimativamente dato che dipende dall'hardware) circa 2-3 hash/sec.
Ciò impatta sia sui tempi di inserimento di una nuova password sul db (ad esempio quando registri un nuovo utente), che sulla comparazione (ad esempio quando fai il login o si fa bruteforce). Quindi bisogna trovare un compromesso tra usabilità (login) e sicurezza (bruteforce).

In generale comunque non tutti i dati vanno hashati/criptati sia perché non sono poi così sensibili, sia perché poi il software sarebbe inutilizzabile (se metti un round di 30 su bcrypt ci vuole approssimativamente una giornata per calcolare l'hash...).

Bisogna poi considerare la nuova normativa gpdr, che però non ho ancora letto/approfondito.

Inviato dal mio Moto G (5) Plus utilizzando Tapatalk
 
  • Mi piace
Reazioni: Andrea1234567

Entra

oppure Accedi utilizzando
Discord Ufficiale Entra ora!