Breve: non c'è ancora molto miglioramento della sicurezza per l'hashing. Ma l'hash è meglio del testo semplice (non perde direttamente la password).
Il secondo hash è apparentemente inteso a proteggere dal recupero di password nel caso in cui il database venga compromesso? In questo scenario, la protezione è valida tanto quanto è difficile risolvere l'input $ _ POST ['hash'] nell'operazione di hash. Questo input non è sufficientemente imprevedibile, almeno non quando vengono utilizzati i tasti deboli.
Ci sono alcuni suggerimenti che potresti provare a rendere le cose più forti.
Derivazione della chiave basata su password
L'hashing usuale non è consigliato per gestire le password. Questo perché almeno una parte degli utenti tende sempre ad avere password molto deboli. La password debole è sempre debole, ma ci sono modi migliori del solito hash per lavorare con le password. scrypt paper illustra l'efficienza dei diversi PBKDF (e di alcuni hash) contro le password brute-force di diversi livelli di entropia.
Se si desidera proteggere meglio la password + nome utente, non utilizzare l'uso sha256, ma la funzione di derivazione della chiave basata sulla password (nota anche come hash lento o hash della password - alcuni di questi usano effettivamente sha256 sotto il cofano; bcrypt, PBKDF2 per i dettagli).
La combinazione di Password + nome utente è (spesso) vulnerabile a ipotesi di forza bruta e tabelle arcobaleno. (Nel caso in cui ci si aspetti che la connessione SSL non protegga sufficientemente le credenziali.)
BTW, se si calcola l'hash della password sul lato client, potrebbe essere possibile rimuovere la necessità per il lato server di conoscere la password. In questo modo, la possibilità che il sito perdesse la password è notevolmente diminuita.
Se l'utente utilizza la stessa password o password simili su altri siti, il risultato non è utilizzabile per questi scopi.
Utilizzo delle stesse informazioni di autenticazione ogni volta
Ho capito che l'utente si autentica con
js > hash = sha256(Password+Username);
sempre. Destra? Questo ha la possibilità di rivedere le credenziali in seguito. (Nota: in molti casi l'SSL impedisce la registrazione e la riproduzione, ma il fatto che le CA siano state occasionalmente interrotte, non è sempre infallibile.)
Per rimuovere questa possibilità di riproduzione, puoi procedere come segue:
Se il server conosce la versione derivata della propria password (o risultato PBKDF o hash sopra [cioè viene memorizzata sul server quando vengono autenticati per la prima volta]), invece di inviare nuovamente il valore, potrebbe essere utilizzato challenge-response protocol .
Alcuni protocolli di risposta alle sfide più complessi, come SRP, si basano sulla "conoscenza zero" e forniscono validi concetti di sicurezza dimostrabili. Anche i protocolli challenge-response abbastanza semplici possono precludere la necessità di inviare direttamente la password o il valore derivato da password, ma ha solo il client che invia qualcosa che convincerà il server, ma non permetterà una riproduzione.
Ulteriori informazioni
C'è una domanda correlata su crypto.SE: L'hashing lento delle password sul lato client è più facile da attaccare che sul lato server? dove Paŭlo Ebermann ha suggerito il PBKDF basato su client e la migliore risposta di Thomas Pornin suggerisce anche di applica PAKE (SRP).