Quando si utilizza HMAC-SHA256 devo salvare il segreto nel database per verificare il mittente?

Question

Quando si utilizza HMAC-SHA256 devo salvare il segreto nel database per verificare il mittente?

#1 da (1 voti)

1

Molte API ho trovato che usando lo stesso metodo per l'autenticazione:

Signature is a HMAC-SHA256 encoded message containing nonce, customer ID (can be found here) and API key. The HMAC-SHA256 code must be generated using a secret key that was generated with your API key. This code must be converted to it's hexadecimal representation (64 uppercase characters).

link

Credo che per farlo funzionare, il fornitore di servizi deve mantenere una copia dell'API segreta, e quindi può controllare se l'utente ha usato lo stesso segreto per generare la firma.

Penso che sia molto insicuro, ed è come memorizzare una semplice password nel database. Chiunque abbia un vecchio backup del database ha i segreti di tutti gli utenti.

Mi manca qualcosa? C'è un metodo per il server, per verificare che l'utente abbia codificato una firma usando un segreto specifico, senza memorizzare il segreto nel database?

Per questo motivo, penso di fornire all'utente una chiave privata della coppia OpenPGP, e quindi posso convalidare la firma usando la chiave pubblica.

Pensi che ci sia un difetto di sicurezza nel modo in cui bitstamp, ad esempio, funziona, e OpenPGP sarebbe meglio?

authentication rsa openpgp

posta Aminadav Glickshtein 14.01.2018 - 17:03

fonte

1 risposta

Leggi altre domande sui tag authentication rsa openpgp

Come posso cambiare le impostazioni di sicurezza di Windows usando python? Esigenze password / Richiedi Ctrl - Alt - Elimina per accedere Virustotal dice che il file è pulito ma PDFexaminer lo trova sospetto

score 1 · Answer 1

HMAC-SHA256 è un codice di autenticazione del messaggio che utilizza un segreto condiviso tra le due parti comunicanti. È assolutamente necessario che entrambe le estremità abbiano la stessa chiave (e chiunque abbia quella chiave può generare e convalidare i messaggi). Quindi sì, la tua conclusione che il fornitore di servizi ha ancora la chiave è un'intuizione corretta. (Potrebbero o memorizzare la chiave o usare un meccanismo per la rigenerazione deterministica.)

Una coppia di chiavi asimmetriche (OpenPGP è un esempio) eviterebbe questo, ma ha un'implementazione molto più complessa, più spazio per errori e tempi di elaborazione più elevati su entrambe le estremità per le comunicazioni.

Nel caso in cui rigenerino la chiave HMAC, potrebbe essere fatto in un modo che renderebbe difficile per un utente malintenzionato rubare la chiave. Forse calcolano un HMAC(username, secret) usando un secret che è memorizzato in un HSM. Ciò consentirebbe loro di generare in modo deterministico la chiave API senza la necessità di memorizzarla in chiaro. L'utilizzo di un HSM rende molto difficile per un utente malintenzionato rubare il segreto necessario per generare le chiavi per utente.

La decisione su quale sia appropriato dipenderà da diversi fattori, inclusi i requisiti di integrità necessari per il servizio in questione. Forse il fornitore di servizi ritiene che il danno che verrebbe fatto da un database trapelato non sia peggiorato a causa dell'inserimento di chiavi API - se le informazioni sono molto più preziose o se il sito serve solo a consentire il recupero di informazioni da quel database, allora il l'accesso alle chiavi API aggiunge poco alla taglia dell'attaccante.