it-swarm-eu.dev

Jak implementovat mechanismus API-Key

nejprve ze všeho: nejsem si jistý názvem otázky, takže pokud máte lepší nápad, neváhejte to sdělit (:

Chtěl bych vědět o příkladech osvědčených postupů, kdy služby (jako Twitter nebo Co), které nabízejí API a chtějí, abyste jako vývojář použili nějaký API-Key, bránili třetím stranám získat tento klíč.

Své pozdravy vysvětlím špatnými příklady:

Pokud vím, Twitter a FB vyžadují, abyste pro žádosti o API používali API-Keys. To je v pořádku pro aplikace na straně serveru, ale jakmile odešlete klíč z webové aplikace nebo desktopové aplikace, bude tento klíč viditelný pro ostatní.

Vzhledem k tomu, že musíte tento klíč odeslat, nemá smysl jej velmi bezpečně ukládat do aplikace. Pro žádost musí být jasné.

Jedna věc, kterou byste mohli udělat, je hostit svou vlastní webovou službu nebo obal, který připojí stranu klíčového serveru a poté směruje tuto žádost na cílový server.

To však není možné, pokud Twitter nebo jakákoli používaná služba omezuje požadavky API na IP nebo chcete vytvářet statistiky založené na IP.

Abych to shrnul: Kdybych byl v pozici vytvořit API pro ostatní a nechtěl bych, aby používali SSL, jaké možnosti bych musel ujistit, že jejich klíč je v bezpečí a nelze je snadno odcizit ?

34
user510083

Nejlepší postup je:

Základní myšlenka Vytvořit klíč API (128bitový symetrický klíč) pro každý samostatný uživatelský účet. Tento klíč musí být bezpečně uložen na serveru a také bezpečně uložen na klientovi uživatele.

Ke každé žádosti klienta přidejte další parametr požadavku, který má „podpis“ pro celou žádost. "Podpis" by měl být počítán jako S = MAC ( [~ # ~] k [~ # ~], [~ # ~] r [~ # ~]), kde [~ # ~] k [~ # ~] je klíč API a [~ # ~] r [~ # ~] = je celý požadavek, včetně všech parametrů požadavku. Zde by měl být MAC algoritmus pro ověřování autentizace zpráv, jako je AES-CMAC nebo SHA1-HMAC.

Za výpočet podpisu a jeho připojení k žádosti odpovídá klient; je odpovědností serveru ověřit podpis a ignorovat všechny požadavky s neplatným podpisem. Možná budete muset do žádosti přidat další parametr, který identifikuje uživatelský účet, který žádost podává.

Tím bude zajištěna autentizace žádosti, ale nikoli důvěrnost nebo prevence opakování, a klient obdrží ověřenou odpověď ze serveru.

Doporučuji odesílat všechny žádosti přes https (nikoli http). To poskytne další úroveň zabezpečení proti řadě komplikovaných případů. Důsledky tohoto výkonu na výkon jsou menší, než si možná myslíte - SSL má nižší režii výkonu, než si většina lidí myslí - tak nevyhazujte tento nápad na základě výkon ledaže skutečně jste měřeno režijní výkon a zjistili, že je nepřijatelný.

Další věci, na které si musíte dát pozor. Možná budete chtít použít jednorázové použití, aby se zabránilo opakování ověřených požadavků. Navrhuji použít náhodnou hodnotu kryptografické síly (nejméně 64 bitů). Pokud používáte protokol https, není to nutné.

Ujistěte se, že váš server je napsán tak, aby bránil proti útokům znečištění hostitele parametrů (HPP) . Například by měl odmítnout jakoukoli žádost s více parametry požadavku stejného typu (např. http://example.com/foo.html?name=x&name=y). Při psaní kódu serveru také buďte opatrní při vytváření nových požadavků na základě žádosti, kterou jste dostali. Například před zpracováním každé žádosti může váš serverový kód ověřit, že žádost přichází pouze s očekávaným seznamem parametrů a nic víc; před zpracováním žádosti zlikvidujte duplicitní parametry nebo neočekávané parametry.

Dávejte pozor na chyby zřetězení , pokud se rozhodnete chránit více hodnot pomocí ověřovacího kódu zprávy.

37
D.W.