Mobilní autentizace (mobile authentication)

Příklady z praxe

1. 01

   Refresh token chráněný biometrií na iOS

   E-shopová aplikace drží refresh token v Keychainu s příznakem, který vyžaduje odemčení zařízení a přítomnost biometrie. Když uživatel otevře aplikaci po týdnu, systém si vyžádá Face ID a teprve pak aplikace získá token a vymění ho za nový access token. Bez odemčení se položka nedá přečíst ani po zkopírování zálohy.

   let access: [String: Any] = [
     kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlockedThisDeviceOnly,
   ]
   let query: [String: Any] = [
     kSecClass as String: kSecClassGenericPassword,
     kSecAttrService as String: "cz.example.app.refresh",
     kSecValueData as String: refreshToken.data(using: .utf8)!,
   ]
   SecItemAdd(query.merging(access) { a, _ in a } as CFDictionary, nil)

2. 02

   Přihlášení přes OAuth 2.0 s PKCE v systémovém prohlížeči

   Aplikace neotevře vlastní WebView, ale systémovou kartu prohlížeče na autorizačním serveru. Vygeneruje náhodný code_verifier, pošle jeho hash jako code_challenge a po návratu přes vlastní URL schéma vymění autorizační kód za tokeny. Odcizený kód je tak bez znalosti verifieru nepoužitelný.

   const verifier = base64url(crypto.getRandomValues(new Uint8Array(32)));
   const challenge = base64url(await crypto.subtle.digest('SHA-256', enc.encode(verifier)));
   const url = `https://id.example.com/authorize?response_type=code`
     + `&client_id=mobile-app&redirect_uri=cz.example.app:/cb`
     + `&code_challenge=${challenge}&code_challenge_method=S256`;

Časté omyly

MýtusOtisk prstu se posílá na server, takže si ho firma ukládá.

Ve skutečnostiBiometrický vzorek zůstává v bezpečném prvku telefonu a nikdy zařízení neopouští. Server dostane jen podpis nebo token, který se zpřístupní po úspěšném lokálním ověření.

MýtusKdyž má aplikace přihlášení otiskem, je automaticky dvoufaktorová.

Ve skutečnostiBiometrie odemyká tajemství uložené v zařízení, takže jde o jeden ověřovací tok postavený na vlastnictví telefonu. Skutečný druhý faktor vzniká až tehdy, když se k němu přidá nezávislý prvek, typicky heslo nebo serverem řízená výzva.

MýtusSMS kód je dostatečně bezpečný druhý faktor pro cokoli.

Ve skutečnostiSMS kódy jsou zranitelné vůči SIM swapu, přesměrování zpráv a sociálnímu inženýrství. U citlivých operací se doporučuje passkey, hardwarový klíč nebo push potvrzení podepsané klíčem v zařízení.

Časté dotazy

Kam se má v mobilní aplikaci ukládat přihlašovací token?

Přihlašovací token patří do systémového úložiště klíčů: Keychain na iOS a Android Keystore, ideálně přes EncryptedSharedPreferences nebo klíč vázaný na odemčení zařízení. UserDefaults, SharedPreferences, obyčejný soubor v sandboxu ani lokální databáze nejsou vhodné, protože na rootnutém zařízení nebo v záloze jde o čitelná data. Access token je rozumné držet pouze v paměti procesu a po restartu ho získat výměnou refresh tokenu. Refresh token by měl mít omezenou platnost, rotovat při každém použití a být okamžitě zneplatnitelný na serveru.

Je passkey v mobilní aplikaci lepší než SMS kód?

Passkey nabízí podstatně vyšší úroveň ochrany než SMS kód, protože klíčový pár je svázaný s konkrétní doménou a podpis nelze použít na podvodném webu. Odpadá tak celá třída phishingových útoků i riziko SIM swapu. Nevýhodou je horší podpora u starších zařízení a nutnost promyslet obnovu přístupu, když uživatel přijde o telefon i o synchronizační účet. Mnoho aplikací proto ponechává SMS jako záložní kanál, ale s nižšími limity pro citlivé operace.

Proč se doporučuje přihlašovat přes systémový prohlížeč místo WebView?

