Quali sono gli svantaggi della combinazione della sicurezza di autenticazione lato client e lato server?

Question

Quali sono gli svantaggi della combinazione della sicurezza di autenticazione lato client e lato server?

Naviga le tue risposte

#1 da (1 voti)
#2 da (1 voti)
#3 da (0 voti)

1

Immagina la situazione:

L'applicazione potrebbe o potrebbe non essere eseguita tramite SSL / TLS
L'applicazione non dovrebbe conoscere la password del client perché il client potrebbe riutilizzare le password

Non avrebbe quindi combinato l'hashing della password lato server e lato server al meglio?

Come funzionerebbe la creazione della password:

L'utente inserisce la password in un campo.
Local javascript hash la password con il nome utente fornito con
Questo dato hash viene trasmesso via rete al server.
Il server aggiunge salt all'hash generato in modo casuale e rehashes entrambi in un nuovo hash. Questo nuovo hash e il sale casuale sul lato server sono memorizzati

Come funzionerebbe il login:

L'utente inserisce la password in un campo.
Il valore del campo "login" è preso come hash di calcoli javascript salt e local side.
Questo hash viene trasmesso sulla rete al server
Il server prende il sale memorizzato per quell'utente, combina l'hash con il sale e lo blocca.
Il server confronta il nuovo hash con l'hash memorizzato, se le corrispondenze, l'utente ha effettuato correttamente l'accesso. Se non corrispondono, all'utente viene negato l'accesso.

Quale sarebbe lo svantaggio di questo approccio rispetto all'approccio standard con la trasmissione di password in chiaro su Internet e quindi l'hashing e l'archiviazione sul server?

authentication client-side passwords

posta Enerccio 16.06.2015 - 15:38

fonte

3 risposte

Leggi altre domande sui tag authentication client-side passwords

Alla ricerca di un binario Meterpreter per Android Attacchi su computer criptato?

score 1 · Answer 1

Non c'è uno svantaggio nell'usare javascript per cancellare la password, ma c'è poco vantaggio. Ciò fornisce protezione contro un'acquisizione passiva, ma non offre più sicurezza su SSL.

L'attaccante ha un MiTM attivo o ha il controllo del server

Nel caso in cui l'attaccante possa Man in the Middle una connessione tra client e server, l'attacker può sostituire la libreria javascript con la sua, quindi sconfiggere qualsiasi protezione.

L'attaccante ottiene una cattura passiva

Nel caso in cui l'attaccante ottenga un'acquisizione passiva del traffico tra client e server. Se il sito Web non utilizza SSL, il traffico del sito Web è vulnerabile a un MiTM, quindi, mentre una cattura passiva non può essere decifrata, l'attaccante si posizionerebbe nel mezzo. Se il sito Web utilizza SSL, il testo in chiaro è già protetto. Nota, potresti creare un argomento per la protezione contro SSL, in cui il sito Web non implementa una perfetta segretezza di inoltro e il certificato SSL viene rubato.

Se sei interessato all'implementazione del browser di crypto, dovresti controllare RFC 2617 che illustra come implementare gli hash delle password in Autenticazione HTTP. Idealmente, il browser esporrà un'interfaccia a una libreria crittografica, ma ci sono alcuni aspetti da considerare. Ad esempio, nello scenario descritto sopra, la mancanza di un nonce renderebbe l'utente vulnerabile a un attacco di riproduzione.

score 1 · Answer 2

Nel tuo schema, stai sostituendo la password con il suo hash. L'hash diventa la password. Un utente malintenzionato che è in grado di annusare l'hash può eseguire l'autenticazione sul server senza conoscere la password. L'autore dell'attacco deve semplicemente creare una richiesta HTTP corretta e inviarla al tuo server, oppure modificare il javascript della pagina web di accesso nel suo browser per riutilizzare l'hash che ha appena annusato.

Alla fine, l'hashing della password nel browser aumenta la complessità del protocollo di autenticazione senza aumentare la sicurezza in alcun modo.

score 0 · Answer 3

What would be a disadvantage to this approach compared to standard approach with transmitting plaintext password over the internet and then hashing and storing it on the server?

Gli utenti che utilizzano più computer, alcuni con JavaScript attivato e alcuni con JavaScript disattivato, non sarebbero in grado di autenticarsi da alcuni dei loro computer e potrebbero non sapere il motivo. Devo ammettere che questo è probabilmente un gruppo molto piccolo di persone.
Se l'hash trasmesso viene intercettato, può essere utilizzato da un utente malintenzionato come password con solo alcune modifiche al codice JavaScript (come dichiarato da Anonymous Coward).
Se implementato in modo ingenuo, questo renderebbe efficace la distinzione tra maiuscole e minuscole del nome utente, ma potrebbe essere attenuato dal fatto che JavaScript converta il nome utente in minuscolo prima di utilizzarlo come sale.