it-swarm-eu.dev

Je v pořádku, aby tajné API bylo uloženo v prostém textu nebo bylo možné dešifrovat?

Nejsou API keys za uživatelská jména a API secrets uvažovaná hesla? Proč je to tak, že servery API, jako je Amazon Web Services, vám umožňují zobrazit vaše API v tajnosti v prostém textu? To mě nutí myslet si, že je ukládají v prostém textu nebo alespoň v dešifrovacím formátu.

Není to lepší, kdyby se s tajemstvími API zacházelo jako s hesly, která byste měli napsat, aby jste vytvořili, pak hashed v databázi, místo aby vám byli předáváni v prostém textu? Pokud z nějakého důvodu byla jejich tajná databáze API kompromitována, snadno otevře brány pro mnoho aplikací, které používají jejich API. Pokud však bylo hashováno nešifrovatelným způsobem, pak není vše snadno ztraceno.

36
IMB

Ne. Klíče API musí být uloženy v čistém textu.

Nejedná se o hesla: jsou to kryptografické klíče. Tyto klíče se používají například pro ověřování požadavků (pomocí SHA1-HMAC). Aby server mohl používat kryptografické algoritmy, musí znát krypto klíč.

Klíč API proto musí být uložen v čistém textu na serveru. Pokud server uložil pouze hash klíče API, nemohl ověřit pravost zpráv od klienta nebo ověřit zprávy odeslané klientovi.

17
D.W.

Hashing není skladování; nezvratně ničí data. Můžeme se dostat pryč s hašováním hesel jako „ukládání hesel“, protože když heslo skutečně potřebujeme, máme k tomu šikovného lidského operátora, který jej napíše. Opravdu, když hash heslo neukládáme heslo, ale pouze token dostatečné k ověření zadaného hesla.

Klíč API musí být uložen tak, aby mohl být znovu použit bezobslužným způsobem . Server to musí opravdu ložit, místo toho, aby si pamatoval ducha, protože k přístupu k API potřebuje originální klíč.

13
Tom Leek

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

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

  1. Vygenerujte náhodnou hodnotu salt a uložte ji do databáze. Tato sůl se nesmí rovnat soli uživatele s heslem.
  2. Vezměte si uživatelské heslo pro prostý text a vypočítejte KDF(password, salt), kde KDF je funkce odvození klíče, jako je například bcrypt. Vyvolejte výslednou hodnotu k.
  3. Vygenerujte klíč API.
  4. Zašifrujte hodnotu klíče API pomocí AES pomocí klíče k 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 jej k výpočtu k, který se potom použije k dešifrování klíče API a jeho zobrazení.

Pokud si uživatel přeje používat API, musí poslat k stejně jako 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 uživatelské heslo.

Pokud útočník poruší databázi, musí crackovat uživatelské heslo, aby mohl vypočítat k.

9
Polynomial

Zdá se, že tady je trochu zmatek a jiná místa , takže přidávám tuto odpověď v naději, že to objasní situaci pro ostatní uživatele.

Mohou být použity dva typy tajemství API.

Případ použití, ve kterém se diskutuje většina odpovědí na této stránce, 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í skutečnou hodnotu klíče k vytvoření podpisu zprávy. Server poté porovná podpis, který vygeneroval, s podpisem, který klient poslal, a je schopen zprávu ověřit. Jak je 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) nemusí být klíč znovu přenášen mezi klientem a serverem.

Další běžné tajemství 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áší na každou žádost, a proto by se mělo přenášet pouze prostřednictvím šifrovaného kanálu (jako je HTTPS). V tomto případě server potřebuje pouze uchovat dostatek informací, aby ověřil, že tajná hodnota dodaná klientem je správná, takže tajemství může a mělo by být hashováno. V tomto případě tajemství skutečně funguje jako heslo, a proto by měla být přijata stejná opatření.

Zřeknutí se odpovědnosti: Nejsem výzkumný pracovník v oblasti bezpečnosti a měli byste absolutně provést další výzkum v této a jakékoli záležitosti, než slepě následujete jakoukoli radu týkající se této StackExchange.

tl; dr Nejdůležitější s sebou je, že různé API mohou použít tajemství různými způsoby. Je důležité pochopit, jak vaše API používá tajemství klienta, aby bylo možné vyhodnotit osvědčené postupy pro jeho uložení.

8
Nick Sloan

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

Existuje ještě jeden důležitý rozdíl mezi klíčem API a heslem. 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í znovu používá hesla napříč kritickými weby: banky, sociální média, e-mail atd., Což znamená, že dobré zabezpečení heslem není tak o ochraně přístupu na váš web, jako o ochraně vašich uživatelů na jiných webech. Nemůžeme nutit uživatele k lepšímu zabezpečení, takže musíme převzít to nejhorší a udělat pro ně další kroky k ochraně jejich vlastního soukromí.

