Sicurezza e crittografia dei dati nei database. Consigli e indicazioni utili.

[Redazione HostingTalk]

Quando si realizza un sistema dinamico occorre sempre valutare bene dove memorizzare i dati e soprattutto come farlo operativamente, in modo che il codice che scriviamo risulti sicuro e inattaccabile da male intenzionati. Queste considerazioni, sono particolarmente importanti per quanto riguarda i dati sensibili, come la raccolta delle credenziali di accesso degli utenti o, soprattutto, quando si fa riferimento a quelle informazioni la cui diffusione incontrollata sarebbe addirittura una violazione della privacy.



Leggi il contenuto dell'articolo Sicurezza e crittografia dei dati nei database. Consigli e indicazioni utili.

[Uno]

Mi permetto di puntualizzare alcune cose viste al volo.
MD5 non è considerato il sistema di hashing più affidabile si continua ad usarlo molto nello scripting in php semplicemente per motivi di compatibilità, se esiste già un archivio utenti non ha senso convertirlo, anche per far un lavoro radicale e veloce bisognerebbe richiedere la collaborazione degli utenti e non è il caso per diversi motivi.
Per pignoleria debbo anche dire che una password trattata con MD5 non si può dire criptata (una cripta si può aprire) ma anche se suona male in Italiano si potrebbe dire hashata

La cosa (la possibilità di collisione tra varie stringhe MD5 e la relativa facilità di brute force) comunque si ovvia, almeno in parte con il concetto di Salt che consiste nell'aggiungere un'altra stringa alla password prima di passarla all'hash.
Se la mia password è pippo ed è in chiaro sul db basta che uno provi tutte le password più semplici per beccare pippo.
Se sul db c'è pippo + hash_MD5 la cosa già è un pelo più complicata, ma con password pippo (cioè semplice) è relativamente facile provare delle combinazioni hashate per trovarla.
Per rendere più difficile la cosa si usa il salt che dicevo sopra. Il salt è una stringa che solo il server conosce decisa in varia maniera dal programmatore, l'ideale potrebbe essere stringa casuale univoca per ogni utente, memorizzata su db.
Quindi la password diventerà MD5(salt+password) ed un attacco a brute force diventerà molto difficile a meno che non si becchi la famosa collisione dell'algoritmo MD5.
32 caratteri in combinazione diversa sono tanti, ma i pc di oggi non sono quelli di 10 anni fa.
E' per questo che oggi si iniziano a considerare un pò più sicuri altri algoritmi, minimo tipo SHA (sta già passando di moda a dire il vero, ma dipende dal tipo di applicazione), e nuovi software che iniziano da zero tendono ad implementare questo al posto di MD5, se non devono integrare db da vecchi software.

Poi per completare il discorso bisognerebbe anche cercare di far si che nell'invio del login i dati siano esposti il meno possibile, cosa che parrebbe possibile solo con il protocollo ssl, cosa non vera.

Per capirci mille hash e salt ma se io becco (sniffo) il form che sta inviando il mio collega sulla scrivania accanto, nella stessa rete, chi se ne frega di sapere la password reale, posso loggarmi al posto suo inviando tutto l'hash-salt-etc...
Casi rari e difficili, ma che tanto più il sistema da proteggere è importante, tanto più vanno presi in considerazione.

Altra cosa apparentemente stupida ma molto importante è limitare nel numero e nel tempo i tentativi di logging. Se io non permetto più di 5 tentativi per mezz'ora, l'utente normale anche se sbaglia e si innervosisce riuscirà ad accedere al proprio account, ma un attaccante non potrà tentare un brute force diretto perchè in una giornata non potrà tentare più di 240 password.
Il problema in questo caso è che potrebbe usare più pc e mascheramenti vari dell'IP, ma comunque gli renderebbe la vita un pelo più difficile.

Stiamo parlando comunque sempre di applicazioni di media sicurezza, non per nulla le banche oggi iniziano ad usare i token ed accorgimenti esterni ai pc.
Usando altri linguaggi di programmazione e controlli sul client dell'utente si possono estrapolare dati tipo num di serie dell'hardware e cose simili.
Si può studiare un sistema euristico che verifica l'identità attraverso la comparazione del modo di battere i tasti e molte altre cose... ma alla fine la cosa più sicura è sempre quella che rimane fuori dal pc e dalla trasmissione dei dati.
Per ipotesi una cartolina inviata con posta tradizionale in busta mascherata, cartolina che contiene una serie di password da usare una sola volta... è un sistema più sicuro di molte altre diavolerie, ma bisogna trovare la giusta proporzione tra:
importanza del sistema da proteggere
facilità di uso per l'utente
comodità di uso per l'utente
sicurezza complessiva.

Mi fermo che se no vado avanti 10 giorni

[ceccus]

Salve,
Tutte cose giuste ...
In particolare, il discorso della One Time Password ... ovvero la password che può essere utilizzata una sola volta e per un periodo limitato (solitamente qualche secondo/minuto)
Da prendere in considerazione anche il fatto del Canale di trasmissione , ovvero del COME voglio arrivare ad utilizzare un' applicazione ... un conto è utilizzare il Cellulare, un conto è utilizzare un PC "casalingo" , un conto è utilizzare un Internet Point ... sono esempi ma che hanno tutti dei risvolti di Sicurezza ben diversi ...

Ciao !!

[Ste]

Grazie dei contributi ragazzi, tutte cose degne di nota. Di fatto si parla di aspetti importanti che non vengono valutati attentamente da una buona percentuale di utenti, e ne vediamo spesso le conseguenze nei carichi di server dedicati o nelle problematiche di sicurezza.

Claudio, giusto sottolineare l'importanza di un login con tot tentativi nel tempo, l'articolo è di fatto una introduzione, ben venga che ci siano altri spunti!

[Uno]

l'articolo è di fatto una introduzione

Questo era sottointeso, l'argomento è talmente vasto che ci si possono scrivere libri, la mia infatti non era una critica all'articolo ma solo una piccola, per quanto limitata, espansione dell'argomento.