Hash una chiave API segreta con un sale casuale invece di inviarlo inviandolo da solo nell'API REST

1

Supponiamo che io abbia un endpoint API https interno utilizzato solo da me come amministratore. In ogni richiesta invio una chiave API segreta per l'autenticazione. E sto bene con questa soluzione.

  curl -x PUT .......
  --header "X-My-Secret-Api-Key $my_secret_key"
  .....

Nel corpo mando l'id dell'utente e l'email come payload.

Sarà più sicuro se ho cancellato $ my_secret_key con l'email dell'utente?

  curl -x PUT .......
  --header "X-My-Secret-Api-Key SHA-256(${user_email}${my_secret_key})"
  .....

L'idea è che anche se "X-My-Secret-Api-Key" viene intercettato, un utente malintenzionato riceverà la chiave segreta solo per quel particolare utente. E sarà in grado di inviare richieste maligne per conto di quell'utente solo e di nessun altro.

E per poter inviare richieste per conto di un altro utente, un utente malintenzionato dovrà cercare di intercettare anche "X-My-Secret-Api-Key" per quell'utente. E così via.

Questo è un miglioramento della sicurezza decente? Eventuali aspetti negativi? È una tecnica conosciuta?

    
posta アレックス 20.07.2018 - 06:00
fonte

1 risposta

1

È una buona idea spostarsi nella direzione dell'autorizzazione di privilegi minimi, quindi se l'uso di un'API di amministrazione comporta la rappresentazione di utenti specifici, dovrebbe esserci una credenziale che rappresenta l'utente specifico sotto rappresentazione.

Detto questo, vorrei incoraggiare l'esame di pratiche diverse dall'assunzione di una chiave di amministrazione permanente e l'hashing con un attributo utente pubblico permanente per produrre una credenziale specifica dell'utente. Il punto debole più importante di quella credenziale specifica dell'utente è che è permanente.

Considerare lo spostamento nella direzione in cui alle singole azioni vengono concesse specifiche credenziali temporanee, quindi non si sta facendo business con una chiave di amministrazione. Quindi: crea un'API che accetta la chiave di amministrazione e un'azione simile a quella di impersonare un utente, sebbene le azioni possano includere azioni di amministrazione che non sono specifiche dell'utente e creare un token temporaneo con solo questi privilegi. Richiedere l'uso di questi token di privilegio limitato e non consentire l'uso della chiave di amministrazione di privilegio completo in qualsiasi operazione privilegiata specifica.

Naturalmente qui c'è molta arte nota e molte considerazioni specifiche che si applicano a situazioni specifiche, alle quali si può o non si può inclinarsi di tuffarsi. In generale, però, muoversi nella direzione dell'uso delle credenziali temporanee è meglio che limitare le credenziali permanenti.

In sum:

Is this a known technique?

Sì, ci sono molti modi per vincolare un token per l'uso in una circostanza specifica. Può aggiungere l'indirizzo email come un'altra intestazione e cancellare la coppia segreta / email. Vedi anche JWT. Molte, molte permutazioni per raggiungere fini simili.

Is this a decent security improvement? 

È meglio usare un token con meno funzionalità di uno con più, quindi rappresenta un miglioramento , ma come sotto, ci sono miglioramenti molto migliori, quindi mentre è un miglioramento, è non un miglioramento decente .

Any downsides? 

La natura permanente dei token non è desiderabile. Qualcuno che riceve un token di un utente può presumibilmente ricevere altri token utente e poiché si basano su attributi permanenti, un segreto permanente e l'email dell'utente, possono essere utilizzati dall'attaccante per sempre. Meglio muoversi nella direzione dell'adozione di token a tempo limitato, che possono anche essere limitati per consentire solo funzioni specifiche.

    
risposta data 20.07.2018 - 17:31
fonte

Leggi altre domande sui tag