Systémový prohlížeč (SFSafariViewController, ASWebAuthenticationSession, Chrome Custom Tabs) běží mimo proces aplikace, takže aplikace nemůže odečíst zadané heslo ani manipulovat s obsahem stránky. Uživatel navíc vidí skutečnou adresu a správce hesel i passkeye fungují normálně. Vlastní WebView tyto záruky ruší, řada poskytovatelů identity ho z bezpečnostních důvodů blokuje a recenzní procesy obchodů s aplikacemi ho hodnotí negativně. Doporučení shrnuje specifikace OAuth 2.0 pro nativní aplikace.

Jak řešit odhlášení, když uživatel ztratí telefon?

Ztráta telefonu se řeší na straně serveru, ne v aplikaci. Každé zařízení by mělo mít vlastní záznam relace s identifikátorem, aby šlo v nastavení účtu zobrazit seznam přihlášených zařízení a jednotlivě je zneplatnit. Zneplatnění musí zrušit refresh token okamžitě; krátká platnost access tokenu pak omezí okno, kdy odcizené zařízení ještě funguje. Doplňkově pomáhá zneplatnit všechny relace při změně hesla a odeslat uživateli notifikaci o novém přihlášení z neznámého zařízení.

Zdroje

1. OAuth 2.0 for Native Apps(otevře se v novém okně)IETF / RFC Editor, 2017
2. Web Authentication: An API for accessing Public Key Credentials(otevře se v novém okně)W3C, 2021
3. OWASP Mobile Application Security(otevře se v novém okně)OWASP
4. Digital Identity Guidelines (NIST SP 800-63)(otevře se v novém okně)NIST, 2017

Související pojmy

• CORSCORS je mechanismus prohlížečů a HTTP hlaviček, který říká, zda skript z jednoho originu smí číst odpověď z jiného originu. Chrání uživatele před nechtěným přístupem webů k datům dostupným v jeho prohlížeči, ale není náhradou autentizace, autorizace ani serverové kontroly požadavků.
• DDoSDDoS je útok, při kterém velké množství rozptýlených zařízení současně zahltí server, linku nebo aplikaci provozem tak, že přestane obsluhovat legitimní uživatele. Na rozdíl od prostého DoS pochází zátěž z tisíců různých adres, takže ji nelze odstavit zablokováním jednoho zdroje. Cílem není krádež dat, ale nedostupnost služby.
• DNSDNS je distribuovaný systém, který převádí doménová jména na technické údaje potřebné pro komunikaci, hlavně IP adresy serverů. Díky DNS může uživatel zadat čitelnou adresu webu, zatímco počítač získá záznamy pro web, e-mail, ověření domény nebo další síťové služby.
• 3-D Secure3-D Secure je protokol, který u online platby kartou ověří, že platí skutečně její držitel, typicky potvrzením v bankovní aplikaci. Při úspěšném ověření se zároveň přenáší odpovědnost za podvodnou transakci z obchodníka na vydavatele karty.
• Adaptive IconAdaptivní ikona je formát ikony aplikace na Androidu, který se místo jedné hotové bitmapy skládá z oddělených vrstev: pozadí a popředí. Systém výsledný tvar sám ořízne podle masky výrobce zařízení a může vrstvy animovat nebo přebarvit. Vývojář tak dodá jeden zdroj a launcher z něj vytvoří kruh, čtverec i squircle.
• AndroidAndroid je operační systém postavený nad linuxovým jádrem, který vyvíjí Google a otevřeně uvolňuje jako projekt AOSP. Android pohání převážnou většinu chytrých telefonů, dále tablety, televize, hodinky i palubní systémy aut. Aplikace se pro něj píší hlavně v Kotlinu nebo Javě a distribuují přes Google Play i alternativní obchody.
• API GatewayAPI Gateway je vstupní vrstva mezi klientem a sadou backendových služeb, která přijímá požadavky, směruje je na správné API, vynucuje bezpečnostní pravidla a často řeší limity, logování nebo transformace odpovědí. Pomáhá skrýt vnitřní strukturu systému a sjednotit chování pro web, mobilní aplikaci i partnery.
• App Store OptimizationApp Store Optimization je soubor postupů pro zlepšení viditelnosti a konverze mobilní aplikace v obchodech jako App Store a Google Play. Pracuje s názvem, klíčovými slovy, popisem, ikonou, screenshoty, hodnocením, lokalizací a testováním, aby správní uživatelé aplikaci našli a po zobrazení detailu také nainstalovali.