Tecniche per rendere sicura una pagina di accesso senza usare SSL

Perché ti stai rifiutando di utilizzare TLS? Funziona, ha un buon track record (alcune eccezioni minori a parte). Rifiutarsi di usare buoni strumenti senza una ragione convincente non genera fiducia e non suggerisce immediatamente professionalità.

Inoltre, non eseguire il rollover del proprio sistema di autenticazione. È sciocco, e tu commetterai degli errori. Invece, dal momento che ti aspetti che i tuoi utenti abbiano un account Facebook, usa OAuth2 per consumare identità e autenticazione federate. Ancora meglio, esternalizza questo servizio a un servizio di federazione che lo ha padroneggiato e fornisce anche snippet di codice (viene in mente link ).

Non rendi la tua vita difficile.

I certificati SSL / TLS saranno gratuiti entro il Q2 2015. Ottieni il certificato qui:

link

Let's Encrypt offrirà certificati validati dal dominio firmati tramite IdenTrust gratuitamente.

Quando questo è attivo, queste domande dovrebbero essere chiuse, IMHO

What could be other good advices, to achieve as much security as I can without using SSL?

Puoi usare TLS invece di fare qualcosa di stupido.

Quello che stai cercando di fare è impossibile senza un modo sicuro di inviare i tuoi file al client, come TLS. I tuoi approcci di hashing della password lato client richiedono che il javascript sia inviato in sicurezza al client. Altrimenti, un MITM potrebbe semplicemente servire uno script che non ha cancellato la password, ma invece invia la password di testo chiaro direttamente a loro.

La parte importante è che hai bisogno di codice fidato sul client . Con TLS, quel codice attendibile è il browser, che a sua volta verifica l'integrità del tuo javascript per renderlo affidabile. Senza fare affidamento su questo o qualcosa di equivalente (che non conosco), non puoi fare ipotesi su ciò che viene eseguito sulla macchina del cliente.

L'unico modo per essere protetti senza TLS è un plug-in del browser, che deve essere scaricato ... su TLS. E un plugin per il browser è un enorme svantaggio dell'usabilità.

Il motivo è che deve esserci un codice attendibile sul computer dell'utente. Questo può essere il codice TLS nel browser dell'utente o il codice del plugin.

Le altre risposte sono chiare - usa SSL

tuttavia, per segnalare cosa fallirebbe se lo implementaste come descritto:

I thought of solving it with a first hashing on client side with JavaScript and then on the server side, if I receive hashed values(in case someone deletes some JavaScript), a second hashing and store those hashed values in the user database. Is it a safe way to implement it? Also, are there any chances that some data get lost? If so how can I know if the received data is not compromised?

quindi in questo scenario un MITM riceverebbe l'hash inviato dal client - se si trattava di un log-in o simile, potevano copiarlo e quindi inviarlo ogni volta che volevano accedere come X. Possibilità di perdita di dati ? con un MITM, è praticamente garantito che alcuni dati possono essere persi - la domanda è che sarete in grado di rilevarlo? quanto a come sai che i dati ricevuti non sono compromessi, il modo tipico sarebbe quello di firmarlo.

Se davvero non devi usare SSL, puoi farlo fuori in sicurezza tramite WS Security invece, ma avvertito, questo sarà più complicato del solo SSL.

Protect from dictionary and brute force attacks.

Generalmente possono essere sconfitti come hai descritto, tuttavia i tempi in cui devi veramente preoccuparti degli attacchi brute-force sono attacchi offline, ovvero quando il tuo codice non è in esecuzione e non puoi proteggere i dati limitando la frequenza di tentativi di accesso - sono necessari molti round di hashing per farlo

The Log In form. I implemented it in this way (without the hashing for now)

quale sarebbe esattamente la differenza per un utente malintenzionato se visualizzasse un URL con hash o un payload con hash degli stessi dati? comunque, se non vuoi i dati nell'URL, usa un POST HTTP invece di un GET HTTP

In realtà esiste uno schema di autenticazione "sicuro" sul web che precede l'SSL chiamato autenticazione di accesso digitale , quindi quale chi chiede l'interrogante non è del tutto impossibile. Questo è FAR meno sicuro di SSL ed è soggetto alla forzatura bruta della password attraverso attacchi offline, oltre che all'uso di un vecchio algoritmo hashing di MD5.

Comunque darei comunque lo stesso consiglio di chiunque altro e dirti che SSL è di gran lunga la soluzione migliore rispetto a un sistema basato su una sfida non aggiornata che non è stato aggiornato dal 1993.