SRP o hash hash su HTTPS?

Question

SRP o hash hash su HTTPS?

#1 da (2 voti)

1

Sto progettando un'API Web, che utilizzerà le credenziali di un altro sistema per l'autenticazione. L'API richiede HTTPS, tuttavia desidero comunque evitare di inviare una password in chiaro sul cavo utilizzando l'autenticazione di base HTTP.

Sono a conoscenza del protocollo Secure Remote Password, ma TLS-SRP (come l'autenticazione SRP su TLS sarà effettivamente) sembra eccessivo per il livello di sensibilità dei dati forniti dall'API (informazioni IT di livello aziendale per lo più delicate; non qualcosa che vogliamo gridare al mondo ma non finanziario o identificativo personale).

Penso che uno schema in cui il client SHA256 hash la loro password, quindi trasmette il nome utente e l'hash su HTTPS al server API, che può quindi crittografarlo prima di confrontarlo con un hash memorizzato, dovrebbe essere più che sufficiente per garantire trasmettere e memorizzare le credenziali dell'utente. A quali vettori potrebbe essere vulnerabile (a parte un keylogger sul dispositivo client)?

api authentication

posta KeithS 29.04.2016 - 22:45

fonte

1 risposta

Leggi altre domande sui tag api authentication

Come abilitare il WiFi mentre si usano due schede wireless una in modalità monitor e un'altra in modalità gestita? Virus / Trojan allegato al file crittografato di GnuPG

score 2 · Answer 1

Quindi chiamerò il tuo hash come payload.

La tua idea suona come:

Send me a payload so I can confirm the bcrypt value of it.

Che è esattamente uguale a una password:

Send me a payload so I can confirm the bcrypt value of it.

Questo non è altro che un teatro di sicurezza e stai cercando di convincere le persone a generare una password assurdamente lunga che poi devono memorizzare e riutilizzare ogni volta perché potrebbero non essere in grado di rigenerare esattamente nello stesso modo.

Hai anche già detto che se qualcuno possiede completamente l'utente in un attacco MITM è praticamente inutile perché ora devono generare un nuovo hash, per questo servizio e qualsiasi altro servizio che utilizza tale hash (proprio come una password ).

In realtà ciò che chiedi all'utente è di creare una password unica, ENORME, impossibile da ricordare per il tuo servizio che devono memorizzare comunque, ora in un formato solo digitale perché è impossibile scrivere o scrivere.

Questa è un'idea BAD. Questo ignora anche la limitazione di bcrypt usando solo i primi 72 caratteri di una stringa.