2009-10-06 36 views
6

Sto provando a rendere sicuro un modulo di accesso "normale" nome utente/password, senza bisogno di HTTPS. La mia idea è questa:Accesso protetto: crittografia a chiave pubblica in PHP e Javascript

  • Il server genera una coppia di chiavi per un qualche tipo di algoritmo di crittografia asimmetrico. Memorizza questa coppia di chiavi in ​​una tabella temporanea di ordinamenti (o forse i dati della sessione locale).
  • Il server invia il modulo al client e include la chiave pubblica.
  • L'utente compila il modulo.
  • Prima di essere inviato al server, Javascript crittografa la password utilizzando la chiave pubblica fornita.
  • Modulo inviato.
  • Il server decrittografa la password con la sua chiave privata (che ottiene dalla tabella temporanea, utilizzando la chiave pubblica per trovarla).

Che cosa ho bisogno di sapere per questo è:

  • Quale metodo di cifratura è il migliore da usare? RSA?
  • Come posso decodificare la password in PHP?
  • E probabilmente il più difficile, come posso fare in modo che Javascript codifichi la password?
+0

Utilizzare sempre SSL/TLS con certificati validi. Se si hanno motivi diversi dalla sicurezza di rete per crittografare l'accesso (come la prevenzione della registrazione debug/crash/normale/ecc. Della password lato server, che può essere successivamente ripristinato da un utente malintenzionato) è possibile utilizzare questo: http://stackoverflow.com/questions/12457234/encrypt-in-javascript-decrypt-in-php-using-public-key-cryptography –

risposta

17

In anticipo: mi dispiace per essere negativo, tuttavia;

L'implementazione del proprio protocollo di sicurezza è mai una buona idea, a meno che non si tratti di un esperto di sicurezza altamente qualificato, o in realtà non si preoccupa veramente della sicurezza e si vuole solo creare un'impressione di sicurezza (marketing) e ferma gli script kiddies.

SSL non è sicuramente un blocco di impronte digitali, come si dice nei commenti, JCryption e la tua proposta sono uguali ad avere una porta in cui è possibile inserire un codice a due cifre per aprire la porta e si hanno infinite ripetizioni. È difficile da rompere se non sei davvero interessato e passa, ma se vuoi entrare in quella casa (e probabilmente lo fai, altrimenti non sarebbe necessaria la sicurezza), entrerai.

Altro Il punto è che le persone dimenticano spesso di menzionare ciò che vogliono ottenere. La sicurezza ha le famose tre componenti chiamate CIA, ovvero riservatezza, integrità e disponibilità. Per te è importante che i dati che trasporti siano confidenziali o che siano importanti per l'integrità (ad esempio sei sicuro che i dati inviati provengano da quello che ti aspetti e non dall'uomo nel mezzo)?

Per renderlo concreto in questo caso, l'unica cosa che si ottiene qui è che un attaccante passivo non può vedere cosa sta passando sulla linea. Non appena l'attaccante diventa attivo e cambia i messaggi sulla loro rotta, tutta la tua sicurezza cade a pezzi. Quindi il mio consiglio sarebbe di limitarsi a seguire la soluzione che gli esperti hanno trovato (TLS in questo caso, non ssl dato che è la vecchia versione di esso) e solo assicurarsi che il server lo supporti.

edit:

Btw, SSL/TLS non può funzionare senza i certificati. L'intero punto nella criptazione della chiave pubblica è che dovrebbe esserci almeno da qualche parte una parte fidata.

D'altra parte, se non ti interessa che i tuoi utenti ricevano un messaggio di "certificato non valido", puoi semplicemente creare il tuo certificato che è davvero facile. In tal caso il tuo certificato non è attendibile dai browser, tuttavia, puoi essere sicuro che almeno la tua comunicazione è sicura (ok, ci sono eccezioni in questo caso, ma comunque ...)

L'argomento che i certificati dovrebbe essere gratis è davvero da un punto di vista prospettico. Penso che le persone che sostengono che sia fasullo/idiota non sanno quello che serve per essere un'autorità di certificazione. Queste società investono milioni per mantenere la comunicazione sicura e sicura di ricavare dei bei guadagni dalla vendita di certificati, ma sono al loro posto e meritano anche di fare soldi, proprio come gli altri.

EDIT2: dopo i commenti

ho davvero dire che si ha una comunicazione sicura. Tuttavia, ti manca il punto che con certificati autofirmati non sai a chi parli in modo sicuro. Immagina una stanza buia completamente isolata dall'ascolto di una conversazione. Ora immagina la differenza tra una stanza simile con e senza luce. Se la stanza è illuminata, puoi effettivamente vedere a chi stai parlando in modo sicuro e solo scegliere per parlare con le persone di cui ti piace fidarti. Ora immagina di fare lo stesso in una stanza completamente buia. Puoi solo sperare che il tizio con cui parli all'interno di questa oscura stanza sia solo un alleato e non il tuo avversario. Tuttavia, non puoi saperlo, solo spero che il numero sia ok. E anche se la tua conversazione è sicura, nessuno può ascoltarti, non hai ancora la sicurezza "completa".

Se io, essendo un truffatore, faccio un attacco man-in-the-middle, posso creare un certificato autofirmato senza che l'utente se ne accorga. Quindi il vantaggio di utilizzare TLS con certificati autofirmati è che si ha almeno l'implementazione del protocollo corrent (e anche l'implementazione di questo è tutt'altro che semplice). Inoltre è possibile evitare i brutti avvisi avvisando gli utenti di affidarsi manualmente al certificato una sola volta. Tuttavia, questo è possibile solo se si dispone di un gruppo relativamente piccolo di visitatori di ritorno, per un sito pubblico questo non è davvero una soluzione.

