Autenticazione con un server non attendibile

Qualsiasi soluzione implicherà una crittografia a chiave pubblica. Ogni utente può avere una coppia di chiavi. La chiave segreta potrebbe essere crittografata con una password come suggerito da @Mark.

Se per qualche motivo non è pratico memorizzare una chiave privata e l'utente deve poter accedere utilizzando solo il software e una password, la chiave privata può essere generata al volo.

Puoi avere un database che contiene quanto segue per ogni utente:

1. Dati utente

2. A salt per la password dell'utente

3. A salt for the public key

4. Un hash della chiave pubblica (Fatto con il sale sopra)

Per autenticare:

1. La password salt viene inviata al client.

2. Il client combina la password salt e la password e usa questa combinazione per seminare un PRNG.

3. L'output del PRNG viene utilizzato come input per qualsiasi algoritmo di generazione di chiavi private scelto dall'utente (RSA o qualsiasi altro algoritmo di firma).

4. La chiave pubblica viene quindi inviata dal client al server.

5. Il client deve anche dimostrare di detenere la chiave privata corrispondente (ciò potrebbe essere fatto firmando un'identificazione di sessione o tramite un protocollo sigma).

6. Una volta che il server sa che il client ha la chiave segreta, convalida la chiave pubblica eseguendo l'hashing della chiave pubblica con la stored salt e confronta il risultato con l'hash memorizzato nel database.

L'ordine degli ultimi due passaggi è stato scelto per impedire a un utente malintenzionato che in qualche modo ha imparato la chiave pubblica (ma non la chiave privata) dall'apprendimento se quella chiave pubblica poteva essere utilizzata per accedere a un determinato account.

Non è necessario alcun hash iterato, poiché l'algoritmo per generare la coppia di chiavi tende ad essere sufficientemente intensivo dal punto di vista computazionale. A differenza dell'hash iterato, il calcolo della coppia di chiavi ha lo scopo secondario di mantenere le informazioni segrete ben nascoste dal server.

Se l'esistenza di un account utente deve essere nascosta, il server può simulare il protocollo quando viene fornito un nome utente non esistente come segue:

• Nel primo passaggio dell'autenticazione genera una password pseudocasuale salt e invialo al client.

• Segui il protocollo seguendo tutti i passaggi seguenti, a seconda del database.

• Nell'ultimo passaggio dell'autenticazione calcola un hash e scarta il risultato. Rifiuta l'utente indipendentemente dal valore dell'hash.

La sfida rimanente nel nascondere l'esistenza di un account utente è come produrre una password psuedorandom che cambia ad una frequenza, che è indistinguibile dalla frequenza delle modifiche della password per un utente reale.

Sembra che tu voglia una crittografia a chiave pubblica simile a quella supportata da SSH. L'idea di base è che l'utente fornisca la propria chiave pubblica al server durante il processo di creazione dell'account, quindi dimostra la proprietà della chiave privata corrispondente durante la procedura di accesso.

La chiave pubblica, come suggerisce il nome, non è nemmeno lontanamente segreta, quindi soddisfa il requisito 1, non può essere utilizzata per costruire la chiave privata, quindi soddisfa 2, è calcolata al momento della creazione dell'account, quindi soddisfa 3, e sì, puoi usare una password per proteggere la chiave privata.

Utilizza i certificati. In questo modo il client non condivide mai la sua chiave privata con nessuno incluso il server. Il server ha solo la chiave pubblica dei client che non è segreta.

In alternativa, esegui una soluzione di identità federata o sfruttane una come Google o Facebook. Ci sono opzioni open source per questo (come link ) Inoltre non puoi essere completamente sicuro che il client non sia stato manomesso, ma nel tuo scenario non sembra comunque un problema.

Tutte e tre le altre risposte consentiranno a un utente di accedere senza che il proprietario del server possa vedere la password. Tuttavia, non forniscono realmente alcuna autenticazione . L'autenticazione è la conferma che è tu che accedi al tuo account.

In questo scenario, stiamo assumendo che l'amministratore del server abbia pieno accesso al DB (e questo probabilmente sarà il caso nella realtà). Ciò significa che l'amministratore può cambiare la password dell'utente in qualsiasi cosa gli piaccia, quindi accedere come tale utente (e inviare messaggi a tutti i suoi amici o leggere le sue chat private o qualsiasi altra cosa).

Penso che l'unico modo per aggirare questo problema sia controllarlo da qualche parte centralizzato. O implementa il tuo o utilizza soluzioni già implementate. Ciò potrebbe anche darti l'ulteriore vantaggio di un singolo account che funziona su più server, se vuoi implementarlo in questo modo.