Quali sono i potenziali rischi dell'uso di PGP per l'accesso al sito web?

Poiché ciò è a scopo di formazione / apprendimento e non una soluzione di produzione, non si applicano i normali avvertimenti relativi alla mancata rotazione delle proprie soluzioni di sicurezza. Tuttavia, ti consiglio vivamente di considerare alcune delle soluzioni stabilite - eventualmente farlo dopo aver provato la tua soluzione è una buona idea in quanto potresti capire perché le cose sono fatte in un certo modo o alcuni dei problemi un po 'di più.

Alcune cose da considerare con la tua soluzione (appena in cima alla mia testa, nessun vero pensiero profondo).

• Taglia e incolla, oppure l'utilizzo degli appunti ha generalmente un certo numero di rischi per la sicurezza. L'ultima volta che ho guardato (qualche tempo fa), Metasploit aveva anche un modulo che si poteva usare per rubare il contenuto degli appunti.

• Il tuo schema fornisce solo assicurazioni in una direzione. Non c'è nulla che possa impedirmi di ottenere la tua chiave pubblica, spoofing del sito e quindi creare una situazione in cui ritieni la tua autenticazione contro il sito, ma in realtà stai autenticandoti contro il mio sito di spoofing. Problemi simili con l'uomo nell'attacco centrale: l'utente malintenzionato può semplicemente passare attraverso la stringa crittografata, recuperare la versione decrittografata e quindi accedere al sito. Dovrai assicurarti che le tue connessioni siano su SSL con un certificato SSL valido e verificabile.

• Casuale di stringa di 1000 caratteri. Questa è spesso la grande debolezza. È molto difficile generare casualità ed è per questo che alcuni programmi che richiedono casualità faranno cose come richiedere il movimento del mouse mentre viene generato il valore casuale. Se la stringa iniziale di 1000 caratteri è del tutto prevedibile, allora sarebbe possibile restringere lo spazio di ricerca per le versioni decifrate della stringa ed evitare in modo efficace la necessità di avere la chiave privata per decrittografarla.

Che cosa stai cercando di ottenere? Il tuo sistema sembra un'autenticazione a due fattori ... senza il primo fattore (la password) e la complessità extra di dover utilizzare PGP.

In nessun ordine particolare:

• Proteggi la tua chiave PGP con una passphrase? Se è così, è memorizzato nella cache o devi digitare ogni 5 minuti? In caso contrario, probabilmente stai facendo qualcosa di sbagliato.
• Perché 5 minuti? Perché è meglio di un cookie di sessione ragionevolmente implementato?
• metterei in discussione l'usabilità del tuo schema; e con scarsa usabilità viene l'abitudine e finisci per abbassare la guardia.
• Come si ottiene la chiave pubblica sul server? Se si tratta di un meccanismo automatizzato in cui il server lo recupera da un server delle chiavi con un ID chiave, il sistema è vulnerabile a un attacco MitM banale. Se hai bisogno di trasferire la tua chiave al server off-channel, allora starai molto meglio con una sessione ssh e il reindirizzamento delle porte.

Non fraintendermi, l'idea sembra piacevole. Mi piacerebbe se tu potessi elaborare di più, ad esempio quali sono i tuoi obiettivi, come misurare un miglioramento della sicurezza, ecc. Ecc.

Il rischio è che la sicurezza interferisca con l'usabilità fino al punto in cui nessuno utilizzerà il sistema.

Stai facendo un'autenticazione utente asimmetrica del client (a.k.a) qui. In fondo va bene.

Ma pensa a questo: quello che hai implementato qui esiste già! Si chiama TLS e TLS Client Authentication.

È possibile configurare il server Web in modo che richieda un certificato client per l'avvio della connessione TLS. Ogni supporto del browser utilizza i certificati client. Tutti supportano i certificati software nell'archivio browser / certificati e possono proteggere la chiave privata con una passphrase.

Alcuni browser supportano anche l'utilizzo di smartcard (IE, Firefox tramite PKCS11), in modo che la chiave privata sia contenuta su una smartcard e non la lascerà mai.

(Lasciando la verifica del certificato fuori portata qui) il server fa esattamente questo. Il server invia una sfida (ad esempio una stringa casuale di 1000 caratteri) al browser. Il browser lo firma con la tua chiave privata, dopo aver fornito la passphrase. I dati vengono inviati al server e il server può verificare la firma con la chiave pubblica. Fatto.