Idea per un algoritmo per autenticare gli utenti con zero-knowledge-proof [need thoughts / review]

Question

Idea per un algoritmo per autenticare gli utenti con zero-knowledge-proof [need thoughts / review]

#1 da (2 voti)

0

Ho un'idea per un algoritmo. Non so se ho commesso degli errori e ho bisogno di alcune riflessioni extra / peer review su di esso.

Ciò funzionerebbe come una prova di conoscenza (quasi) zero per l'invio di password che possono essere facilmente implementate.

registrazione:

Un utente invia la sua password al server (rischio una tantum).

Il server calcola un hash "sicuro" di detta password. Questo hash deve essere molto lungo, diciamo 4k caratteri.

login:

Quando un utente vuole accedere, prima esegue il calcolo dell'hash sul suo computer locale. Il server poi dice al client di unire lettere casuali a una nuova password unica. Il server invia solo posizioni di lettere e le invia a caso, in modo che ci siano permute sufficienti per non esaurire mai le combinazioni. Deve esserci una cronologia di lettere già utilizzate, in modo che venga utilizzata almeno una lettera mai esposta. Altrimenti un MITM potrebbe simulare un client.

Dopo aver unito tutte le lettere a una nuova password, detta password ottiene hash "in sicurezza" e invia al server per la verifica. il server esegue le stesse attività del client e controlla la sua versione rispetto ai dati dei client.

Anche se le password monouso sono hash "in sicurezza", l'utente malintenzionato ha tempo. Quindi, dopo che circa la metà della password originale hash viene rivelata, viene aumentato un contatore e la password viene cancellata una sola volta sul lato server e la vecchia password con hash viene eliminata. Questo contatore viene inviato al client ogni volta che si desidera effettuare il login, quindi aumenta i cicli di hashing per il contatore per abbinare i dati del server.

Questa è un'idea che mi è venuta in mente qualche secondo fa. Sembra essere un buon approccio. Ma mi piacerebbe vedere i tuoi pensieri su questo, dov'è il difetto? O è già qualcosa di simile usato?

authentication hash one-time-password

posta Kostronor 12.09.2014 - 21:15

fonte

1 risposta

Leggi altre domande sui tag authentication hash one-time-password

Come identificare gli hacker in base agli indirizzi IP e alle pagine a cui si accede Come funzionano i cookie di sessione? [chiuso]

score 2 · Answer 1

Ecco come lo capisco, per favore correggimi se ho interpretato male qualcosa.

Invio della password in Clear

Un rischio una tantum non vale mai la pena quando può essere evitato. L'uso di un algoritmo sicuro come bcrypt o PBKDF2 con sale non richiede che la password venga inviata in chiaro. Anche se la password è stata inviata in TLS, devo credere che non stai mantenendo la mia password?

Questa risposta fornisce un meccanismo completamente sicuro per l'autenticazione di accesso senza l'invio di una password in chiaro.

Overhead

C'è un sovraccarico che un utente malintenzionato può vedere sul filo.

When a user wants to log in, he first computes said hash on his local machine. The server then tells the client to join random letters to a new one time password. The server only sends out letter positions and sends them out at random, so that there are enough permutations to never run out of combinations. There has to be a history of already used letters, so that at least one never exposed letter gets used. Else a MITM could simulate a client.

Che cosa sta succedendo esattamente qui? Stai unendo lettere casuali all'hash della password? Stai inviando le lettere in chiaro, quindi perché esattamente qualcuno non può essere nel mezzo? Capisco che tu abbia scambiato un segreto solo una volta, ma quel segreto è memorizzato sia sul client che sul server. Due vettori di attacco separati. Se si concatenano le lettere alla fine dell'hash, allora tutto ciò di cui ho bisogno è l'hash e posso accedere con il server.

Se stai creando una password completamente nuova dalle lettere inviate dal server, a quel punto verifichi che la password originale fosse corretta? Altrimenti posso connettermi personalmente al server e il server mi fornisce felicemente una nuova password.

Even if send one-time passwords are "securely" hashed, the attacker has time.

Non sono sicuro di cosa ti stai riferendo.

This counter gets send to the client every time he want's to login, so he increases hashing rounds by the counter to match server data.

Ancora una volta stai fornendo qualche altra caratteristica sul filo, se un malintenzionato può vederlo, allora è riproducibile. Non credo che questo aggiunga nulla alla sicurezza, dal momento che qualsiasi algoritmo di hashing sicuro eseguirà abbastanza iterazioni da solo.

Requisito password inutilmente lungo

Non c'è alcun motivo per una password di 4000 caratteri. per un algoritmo sicuro questo metterà a dura prova le prestazioni sul tuo server. Mi assicuro che l'algoritmo di hashing iterazioni 20.000 volte sull'intera password. Una stringa di 16 caratteri è il minimo necessario per una password sicura. 4000 caratteri è eccessivo.

Fatto prima (tipo di)

Sembra che i caratteri casuali forniti dal server agiscano come un sale casuale. Tuttavia, dal momento che sono limitati alle lettere, non saranno altrettanto efficaci.

Controlla Hash delle password salate - Eseguendo correttamente