Sto studiando il meccanismo di autenticazione della risposta alla risposta salata (SCRAM).
Secondo la descrizione al link sembra che il Cliente non debba conoscere la password in testo normale; conoscere SaltedPassword è sufficiente per calcolare ClientProof.
Ciò significherebbe che se riesco ad ottenere le password salate da un database, potrei accedere senza dover forzare le password.
La mia comprensione di SCRAM è corretta in questo senso?
Disclaimer : non sono esperto in crittografia, quindi questa risposta deriva dalla mia comprensione limitata del protocollo.
Diamo un'occhiata al protocollo
SaltedPassword := Hi(Normalize(password), salt, i)
ClientKey := HMAC(SaltedPassword, "Client Key")
StoredKey := H(ClientKey)
AuthMessage := client-first-message-bare + "," +
server-first-message + "," +
client-final-message-without-proof
ClientSignature := HMAC(StoredKey, AuthMessage)
ClientProof := ClientKey XOR ClientSignature
ServerKey := HMAC(SaltedPassword, "Server Key")
ServerSignature := HMAC(ServerKey, AuthMessage)
Chi lo sa cosa all'inizio?
La risposta
Hai ragione che è necessario solo SaltedPassword per calcolare tutto, ma il problema è che nessuno memorizza SaltedPassword. Inoltre, se vuoi semplicemente impersonare il client, devi solo usare ClientKey per ingannare il server.
L'idea alla base di SCRAM - > Un fallimento?
The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS.
Tuttavia, non sembra spiegare come proteggerà la password dal server. Devi capire che anche se utilizzi un qualche tipo di meccanismo di risposta alla sfida di fantasia per "non" inviare la password sul filo, che quando inserisci la password nella pagina del browser, che è servita dal server, lo script nella pagina potrebbe decidere di registrare la tua password anche se ti dice che non è così.
Il vantaggio principale, che vedo, di un meccanismo di risposta alle sfide per gli utenti è che sarebbero in grado di riutilizzare la stessa password ovunque. Ma poiché l'utente non può davvero fidarsi della pagina in cui inserisce la sua password, non può riutilizzare la sua password.
Quindi, il prossimo grande vantaggio che potrei pensare è che in un meccanismo di risposta alla sfida la password di solito non è memorizzata sul server. Quindi, anche se un utente malintenzionato ha rubato una copia del server, non può provare a rimuovere la password. Di nuovo, si tratta di un grosso errore poiché il server ha una copia di StoredPassword, il numero di sale e il numero di iterazioni. Ha tutto ciò di cui ha bisogno per provare a rompere la tua password tramite dizionario o attacco bruteforce.
Ad un certo punto, mi chiedo, perché non dare solo la password al server? L'unica protezione che aggiunge è che se TLS è rotto (ma l'attaccante può solo ascoltare), l'attaccante deve ancora forzare la tua password per poter accedere.
Leggi altre domande sui tag authentication hash pbkdf2