it-swarm-eu.dev

Ověřování pomocí tokenů - Zabezpečení tokenu

Vyvinul jsem backend REST API pro mobilní aplikaci) a nyní se chystám implementovat autentizaci založenou na tokenu, aby se zabránilo nutnosti vyzvat uživatele k přihlášení při každém spuštění aplikace.

Měl jsem na mysli počáteční požadavek, který uživatel odešle svá přihlašovací údaje pomocí základního ověřování přes SSL. Jakmile server autentizuje pověření, vytvoří zabezpečený token a odešle jej zpět uživateli, aby jej mohl použít v následných požadavcích, dokud token nevyprší nebo nebude zrušen.

Hledám radu, jak mohu vygenerovat token, který nebude citlivý na věci, jako jsou útoky MoM/Replay, a jak zajistit, aby data uložená v tokenu nemohla být extrahována.

Budu používat následující přístup k vygenerování tokenu, o kterém si myslím, že by zabránil extrahování dat z něj. Stále se však musím ujistit, že to není únosné z jiných útoků.

API bude přístupné pouze přes SSL, ale nejsem si jistý, jestli se na to mohu spolehnout pouze z hlediska bezpečnosti.

99
James

"Ověřovací token" funguje podle toho, jak si jej server pamatuje.

Obecný token je náhodný řetězec; server udržuje ve své databázi mapování z emitovaných tokenů na autentizovaná uživatelská jména. Staré tokeny lze automaticky odebrat, aby nedošlo k neomezenému růstu databáze serveru. Takový token je pro zabezpečení dostatečně dobrý, pokud útočník nemůže vytvořit platný token s nezanedbatelnou pravděpodobností, přičemž „platný token“ je „token, který je v databázi emitovaných tokenů“. Je dostatečné , že hodnoty tokenů mají délku alespoň 16 bajtů a jsou vytvářeny s kryptograficky silným PRNG (např. /dev/urandom, CryptGenRandom(), Java.security.SecureRandom ... v závislosti na vaší platformě).

Je možné vyložit požadavek na úložiště na samotné klienty. Jaká „paměť“ by měla mít server ve výše uvedeném odstavci token? Jmenovitě uživatelské jméno a datum výroby tokenu. Takže vytvořte své tokeny takto:

  • Server má tajný klíč [~ # ~] k [~ # ~] (sekvence, řekněme 128 bitů, produkovaná kryptograficky bezpečným PRNG ).
  • Token obsahuje uživatelské jméno ( [~ # ~] u [~ # ~] ), čas vydání ( [~ # ~] t [~ # ~] ) a kontrola integrity klíčů vypočteno přes [~ # ~] u [~ # ~] a [~ # ~] t [~ # ~] (společně) , keyed with [~ # ~] k [~ # ~] (ve výchozím nastavení použijte HMAC se SHA-256 nebo SHA-1).

Díky jeho znalostem [~ # ~] k [~ # ~] může server ověřit, že daný token, zaslaný zpět uživatelem, je jedním ze svých nebo ne; útočník však nemůže takové tokeny falšovat.

Odpověď, na kterou odkazujete, vypadá trochu podobně, kromě toho, že mluví o šifrování místo MAC, a to:

  1. zmatený;
  2. matoucí;
  3. potenciálně nejistá;

protože šifrování není MAC.

82
Thomas Pornin

Stručně řečeno, měli byste použít jednorázový náhodný token kryptografické síly a hashovat jej v databázi.

Token

  • musí být povoleno použít pouze jednou,
  • musí být použitelný pouze pro uživatele, pro kterého byl vytvořen,
  • musí zasílat pouze přes HTTPS,
  • by mělo mít datum ukončení platnosti (např. 7 dní).

Jakmile se uživatel přihlásí pomocí tokenu, je neplatný a měl by být vytvořen nový token a daný uživateli. V případě tokenu, jehož platnost vypršela, musí být uživatel nucen znovu se přihlásit pomocí svých skutečných údajů.

Podrobnější a zdlouhavější popis těchto pravidel je uveden v části 2 Definitivní průvodce ověřováním webových stránek založených na formulářích :

Trvalé přihlašovací cookies (funkce „pamatujte si mě“) jsou nebezpečnou zónou; na jedné straně jsou zcela bezpečné jako konvenční přihlášení, když uživatelé pochopí, jak s nimi zacházet; a na druhé straně představují obrovské bezpečnostní riziko v rukou většiny uživatelů, kteří je používají na veřejných počítačích, zapomínají se odhlásit, nevědí, co jsou cookies nebo jak je mazat atd.

[...]

Postupujte článek Charlese Millera o „Best Practices“ . Nenechte se v pokušení řídit se „vylepšenými“ nejlepšími postupy spojenými na konci tohoto článku. Je smutné, že „vylepšení“ systému jsou snadno zmařena (vše, co útočník musí udělat, když ukradne „vylepšený“ soubor cookie, si pamatuje, že starý soubor odstraní. To bude vyžadovat, aby se legitimní uživatel znovu přihlásil a vytvořil nový identifikátor řady) a nechat ukradeného platit).

A NEUCHOVÁVEJTE PERSISTENT LOGIN COOKIE (TOKEN) VE VAŠE DATABÁZE, POUZE HASH IT! Přihlašovací token je ekvivalentem hesla, takže pokud útočník dostal ruce do vaší databáze, mohl pomocí tokenů přihlásit k libovolnému účtu, jako by to byly kombinace jasného textu a hesla. Proto při ukládání trvalých přihlašovacích tokenů používejte silné solené hašování (bcrypt/phpass).


Aktualizace: Je nám líto, nepochopil jsem otázku. Metoda, kterou jste propojili, vypadá přiměřeně, ale nebude vás chránit před opakovanými útoky nebo člověkem uprostřed. Vedle toho byste měli používat SSL.

38
Polynomial

Čistá webová služba API RESTful API by měla používat základní standardní vlastnosti protokolu:

  1. U protokolu HTTP by rozhraní RESTful API mělo zahrnovat a splňovat stávající záhlaví standardů HTTP, stavové kódy a metody. Přidání nové hlavičky HTTP porušuje zásady REST).

  2. RESTful služby MUSÍ BÝT STATISTNÍ. Jakékoli triky, jako je autentizace založená na tokenu, která se pokouší zapamatovat si stav předchozích REST požadavků na serveru), porušuje zásady REST).

Sečteno a podtrženo: Pro účely autentizace/autorizace byste měli použít hlavičku autorizace HTTP. Měli byste přidat konkrétní hlavičku schématu autorizace HTTP do každého následného požadavku, který musí být ověřen.

Vyvinul jsem RESTful webovou službu pro aplikaci Cisco Prime Performance Manager. Vyhledejte na Googlu Cisco Prime Performance Manager REST API dokument, který jsem napsal pro tuto aplikaci) pro více informací o kompatibilitě RESTFul API - viz níže. Pro tuto aplikaci jsme se rozhodli použít HTTP "Basic" „Schéma autorizace k ověření a autorizaci požadavků. A samozřejmě, používáme HTTP k šifrování všech dat přenášených z klienta na server, když používáte HTTP autorizaci.

http://www.Cisco.com/c/en/us/support/cloud-systems-management/prime-performance-manager/products-programming-reference-guides-list.html

4
Rubens Gomes