Metodo di offuscamento della memorizzazione della password reversibile per le credenziali di accesso di terze parti

10

Ho un'applicazione aziendale interna, che come parte della sua funzionalità si collega a un'app di terze parti utilizzando le credenziali di accesso specifiche per l'utente della mia app. Queste password sono memorizzate in un database centrale. Attualmente sono di testo semplice (questo era giustificato in base ad un alto livello di sicurezza in prima linea nella nostra LAN aziendale), ma un recente attacco contro la rete della nostra nuova casa madre (fortunatamente non sono entrati) mi ha portato a dare un'altra occhiata a quello.

Le password per l'app interna principale, possiamo crittografarle con un sale, senza problemi lì. Il problema è la crittografia delle credenziali dell'applicazione di terze parti. Come tutti sappiamo, gli utenti preferiscono mantenere la stessa password per più app, quindi, indipendentemente da ciò che faccio per la password della app interna per sicurezza, non farà una piccola differenza se le credenziali di terze parti sono lì in chiaro proprio accanto ad esso.

Ecco il kicker; qualunque sia il metodo utilizzato, deve essere reversibile all'interno dell'applicazione , poiché l'app di terze parti # $% ^ & * richiede la trasmissione di credenziali in chiaro dal processo dell'app interna a un servizio SOAP (fortunatamente lo fa su HTTPS), e l'applicazione interna consente agli utenti di mantenere queste credenziali di terze parti memorizzate (salvando il reparto Dev il problema di mantenere il contenuto del DB). Quindi, il meglio che posso fare è la crittografia, non l'hashing.

Quindi, mi rendo conto che qualsiasi metodo che uso qui non sarà ideale; se l'attaccante ottiene sia l'applicazione che le credenziali, otterrà le password in chiaro e non c'è molto che possa pensare per impedirlo. Sto solo cercando di far funzionare un hacker solo un po 'più difficile per ottenere le credenziali, sperando che mi dia abbastanza tempo per avvisare almeno la terza parte in modo che possano disabilitare i nostri login, se non costringono tutti gli utenti del sistema a cambiare la loro credenziali di terze parti prima che l'hacker possa crearne uno.

Quindi, cosa suggerisci? AES (Non riesco a immaginare che RSA sia di grande utilità in quanto l'applicazione deve crittografare e decifrare)? Qualche astuzia per tenere la chiave fuori mano da qualcuno che riesce a ottenere sia il DB che i binari dell'applicazione?

    
posta KeithS 17.10.2012 - 21:03
fonte

1 risposta

11

Supponiamo che nella tua app (chiamiamola App1), l'utente debba già inserire alcune credenziali C 1 (nome e password) che App1 usa quando si collega al tuo database centrale. Al momento, il tuo database centrale contiene C 2 come testo in chiaro, da utilizzare quando App1 si connette a App2.

Sia H () una funzione hash con un output di grandi dimensioni, ad esempio SHA-512. Quando l'utente immette la sua password (C 1 ) nell'interfaccia di App1, App1 calcola H (C 1 ) e ottiene un valore di 512 bit, che quindi divide in due metà a 256 bit, P l e P r .

Le credenziali C 2 sono simmetricamente crittografate con una chiave derivata da P l . Questa derivazione dovrebbe essere lenta (come bcrypt o PBKDF2 o qualcosa di equivalente); Suggerisco di fare affidamento su un formato esistente e ben controllato per i dettagli di crittografia e la derivazione della chiave, ad es. OpenPGP . Chiamiamo E (C 2 ) il risultato della crittografia.

Ora lascia il tuo archivio di database centrale E (C 2 ) e bcrypt (P r ).

Quando l'utente inserisce C 1 in App1, App1 applica H () per ottenere P l e P r . App1 contatta quindi il database centrale e invia P r (all'interno di un tunnel SSL, ovviamente). Il database centrale applica bcrypt () su P r per vedere se corrisponde al valore memorizzato; se sì, invia E (C 2 ) di nuovo al client. Quindi, App1 utilizza P l per decrittografare il blob e ottenere C 2 .

In questo modo, il database centrale non ottiene mai il C 2 decrittografato; e C 2 sono noti ad App1 solo in modo transitorio (in RAM, non "nascosto" nel codice). Ciò che il database centrale conosce è sufficiente per testare la validità della password, ma l'hashing e il saling lenti vengono utilizzati per neutralizzare tale problema (come parte di E () per P l , usando bcrypt () per P < sub> r ).

    
risposta data 17.10.2012 - 21:46
fonte

Leggi altre domande sui tag