Schema di autenticazione con hashing doppio

Question

Schema di autenticazione con hashing doppio

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

0

Valuta il mio schema di autenticazione? (Questo sembra abbastanza semplice da essere un duplicato, ma è veramente difficile da cercare per questo tipo di domande. Scusa se è un duplicato.)

Quando viene impostata una password, viene immediatamente sottoposta a hash con una salt salt S1 e memorizzata come H1 .

Quando un utente prova ad autenticare, viene inviato S1 e un valore casuale S2 . Poi hanno cancellato la loro password con S1 per ottenere H1 , poi ha cancellato quello con S2 per ottenere H2 . H2 viene quindi inviato al server.

Il server calcola semplicemente H2 allo stesso modo, quindi confronta i valori. Il server genera quindi un valore casuale a 64 bit C e lo invia all'utente.

Tutte le altre comunicazioni con il server contengono C come token di autenticazione.

Il punto qui è garantire che la password non venga mai inviata in chiaro; si presume che il canale di comunicazione tra utente e server sia "ragionevolmente" sicuro, nel senso che questo schema è per un target estremamente basso; le password più comuni dell'utente sono probabilmente le informazioni più preziose presenti.

Il protocollo dovrebbe difendersi da:

Determinazione della password da parte di un attaccante passivo o attivo
Impersonificazione dell'utente da parte di terzi senza capacità di intercettazione

EDITS

Non sto usando TLS perché è per un videogioco; Sto cercando di ridurre al minimo la latenza il più possibile.
La password dell'utente viene impostata tramite una webapp protetta da TLS.
Non mi interessa (molto ☺) della NSA che dirotta l'account di un utente tanto quanto 1337Kid__1 dirottando l'account di OtherPlayer o un utente malintenzionato che intercetta le password.
- Sto prendendo le premesse su quanto sopra che è difficile fare intercettazioni sul traffico di un altro utente (per qualcuno che non è l'NSA) senza essere sullo stesso segmento di rete di loro; se questa è una nozione di cui dovrei essere disabitata, fammi sapere.

authentication hash custom-scheme

posta Nathan Ringo 31.12.2016 - 11:48

fonte

3 risposte

1

When a password is set, it's immediately hashed with a random salt S1 and stored as H1.

Hashed dal lato client? In caso contrario, la password deve essere inviata almeno una volta in chiaro.

The point here is to ensure that the password is never sent in cleartext; the communication channel between the user and server is assumed to be "reasonably" secure,

Perché non utilizzare il traffico crittografato, come TLS?

risposta data 31.12.2016 - 11:59

fonte

0

Un aspetto interessante di / always / doing hashing sul server è che non si avrà mai un attacco di temporizzazione. Confrontando in modo ingannevole la password memorizzata dal server con quella proveniente dalla rete, la password verrà rivelata nel tempo necessario perché l'autenticazione fallisca (dopo diversi errori).

L'hashing non è l'unico modo per evitare un attacco a tempo, ovviamente - potresti usare una funzione di confronto a tempo costante. Ma come linea guida è molto più sicuro raccomandare l'hashing anche sul server.

risposta data 31.12.2016 - 12:23

fonte

Leggi altre domande sui tag authentication hash custom-scheme

Quale potrebbe essere la fonte di vari "exploit" di AVG (Rogue Scanner, Fake Video Player, Social Engineering, ecc.)? Sicurezza dei pacchi attraverso yum

score 1 · Accepted Answer

Non importa quale sia la password perché in effetti H1 è considerata come la password, cioè un utente malintenzionato non ha bisogno di conoscere la password originale ma H1 è sufficiente. Ma questo passaggio assicura almeno che il server non veda la password originale (debole?) Ma una derivata (strong) e che le stesse password siano memorizzate sul server con H1 diverso (se S1 è diverso) che rende forzato il brute password originale più difficile.

Il modo per passare da H1 a H2 usando S2 è simile a Autenticazione del digest in quanto non la password (o l'equivalente della password, cioè H1) viene trasferito ma un hash della password (o equivalente) e un server fornito nonce casuale. Gli stessi vantaggi e svantaggi si applicano: protegge dallo sniffing (buono) ma la password o equivalente (H1) deve essere memorizzata in chiaro sul server. L'ultimo è negativo poiché qualcuno che attacca il server può accedere a H1 e utilizzarlo direttamente per autenticare ulteriormente come utente originale. Contrariamente a ciò, il solito modo di memorizzare le password hash ha bisogno che l'utente malintenzionato trovi la password originale che risulta nell'hash memorizzato.

L'ultimo passo con l'invio di una C casuale senza ulteriore protezione poiché il token di autenticazione dal server al client annulla efficacemente tutte le protezioni contro lo sniffing che hai avuto sin da quando è sufficiente che l'attacker annulli questo token casuale per poterlo dirottare la sessione.

Il mio suggerimento non è quello di reinventare la sicurezza ma utilizzare tecnologie ben consolidate e analizzate come TLS per trasferire password semplici e quindi memorizzare le password in modo sicuro utilizzando un funzione hash adatta .

I'm not using TLS because this is for a video game; I'm trying to minimize latency as much as possible.

Dubito che tu riesca ad autenticare l'utente ancora e ancora e che un piccolo ritardo nell'autenticazione della password iniziale sia un problema. Ma è necessario proteggere il token di autenticazione C dallo sniffing o dal riutilizzo che al momento non si fa. Un modo sarebbe non riutilizzare mai il token, ma invece avere un algoritmo che crea continuamente uno nuovo da un segreto condiviso o utilizzare il segreto condiviso in un HMAC sul payload.