Ne. Klíče API je třeba ukládat v čistém textu.

Nejsou to hesla: jsou to kryptografické klíče. Tyto klíče se používají například pro ověřování požadavků (pomocí SHA1-HMAC). Server potřebuje znát krypto klíč, aby mohl použít kryptografické algoritmy.

Proto je třeba klíč API uložit na serveru v čistém textu. Pokud server uložil pouze hash klíče API, nemohl ověřit pravost zpráv od klienta ani ověřit zprávy odeslané klientovi.

Hašování není úložiště; nenávratně ničí data. Můžeme se zbavit volání hashování hesla jako „úložiště hesel“, protože když heslo skutečně potřebujeme, máme šikovného lidského operátora, který jej zadá. Ve skutečnosti, když heslo hashujeme, heslo neukládáme, ale pouze token dostatečné pro ověření zadaného hesla.

Klíč API musí být uložen takovým způsobem, aby jej bylo možné znovu použít bezobslužným způsobem . Server to musí skutečně uložit , místo aby si pamatoval jeho ducha, protože pro přístup k API potřebuje pravý klíč.

Zdá se, že zde a na dalších místech panují nejasnosti, a proto přidávám tuto odpověď v naději, že objasní situaci ostatním uživatelům.

Tam jsou dva typy tajných kódů API, které lze použít.

Případ použití, o kterém většina odpovědí na této stránce diskutuje, je tajný klíč, který se používá k podepisování a ověřování zpráv pomocí algoritmu, jako je HMAC. V tomto případě klient i API potřebují k vytvoření podpisu zprávy skutečnou hodnotu klíče. Server poté porovná podpis, který vygeneroval, s podpisem, který klient poslal, a je schopen ověřit zprávu. Jak bylo uvedeno výše, pokud původní klíč není na serveru reprodukovatelný, nemůže to fungovat. Po počátečním sdílení klíče s klientem (přes šifrovaný kanál) již nemusí být klíč mezi klientem a serverem přenášen.

Další běžný tajný klíč klienta API je pouze tajný pověření (jak můžete vidět v typické žádosti o přístupový token OAuth2). Toto pověření se přenáší při každém požadavku, a proto by se mělo přenášet pouze přes šifrovaný kanál (například HTTPS). V tomto případě server potřebuje pouze uchovat dostatek informací k ověření, že hodnota tajného kódu zadaná klientem je správná, takže tajemství může a mělo by být hašováno. V tomto případě toto tajemství skutečně funguje jako heslo, a proto je třeba dodržovat stejná opatření.

Zřeknutí se odpovědnosti: Nejsem výzkumník zabezpečení a měli byste se tímto tématem podrobně zabývat a jakýkoli subjekt, než slepě následuje jakoukoli radu v této StackExchange.

tl; dr Nejdůležitějším krokem je, že různá rozhraní API mohou používat tajemství různými způsoby . Je důležité porozumět tomu, jak vaše rozhraní API používá klientské tajemství, aby bylo možné vyhodnotit osvědčené postupy pro jeho ukládání.

Ačkoli by bylo bezpečnější hašovat tokeny API, představuje to problém s použitelností: tokeny jsou dlouhé a náhodné a před hašováním by musely být uživateli sděleny pouze jednou. Díky tomu je trochu obtížné je zabezpečit hashem.

Můj návrh bezpečného scénáře by byl následující:

1. Generovat náhodný sůl kód> hodnotu a uložte ji do databáze. Tato sůl se nesmí rovnat soli uživatele s heslem.
2. Vezměte si prosté heslo uživatele a spočítejte KDF (heslo, sůl) , kde KDF je funkce odvození klíče, jako je bcrypt. Zavolejte výslednou hodnotu k .
3. Vygenerujte klíč API.
4. Šifrujte hodnotu klíče API pomocí AES pomocí k jako klíč a uložte ciphertext do databáze.
5. Zlikvidujte klíč API prostého textu a k.

Když se uživatel přihlásí, webapp zná své heslo a použije ho k výpočtu k , které se poté použije k dešifrování klíče API a jeho zobrazení.

Když si uživatel přeje použít API, musí poslat k a také klíč API prostého textu přes SSL. Webapp pak může dešifrovat uloženou hodnotu klíče API pomocí k a porovnat ji s daným klíčem API. Pokud se shodují, je to platné. To umožňuje použití klíče API, aniž by aplikace musela ukládat heslo uživatele.

