it-swarm-eu.dev

Come implementare un meccanismo chiave API

prima di tutto: non sono abbastanza sicuro del titolo della domanda, quindi se hai un'idea migliore, non esitare a dirlo (:

Vorrei sapere degli esempi di best practice in cui servizi (come Twitter o co) che offrono API e vogliono che tu sviluppatore usi una chiave API impediscono a terzi di ottenere quella chiave.

Spiegherò i miei saluti con cattivi esempi:

Per quanto ne so, Twitter e FB richiedono di utilizzare i tasti API per le richieste API. Va bene per le applicazioni lato server, ma non appena si invia la chiave da un'app Web o un'applicazione desktop, la chiave è visibile agli altri.

Poiché devi inviare quella chiave, non ha molto senso archiviarla in modo super sicuro all'interno della tua app. Per la richiesta, deve essere semplice.

Una cosa che potresti fare è ospitare il tuo servizio web o wrapper che accoda il lato server chiave e quindi instrada tale richiesta al server di destinazione.

Ma ciò non è possibile se Twitter/o qualunque altro servizio tu stia limitando le richieste API per IP o desideri creare statistiche basate su IP.

Quindi per riassumere: se fossi nella posizione di creare un'API per gli altri e non volessi che usassero SSL, quali possibilità avrei per assicurarsi che la loro chiave sia sicura e non possa essere facilmente rubata ?

34
user510083

La migliore pratica è:

L'idea di base. Crea una chiave API (una chiave simmetrica a 128 bit) per ciascun account utente separato. Questa chiave deve essere archiviata in modo sicuro sul server e archiviata in modo sicuro sul client dell'utente.

Per ogni richiesta fatta dal client, aggiungi un parametro di richiesta extra che ha una "firma" sull'intera richiesta. La "firma" dovrebbe essere calcolata come S = MAC ( [~ # ~] k [~ # ~], [~ # ~] r [~ # ~]), dove [~ # ~] k [~ # ~] è la chiave API e [~ # ~] r [~ # ~] = è l'intera richiesta, inclusi tutti i parametri di richiesta. Qui MAC dovrebbe essere un algoritmo di codice di autenticazione dei messaggi sicuro, come AES-CMAC o SHA1-HMAC.

È responsabilità del cliente calcolare la firma e aggiungerla alla richiesta; è responsabilità del server verificare la firma e ignorare qualsiasi richiesta con una firma non valida. Potrebbe inoltre essere necessario includere un parametro aggiuntivo nella richiesta che identifica l'account utente che effettua la richiesta.

Ciò fornirà l'autenticazione della richiesta, ma non la riservatezza o la prevenzione della riproduzione, e il client riceverà una risposta autenticata dal server.

Suggerisco di inviare tutte le richieste tramite https (non http). Ciò fornirà un ulteriore livello di sicurezza contro una serie di casi difficili. Le implicazioni in termini di prestazioni nel fare ciò sono inferiori a quanto si possa pensare - SSL ha un sovraccarico in termini di prestazioni inferiore a quello che la maggior parte della gente pensa - quindi non scartare questa idea per motivi di prestazioni a meno che hai effettivamente misurato l'overhead delle prestazioni e l'hai trovato inaccettabile.

Aspetti aggiuntivi a cui prestare attenzione. È possibile che si desideri utilizzare un nonce monouso per impedire la riproduzione di richieste autenticate. Suggerisco di usare un valore casuale di forza crittografica (lungo almeno 64 bit). Ciò non è necessario se si utilizza https.

Assicurati che il tuo server sia scritto per difendersi dagli attacchi Inquinamento da parametri dell'host (HPP) . Ad esempio, dovrebbe rifiutare qualsiasi richiesta con più parametri di richiesta dello stesso tipo (ad es. http://example.com/foo.html?name=x&name=y). Inoltre, quando si scrive il codice del server, fare attenzione quando si creano nuove richieste in base a una richiesta ricevuta. Ad esempio, prima di elaborare ogni richiesta, il codice del server potrebbe confermare che la richiesta viene fornita solo con l'elenco di parametri previsto e niente di più; eliminare i parametri duplicati o i parametri imprevisti prima di elaborare la richiesta.

Fai attenzione a difetti di concatenazione se decidi di proteggere più valori con il codice di autenticazione del messaggio.

37
D.W.