Esiste un motivo per utilizzare un valore crittografato per la chiave di firma del testo normale?

-1

Sto creando un'API e sto pensando di utilizzare un valore crittografato di alcune password casuali come valore da memorizzare per la rappresentazione in testo normale della mia chiave di firma. È solo un vano tentativo di rendere le cose sicure o c'è qualche vantaggio?

modifica
 è una chiave privata di firma per un JWT. Qualcosa che stavo memorizzando in un file di proprietà o altrove. L'API fornisce funzionalità per la pubblicazione di dati sul server. Mi sto chiedendo in particolare se utilizzare un hash bcrypt generato in modo arbitrario fornisca alcun beneficio da utilizzare come valore di testo normale della mia chiave di firma.

    
posta zero01alpha 05.02.2018 - 19:35
fonte

1 risposta

1

Considerando le risposte ai commenti, cercherò di fornire una risposta qui.

Per maggiore chiarezza, OP ha un webservice che consegna i Token Web firmati JSON ed è preoccupato per la sicurezza della sua chiave privata sul server. L'OP ha chiesto, se la codifica è valida, la risposta è no . Le codifiche non forniscono sicurezza, in quanto sono reversibili senza chiave. Se un utente malintenzionato accede alla tua chiave privata codificata, non c'è nulla che gli impedisca di decodificarlo.

Inoltre, OP ha chiesto, se bcrypt è un modo sicuro di memorizzare la chiave privata. La risposta è anche no . bcrypt è not una funzione di codifica o crittografia, ma una funzione di hash crittografica . Prende un input e genera un hash crittografico sicuro salato, che consente al server di confrontarlo con altri input e decidere se entrambi gli input sono uguali (ovvero, la corrispondenza con la password di un utente durante l'accesso, senza dover memorizzare la password in testo normale ).

L'hashing della tua chiave privata lo rende inutilizzabile, in quanto non può essere ripristinato e l'hash non può essere utilizzato per firmare o decodificare alcun messaggio.

Forse puoi memorizzare la tua chiave privata in un file, leggibile solo dall'utente del server web (cioè www-data, quando si usa apache) o usarne un'altra. Tuttavia, se non si può nemmeno fidarsi del proprio server fino a questo punto, forse è questo il punto di iniziare a prendere in considerazione ulteriori misure di sicurezza. Alla fine devi fidarti di qualcosa .

Modifica: OP indica che solo il server è interessato al JWT stesso, rendendo obsoleta la verifica della firma da parte dell'utente. In questo caso, il server può generare una coppia di chiavi per se stessa, il che sembra un eccesso, se il server di firma e verifica è sempre la stessa macchina.

Considerando che avere un segreto è sufficiente per OP, HMAC o una funzione di hash simile a una chiave potrebbe essere una scelta migliore qui. Il server ha una chiave segreta, che viene utilizzata per creare un hash del JWT e verificarlo dopo aver ricevuto il token da un utente. La manomissione è impedita da questa tecnica.

Un approccio asimmetrico potrebbe essere migliore, se esiste un singolo server / servizio (micro) che crea quei token e altri endpoint richiede la verifica delle firme JWT. Un vantaggio è che la "fabbrica di token" può essere una macchina / servizio ancora più protetta, mentre gli endpoint regolari necessitano solo della chiave pubblica corrispondente, quindi non comprimono la coppia di chiavi, se violati.

    
risposta data 06.02.2018 - 14:53
fonte

Leggi altre domande sui tag