Protezione delle password degli utenti nelle applicazioni desktop (Rev 2)

Question

Sto creando un client Twitter e sto valutando i vari modi di proteggere le informazioni di accesso dell'utente.

IMPORTANTE: devo proteggere i dati dell'utente da altre altre applicazioni. Ad esempio, immagina cosa succede se un bot inizia a rubare le password di Twhirl o Hotmail / GMail / Yahoo / Paypal dalle applicazioni eseguite sul desktop dell'utente.

Chiarimento: l'ho chiesto prima senza la parte "importante", ma l'interfaccia utente di StackOverflow non aiuta con l'aggiunta di dettagli in seguito nella conversazione Q / A.

• A quanto pare l'hashing non lo fa
• Offuscare in modo reversibile è come cercare di nascondermi dietro il mio dito
• Il testo in chiaro suona e probabilmente è promiscuo
• Richiedere all'utente di digitare la propria password ogni volta renderebbe l'applicazione noiosa

Qualche idea?

Answer 1

Questo è un catch-22. O fai in modo che l'utente digiti la sua password ogni volta o la memorizzi in modo non sicuro (offuscata, crittografata, qualunque cosa).

Il modo per risolvere questo problema è che più sistemi operativi incorporino i gestori di password integrati, come il portachiavi di OS X. In questo modo memorizzi semplicemente la tua password nel Portachiavi, il sistema operativo la mantiene sicura e l'utente deve solo digitare 1 password principale. Molte applicazioni (come Skype) su OS X usano Keychain per fare esattamente quello che stai descrivendo.

Ma dal momento che probabilmente stai usando Windows, direi che vai con qualche offuscamento e crittografia. Penso che potresti essere leggermente paranoico sui robot che rubano le password; se la tua applicazione non ha una base di utenti di grandi dimensioni, le probabilità sono piuttosto basse che qualcuno la prenderà di mira e in particolare tenterà di rubare le password. Oltre a ciò, dovrebbero anche avere accesso al filesystem della loro vittima. In tal caso, probabilmente hanno un virus / worm e hanno problemi maggiori.

Answer 2

Penso che ti stia perdendo l'immagine più grande qui:

Se il desktop è compromesso, sei F # *% ED!

Per rubare una password dal tuo programma, un virus dovrebbe essere in esecuzione sul sistema come amministratore. Se il virus ha raggiunto questo obiettivo, rubare le password dal tuo programma è in fondo alla sua lista di cose dannose che vuole fare.

Answer 3

Conservalo in testo semplice e fai sapere all'utente .

In questo modo, non ci sono idee sbagliate su quale livello di sicurezza hai raggiunto. Se gli utenti iniziano a lamentarsi, considera xo'o una costante pubblicata sul tuo sito web su di essa. Se gli utenti continuano a lamentarsi, " nascondi " la costante nel tuo codice e dire loro che è una cattiva sicurezza.

Se gli utenti non riescono a tenere le persone cattive fuori dalla scatola, allora in effetti tutti i dati segreti che hanno sono conosciuti dal Dr. Evil. Non importa se è crittografato o meno. E se riescono a tenere lontane le persone malvagie, perché preoccuparsi di archiviare le password in testo semplice?

Potrei parlare il mio culo qui, ovviamente. Esiste uno studio che dimostra che l'archiviazione delle password in testo normale comporta una sicurezza peggiore rispetto alla loro memorizzazione offuscata?

Answer 4

Se stai creando un client Twitter, utilizza la loro API

Twitter ha un'ottima documentazione , quindi ti consiglio di leggere tutto prima di creare un client. La parte più importante in relazione a questa domanda è che non è necessario archiviare le password, archiviare OAuth invece. È necessario utilizzare lo xAuth per ottenere il token OAuth, quindi utilizzare altre API di Twitter con questo token OAuth dove necessario.

  

xAuth offre un modo per scambiare applicazioni desktop e mobili a   nome utente e password per un token di accesso OAuth. Una volta il token di accesso   viene recuperato, gli sviluppatori abilitati per xAuth dovrebbero disporre dell'accesso e   password corrispondente all'utente.

