Come inviare la password in modo sicuro tramite HTTP?

Se in una schermata di accesso l'utente invia un modulo con il suo nome utente e password, la password viene inviata in testo normale (anche con POST, correggimi se sbaglio).

Quindi la domanda è qual è il modo giusto per proteggere l'utente e la sua password da terze parti che potrebbero intercettare i dati di comunicazione?

Sono consapevole che HTTPS è una soluzione al problema, ma esiste un modo per garantire almeno un certo livello di sicurezza utilizzando il protocollo HTTP standard (richiesta POST)? (forse usando javascript in qualche modo)

EDIT Potrei aver tralasciato alcune cose importanti.

Ciò di cui mi occupavo era una pagina, ovvero una pagina di accesso generata da PHP, che ovviamente viene inviata all'utente nella richiesta HTTP GET come file HTML. Non è stata stabilita alcuna connessione (@Jeremy Powel) tra il server e il client, quindi non posso creare tale protocollo di handshaking. E voglio che il processo completo sia trasparente per l'utente: vuole inviare una password, non occuparsi della crittografia.

Grazie.

Usare HTTP con SSL ti renderà la vita molto più facile e potrai stare tranquillo persone molto intelligenti (più intelligenti di me almeno!) Hanno esaminato questo metodo di comunicazione riservata per anni.

L'autenticazione sicura è un argomento ampio. In poche parole, come menzionato da @ jeremy-powell, preferisci sempre l'invio di credenziali su HTTPS anziché su HTTP. Porterà via molti grattacapi legati alla sicurezza.

I certificati TSL / SSL sono piuttosto economici in questi giorni. In effetti, se non vuoi assolutamente spendere soldi, c'è un letsencrypt.org gratuito - Autorità di certificazione automatizzata.

Puoi fare un ulteriore passo avanti e utilizzare caddyserver.com che chiama letsencrypt in background.

Ora, una volta eliminato HTTPS ...

Non inviare login e password tramite payload POST o parametri GET. Utilizzare invece un'intestazione di autorizzazione (schema di autenticazione di accesso di base), che è costruita come segue:

• Il nome utente e la password vengono combinati in una stringa separata da due punti, ad esempio: nome utente: password
• La stringa risultante viene codificata utilizzando la variante RFC2045-MIME di Base64, eccetto non limitato a 76 caratteri / riga.
• Il metodo di autorizzazione e uno spazio, ad esempio "Basic", vengono quindi inseriti prima della stringa codificata.

fonte: Wikipedia: intestazione di autorizzazione

Potrebbe sembrare un po 'complicato, ma non lo è. Ci sono molte buone librerie là fuori che ti forniranno questa funzionalità fuori dagli schemi.

Esistono alcuni buoni motivi per utilizzare un'intestazione di autorizzazione

1. È uno standard
2. È semplice (dopo aver imparato a usarli)
3. Ti consentirà di accedere a livello di URL, in questo modo: https://user:password@your.domain.com/login(Chrome, ad esempio, lo convertirà automaticamente in Authorizationintestazione)

IMPORTANTE:
come sottolineato da @zaph nel suo commento qui sotto, l'invio di informazioni sensibili come query GET non è una buona idea in quanto molto probabilmente finirà nei log del server.

È possibile utilizzare uno schema di risposta alla sfida. Supponiamo che il client e il server conoscano entrambi un segreto S. Quindi il server può essere sicuro che il client conosce la password (senza rivelarla):

1. Il server invia un numero casuale, R, al client.
2. Il client invia H (R, S) al server (dove H è una funzione hash crittografica, come SHA-256)
3. Il server calcola H (R, S) e lo confronta con la risposta del client. Se corrispondono, il server sa che il client conosce la password.

Modificare:

C'è un problema qui con la freschezza di R e il fatto che HTTP è senza stato. Questo può essere gestito facendo in modo che il server crei un segreto, chiamalo Q, che solo il server conosce . Quindi il protocollo funziona in questo modo:

Da notare, poiché H (R, Q) non può essere contraffatto dal client, H (R, Q) funge da cookie (e potrebbe quindi essere implementato effettivamente come cookie).

Un'altra modifica:

La precedente modifica al protocollo non è corretta poiché chiunque abbia osservato H (R, Q) sembra essere in grado di riprodurlo con l'hash corretto. Il server deve ricordare quali R non sono più fresche. Sto scrivendo questa risposta in modo che voi ragazzi possiate modificare questa e elaborare qualcosa di buono.