Pokud útočník naruší databázi, musí prolomit heslo uživatele, aby mohl vypočítat k .

Uvedení vlastních dvou centů kvůli jednomu problému, který dosud nebyl zmíněn. Zejména souhlasím s tím, co řekl @NickSloan, ale s ještě jednou námitkou.

Mezi klíčem API a heslem je ještě jeden důležitý rozdíl. Klíče API jsou pro váš web jedinečné. Část, díky níž je zabezpečení hesla tak důležité, je sdílení hesla. Pokud někdo získá heslo, které uživatel uložil na váš web, není ohrožen pouze váš web: je to každý jiný web, pro který uživatel toto heslo (a e-mail / uživatelské jméno) použil. Mnoho lidí opakovaně používá hesla na důležitých webech: v bankách, na sociálních médiích, v e-mailech atd., Což znamená, že dobré zabezpečení heslem neznamená ani tak ochranu přístupu na váš web, jako spíše ochranu uživatelů na jiných webech. Nemůžeme nutit uživatele, aby zlepšili zabezpečení, takže musíme předpokládat to nejhorší a podniknout pro ně další kroky k ochraně jejich vlastního soukromí.

Klíč API je úplně jiný scénář, protože je jedinečný pro tvoje stránka. Výsledkem je, že pokud dojde ke krádeži, útočník získá přístup na váš web, ale nezíská nic, co by mohl využít proti bance / e-mailu / atd. Této osoby. To znamená, že úroveň rizika pro klíče API je ve skutečnosti nižší než pro hesla. Nejsou úplně ve stejném parku: klíče API se více podobají identifikátorům relací než heslům.

Pochopení, že se podobají identifikátorům relací více než hesla, poskytuje praktické poznatky o tom, jak je správně chránit. klíče. Následující diskuse se týká klíčů API pro věci, jako jsou přihlašovací údaje OAuth, a nikoli přihlašovací údaje pro šifrování (jak je popsáno v odpovědi @NickSloan).

Největší hrozbou pro hesla jsou phishingové útoky a napadené databáze, a proto je v našich databázích ukládáme hašované. Největší hrozby pro klíče API jsou stejné jako pro klíče relace: slabiny v aplikacích front-end, jako jsou chyby zabezpečení XSS, MIM a podobně. Je důležité si uvědomit, že front-end aplikace potřebuje heslo v nezašifrované podobě, takže hašování klíče API vám ve skutečnosti nezíská nic, když ho osoba, u které je s největší pravděpodobností ukradeno, potřebuje v prostém textu.

Místo toho chráníte identifikátor relace (nebo token OAuth nebo klíč API specifický pro klienta) primárně sledováním klienta. Pokud dojde k odcizení identifikátoru relace prostřednictvím XSS nebo jiným způsobem od klienta, je typickým výsledkem použití tohoto identifikátoru útočníkem na novém zařízení. To znamená, že najednou uvidíte starý klíč přicházející s novým uživatelským agentem. Takovou změnu lze snadno zjistit a opravit: okamžitě zneplatněte všechny klíče API. Zejména v případě požadavků OAuth je to pro uživatele velmi bezbolestné: pouze se přihlásí zpět a okamžitě získají nový, zatímco někdo, kdo pouze ukradl klíč (a nemá heslo), je zpět na rýsovacím prkně .

Toto je dostatečně běžné obranné opatření, že chytřejší hacker se také pokusí zaznamenat uživatelského agenta spojeného s odcizeným klíčem a použít jej ve všech budoucích požadavcích, ale stále můžete snadno vidět, že se něco děje když má stejný uživatel požadavky přicházející z více IP adres. Stejně jako všechno ostatní na světě to může být trochu hra na kočku a myš, ale existuje několik důležitých možností:

