Come è possibile memorizzare una chiave segreta API in testo semplice (in un database) sicura?

Il tuo pensiero su questo è troppo bianco e nero: sicuro o pericoloso. Non c'è sicurezza qui, solo uno spettro di rischi.

Le aziende che forniscono queste API stanno effettuando una valutazione e stanno cercando di bilanciare il rischio con le prestazioni. Non tutte queste chiamate API devono avvenire su SSL. Pensa a caricare un'immagine su S3, ha bisogno di essere crittografata? Probabilmente no. Il requisito fondamentale è che le chiamate siano autenticate e autorizzate . Pensa a un milione di chiamate distinte a SDB o SQS, quanto sovraccarico sul lato client e server creerà SSL? Fondamentalmente SHA2 è veloce e costoso SSL, ora moltiplicato per 1.000.000.

Esiste il rischio di mantenere le chiavi API in chiaro sul lato server? Certamente, ma queste aziende stanno facendo una scommessa sul fatto che possono mettere altre mitigazioni intorno a quei negozi chiave che riducono il rischio a un livello accettabile. (In ultima analisi, se accedo al tuo keystore, hash o testo in chiaro, ci sono diverse cose maligne che posso fare come scambiare la mia chiave segreta con la tua.)

Informazioni sulla tua affermazione: "in realtà non fornisce alcuna garanzia che il cliente sia chi dice di essere"

Questo è vero per quasi tutti gli schemi di autenticazione. Se qualcuno accede a questo sito con il mio nome utente e password, non dimostra che sono io, solo che possiedono le mie credenziali. Se qualcuno usa la mia impronta digitale per sbloccare un lucchetto biometrico, indica che hanno un modo di fornire il mio impronta digitale in un modo che il lucchetto accetterà. Ciò che cambia qui è quanto sia difficile. Rubare le credenziali potrebbe non essere così difficile, impersonare le impronte digitali è probabilmente più difficile ma non impossibile.

In breve non lo è, tuttavia la chiave segreta non ha necessariamente bisogno di essere archiviata in chiaro sul server. Potrebbe essere crittografato (ma non hash come altri hanno spiegato) con informazioni che fanno parte di una richiesta del cliente.

Allo stesso modo, se accedi a un servizio che visualizza le tue chiavi segrete, le chiavi non devono essere state salvate in chiaro in quanto potrebbero essere crittografate con una derivata unidirezionale della password che è stata utilizzata per accedere e che viene mantenuta associata con la sessione. Mentre è possibile scoprire la chiave segreta in caso di accesso ai dati della sessione, solo un sottoinsieme di chiavi segrete del client potrebbe essere a rischio in qualsiasi momento.

Recentemente ho aggiunto una risposta all'altra domanda che penso sia rilevante anche qui. Ho modificato leggermente la mia risposta per indirizzare più direttamente la tua domanda:

C'è un'altra importante differenza tra una chiave API e una password. Le API Key sono uniche per il tuo sito. La parte che rende la sicurezza delle password così importante è la condivisione delle password. Se qualcuno ottiene una sospensione della password che un utente ha salvato sul tuo sito, non è solo il tuo sito a essere compromesso: è ogni altro sito che l'utente ha utilizzato per tale password (e email / nome utente).

Una chiave API è uno scenario completamente diverso perché è univoco per il tuo sito. Di conseguenza, se viene rubato, l'attaccante ottiene l'accesso al tuo sito, ma non guadagna nulla che possa fare leva sulla banca / email / etc di quella persona. Ciò significa che le chiavi API sono più simili agli identificatori di sessione che alle password.

Dal punto di vista della sicurezza, esaminerai il problema in modo più chiaro se pensi alle chiavi API non come password ma come ID di sessione, specialmente nei casi in cui le chiavi API possono essere assegnate automaticamente (OAuth e simili). Sì, le chiavi API possono essere rubate e il tuo account potrebbe essere compromesso, ma i modi in cui le chiavi sono vulnerabili a essere rubate sono molto diverse da quelle in cui una password può essere rubata. In particolare, una password è (teoricamente) memorizzata solo in due punti: la testa dell'utente e il tuo database. Di conseguenza il tuo database è la più grande minaccia alla sicurezza delle password (se ignoriamo gli attacchi di phishing), e il riutilizzo delle password rende il pericolo reale per gli utenti molto alto nel caso in cui il tuo database venga rubato con password in puro testo.

Tuttavia, nel caso di un identificativo di sessione o di una chiave API, nessuna di queste analisi è vera. Le chiavi API sono memorizzate nel tuo database, ma sono anche memorizzate in qualunque client stia utilizzando la password. Questo potrebbe essere nella memoria di un'applicazione javascript front-end (che è vulnerabile agli attacchi XSS), un file di configurazione su un server che si sta integrando con l'API (che è vulnerabile a un set di attacchi completamente diverso) o che sa dove altro. Di conseguenza, il database non è più il vettore di attacco principale da cui accedere alle chiavi API. Questo sicuramente cambia le priorità di sicurezza.

Per fare un altro punto, gli identificatori di sessione sono la prospettiva giusta per visualizzare le chiavi API. Qualsiasi sito web che fa affidamento sulle sessioni per archiviare i dati utente di solito ha un ID di sessione che viene anche memorizzato nel database e memorizzato in un cookie con il browser dell'utente. Di conseguenza, se il tuo database è compromesso e scaricato, le sessioni dell'utente sono completamente compromesse. Un utente malintenzionato potrebbe acquisire un ID di sessione, modificare i cookie per il tuo sito Web e accedere come qualsiasi utente senza alcuno sforzo. Gli hasht di sessione di hashing prima di archiviarli nel database arresterebbero questo particolare attacco, ma non farebbero nulla per fermare gli attacchi XSS che sono più comunemente usati per rubare le sessioni.