Questione di sicurezza.

[Ricky1966]

Ciao a tutti. Vorrei capire alcune cose sulla sicurezza dei dati.
1) Cosa conviene 'hashare'? Solo la password o anche l'user? (anche dal punto di vista legale)
2) Da quel che ho capito una volta che ho messa l'hash ottenuto da password_hash nel DB, per verificare se l'utente sia presente devo caricare due array, uno per user (se hashato) e uno per password, con tutte le righe e poi verificare con password_verify, giusto?
Grassssssie

[Alhazred]

1) solo password

2) che roba è password_verify?
Di array non ne serve nemmeno uno, basta eseguire una query cercando username e password (dopo aver eseguito l'hash su quella inserita nel form di login) e vedere se viene restituito o no un record, se viene restituito vuol dire che il login è valido, se vengono restituiti 0 o più di un risultato il login è da considerare fallito.

3) "hashato" non si può sentire/leggere

[Ricky1966]

Mai sentito parlare di Chenglish o Spenglish? Beh "hashato" è Riclish! ��
Ad ogno buon conto password_hash sul manuale php.net è dato con password_verify.... Non riesco a incollare il link.

[Santino83_02]

tabella utente con

username
salt
password ( che sarebbe la password inserita dall'utente criptata con il salt)

login:

utente inserisce in form username e password
find by username
se risultato = 1 (username esiste), faccio l'encrypt della password col salt prelevato dal db
se la password salvata nel db è uguale all'hash che ho ottenuto dal criptaggio, allora la login è corretta
altrimenti restituisco "nome utente/password errati"
mai restituire informazioni che possano far capire che la username è corretta ma la password no

per quanto riguarda password_hash/password_verify non saprei, ho sempre usato crypt o chi per lui

[Ricky1966]

Grazie Santino83_02.
Crypt mi pare sia diventato obsoleto.
Credo che password_hash/password_verify serva per evitare di mettere il salt nella tabella.
Io ho provato, ma non sono ancora sicuro del codice, così :
login:
user e password(in chiaro)
verifica:
select su tabella con user + password_hash se 1 ok
Però ho notato che password_hash con PASSWORD_BCRYPT, rende sempre hash diversi, probabilmente (anzi di sicuro) cambia il salt, ma non saprei come recuperarlo per provare la tua procedura.

[Alhazred]

Come santino, anche io non ho mai usato password_hash/password_verify, sempre crypt o simili.
Stando alla documentazione ufficiale crypt non è deprecato, non sta scritto da nessuna parte.

Ricorda che se se salvi sul db la password criptata, ma poi dal form di login ti fai arrivare la password in chiaro buona parte della sicurezza va a farsi benedire, basterebbe sniffare il traffico di chi esegue il login e prendi la password. Inviare la password in chiaro ha senso se usi una connessione SSL (HTTPS), se la connessione avviene in chiaro su HTTP non c'è alcuna sicurezza.

[k.b]

In realta' se invii su connessione non criptata non fa molta differenza tra inviare la password liscia o il suo hash.

[Ricky1966]

Differeza ce n'è, se ci pensi.
Se come detto da Santino metti il salt nella tabella e questo è generato random uno per ogni utente della password in chiaro non te ne fai nulla, almeno penso così. A quel punto se vuoi i dati del db ti conviene entrare dalla porta principale, cioè provi ad attaccare user e password di mysql.
Ma ripeto, sono alle prime armi con queste tematiche, ci ragiono solo sopra. Un sistema inviolabile credo non esista in assoluto.... Dipende se a qualcuno interessa o meno entrare in un sito.

[Alhazred]

Differeza ce n'è, se ci pensi.
Se come detto da Santino metti il salt nella tabella e questo è generato random uno per ogni utente della password in chiaro non te ne fai nulla, almeno penso così.

Non proprio, prova a pensare: io utente regolare voglio fare l'accesso al mio account e per farlo devo scrivere in chiaro username e password, invio, il server prende la mia password in chiaro, ne esegue l'hash e confronta questo con i dati sul db, giusto?
Bene, ora c'è Tizio che sniffando il mio traffico ha beccato il mio username e la mia password in chiaro, che fa? Va sul sito, scrive sul modulo di login username e password in chiaro, invia, il server prende la password in chiaro, ne esegue l'hash, lo confronta coi dati del db, coincide e Tizio entra sul mio account.
Il fatto è che l'hash viene eseguito sul server, quindi a Tizio non gliene frega niente di come sia la password dopo l'hash, a lui serve come è quella in chiaro, perché il server quella si aspetta, l'hash viene eseguito dopo.

[k.b]

Quello che intendo e' che se il server si aspetta una pass in chiaro, la riceve, crea l'hash e lo confronta; se si aspetta un hash lo prende com'e' e lo confronta. In entrambi i casi il procedimento e' suscettibile all'intercettazione del dato.