1. Klíč API / OAuth Token / ID relace je opravdu jen způsob, jak si uživatele zapamatovat na konkrétním zařízení, takže nemusí zadávat své heslo na každou stránku. Výsledkem je, že pokud máte pochybnosti, stačí zabít všechny autorizované klíče a přinutit uživatele, aby se znovu přihlásil.
2. Ve všech třech případech, protože ztráta klíče / tokenu / ID vede ke kompromisu účtu, je důležité mít kolem těchto věcí aktivní zabezpečení a detekovat / reagovat, pokud se něco stane. Pokud jste někdy dostali oznámení z facebooku / google / atd. O tom, že se někdo pokouší přihlásit k vašemu účtu z Mexika, je to proto, že bezpečnostní pracovník někde dělá svou práci správně.
3. Primární vektory útoku pro klíče / Tokeny / ID se liší od tokenů / hesel. Možná je budete chtít hashovat ve své databázi (opět nemluvíme o šifrovacích pověřeních, která musí být v prostém textu), ale nemůžete je pouze hashovat ve své databázi a nazývat se zabezpečeným. Musíte se ujistit a zabezpečit je proti zcela nové řadě vektorů útoků. Pokud o nich uvažujete pouze jako o heslech, zmeškáte některé důležité části celkového obrazu.

Jedním z hlavních důvodů, proč jsou hesla před jejich uložením hašována, je ochrana proti útočníkovi, který získá přístup jen pro čtení do databáze . Tímto způsobem, pokud se útočník zmocní seznamu přihlašovacích údajů, stále je nebude moci přímo použít, protože hesla jsou hašována / solena.

A nejde jen o teoretický problém, který '' Když se zde pokoušíme vyřešit, tyto typy útoků se skutečně stávají ( včetně hlavních hráčů v oboru) a správné hashování pomáhá zmírnit dopad útoku.

Pokud necháváte uživatele ověřovat se pomocí tajemství API, pak se tajemství API skutečně stalo heslem , a proto by z bezpečnostního hlediska měli mít stejné mechanismy ochrany jako běžná hesla. .

Samotný Amazon neumožňuje načíst tajemství API. Pokud jej zapomenete, musíte požádat o nový.

Ne, pro některé služby to není v pořádku.

Implementace

1. Po připojení uživatele pomocí přihlašovacího hesla , vygenerujte klíč odvozený z jeho hesla k zašifrování dat pro tohoto uživatele a jeho udržení v relaci na serveru.

Tímto způsobem bude mít každý uživatel jedinečný klíč. Tento odvozený klíč nesmí být reverzibilní, to je hlavní bod. Toto umožňuje použití hash_mac nebo jiné hashovací metody se solí a / nebo hlavním klíčem.

2. Tento klíč použijte k zašifrování generovaného tajemství API pomocí AES 256 s náhodným iv pro každý uživatel.

Nebo

2.bis Tento klíč použijte ke generování skutečného šifrovacího klíče na poslední chvíli a k ​​zašifrování metody API stejným způsobem jako v 2. vyhnout se v paměti plovoucím heslům.

3. Uložte iv do databáze spolu s ID uživatele a ID aplikace ve vyhrazené tabulce

4. Uložte šifrovaný tajný klíč API do databáze v příslušné tabulce.

Použití

Nyní, když se uživatel připojí do jeho ovládacího panelu můžete znovu vytvořit klíč, načíst iv, dešifrovat tajemství API pro tohoto uživatele a zobrazit jej v čistém textu. Při volání API také zobrazíte klíč a požádáte o obojí, abyste mohli ověřit tajemství aplikace.

Pokud se chcete vyhnout zobrazení klíče a nemusíte ho vyžadovat při volání API, můžete také pro autentizaci použijte stejnou metodu jako pro přihlášení. To znamená, že můžete vytvořit další tabulku pro uložení náhodného klíče / soli pro každou klientskou aplikaci a uložení hash_mac verze tajemství API. K ověření požadavku API je tedy vyžadováno pouze ID API a tajemství API. ale je to více práce.

Poznámka

Toto je prakticky to samé jako odpověď @Polynomial.

Tímto způsobem je pro někoho, kdo hackne váš server a databázi, velmi obtížné odcizit pověření uživatelů a uskutečnit volání API jejich jménem. Nyní můžete posoudit, že pokud byl požadavek přijat od klienta API, je to ten pravý klient nebo jeho únik.

Pokud uživatel ztratí své heslo, vygenerujete z jeho nového hesla nový tajný klíč a klíč API. .

V tomto backendu můžete také zřídit server a stejně přečíst všechna data. Musíte se ujistit, že nikdo nemá přístup k vašemu back-endu, jinak si přečte všechna vaše data najednou včetně záloh.