Un protocollo di accesso semplice, medio sicuro?

Question

Ho chiesto a qui di un protocollo che mi è stato chiesto di implementare, e quanto fosse sicuro. Dal momento che sembrava chiaro fin dall'inizio che era merda. Essendo così chiedo:

Ragazzi, potete indicarmi un protocollo di accesso molto semplice (sono nullo nei sistemi di crittografia) ?? Sto sviluppando l'applicazione lato server e client e ho il mio sistema di messaggistica, quindi ho abbastanza libertà.

Solo 2 caratteristiche speciali per i tuoi suggerimenti.

1. Semplice: la rete su cui passerà questa applicazione non è particolarmente insicura e voglio solo evitare l'invio della password in testo normale

2. Se possibile, non uno scambio di messaggi troppo lungo. Più è corto, meglio è.

Answer 1

Scopri Autenticazione risposta alla sfida

• Il server include una stringa di verifica casuale nel modulo di accesso
• Quando effettui il login, javascript esegue l'hashing della password, quindi l'hash con la sfida
• Il server esegue quindi lo stesso controllo (il tuo DB dovrebbe archiviare le password con hash, ma questo metodo ti impedisce di utilizzare efficacemente un salt per quell'hash poiché dovresti trasmettere questo)

Answer 2

Protocollo a tre passaggi sarebbe utile. Fondamentalmente, si riduce a:

• La persona A crittografa la sua password e la invia alla persona B.
• La persona B crittografa la password crittografata e la restituisce alla persona A.
• La persona A lo decodifica e lo rispedisce.
• La persona B la decodifica e ottiene la password in chiaro.

In questo modo, la password non viene mai inviata in testo normale, né le chiavi di crittografia. È anche un protocollo relativamente veloce, poiché si basa (presumibilmente) sulla crittografia simmetrica, che è molto veloce.

Answer 3

La memorizzazione dell'hash della password nel database non è sicura in modo ottimale nel caso in cui il contenuto del database finisca in mani non autorizzate. Non è possibile invertire direttamente l'hash, ma ci sono dictinonaries online (come qui ) per invertire le parole hash (pass).

Nel DB dovresti memorizzare qualcosa come:

md5(login_name +  domain_or_appname_salt + password);

Il sale nel mezzo impedisce molte forme di attacchi ai dizionari.

Sul lato client (nel browser) si avrebbe un modulo di login con nome utente e password. Un piccolo frammento di javascript avrebbe hash userame + app_salt_ e password, quindi solo il login_name e l'hash generato vengono inviati al server.

Ora, la password in chiaro non verrà mai inviata al server in chiaro. Quindi non dovresti fare affidamento su HTTPS qui.

La stessa tecnica può essere utilizzata nel modulo di aggiornamento della password. Quindi il server non conosce mai la password in chiaro.

Spero che tu abbia tratto ispirazione da questa e dalle altre risposte.

Happy Hacking!

Huibert

Answer 4

Se il tuo protocollo funziona su TCP, puoi semplicemente scrivere l'autenticazione in chiaro e quindi concludere la comunicazione con SSL. Ad esempio, se si utilizza la porta 1234 per il protocollo, è possibile quindi chiudere quella porta sul server e consentire ai client di tunnelarla con SSH. Questo può essere fatto a livello di codice ed è una soluzione molto comune.

Se il tuo protocollo funziona su HTTP, puoi farlo in modo standard usando HTTPS. Ad esempio, l'autenticazione di base su HTTPS è abbastanza sicura per le esigenze specificate.

D'altra parte, se non si desidera mai inviare la password sul filo, è necessario eseguire un'autenticazione di risposta alla sfida.

1. Il server invia una stringa casuale
2. Il client invia l'hash di stringa casuale + password
3. Il server verifica l'hash.

Questo ha il rovescio della medaglia che la password sarà disponibile (crittografata in testo normale) sul server. Se non si desidera memorizzare le password sul server, è necessario tornare al mio primo esempio.

Answer 5

SASL è un meccanismo di autenticazione sicuro. Il supporto per SASL è fornito nelle librerie standard Java per le versioni 1.5+.