Non archiviare mai le password se riesci a cavartela

Usando OAuth il peggio che può accadere è che una terza parte (hacker black hat) ottenga accesso a quell'account Twitter ma non la password . Ciò proteggerà gli utenti che usano ingenuamente la stessa password per più servizi online.

Utilizza un portachiavi di qualche tipo

Infine, concordo sul fatto che soluzioni prefabbricate come il portachiavi di OSX dovrebbero essere utilizzate per memorizzare le informazioni sensibili di OAuth, una macchina compromessa rivelerebbe solo le informazioni dei portachiavi attualmente sbloccati. Ciò significa che in un sistema multiutente solo gli utenti che hanno effettuato l'accesso hanno i loro portachiavi vulnerabili.

Altre limitazioni al danno

Potrebbero esserci cose che mi sono perso prendere un Google per " migliori pratiche di sicurezza " e inizia a leggere per ciò che potrebbe essere rilevante.

MODIFICA (in risposta alla soluzione del caso generale desiderata)

Desideri, dato l'input dell'utente, accedere a un servizio online. Ciò significa che in genere hai, al massimo, il controllo dell'accesso a livello utente alle credenziali di autenticazione tramite qualcosa come Keychain.

Non ho mai usato il portachiavi OSX, quindi ora parlerò di SELinux. In SELinux puoi anche assicurarti che queste credenziali di autenticazione vengano fornite solo al tuo programma. E se continuiamo a fare cose a livello di sistema operativo, puoi anche firmare tutti i processi dall'avvio a crittograficamente per essere certo che nessun altro programma potrebbe imitare il tuo programma. Tutto ciò è al di là di un tipico sistema utente e, dato questo livello di installazione, si può essere certi che l'utente non è abbastanza ingenuo da essere compromesso o che un amministratore di sistema è abbastanza compiacente. A questo livello potremmo proteggere tali credenziali.

Supponiamo che non andiamo così lontano nella protezione di quelle credenziali, quindi possiamo presumere che il sistema sia compromesso. A questo punto le credenziali di autenticazione vengono compromesse, l'offuscamento / la crittografia di queste credenziali sul lato locale non aggiunge alcuna sicurezza reale e nemmeno la memorizzazione parziale o totale su un server di terze parti. Questo è facile da vedere perché, dato l'input dell'utente, il programma deve avviarsi da solo per ottenere quelle credenziali. Se il tuo programma può farlo senza input, anche chiunque abbia invertito ha progettato il tuo protocollo di offuscamento / crittografia / server.

A questo punto è una limitazione del danno, non archiviare la password come credenziali di autenticazione. Usa OAuth, sessioni di cookie, hash salati, ecc. Sono tutti token che rappresentano che ad un certo punto in passato hai dimostrato di conoscere la password. In qualsiasi buon sistema questi token possono essere revocati, il tempo è scaduto e / o scambiati periodicamente con un nuovo token durante la sessione attiva.

Il token (qualunque sia la forma) può anche contenere ulteriori informazioni di autenticazione di input non utente che limitano la possibilità di utilizzarle altrove. Ad esempio, potrebbe incapsulare il nome host e / o l'indirizzo IP. Ciò rende difficile utilizzare le credenziali su una macchina diversa poiché imitare queste forme di credenziali richiederebbe l'accesso al livello adeguato di infrastruttura di rete.

Answer 5

Dopo ulteriori riflessioni penso di aver trovato un modo. Userò l'autenticazione ASP.net per la mia applicazione desktop dell'applicazione, memorizzerò le loro credenziali online e lascerò che il gestore password di Internet Explorer gestisca la cache locale di questa coppia secondaria o credenziali per me.

Dovrò solo farli autenticare tramite un modulo API di Facebook durante il primo accesso.

Answer 6

Non capisco ... perché la crittografia non va bene? Utilizzare una chiave grande e archiviare la chiave nell'archivio chiavi della macchina (presupponendo Windows). Fatto e fatto.

Answer 7

OSX: usa il portachiavi

Windows: usa CryptProtectData e CryptUnprotectData

Linux: usa GNOME Keyring e KDE KWallet