Questione di sicurezza.

[brancomat]

E chi se ne frega, l'ha scritto lui, viene mostrato solo a lui e se c'e' qualche XSS se lo becca lui

Che brutale che sei!

[k.b]

Ma no il punto e' usare misure di sicurezza quando servono, e anche quando servono usare quelle giuste.

Nel caso che hai citato non c'e' nessun problema di sicurezza e comunque fare l'hash dello username per evitare XSS e' infilare in perno tondo in un foro quadrato

[.Kurt]

E chi se ne frega, l'ha scritto lui, viene mostrato solo a lui e se c'e' qualche XSS se lo becca lui

Il problema rimarrebbe: e se la vittima viene viene fatta loggare con "quell'account pericoloso" con l'inganno? Oppure l'applicazione permette di modificare il nome utente, ma il pannello non è protetto da csrf?

La sicurezza non è "base" o "avanzata": o è sicura o non lo è, non c'è una via di mezzo.

hqdefault.jpg

Ma se possibile eviterei di usare "soluzioni fatte in casa", che 1. non funzionano e 2. non sono sicure.

[k.b]

La soluzione pero' e' validare i dati in ingresso, ad esempio non accettare codice html/javascript come username. Usare un hash come "sicurezza contro XSS" e' come usare htmlentities per inserire i dati in un database.

Nell'esempio sopra poi il punto era solo mostrare un messaggio allo stesso utente che cerca di entrare impropriamente, motivo per cui preoccuparsi di un XSS non ha molto senso.

[theboss280489]

Ho letto questa interessante discussione e vorrei approfittare per chiarire un paio di dubbi.
Spero che qualche utente possa rispondermi visto che c'è gente molto preparata in materia.
Costruendo un semplice sistema in cui in una tabella mysql si salva il numero di telefono e l'email di una persona, quale è l'articolo di legge che indica come trattare questo tipo di dato? So che occorre avvisare gli utenti durante la registrazione con qualcosa del tipo:

I dati forniti saranno utilizzati esclusivamente per l'uso richiesto dall'utente, e secondo le leggi in vigore, e non saranno ceduti a terzi. Premendo "REGISTRATI", l'utente garantisce la veridicità dei dati forniti e presta il proprio consenso all'uso dei dati sopra raccolti come indicato. Dichiara inoltre di aver preso visione delle informazioni che seguono: i responsabili del sito dichiarano che, in conformità con l'art. 13 del DLgs 196/2003, i dati vengono raccolti al fine di fornire le informazioni richieste; l'utente gode dei diritti di cui all'art. 13 del DLgs 196/2003.