+0

Hai davvero ragione quando si tratta di cose davvero delicate, come le banche. Sto, tuttavia, in effetti sto solo cercando di fermare qui i copioni. –

+0

Inoltre, dal momento che sembra effettivamente proporre certificati autofirmati, perché non dovrebbe esserci un sistema in cui ciò è possibile senza brutti avvisi. Dopotutto, è come dici tu: allora "puoi essere sicuro che almeno la tua comunicazione è sicura" –

+0

Inoltre (scusami per il triplo commento) +1 visto che, mentre mi capita di non essere d'accordo, il tuo post è ben scritto. –

0

Questa è un'ottima idea, ed è già stata eseguita. Vedi jCryption.

3

Sembra che un sacco di quello che vuoi fare è fornito dal plugin jquery JCryption. Assume anche PHP come back-end, quindi una buona idea per te.

+0

JCryption è ottimo se si desidera un sistema di sicurezza: http://www.securityfocus.com/archive/1/520683 Se vuoi una sicurezza reale prova phpseclib, una vera implementazione RSA di PHP (secondo le raccomandazioni della disclosure securityfocus.com) – neubert

0

jCryption sembra interessante, non l'ho visto prima.

Ma devo chiedere cosa c'è di sbagliato con SSL?

Il codice di crittografia è notoriamente difficile da eseguire correttamente e si può scommettere che le implementazioni SSL rilevate nei browser e nei server http sono molto più rigorosamente testate e riviste rispetto a quelle di jCryption.

Detto questo, jCryption sembra accurato se è assolutamente necessario evitare SSL e non si ha a che fare con informazioni super-sensibili.

+0

Oh sì, SSL è ottimo, tranne che per una decisione di progettazione idiota che hanno fatto: hai bisogno di un certificato e questo costa i soldi. Se lo avessero fatto in modo da poter avere la crittografia senza la parte di convalida dell'identità, la crittografia sarebbe stata utilizzata più spesso e la rete sarebbe stata più sicura del tutto. –

+0

La convalida dell'identità è necessaria affinché il certificato possa essere firmato. Se non è firmato, i clienti non hanno modo di sapere se vengono presentati o meno con un certificato falso. L'argomento secondo cui "costa denaro" è piuttosto scadente, dato che molti provider di hosting spesso abbinano un certificato SSL perfettamente valido o lo forniscono a un piccolo costo aggiuntivo. Se si è seriamente intenzionati a operare in un ambiente in cui ci si aspetta che aderiscano a determinati standard di sicurezza, allora si dovrà accettare che ci saranno dei costi. – Rob

+0

È sempre possibile generare il proprio certificato SSL autofirmato. Naturalmente, i browser hanno iniziato a renderlo ancora più spaventoso per gli utenti di quanto non fossero soliti fare. Ma io tendo ad ammettere che la discussione sui costi è falsa. Il tempo del programmatore per implementare il tuo modo di pagare un certificato SSL costa anche. – timdev

10

Questo non sembra sicuro dal punto di vista del cliente. Due (oggetti legati) problemi:

  1. Come funziona il client di fiducia del server? Come può verificare che la chiave che presenta il server sia quella che gli appartiene?
  2. È possibile effettuare attacchi man-in-the-middle. Un proxy malintenzionato potrebbe rimuovere e archiviare la chiave pubblica prima che il client la veda, sostituendola con la sua, quindi decrittografare la password quando il client autentica, memorizza e re-crittografa e invia la risposta in modo che il client non realizzi qualcosa è successo

Cosa c'è che non va con il normale SSL? Deve esserci consenso sul fatto che sia sicuro, altrimenti i fornitori e le organizzazioni abbandonerebbero il supporto durante la notte.Al contrario, la maggior parte dei tentativi di inventare un nuovo modo funky per fare sicurezza "a buon mercato" di solito manca qualcosa di fondamentale.

+1

Non c'è modo di controllare l'identità del server, è vero. Ma importa? Un vero certificato SSL non sta per accadere, e questo è meglio di niente ... molto meglio. SSL è come se non si potesse bloccare la porta o uno scanner di impronte digitali. La serratura normale con una chiave di metallo non è disponibile. –

+1

Direi che è * peggio * di niente, perché ti sta dando un senso di sicurezza completamente falso. Un vero certificato SSL può essere ottenuto per $ 30 - i tuoi dati valgono davvero meno di $ 30? – caf

1

Livejournal fa qualcosa di simile a ciò che si desidera dove:

  1. Server genera una stringa sfida, inserisce questo in forma. [1]
  2. Il client genera una risposta tramite MD5 con hashing della password, quindi MD5 esegue l'hash precedente con la sfida anteposta [2].
  3. Il server riceve la risposta, verifica la validità della verifica, quindi esegue la stessa operazione del passaggio 2, confrontando il risultato con la risposta.
0

Memorizzando le password in modalità crittografata sul server, il server può recuperare le password e verificare il checksum inviato dal client. Invia una password di sessione e chiedi al cliente di fare un hash di password di sessione e la password immessa dall'utente, fare lo stesso sul server e confrontare i due hash.

Questo non protegge gli utenti dagli attacchi MITM - amministratori locali, NSA, telecom, dirottatori di router, ma manterrà la password sicura in open wlan.

Problemi correlati