Se il tuo webhost lo consente o dovrai gestire dati sensibili, utilizza HTTPS, punto. (È spesso richiesto dalla legge afaik).

Altrimenti se vuoi fare qualcosa tramite HTTP. Farei qualcosa di simile.

1. Il server incorpora la sua chiave pubblica nella pagina di accesso.
2. Il client compila il modulo di accesso e fa clic su Invia.
3. Una richiesta AJAX ottiene il timestamp corrente dal server.
4. Lo script lato client concatena le credenziali, il timestamp e un salt (hash da dati analogici, ad es. Movimenti del mouse, eventi di pressione dei tasti), crittografa utilizzando la chiave pubblica.
5. Invia l'hash risultante.
6. Il server decrittografa l'hash
7. Controlla se il timestamp è abbastanza recente (consente solo una breve finestra di 5-10 secondi). Rifiuta il login se il timestamp è troppo vecchio.
8. Memorizza l'hash per 20 secondi. Rifiuta lo stesso hash per l'accesso durante questo intervallo.
9. Autentica l'utente.

In questo modo la password è protetta e lo stesso hash di autenticazione non può essere riprodotto.

Informazioni sulla sicurezza del token di sessione. È un po 'più difficile. Ma è possibile rendere un po 'più difficile riutilizzare un token di sessione rubato.

1. Il server imposta un cookie di sessione aggiuntivo che contiene una stringa casuale.
2. Il browser restituisce questo cookie alla richiesta successiva.
3. Il server controlla il valore nel cookie, se è diverso distrugge la sessione, altrimenti va tutto bene.
4. Il server imposta nuovamente il cookie con un testo diverso.

Quindi, se il token di sessione è stato rubato e una richiesta viene inviata da qualcun altro, alla successiva richiesta dell'utente originale la sessione verrà distrutta. Quindi, se l'utente naviga attivamente nel sito, facendo clic spesso sui collegamenti, il ladro non andrà lontano con il token rubato. Questo schema può essere rafforzato richiedendo un'altra autenticazione per le operazioni sensibili (come l'eliminazione dell'account).

EDIT: Si prega di notare che questo non impedisce gli attacchi MITM se l'aggressore imposta la propria pagina con una chiave pubblica diversa e le richieste proxy al server. Per proteggersi da ciò, la chiave pubblica deve essere bloccata nella memoria locale del browser o all'interno dell'app per rilevare questo tipo di trucchi.

Informazioni sull'implementazione: RSA è probabilmente all'algoritmo più noto, ma è piuttosto lento per chiavi lunghe. Non so quanto sarebbe veloce un'implementazione PHP o Javascript di. Ma probabilmente ci sono algoritmi più veloci.

Vorrei utilizzare un sistema di scambio di chiavi Diffie-Hellman lato server e lato client con AJAX o più invii di moduli (consiglio il primo), anche se non vedo alcuna buona implementazione su Internet. Ricorda che una libreria JS può sempre essere danneggiata o modificata da MITM. L'archiviazione locale può essere utilizzata per combattere questo, in una certa misura.

È possibile utilizzare SRP per utilizzare password sicure su un canale non protetto. Il vantaggio è che anche se un utente malintenzionato rileva il traffico o compromette il server, non può utilizzare le password su un server diverso. https://github.com/alax/jsrp è una libreria javascript che supporta password sicure su HTTP nel browser o lato server (tramite nodo).

HTTPS è così potente perché utilizza la crittografia asimmetrica. Questo tipo di crittografia non solo ti consente di creare un tunnel crittografato, ma puoi verificare che stai parlando con la persona giusta e non con un hacker.

Ecco il codice sorgente Java che utilizza la crittografia asimmetrica RSA (utilizzata da PGP) per comunicare: http://www.hushmail.com/services/downloads/

puoi usare ssl per il tuo host c'è un progetto gratuito per ssl come letsencrypt https://letsencrypt.org/

L'uso di https sembra l'opzione migliore qui (i certificati non sono così costosi al giorno d'oggi). Tuttavia, se http è un requisito, è possibile utilizzare una codifica: codificarla sul lato server e decriptarla nel browser dell'utente (inviare la chiave separatamente).

Lo abbiamo utilizzato durante l'implementazione di safevia.net - la codifica viene eseguita sui lati dei client (mittente / destinatario), quindi i dati degli utenti non sono disponibili sulla rete né sul livello del server.