Inoltre: i dati come i numeri di telefono e l'email vanno crittografati? e se si in quale modo?
Inoltre ho un dubbio sull'uso del SALT: se questo viene salvato nella stessa riga del'utente con gli altri campi (come l'hash della password), per un attaccante che abbia in mano il database è pensabile un attacco brute force? (conoscendo il salt e generando automaticamente password). Il SALT diverso per ogni utente ha dunque solo lo scopo di rallentare il procedimento visto che per ogni utente occorrerebbe provare milioni di combinazioni diverse che non sono comuni ad altri utenti?
Grazie!

[.Kurt]

i dati come i numeri di telefono e l'email vanno crittografati?

Perché dovresti farlo?

Inoltre ho un dubbio sull'uso del SALT: se questo viene salvato nella stessa riga del'utente con gli altri campi (come l'hash della password), per un attaccante che abbia in mano il database è pensabile un attacco brute force? (conoscendo il salt e generando automaticamente password).

L'utilità del salt è quella di rendere virtualmente impossibile la creazione di grandi tabelle con hash già preparati. (rainbow table) Questo significa che, nel caso il tuo database sfortunatamente trapelasse a terzi, l'attaccante dovrà "craccare" tutte le password una per volta. Creando l'hash utilizzando un buon algoritmo, iterandolo più volte, e con l'utente che utilizza una buona password (più di 8 caratteri, con caratteri speciali), per l'attaccante richiederà comunque abbastanza tempo per trovarla. Tempo che puoi utilizzare per bloccare il login del tuo sito, e chiedere a tutti gli utenti di cambiare la propria password.

[theboss280489]

Perché dovresti farlo?

Mi chiedevo se ci fosse qualche articolo della legge che obbligasse il titolare dei dati o il responsabile a farlo. Se l'archivio cadesse nelle mani sbagliate ci sarebbero numeri di telefono ed email in chiaro mentre crittandole no.

Grazie per la spiegazione del SALT. Ora è chiarissimo

[.Kurt]

Mi chiedevo se ci fosse qualche articolo della legge che obbligasse il titolare dei dati o il responsabile a farlo.

Nope.

Se l'archivio cadesse nelle mani sbagliate ci sarebbero numeri di telefono ed email in chiaro mentre crittandole no.

Quello legale non è il mio campo, ma immagino che le tue responsabilità siano limitate all'utilizzo di cosa fai tu con quei dati. Un conto è se tu stesso vendi certe informazioni a qualcuno, senza che ti abbiano dato il consenso, un'altra è se qualcuno te li ruba per poi rivenderle.

[theboss280489]

Chiaro.
Tuttavia (anche a scopo di esercizio) mi pongo questa domanda. Dovendo utilizzare una chiave per crittare e decrittare il numero di telefono, quale è la scelta più conveniente su dove tenerla? Una seconda tabella mysql contenente idutente e chiave? Un file non testuale ma per esempio php aggiornato ad ogni nuova iscrizione di un utente? Naturalmente non esiste la sicurezza assoluta, ma dovendo proteggere qualcosa anche da mal intenzionati che hanno accesso al server, come vi comportereste in questo caso?
Un esempio che mi viene è di tutte quelle banche che utilizzano un token OTP per la ratifica delle transazioni: per generarlo ocorre un aggeggio elettronico con un id univoco che deve essere sincronizzato temporalmente con il server. Sul server tuttavia ci deve essere una corrispondenza tra id del dispositivo è id utente. In tal caso per proteggersi da attacchi di gente che ha accesso al server, tale corrispondenza come è conservata?

[.Kurt]

Tuttavia (anche a scopo di esercizio) mi pongo questa domanda.

Prima di tutto tieni a mente che la crittografia non è la soluzione a tutti i mali del mondo. L'argomento "sicurezza" è vasto, e non può essere trattato da qualunque programmatore. Per quanto mi piacerebbe, non sono qualificato per trattare tale argomento. Fatte tali premesse, possiamo però provare a discuterne insieme.

Dovendo utilizzare una chiave per crittare e decrittare il numero di telefono, quale è la scelta più conveniente su dove tenerla?

Bella domanda. Non è facile rispondere: purtroppo non è il tipo di domanda che ha un'unica soluzione ben consolidata che tutti usano. Dipende anche dai tuoi requisiti. È il tipo di dato a cui neanche tu (servizio/sito web/amministratore/database admin/etc.) dovresti poter accedere? Allora magari dev'essere l'utente stesso ad avere la responsabilità di cifrare il dato (e possedere la key). Una cosa dev'essere chiara: la chiave non deve stare nello stesso posto dei dati cifrati. Se vuoi cifrare le informazioni lato server (tra il tuo sito web e il database), in modo tale che le informazioni presenti nell'una non siano "visibili" nell'altra, ed assumendo che la responsabilità di cifrare il dato sia dell'applicazione (il sito web), allora, solitamente, l'encryption key (che viene utilizza per cifrare i dati) viene memorizzata in una cartella a cui solo l'amministratore (root) può accedere. Quell'encryption key si cifra ulteriormente utilizzando una key-encryption key (KEK) che non deve essere memorizzata insieme all'encryption key, ma, ad esempio, in un hardware dedicato (HSM), che ha il vantaggio di effettuare il lavoro di cifratura senza che la KEK sia visibile dall'applicazione stessa. Così facendo, qualora avessi necessità di revocare o sostituire l'encryption key (consigliabile di fare dopo tot. tempo, ad esempio ogni anno) ti basterà cifrare nuovamente l'encryption key con una nuova KEK, senza dover andare a cifrare nuovamente tutti i campi del database.

dovendo proteggere qualcosa anche da mal intenzionati che hanno accesso al server, come vi comportereste in questo caso?

Bhè, se qualcuno mi ruba le chiavi di casa, per prima cosa lo butto fuori e cambio la serratura.