Il modo migliore per inviare in modo sicuro le password da un'applicazione a un server gestito dall'utente

0

Ho la seguente situazione:

  • Un utente configura un server che dovrà ricevere i dettagli di accesso.
  • Gli altri utenti quindi creano account e accedono a questo server.

Tutto ciò accade solo su LAN. Sto pensando di usare HTTPS; tuttavia, poiché gli utenti dovranno configurare i propri server, non avranno certificati firmati.

Come faccio a essere sicuro che l'applicazione stia parlando al server attuale senza richiedere certificati (pagati)?

O c'è un modo migliore per trasferire in sicurezza queste password?

    
posta Boelensman1 25.08.2015 - 16:57
fonte

3 risposte

2

È possibile utilizzare Internet Protocol Security ( IPSec ). In questo modo le comunicazioni LAN sono autenticate e crittografate per ogni pacchetto IP di una sessione di comunicazione. Non è un problema se i tuoi computer eseguono Windows o Linux sistemi operativi basati. Tieni presente che puoi anche utilizzarlo insieme al protocollo di tunneling Layer 2 ( L2TP ) che interagisce perfettamente con IPSec.

    
risposta data 25.08.2015 - 17:15
fonte
2

Cercherò di risolverlo a livello di rete / protocollo e lasciare a te il metodo che gli hai inviato (IE-mail). Se hai pensato al mezzo di trasferimento che possiamo affrontare anche quello.

Base sul tuo post, immagino che siano solo per uso interno e non è richiesto alcun accesso esterno. Se questo non è il caso, acquista un certificato di terza parte.

Solo interno, il tuo tentativo di contenere i costi non acquistando un certificato di terze parti (solo una FYI, questo è probabilmente uno dei modi più economici per gestire un certificato, fornire sicurezza e fornire Non-repudiation )

Con certificati autofirmati, è necessario indirizzarli tutti e tre. A partire dal più semplice:

Sicurezza (crittografia IE):

Il certificato stesso fornirà il livello di crittografia che desideri. L'attuale standard minimo di sicurezza a questo punto credo sia RSA a 2048 bit, certificati firmati SHA2.

Gestione dei certificati:

Ora che hai il certificato autofirmato, come lo gestirai? La pratica standard è di 1-3 anni su certificazioni valide, è ovvio che il tuo certificato di sicurezza vada più a lungo, ma è malvisto. È più facile gestire un certificato, ma anche su 3 server inizia a diventare un problema. Qui non c'è il proiettile d'argento, puoi rintracciarlo manualmente, puoi acquistare software, puoi aggiungere un server CA, ma tutto richiede uno sforzo.

Infine non ripudio:

Questa è la parte più importante e, purtroppo, con i certificati autofirmati, è anche la più difficile. I Certificati di Terze Parti ottengono questo risultato essendo una CA Trust, utilizzata da tutti. Avere un certificato di Verisign o di chiunque altro significa che è avvenuto un livello di pre-verifica per la propria azienda. Ciò impedisce anche i ben noti attacchi MITM. I certificati autofirmati non forniscono questo.

È possibile caricare la CA di firma (in genere il server in certificati autofirmati) in ogni computer che utilizzerà il sito, incluso il certificato utilizzato per crittografare con. Questo può tecnicamente prevenire gli attacchi MITM, ma è ovvio quanto sarà complesso.

Potresti avere un server CA (e usarlo per gestire i certs) e avresti solo bisogno che i client abbiano il certificato dei trusted signers del server CA, ma questo è ancora complesso.

Lasciarlo fuori ti rende suscettibile agli attacchi MITM.

@begueradj ha anche fornito un'altra soluzione. L2TP e IPSec . L2TP non è sicuro per impostazione predefinita, motivo per cui viene utilizzato IPSec (lo si vede comunemente in VPN), ma questo fornisce anche gli stessi identici problemi. IPSec richiede la distribuzione delle chiavi. Come gestirai le chiavi? Come verranno inviate le chiavi in modo sicuro? Come fornirai il non ripudio?

TL: DR Ci sono soluzioni e dopo averle esaminate tutte, molto probabilmente si arriva alla conclusione che i $ 500 per un certificato di terze parti (Hell, anche se si tratta di un jolly) è ciò che si vuole veramente. Questo cambia davvero quando la tua organizzazione è abbastanza grande dove l'impatto sui costi cambia ei team hanno le conoscenze e le competenze per gestire CA Server, ecc.

    
risposta data 26.08.2015 - 17:54
fonte
0

Utilizzerei HTTPS con certificati firmati da una CA che hai creato, se non vuoi il costo / la seccatura di utilizzare una CA attendibile.

Quindi verifica semplicemente le tue chiavi contro la tua CA. Per esempio vedi questa guida su come creare la tua CA, e firmare i propri certificati con questa CA, anche se per il proprio scopo, non è necessario installare il certificato di root in workstation / browser (il che farebbe in modo che l'intero computer si fidasse completamente di qualsiasi cosa firmata dai certificati).

La maggior parte delle librerie HTTPS consente di specificare la posizione del certificato per la CA per il controllo dell'applicazione. Ad esempio, in python con richieste si definisce variabile ambientale REQUESTS_CA_BUNDLE o in java si aggiunge Certificato di CA per il tuo truststore .

    
risposta data 26.08.2015 - 19:17
fonte

Leggi altre domande sui tag