Il modo migliore per memorizzare un segreto in modo sicuro

Question

Il modo migliore per memorizzare un segreto in modo sicuro

#1 da (2 voti)
#2 da (0 voti)

7

Sto lavorando a un software che deve archiviare e utilizzare i segreti.

Questi segreti possono essere ad esempio:

una password per connettersi a un database
un segreto client per una sovvenzione di OAuth 2.0 client_credentials .

Ho bisogno di memorizzare queste password da qualche parte (preferibilmente in qualche tipo di file di configurazione) e proteggerle con ragionevole sicurezza.

Sicurezza ragionevole significa: nessuna soluzione hardware pesante come HSM o un'infrastruttura complicata (PKI, ...).

Il software è in Java, dovrebbe essere eseguito ovunque Java possa essere eseguito (Soprattutto Windows, GNU / Linux, Solaris, AIX).

Non può fare affidamento su un sistema operativo o su uno strumento specifico di distribuzione come il keystore di GNOME, KDE Wallet o uno di questi, a meno che Java non sia in grado di gestirli (ma ne dubito).

Ho pensato di utilizzare la crittografia simmetrica per crittografare i segreti durante la configurazione del software e decrittografarli in fase di runtime quando necessario. Ma non so come gestire la chiave di crittografia.

Ho trovato 4 possibili soluzioni:

Usa PBKDF2 (SHA256-AES256-CBC) o semplice AES256-CBC con una chiave crittografica hardcoded e opzionalmente qualche offuscamento del codice (con ProGuard )
- Di questo c'è un CWE dedicato: CWE-321 - Uso della chiave crittografica hard-coded . Quindi dubito che questa sia la soluzione.
Usa PBKDF2 (SHA256-AES256-CBC) o semplice AES256-CBC con una chiave in un file sul filesystem
- Espone la chiave in un file che dovrebbe essere protetto in qualche modo
  - filesystem crittografato e / o
  - ACL forzato
  - qualcos'altro?
Utilizza il keystore Java
- Il keystore Java richiede una password da sbloccare, quindi dove memorizzare la password del keystore Java? Come proteggerlo? Il serpente si sta mangiando la coda ...
- In qualche modo equivalente a 2
Utilizza la crittografia white-box
- Ha mostrato alcuni punti deboli ed è più o meno equivalente all'offuscamento. (che si trova all'interno dell'opzione 1).
- Non sono sicuro che l'implementazione Java di WBC sia matura.

Ho visto questa domanda: Pratiche per la memorizzazione del nome utente / password nelle applicazioni Web .

Quindi la mia domanda qui è: Qual è l'opzione "migliore" risonabile per proteggere i miei dati segreti?

Ritengo che 2 sia migliore, dopotutto è semplice, e la protezione della chiave segreta si baserebbe sul sistema operativo piuttosto che sul software stesso, proprio come OpenSSH, ma non ne sono totalmente convinto.

Modifica

PBKDF2 potrebbe essere sostituito da qualsiasi altro algoritmo di derivazione della chiave di base della password, come l'algoritmo di derivazione chiave PKCS # 12 v1.

Bonus:

Se dovessi scegliere tra PBKDF2 (SHA256-AES256-CBC) o semplice AES256-CBC , quale sarebbe il migliore?

Si dice che PBKDF2 sia buono per proteggere le password perché è 'lento'. Ed è stato progettato per questo.
AES256-CBC è più semplice (non c'è bisogno di salare / hash / iterare la chiave come in PBKDF2)

java storage passwords confidentiality pbkdf2

posta superbob 21.01.2016 - 15:17

fonte

2 risposte

0

Se stai usando Java, non dovresti usare il KeyStore Java?

link

This class represents a storage facility for cryptographic keys and certificates.

A KeyStore manages different types of entries. Each type of entry implements the KeyStore.Entry interface. Three basic KeyStore.Entry implementations are provided:

KeyStore.PrivateKeyEntry This type of entry holds a cryptographic PrivateKey, which is optionally stored in a protected format to prevent unauthorized access. It is also accompanied by a certificate chain for the corresponding public key.

Private keys and certificate chains are used by a given entity for self-authentication. Applications for this authentication include software distribution organizations which sign JAR files as part of releasing and/or licensing software.

KeyStore.SecretKeyEntry This type of entry holds a cryptographic SecretKey, which is optionally stored in a protected format to prevent unauthorized access.

KeyStore.TrustedCertificateEntry This type of entry contains a single public key Certificate belonging to another party. It is called a trusted certificate because the keystore owner trusts that the public key in the certificate indeed belongs to the identity identified by the subject (owner) of the certificate.

This type of entry can be used to authenticate other parties.

risposta data 23.01.2016 - 17:03

fonte

Leggi altre domande sui tag java storage passwords confidentiality pbkdf2

qual è la logica nella scelta di una catena di certificati durante un messaggio "server-hello" in un handshake SSL / TLS Pratiche di sicurezza per interrogare in modo sicuro le API di terze parti autenticate per conto dei clienti

score 2 · Accepted Answer

Suppongo che il tuo modello di minaccia sia un utente malintenzionato che ha accesso a file sul tuo server web tramite un qualche tipo di exploit web. In caso contrario, dovresti interrogarti su cosa esattamente stai mitigando con la tua strategia di crittografia proposta.

Se lo è, un'opzione simile a 2 è probabilmente la più semplice.

Vorrei utilizzare AES128-CBC come algoritmo per una chiave di crittografia chiave. Con una chiave di crittografia a 128 bit generata da CSPRNG, non è necessario utilizzare un algoritmo di allungamento della chiave. Algoritmi come PBKDF2 sono necessari solo quando si tenta di proteggere le password deboli fornite dall'utente. Se puoi impostare tu stesso i tasti, puoi semplicemente assicurarti che siano la forza del bit richiesta.

AES256 è più lento e senza ulteriore protezione su AES128.

Assicurati che il tuo file di configurazione e il tuo file chiave siano bloccati dagli elenchi di controllo degli accessi.

File chiave:

<128 bit random key>

Può essere letto solo da un account di servizio personalizzato.

File di configurazione:

Passwords to systems, encrypted by the key in the Key file.

Può essere letto solo dall'identità del server web.

Assicurati che questi file non siano servibili dal tuo server web (ad esempio example.com/config.txt non funzionerà). Il modo in cui dovrebbe funzionare è che si dispone di un account di servizio che esegue un processo. Il servizio Web chiama questo processo e chiede al servizio di decrittografare una password del file di configurazione per esso. Il servizio convalida che solo il processo del server Web può chiamarlo.

Questo proteggerà i tuoi segreti dagli exploit LFI nel tuo sistema o server perché un utente malintenzionato nel contesto dell'utente del server web non avrà il permesso di leggere il file chiave o decrittografare le credenziali nel file di configurazione.

Non proteggerà dall'accesso fisico, dall'accesso logico al sistema da parte di un altro account di livello amministratore o da eventuali vulnerabilità che consentono di chiamare un processo. Fonderebbe fondamentalmente solo contro le letture di file del file di configurazione direttamente dall'identità web (l'utente che il sito stesso esegue come). Se questo non è un problema, non è necessario crittografare i segreti - l'unica cosa che potrebbe proteggere è l'osservazione casuale da parte delle parti che potrebbero vedere il file di configurazione.