Otázka:
Jak by měly být generovány klíče API?
James
2012-09-06 02:34:01 UTC
view on stackexchange narkive permalink

Chci zajistit, aby žádosti nemohly být padělány a odeslány na můj server. Za tímto účelem musím vygenerovat klíč API na uživatele v mém systému. Účelem klíče bude podepsat žádosti na straně klienta & a ověřit je na serveru.

Otázkou je, z čeho se obvykle skládají klíče API? Jsou to jen kryptograficky zabezpečené náhodné číslo (podobné jako sůl s heslem)? Nebo je za nimi nějaká logika, např. měly by být tvořeny z údajů specifických pro uživatele.

V mém systému každý uživatel již má jedinečné ID (GUID), které není veřejně přístupné, mohu jej použít jako svůj „klíč“ nebo by měl klíč API se liší od ID uživatele?

Jeden odpovědět:
Thomas Pornin
2012-09-06 03:00:01 UTC
view on stackexchange narkive permalink

Záleží na tom, kolik chcete oddělit rolí.

Základní systém: váš „podpis“ je MAC. „Klíč API“ je tajná hodnota, se kterou je sdílen mezi serverem a uživatelem. Normální algoritmy MAC jako HMAC mohou jako klíč používat libovolné sekvence bitů, takže klíč lze snadno generovat pomocí / dev / urandom (Linux, * BSD, MacOS X), volání CryptGenRandom () (Win32) nebo použití java.security.SecureRandom (Java).

Vylepšený systém: váš signature je skutečný digitální podpis. To dává smysl, pokud chcete oddělit generátor klíčů (který může produkovat klíče, které budou akceptovány serverem) od samotného serveru (který ověřuje příchozí podpisy). Klíče pro podpisové algoritmy jsou matematické objekty se spoustou vnitřní struktury a každý algoritmus implikuje konkrétní algoritmus generování klíčů. Použijte knihovnu, která již implementuje potřebné bity (např. OpenSSL).

Ať tak či onak, je toho víc než jen klíč generace a podpisy. Pravděpodobně se například budete chtít vyhnout útokům na opakování : třetí strana, která má v úmyslu špehovat síť, a zaznamená platný požadavek podepsaný běžným uživatelem. Později útočník odešle požadavek znovu, spolu se svým podpisem, aby replikoval účinek. Abyste se vyhnuli útokům na opakování, musíte přidat nějaký druh externích protokolů a tyto věci je těžké udělat (není těžké definovat protokol; je velmi těžké definovat zabezpečený protokol). Chytré proto je opětovné použití existujícího dobře prověřeného protokolu, což v praxi znamená SSL / TLS.

U SSL je „základní systém“ omezeno na odeslání klíče API do záhlaví na začátku konverzace (to je přesně to, co se stane s ověřováním pomocí hesla na webových stránkách HTTPS). „Rozšířeným systémem“ je pak „SSL s certifikátem klienta“.

API běží přes SSL a pro počáteční požadavek vlastně používám přístup Basic authentication. Musím však uložit ověřovací token na straně klienta, který bude použit pro následné žádosti. Jsem si vědom, že použití SSL by zmírnilo útoky MitM / Replay, protože kanál je šifrován, ale to nezabrání tomu, aby někdo přednesl požadavek .... ne?
Mám pravdu v tom, že kdybych měl implementovat klientské certifikáty, pak bych vůbec nepotřeboval token „auth“?
@James: ano. S SSL s klientskými certifikáty není třeba dělat nic jiného, ​​pokud jde o ověřování. U SSL bez klientských certifikátů musí klient na začátku konverzace odeslat „heslo“ (tajný řetězec známý také serveru) v tunelu SSL (např. Jako záhlaví HTTP, pokud váš SSL je HTTPS).
V mém scénáři mám SSL, ale žádné klientské certifikáty. Potřebuji tedy klientovi poslat tento klíč „API“ (nebo „heslo“). Ponechám si kopii tohoto uloženého na serveru a pro každou žádost klienta ji podepíše pomocí klíče „API“ a server může pomocí tohoto klíče vyhledat klienta a poté ověřit požadavek. Jediné bezpečnostní riziko, které zde vidím, je potřeba někam uložit klíč API (mobilní aplikace), který by mohl být * potenciálně * extrahován a znovu použit?
@James: ach ano. Kdokoli ví všechno, co klient ví, může udělat vše, co klient může. Což je důvod, proč (moudře) chcete vytvořit klíč API pro uživatele: alespoň můžete odebrat přístup pro daný klíč, pokud se ukáže, že je zneužit. Jedná se o ochrannou funkci. Abyste se tomuto problému vyhnuli, neukládejte klíč do mobilní aplikace; místo toho jej uložte do mozku lidského uživatele (tj. udělejte z něj skutečné heslo); ale to znamená, že lidský uživatel bude muset heslo zadávat pravidelně a pravděpodobně se mu nebude líbit.
Takže opravdu musím obětovat jistotu pro použitelnost nebo naopak. Myslím, že další možností by bylo pokusit se získat rovnováhu správně, tj. Často zneplatnit klíče API, aby uživatelé přinutili znovu ověřit své přihlašovací údaje a vygenerovat nový klíč. Jak však používání klientských certifikátů tento problém zmírňuje? Nebyl by to stejný problém, pokud má klient certifikát na zařízení, nemohl by být samotný extrahován a použit?
co děláte následující [přístup] (http://stackoverflow.com/questions/11775594/how-to-secure-an-aspnet-mvc-web-api/11782361#11782361)?
Pokud používáte SSL / TLS (a pokud nejste, můžete také napsat heslo na zeď), nepotřebujete vlastní funkci MAC.SSL / TLS zaručuje důvěrnost a integritu zpráv.Váš klíč API tedy musí být jen nějakým nezjistitelným tajemstvím.Můžete použít kryptograficky zabezpečený generátor náhodných čísel k vytvoření čísla menšího než řekněme 2 miliardy.Nebo kterákoli z dalších možností zabezpečeného generátoru hesel.A absolutně nepoužívejte uživatelský klíč jako apikey.Budete chtít mít možnost klíče odvolat a znovu vydat.


ⓘ
Tyto otázky a odpovědi byly automaticky přeloženy z anglického jazyka.Původní obsah je k dispozici na webu stackexchange, za který děkujeme za licenci cc by-sa 3.0, pod kterou je distribuován.
Loading...