Invece di passare un token di autenticazione o una chiave API in un'intestazione http a un server nel testo normale, cosa succede se ho calcolato il suo hash e passato l'hash? In questo modo, anche se un avversario intercetta l'hash, sarà inutile per loro. E un server può facilmente calcolare anche un hash della password reale sul suo lato e quindi verificare se corrispondono. Un sale può anche essere aggiunto.
Funzionerà? Questo approccio è ampiamente utilizzato?
No, questo approccio non è ampiamente utilizzato ed ecco perché:
Se il client blocca la password e la invia al server, allora quell'hash non diventa "la password"? Come attaccante, non posso semplicemente intercettare l'hash e usarlo in un attacco di replay?
Hai detto "Un sale può essere aggiunto anche". Questo in realtà è fatto in alcuni protocolli, quando aggiungi un valore casuale per rendere l'hash diverso ogni volta, viene chiamato un nonce .
Soprattutto, il server conosce la password in chiaro !? Cattiva idea! Se il tuo server conosce la password in chiaro, significa che sta archiviando le pianure in un database, il che significa che una violazione del database fa perdere la password in chiaro a tutti i tuoi utenti. Solo la memorizzazione degli hash delle password nel db ti protegge da questo. Sei davvero disposto a rischiare una totale e completa violazione per rendere il tuo protocollo un po 'più semplice?
Conclusione: sono felice che tu stia pensando al design del protocollo dal punto di vista della sicurezza. Ti inviterei a dare un'occhiata al TLS handshake perché è un protocollo molto ben congegnato che utilizza molti dei concetti a cui stai pensando.
Leggi altre domande sui tag http passwords password-management hash