Utilizzo di BCrypt per trasmettere dati sensibili nella configurazione client / server

Senza un'adeguata sicurezza del livello di trasporto (cioè una connessione TLS) non è possibile proteggere un'applicazione contro gli attaccanti man-in-the-middle. Usare bcrypt o qualcos'altro per trasferire la password non aiuta la situazione. Dovresti avere una connessione sicura tra il client e il server, con crittografia e autenticazione.

Una volta ottenuto ciò, non c'è alcun problema nell'invio della password così come avviene con la connessione protetta.

Un'altra superficie di attacco è un compromesso del database, per cui la soluzione corretta è quella di memorizzare una password briptata invece di una password in chiaro nel database.

Una possibilità è di cancellare la password sia sul client che sul server.

1. Il client invia bcrypt (password) al server.
2. I computer server bcrypt (bcrypt (password)) e controllano la password rispetto al database.

Le password nel database sono quindi bicrate due volte. In questo modo, le password in chiaro sono sicure contro l'intercettazione e il token di autenticazione è sicuro contro il compromesso del database.

Potresti provare a inviare il sale al client, che quindi userebbe quello per codificare la password. Oppure chiedi al client BCrypt la password.

Quindi, il server eseguirà un BCrypt della password e verificherà che corrisponda.

APPARENTEMENTE questo è più sicuro, tranne che non lo è. Perché se l'attacco che stai difendendo - cattura del segreto in transito - è riuscito, l'attaccante sarebbe ora in possesso di BCrypt (pwd) - e, con questo, potrebbe ottenere l'accesso e impersonare un cliente legittimo. Il sistema non richiede più la conoscenza della password, solo del suo hash bcrypt . Ora sei esposto a un replay attack .

Per poter cambiare il sale e difendersi dagli attacchi di replay dopo un'acquisizione riuscita, dovrai memorizzare la password in chiaro.

Quello che puoi fare allora è:  - Memorizza la password briptata con salt S1 sul server, ogni password ha il suo sale  - inviare al cliente una sfida contenente S1 e SX (generata casualmente ogni volta); ciò richiede che l'utente sia già stato inviato al server. Un utente sconosciuto riceve un di sale costruito da hashing un segreto con lo username .  - il client ha la password in chiaro e ti manda Bcrypt (SX, Bcrypt (S1, password))

• hai Bcrypt (S1, password) e non sei quindi in grado di rivelare la password
• il filo vede Bcrypt (SX, hash) e non è quindi in grado di rivelare l'hash
• ottieni una crittografia della CPU in ogni fase.