Mantenere la password segreta su un normale http

0

In primo luogo vorrei chiarire che questo è per i proprietari di siti poveri che non possono permettersi l'opzione SSL ma richiedono accessi al loro sito, potenzialmente da un chiosco pubblico, e hanno bisogno di un metodo sicuro per consentire tali. Tutto quello che sto cercando è un controllo pubblico del processo che ho elaborato, se ci sono degli attacchi che potrei aver perso che questo processo consente, e qualsiasi incidente stradale prevedibile che potrebbe introdurre.

Il processo per la registrazione è quindi:

  • L'utente arriva alla pagina e il modulo di accesso viene popolato con la chiave pubblica del server e un nonce.
  • L'utente inserisce la password in forma (e altri dettagli identificativi). Password e nonce sono combinati e inseriti in una funzione di derivazione della chiave
  • Utilizzando la chiave privata del server e la chiave pubblica del server, crittografare la password e inviare la chiave pubblica del client ad-hoc e la password crittografata (e i dettagli necessari per l'identificazione).
  • Usando la chiave pubblica del client e la chiave privata del server, decrittografare la password, generare il sale, spingere sia attraverso l'hash lento che il risultato del negozio.

Il processo di accesso sarà quindi:

  • arriva l'utente, riceve nonce e la chiave pubblica del server.
  • l'utente immette nome utente / password combo. Come prima, nonce e password generano la coppia di chiavi
  • crittografare la password con la chiave pubblica del server e generare la chiave privata, eliminare il privato, quindi inviare il client pubblico, la password crittografata e il nome utente
  • lato server, decrittografare con server pubblico e client pubblico, afferrare sale corrispondente a nome utente, password hash lento salata, verificare nei confronti del database e continuare l'accesso se tutto va bene.

La mia preoccupazione principale è che l'uso della password per generare la coppia di chiavi introduce una vulnerabilità in quanto se la chiave pubblica ad-hoc inviata tramite fili può essere utilizzata per decodificare la combinazione nonce / password che ha generato la chiave coppia, o peggio ancora essere usato per creare in qualche modo la chiave privata per decrittografare la password se la funzione di derivazione non è abbastanza strong. Sono queste preoccupazioni legittime e questa opzione dovrebbe essere sul tavolo?

    
posta Mike S 27.08.2012 - 16:21
fonte

2 risposte

7

In breve: basta andare su startssl.com e ottenere gratuitamente il certificato SSL.

Il protocollo non è abbastanza specifico. Se si intende implementare questo da soli, è probabile che si introducano difetti nelle fasi di firma e crittografia. In che modo gli utenti convalideranno la chiave pubblica del server qui? Ti aspetti che confrontino le cifre esadecimali?

Sembra anche presumere che client e server possano eseguire passi di computazione personalizzati, il che non è in genere il caso sui terminali Internet scelti come target. Puoi prendere in considerazione l'utilizzo del protocollo Secure Remote Passwort Protocol (SRP) in questo caso: trustedhttp.org

    
risposta data 27.08.2012 - 17:25
fonte
6

Il tuo metodo è banalmente vulnerabile a un attacco Man in the Middle (MitM). Ci sono due vantaggi dell'utilizzo di SSL:

  1. Il traffico sensibile sul filo viene inviato crittografato (che il metodo esegue in modo efficace) e

  2. puoi verificare in modo crittografico che stai andando sul sito giusto e non su una versione falsa del sito web. (Anche in questo caso, l'URL nella barra degli indirizzi o l'indirizzo IP non sono necessariamente attendibili se il routing è stato in qualche modo modificato).

È relativamente facile per un utente malintenzionato reindirizzare il traffico da qualche luogo a una pagina che controllano. Tuttavia, non possono farlo in modo apparentemente per i siti Web SSL in quanto non dispongono della chiave privata SSL. Quindi il modo corretto per farlo è un certificato SSL firmato da una CA gratuita.

La prossima cosa migliore è usare l'autenticazione digest di HTTP che implementa un processo di firma nonce in un modo simile al tuo schema (sebbene usi MD5 - una funzione di hash piuttosto scadente, anche se questo è probabilmente l'ultimo dei tuoi problemi con questo metodo). Questo è implementato nel browser web (quindi non è banale per un utente malintenzionato falsificare la stessa schermata di accesso mentre altera il back-end). Tuttavia, si noti per vari motivi UX oltre la sicurezza più debole di SSL (tutto il traffico tranne le password è in chiaro e un MitM complicato è difficile ma ancora possibile), non consiglio il digest HTTP.

    
risposta data 27.08.2012 - 17:43
fonte

Leggi altre domande sui tag