Klíč API je zcela odlišný scénář, protože je jedinečný pro váš web. Výsledkem je, že pokud dojde k odcizení, útočník získá přístup na váš web, ale nezíská nic, co by mohl využít proti bance/e-mailu/atd. Dané osoby. To znamená, že úroveň rizika pro klíče API je ve skutečnosti nižší než u hesel. Nejsou úplně ve stejném parkovišti: klíče API se více podobají identifikátorům relace než hesla.

Pochopení, že se více podobají identifikátorům relací než hesla, poskytuje některé praktické poznatky o tom, jak tyto klíče správně chránit. Všimněte si, že následující diskuse je použitelná pro API Keys pro věci jako OAuth pověření a ne šifrovací přihlašovací údaje (jak je diskutováno @NickSloan ve své odpovědi).

Největší hrozbou pro hesla jsou phishingové útoky a hackované databáze, proto je ukládáme hashované v našich databázích. Největší hrozby pro klíče API jsou stejné jako pro klíče relace: slabiny v aplikacích front-end, jako jsou zranitelnosti XSS, MIM a podobně. Je důležité si uvědomit, že aplikace front-end potřebuje heslo v nezašifrované podobě, takže hashování klíče API vám nic nezíská, když to osoba, která jej pravděpodobně ukradne, potřebuje jako prostý text.

Místo toho chráníte identifikátor relace (nebo OAuth nebo klíč API specifický pro klienta) především sledováním klienta. Pokud dojde k odcizení identifikátoru relace pomocí XSS nebo jinými prostředky od klienta , typický výsledek je, že útočník použije nový identifikátor v 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ě zruší platnost všech klíčů API. Zejména v případě požadavků OAuth žádostí, je to pro uživatele velmi bezbolestné: prostě se přihlásí a okamžitě získají nový, zatímco někdo, kdo pouze ukradl klíč) (a nemá heslo) je zpět na rýsovací prkno.

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 něco, co se děje, když stejný uživatel přijde požadavky z více IP adres. Stejně jako všechno ostatní na světě to může být trochu hra s kočkou a myší, ale existují i ​​některé důležité věci:

  1. ID klíče API/OAuth Token/Session ID je opravdu jen způsob, jak si pamatovat uživatele na konkrétním zařízení, takže nemusejí vkládat své heslo na každou stránku. Výsledkem je, že pokud máte pochybnosti, můžete zabít všechny autorizované klíče a donutit 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 kompromitaci účtu, je důležité mít v těchto věcech aktivní zabezpečení a detekovat/reagovat, pokud se něco rybího stane. Pokud jste někdy dostali oznámení od facebooku/google/atd. O tom, že se někdo pokouší přihlásit k vašemu účtu z Mexika, je to proto, že někde se o práci postará bezpečnostní chlap.
  3. Primární útočné vektory pro klíče/tokeny/id jsou odlišné od 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 ve formě prostého textu), ale nemůžete je pouze hashovat v databázi a volat si bezpečně. Musíte se ujistit a zajistit je proti zcela nové řadě útočných vektorů. Pokud je považujete pouze za hesla, bude vám chybět několik důležitých částí velkého obrazu.
5
Conor Mancone

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

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

Pokud uživatelům necháte autentizaci pomocí API API, pak se API tajemství stalo (== --- ==) účinným heslem , a proto by z hlediska zabezpečení měli mít stejné mechanismy ochrany, jaké mají běžná hesla.

Amazon sám nyní neumožňuje načíst tajemství API . Pokud na to zapomenete, musíte požádat o novou.

2
Pedro Rodrigues

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, který zašifruje data tohoto uživatele a ponechá jej v relaci na serveru.

Každý uživatel tak bude mít jedinečný klíč. Tento odvozený klíč nesmí být reverzibilní, to je hlavní bod. To umožní použití hash_mac nebo jiné hashovací metody se solí a/nebo hlavním klíčem.

2. Pomocí tohoto klíče zašifrujete vygenerované API Secret pomocí AES 256 s náhodným iv pro každého uživatele.

Nebo

2.bis Pomocí tohoto klíče vygenerujete skutečný šifrovací klíč v poslední chvíli a zašifrujete metodu API stejným způsobem jako v 2., abyste se vyhnuli v paměti plovoucí hesla.

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

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

Použití

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

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

Poznámka

To je prakticky stejné jako @Polynomiální odpověď.

Tímto způsobem je pro někoho, kdo hackuje váš server a databázi, velmi obtížné ukrást vaše přihlašovací údaje a volat jménem api. Nyní můžete posoudit, že pokud byl požadavek přijat od klienta API, je to ten správný klient nebo je to jejich únik.

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

0
Nicolas Manzini