In che modo la scelta di dove viene memorizzata una password influisce sul non ripudio? (o archiviazione della chiave privata)

3

Gestori di password e numerosi strumenti sono stati creati per archiviare i segreti degli utenti finali nel corso degli anni. Questa proliferazione ha portato a un confuso mix di opportunità per migliorare la sicurezza.

In breve, penso che questo potrebbe essere suddiviso nei seguenti gruppi. (scenari alternativi ricercati)

  • Autenticazione locale (senza diritti impliciti di rete) (segreto semi-trasferibile)
  • Autenticazione di rete (con diritti impliciti di rete) (segreto semi-trasferibile)
  • Autenticazione hardware (segreto non trasferibile) da utilizzare con entrambi gli scenari precedenti

Sto provando a creare un diagramma dei rischi su dove possono essere archiviate le credenziali di autenticazione e quali sono i rischi / le minacce di ciascun approccio.

L'obiettivo è di fornire a uno sviluppatore di applicazioni o consulente di sicurezza una guida sul luogo in cui un utente finale dovrebbe archiviare chiavi private e password unshshed per motivi di non ripudio.

Domanda

Quali modelli di autenticazione locale esistono e quali sono i punti di forza relativi nel garantire la non reclamazione?

    
posta random65537 08.09.2016 - 03:58
fonte

1 risposta

1

Questo è un compendio di metodi di autenticazione. Spero che qualcuno completi questa mappa e la scopra in modo appropriato per non ripudio.

Gran parte delle mie conoscenze sulla sicurezza si basano su iOS, ma l'input su altre piattaforme è benvenuto.

Autenticazione solo locale

La differenza principale è che gli attacchi remoti (SSH / RDP / HTTP 401 non autorizzati) non sono possibili anche se l'utente remoto ha tutte le informazioni corrette. Il vantaggio qui è che se la persona è nel controllo fisico del dispositivo, allora il dispositivo stesso agisce come "qualcosa che hanno" e possono essere applicate regole di sicurezza meno rigorose.

Inoltre, a volte questa credenziale di autenticazione non è direttamente convertibile in un token di autorizzazione.

A seconda se il materiale della chiave privata è protetto da hardware (sezione successiva), è possibile che i privilegi vengano incrementati accedendo a una memoria protetta sul dispositivo. Non sono sicuro che questa distinzione valga la pena di notare poiché non ho osservato l'autenticazione di rete che sfrutta questa caratteristica di sicurezza.

di Windows

  • Windows Hello come riconoscimento facciale
  • Windows Hello come spillo
  • Windows Hello come sblocco di immagini
  • Windows Hello come Thumbprint

Android

  • Sblocco pattern
  • Blocca sblocco
  • identificazione personale

iOS

  • identificazione personale
  • Codice pin

Apple Watch

  • Codice pin
  • Rilevamento polso

Hardware protetto

Questo è il caso in cui le chiavi private non sono trasferibili e / o l'algoritmo di convalida è protetto dall'hardware. L'estrazione della chiave privata può fornire indicazioni fisiche di violazione e può rischiare di rendere inutilizzabile la stessa periferica di autenticazione.

Nessuna di queste modalità è utilizzabile attraverso la rete.

Queste modalità di autenticazione si basano sui precedenti metodi di autenticazione locali.

Hardware Secured Part 2

Non sono sicuro di come classificare le smartcard, poiché in RDP è possibile autenticarsi su una macchina remota attraverso un'altra macchina. Ho bisogno di fare più analisi di come un "proxy" privato Smartcard funziona in contrasto con altre soluzioni "proxy" che potrebbero essere teoricamente utilizzate nella sezione precedente

  • Smartcard

Software protetto tramite il sistema operativo

Questo è il punto in cui il sistema operativo fornisce una misura di sicurezza. I dispositivi jailbroken o rooted possono compromettere le garanzie di sicurezza altrimenti disponibili.

Questi possono essere trasferibili condizionalmente al di fuori dell'ecosistema fidato (alcuni più facilmente di altri).

iOS

  • Spazio di archiviazione privato per applicazione
  • Gruppi di applicazioni
  • sincronizzazione iCloud della memoria privata
  • Messaggi SMS (iMessage non ha hook di terze parti, Android lo fa)
  • Norme Stessa origine basata sul browser (token al portatore, ricordami cookie, SOP, archiviazione locale HTML)
  • Password sincronizzata da app a sito web di Safari tramite iCloud

di Windows

  • TPM dispositivi basati su dispositivi?
  • Autenticazione LiveID / Passport
  • Norme sulla stessa origine basata sul browser
  • Memorizzazione nella cache locale basata su browser (Chrome, IE, FireFox)

Chrome

  • Sincronizzazione password Chrome su passwords.google.com "

Android

  • Password SMS / codici a una volta potrebbero essere intercettati da applicazioni di terze parti

Software protetto / gestori di password

In molti casi un gestore di password fornisce "un ulteriore posto dove guardare" per questi token trasferibili / al portatore e non fornisce lo stesso livello di integrità fornito dai segreti protetti dall'hardware e non ha garanzie a livello di sistema operativo .

  • HOTP / TOTP in software, come Google Authenticator (mantiene la chiave da qualche parte) e codici di autorizzazione di Facebook (a seconda di dove l'app memorizza la chiave e se il dispositivo è jailbroken / rooted)
  • Lastpass, Avast, 1Password può memorizzare il database delle password in DropBox, il che rende piuttosto facile per un'applicazione dropbox di terze parti accedere al file e forzare le credenziali. (I token OAuth di client di terze parti richiedono spesso l'accesso completo, non l'ambito)

Backup

I backup possono essere crittografati debolmente su un computer compromesso o su un altro dispositivo che può quindi essere utilizzato per prendere tutti i token al portatore o non "solo locali"

    
risposta data 08.09.2016 - 03:58
fonte

Leggi altre domande sui tag