Come eseguire l'autenticazione sicura tramite HTTP?

17

Devo accedere su un sito Web HTTP.

C'è un modulo di login che contiene gli input per username e password e come input nascosti il sessionId. Sto creando un'applicazione in cui devo accedere a risorse a cui è possibile accedere solo se si è connessi a questo sito Web, quindi fornisco un nome utente e l'immissione della password nella mia applicazione per accedere.

Ho guardato le richieste HTTP ora e la richiesta POST HTTP in cui i dati di accesso sono stati inviati ha i parametri password e username, quindi ho potuto vedere il mio nome utente e password in Fiddler non crittografati, ma Non voglio inviare i miei dati non protetti.

Se i parametri di una richiesta POST HTTP possono essere visti da strumenti come Fiddler in chiaro, significa che i miei dati vengono inviati senza alcuna crittografia al server? O c'è qualche tipo di crittografia che non è visibile per me?

    
posta Richard_Papen 24.02.2015 - 12:12
fonte

6 risposte

50

L'ordinario HTTP di tutti i tipi non è criptato. Se vuoi proteggere i tuoi dati, devi inviarli tramite HTTPS.

    
risposta data 24.02.2015 - 12:15
fonte
20

Esiste un meccanismo per consentire l'autenticazione sicura su HTTP senza SSL o TLS, ma è usato raramente e non è ancora buono come HTTPS. Fondamentalmente, si tratta di una misura di sicurezza semi-assed di interesse storico che non ha mai preso piede, e in ogni caso dovresti usare solo HTTPS. Ma dal momento che hai chiesto ......

Il protocollo HTTP supporta due meccanismi di autenticazione: Basic e Digest Access Authentication, entrambi descritti in RFC 2617 . Questi sono meccanismi che fanno sì che il browser stesso mostri una finestra di dialogo di autenticazione , non incorporata in il contenuto della pagina. L'autenticazione di base, che a volte viene utilizzata, non è molto meglio della trasmissione in chiaro.

Il meccanismo Digest, tuttavia, è un protocollo challenge-response. Il server invia una richiesta contenente un nonce (una stringa casuale). Il cliente deve riemettere la richiesta con una risposta che è una funzione hash del nonce e della password (ma non la password stessa).

Ci sono alcuni avvertimenti significativi:

  • Il server solitamente memorizza la password in chiaro (o una versione equivalente in testo non crittografato) per essere in grado di verificare la sfida. Ciò non è auspicabile, poiché le best practice impongono di archiviare solo gli hash delle password salate. (@utente2829759 sottolinea che il server potrebbe anche memorizzare l'hash MD5 di (username: realm: password) .
  • Il meccanismo Digest utilizza MD5, che è considerato un algoritmo di hash insicuro in questi giorni. A differenza di SSL / TLS, non esiste una negoziazione algoritmica tra client e server.
  • Non c'è alcuna verifica dell'identità del server. Lo spoofing è possibile, così come gli attacchi man-in-the-middle. L'unica cosa che Digest Authentication è in grado di proteggere è la password stessa - il che non è così utile come si potrebbe pensare.

In Apache, il supporto per l'autenticazione del digest è fornito da mod_auth_digest .

Una lezione che si può trarre da questo pezzo di curiosità è che un hack basato su JavaScript potrebbe soffrire degli stessi punti deboli. Se hai bisogno di sicurezza, usa HTTPS!

    
risposta data 25.02.2015 - 02:08
fonte
3

Per rispondere a la domanda che hai posto : Sì, è probabile che le credenziali vengano inviate in chiaro.

L'unica volta in cui Fiddler sarebbe in grado di vedere il cleartext per le credenziali, mentre le credenziali vengono inviate crittografate, è se hai abilitato il proxy SSL in Fiddler e hai configurato i dispositivi client in modo che si fidino della CA Root Fiddler o ignorare gli errori del certificato. Probabilmente saprai se l'hai fatto.

Per la cronaca: fidarsi della CA di Fiddler La CA dovrebbe solo essere eseguita a scopo di test, e scrivere un'applicazione che ignori gli errori dei certificati è di per sé una vulnerabilità di sicurezza.

Poiché stai scrivendo un'app che autentica per un servizio di terze parti, un servizio che presumibilmente non hai alcun controllo, non c'è nulla che tu possa fare per migliorare la sicurezza di questo processo di accesso.

    
risposta data 25.02.2015 - 00:58
fonte
2

Sarebbe possibile per la tua applicazione autenticare in sicurezza su HTTP se il sito web (e la tua applicazione) implementano il protocollo SRP (Password remota protetta).

Si noti che sarebbe sicuro solo per le applicazioni che implementano il protocollo SRP, non per gli utenti che accedono al sito Web con un browser, perché se il codice JavaScript richiesto per far funzionare SRP viene inviato su HTTP, può essere manomesso.

Ora, dal momento che è molto improbabile che il sito web con cui stai lavorando implementa il protocollo SRP (perché se si preoccupano della sicurezza, dovrebbero almeno usare HTTPS), non puoi fare nulla per proteggere il login processo.

Inoltre, sarebbe più semplice passare a HTTPS piuttosto che implementare il protocollo SRP.

    
risposta data 25.02.2015 - 10:24
fonte
-2

Mmm il problema è nel titolo della domanda "HTTP - login sicuro"

"HTTP" e "login sicuro" si escludono a vicenda.

... a meno che tu non aggiunga una "S" al precedente: -)

È probabile che il sito non abbia crittografia o crittografia debole, quindi dovresti stare molto attento a chiamare il sito dalla tua app web se vuoi mantenere sicure le tue password!

Hai provato a cercare una versione crittografata dello stesso sito web?

    
risposta data 24.02.2015 - 19:17
fonte
-3

Esiste un'estensione jQuery chiamata jCryption

link

puoi crittografare nome utente / password con la tua chiave pubblica ssl e decodificarlo sul server con una chiave privata., quindi utilizzerai HTTP ma il login ecc. sarà protetto se sono crittografati sul computer client usando il tuo pubblico chiave.

    
risposta data 24.02.2015 - 22:09
fonte

Leggi altre domande sui tag