Perché le chiavi PGP e SSH non vedono un uso più diffuso come un secondo fattore durante l'autenticazione?

35

Uno dei principali metodi MFA emergenti è U2F, che si basa su uno scambio di chiavi iniziale e un meccanismo di risposta alle sfide.

Si tratta di un protocollo relativamente nuovo e sta iniziando a vedere un'adozione più diffusa, in particolare tra le grandi entità Web come Google, ma non è il primo meccanismo di facile risposta, in grado di ridefinire le chiavi e di rispondere alle sfide; in effetti, due vengono in mente abbastanza facilmente:

  • SSH, che esiste dal 1995 ed è disponibile essenzialmente su ogni box Linux e BSD creato dal 2000, con crescente adozione su Windows tramite software aggiuntivo nelle versioni precedenti e software integrato nelle versioni più recenti ; e

  • PGP, che esiste dal 1991, ed è attualmente incluso in alcuni dei più recenti Yubikeys (anche se, controverso, con un'implementazione closed-source di ultima generazione), e

Sembra che sarebbe perfettamente logico utilizzare uno di questi protocolli / standard ampiamente disponibili (rispettivamente) come meccanismo di MFA per qualcosa di più della sola SSH in una macchina remota o per la crittografia della posta elettronica; quindi perché non hai guadagnato alcuna trazione dove U2F è in piena espansione?

    
posta Jules 17.06.2016 - 07:13
fonte

6 risposte

25

Controlliamo cosa offrono attualmente PGP e SSH per questo scopo:

  • PGP:
    Il client deve installare il software PGP che non è installato di default nella maggior parte dei sistemi. Il cliente deve creare una coppia di chiavi PGP. Quindi deve inviare la chiave pubblica al server in modo che il server possa utilizzarlo in seguito per la convalida. Durante l'autenticazione con 2FA il server invierà una richiesta che il client deve firmare con la sua chiave privata e inviare la richiesta firmata come risposta. Ovviamente il cliente deve proteggere la sua chiave contro il furto, magari con una password.
  • SSH:
    Il client deve installare il software SSH che non è installato di default nella maggior parte dei sistemi. È necessario creare una coppia di chiavi e inviare la parte pubblica al server. Quando si effettua l'autenticazione con 2FA su alcuni servizi Web, il client deve creare una connessione SSH a un server correlato e il server deve unire l'autenticazione corretta utilizzando SSH e l'accesso al sito Web in qualche modo insieme, magari con un token aggiuntivo che il client deve fornire dopo l'uso SSH. E ops, potrebbe esserci un firewall nel modo di bloccare SSH. E naturalmente il cliente deve proteggere la chiave contro il furto.

Quindi essenzialmente entrambe le soluzioni si riducono a:

  • installa inizialmente del software
  • crea una coppia di chiavi statiche e pubblica la parte pubblica (questo potrebbe essere integrato nel software per comodità ma al momento non lo è)
  • in qualche modo ottenere una sfida dal server e in qualche modo inviare indietro la sfida firmata. E in qualche modo il server deve integrare la convalida della sfida nel processo di autenticazione. "in qualche modo" perché non esiste un processo già stabilito per questo che integri tutto con il flusso di autenticazione utilizzato nelle applicazioni Web.
  • e ovviamente il client deve proteggere la sua chiave

La stessa procedura può essere eseguita molto più facilmente con un certificato TLS del sito client. Ciò lascia comunque la creazione del certificato come un problema grave (ma questo è possibile anche all'interno del browser oggi), ma almeno la convalida è già integrata nel protocollo HTTPS.

Inoltre, non vedo come queste soluzioni forniscano un'esperienza utente migliore o un'esperienza di integrazione rispetto alle soluzioni 2FA esistenti. Sono non facili da usare , richiedono software aggiuntivo, richiedono nuovi modi per integrarsi con il lato server ecc. E non forniscono una sicurezza migliore . Allora perché preoccuparsi e non prendere in considerazione le soluzioni più recenti progettate pensando all'usabilità e all'integrazione dei server?

A parte questo, le attuali soluzioni 2FA economiche utilizzano un telefono cellulare. Questi forniscono di solito una migliore architettura di sicurezza rispetto ai PC attuali. E sono un dispositivo hardware aggiuntivo a cui l'utente deve avere accesso e che rende più strong la protezione offerta da 2FA.

    
risposta data 17.06.2016 - 08:35
fonte
11

Mancanza di portabilità

SSH e PGP sono ampiamente usati, ma non sono tecnologie web. C'è stata una tecnologia web equivalente per molti anni - certificati client SSL. Tuttavia, questo non è molto usato.

Il motivo è la mancanza di portabilità. Se si dispone di un certificato client SSL sul desktop di casa, è difficile spostarlo da qualche altra parte. Quindi non puoi accedere dal tuo laptop di lavoro, dal desktop di tua suocera, ecc.

Esiste una soluzione di certificato client portatile che esiste da molto tempo ed è molto sicura: le smart card. La chiave privata è memorizzata nella smart card e mai rilasciata. Tuttavia, questo è stato visto soprattutto nelle applicazioni ad alta sicurezza, come l'online banking aziendale.

All'inizio degli anni 2000 c'era un'innovazione limitata attorno all'autenticazione. Gli sforzi mirati al mercato di massa, come Microsoft Passport e OpenID, non sono decollati. La maggior parte dei prodotti puntava alla fascia alta: accesso VPN aziendale, ecc. Questo sta cambiando e stiamo assistendo all'innovazione nel settore dell'autenticazione di massa. Ad esempio:

  • Mozilla persona - In pratica rende portatile un certificato client memorizzandolo nel cloud. Anni fa questo sarebbe stato respinto come un'idea pazza, ma negli ultimi tempi il modello della minaccia è stato meglio compreso e i benefici sono evidenti.

  • U2F - Porta l'elevata sicurezza delle smart card al mercato di massa. I dispositivi sono più portabili ed è sicuro utilizzare un dispositivo su molti siti Web diversi. Quindi U2F è una tecnologia che si adatta perfettamente ai modelli di utilizzo moderni, quindi è un successo.

risposta data 17.06.2016 - 12:20
fonte
4

Perché i fattori auth aggiuntivi dovrebbero, idealmente, essere fuori dalla banda. Come un telefono, un token o qualche tipo di messaggio telepatico.

U2F è buono perché NON puoi estrarre la chiave privata e richiede un tocco fisico al dispositivo prima che firmi.

    
risposta data 17.06.2016 - 18:02
fonte
1

Per il pubblico in generale, qualsiasi autenticazione a 2 fattori dovrebbe essere compresa in meno di 2 minuti, altrimenti fallirà molto rapidamente poiché poche persone saranno in grado di capirlo. Questo in genere richiede l'utilizzo di qualcosa che le persone hanno già familiarità o è molto semplice.

PGP e SSH sono tecnologie complesse che pochissime persone, tranne gli sviluppatori e le operazioni IT capiscono. Come sottolinea Stephen, entrambi richiedono non solo l'installazione del software, ma la comprensione di metodi molto complessi di generazione di file, l'invio a terze parti e (molto peggio) la comprensione dei concetti sottostanti coinvolti. Per la persona media, questo richiederebbe molte ore di allenamento, prove ed errori e concetti completamente nuovi. Anche allora, avresti alti tassi di errore.

Confrontalo con le soluzioni utilizzate in 2 fattori. Messaggi di testo, hard token che visualizzano numeri o telefonate. Messaggi di testo e telefonate sono cose a cui le persone hanno già familiarità. Un token difficile è leggermente più complesso, ma un utente può essere addestrato in meno di 2 minuti su come utilizzare questi dispositivi perché sono semplici.

    
risposta data 17.06.2016 - 21:21
fonte
0

Il plugin EnigForm FireFox è stato un approccio molto promettente. E in combinazione con una SmartCard OpenPGP era sicuro almeno quanto FIDO U2FA. È un peccato che non abbia ottenuto un'adozione diffusa.

    
risposta data 17.06.2016 - 21:11
fonte
0

Due cose.

1. È sempre stato così

I token biometrici o hardware (come RSA SecurID) erano lo standard per 2FA, quindi tutti hanno ricevuto telefoni cellulari e in seguito smartphone. All'improvviso è stato facile creare un secondo fattore inviando un'email agli smartphone, oppure a un'app sui loro smartphone o un sms ai telefoni più vecchi.

Il fatto che si potesse utilizzare una crittografia a chiave pubblica non era considerato un secondo fattore, poiché in genere si utilizzavano le chiavi pubbliche anziché una password. Quella era la percezione della gente, e ad essere onesti, fino ad ora non ci avevo pensato molto.

2. È meno sicuro

Mentre un messaggio a un'app è già più facilmente intercettato rispetto a RSA SecurID (o Yubikey o altro token hardware) e quindi meno sicuro, l'utilizzo dell'autenticazione a chiave pubblica è probabilmente ancora meno sicuro di così:

Un token può essere intercettato mentre lo scrivi, ma la tua chiave privata può essere rubata dal tuo computer una volta per tutte. La fonte del secondo fattore non è su un server (invio di messaggi di testo) o nascosta in un modulo antimanomissione (un token), è nel sistema che usi tutto il tempo per molte cose.

(Va notato che le smartcard risolvono questo problema, ma poi conosco davvero poche persone che lo utilizzano al di fuori del lavoro.)

Inoltre, molte altre risposte includono "nessuno ha questo" in una forma o nell'altra, e hanno ragione. Ma la maggior parte delle persone non usa 2FA neanche. Penso che la sovrapposizione tra i tecnici che usano SSH e / o PGP e 2FA sia significativa, invalidando l'argomento secondo cui nessuno usa SSH, PGP o qualcosa di simile. Specialmente posti come Github potrebbero offrire a SSH un secondo fattore; già supportano le chiavi SSH (e le persone lo usano! ), non solo per 2FA.

    
risposta data 17.06.2016 - 21:47
fonte

Leggi altre domande sui tag