Biometrické přihlášení: Face ID a otisk, které opravdu chrání účet

01Určete, co má biometrie chránit

Rozlišujte tři účely. Lokální zámek brání otevření už přihlášené aplikace na konkrétním zařízení. Přihlášení ověřuje účet vůči službě. Dodatečné ověření před citlivým úkonem potvrzuje, že danou operaci může nyní provést oprávněný uživatel. Jedno tlačítko může spustit více kroků, jejich pravidla ale nejsou totožná.

U zákaznického portálu může biometrie usnadnit návrat do platné relace. U aplikace, která mění číslo účtu pro výplatu peněz, nestačí znovu zobrazit stejnou obrazovku. Zapište, jak se ověří čerstvost přihlášení, oprávnění i konkrétní změna. Požadavky vybírejte podle rizika operace, ne podle dostupnosti senzoru.

Zodpovědnost rozdělte mezi aplikaci, backend a provozní podporu. Pokud každou část dodává jiný tým, určete také společné přejímací testy. Samostatně funkční biometrický dialog ještě neprokazuje bezpečný přístup k účtu.

02Používejte systémovou biometrii, nikoli vlastní rozpoznávání obličeje

Apple umožňuje aplikacím vyžádat ověření prostřednictvím systémových rozhraní. Aplikace se dozví výsledek, nemá přístup k uloženým údajům Face ID nebo Touch ID. Systém umí také podmínit vydání chráněné položky z klíčenky nebo použití klíče úspěšným ověřením. Tyto možnosti popisuje Apple Platform Security.

Fotografie pořízená přední kamerou a odeslaná vlastnímu serveru je jiný návrh. Nelze ji vydávat za Face ID jen proto, že se uživatel také dívá do telefonu. Mění se bezpečnostní model, práce s osobními údaji i odpovědnost za rozpoznávání.

Na Androidu použijte systémový BiometricPrompt a předem zjistěte dostupnost podporované metody. Dokumentace Androidu rozlišuje povolené typy ověření včetně silné biometrie a přihlašovacího údaje zařízení. Kombinace dostupných možností závisejí také na verzi systému. Požadovanou úroveň proto ověřujte, samotná přítomnost senzoru není specifikace.

Pro uživatele popište účel žádosti běžnou větou, například „Ověřte se pro otevření zákaznického účtu“. Po zrušení dialogu ponechte bezpečný stav a srozumitelnou možnost pokračovat jinou schválenou cestou. Neustálé opakování výzvy zvyšuje frustraci a komplikuje přístup lidem, kterým senzor nefunguje spolehlivě.

03Propojte lokální ověření s chráněným klíčem

Slabá implementace uloží do běžné paměti příznak „ověřeno“ a podle něj povolí další obrazovku. Lepší návrh váže ověření na použití chráněného přihlašovacího prostředku nebo na přístup k tajemství, které aplikace skutečně potřebuje. Konkrétní vazbu musí vývojář popsat i otestovat.

Android Keystore umožňuje stanovit podmínky použití klíče. Hardwarová ochrana závisí na zařízení a podporovaných vlastnostech; StrongBox není dostupný všude. Vyžadujete-li určitou úroveň, musí ji aplikace ověřit a mít stanovené chování pro zařízení, které ji nesplňuje.

• Tajné tokeny a klíče neukládejte do běžných nastavení aplikace ani do diagnostických výpisů.
• Dohodněte pravidla po odhlášení, změně účtu a zrušení zařízení.
• Určete, zda přidání nové biometrie vyžaduje nové navázání účtu. Chování závisí na platformě a konfiguraci.
• Otestujte návrat aplikace z pozadí i situaci, kdy relace mezitím skončila.

Vývojář by měl umět ukázat, která operace s klíčem byla po ověření povolena a která bez něj selže. To je užitečnější přejímací důkaz než video hladkého přihlášení na jednom telefonu. Další související oblasti rozebírá přehled bezpečnosti mobilní aplikace.

04Passkey není otisk prstu a server nesmí věřit samotnému výsledku dialogu

Passkey používá kryptografický přihlašovací prostředek. Biometrie může lokálně povolit jeho použití, ale ověření může proběhnout i jinou podporovanou cestou, například PINem zařízení. WebAuthn popisuje biometrické ověření uvnitř autentizátoru; biometrické údaje se nepředávají službě, která přihlášení ověřuje. Neztotožňujte tedy passkey s Face ID.

Při přihlášení musí backend ověřit přijatý důkaz. Postup Googlu pro serverové ověření passkeys zahrnuje kontrolu výzvy, podpisu, očekávaného origin a RP ID i požadovaného ověření uživatele. Výzvu nelze opakovaně přijímat. Teprve úspěšná kontrola opravňuje server vytvořit přihlášenou relaci.

Pro zadavatele to znamená konkrétní otázku: co server dostane a jak pozná, že odpověď patří k tomuto pokusu o přihlášení a této službě? Odpověď „mobil nám pošle úspěch“ je nedostatečná. U vlastní mobilní autentizace má tým předložit stejně jasný návrh, i když nepoužívá právě WebAuthn.

05Náhradní přístup navrhněte před spuštěním

Otisk nemusí fungovat, uživatel nemusí mít biometrii nastavenou a zařízení může po určité situaci vyžadovat svůj přihlašovací údaj. Náhradní cesta patří do běžného návrhu. Nemá vzniknout až jako improvizace podpory při první reklamaci.

Odlište lokální PIN zařízení od hesla k účtu a od obnovy přístupu. Každý z těchto prostředků ověřuje něco jiného. U citlivé aplikace stanovte, které varianty jsou povolené a zda má konkrétní operace vyžadovat silnější či čerstvější ověření. Univerzální tvrzení, že každý PIN je slabý nebo každé heslo dostačující, nepomůže.

Nový telefon připojujte až po ověření existujícího účtu schváleným postupem. Uživatel má mít přehled svých přihlašovacích prostředků a možnost zrušit nepotřebný přístup. Ztráta zařízení musí spustit postup, který řeší také platné relace; pouhé odstranění názvu telefonu ze seznamu není přejímací kritérium.

Pozor na sdílené zařízení. Systémová biometrie ověřuje vůči údajům zaregistrovaným v zařízení. Výsledek sám o sobě neříká, který konkrétní člověk z firemního seznamu právě pracuje. Pro společný tablet na recepci proto navrhněte oddělené účty a přepínání uživatelů, místo automatického připsání všech úkonů jednomu zaměstnanci.

06GDPR posuzujte podle skutečného toku dat

Nejdříve zakreslete, co aplikace a server skutečně zpracovávají. Použití systémové biometrie bez přístupu aplikace k biometrickým údajům se liší od vlastní databáze šablon obličejů nebo otisků. Z toho ale neplyne, že celá služba žádné osobní údaje nezpracovává. Účty, identifikátory přihlašovacích prostředků a záznamy o přístupech mohou dál patřit konkrétním osobám.

Kontrola ÚOOÚ u logistické společnosti ukazuje, proč nestačí prohlásit biometrickou šablonu za anonymní. Úřad ji v docházkovém systému posoudil jako biometrický údaj podle GDPR. Přestože firma používala výslovný souhlas a nabízela alternativy, kontrola konstatovala porušení minimalizace, protože údaje nebyly pro evidenci docházky nezbytné.

Tento závěr nepřenášejte automaticky na každou aplikaci s Touch ID. Je důvodem rozlišovat účel, roli správce, nezbytnost a skutečné údaje. Pokud chcete vlastní biometrickou identifikaci, nechte před implementací posoudit podmínky zpracování zvláštní kategorie údajů a potřebu dalších opatření. Souhlas není univerzální zkratka k libovolnému návrhu.

Do přístupových logů zapisujte jen potřebné události, omezte jejich dostupnost a stanovte dobu uchování. Fotografie, tajné tokeny ani kopie citlivých odpovědí do nich nepatří. Popis ochrany osobních údajů slaďte s reálným chováním aplikace a zapojených služeb.

07Testujte selhání, změny účtu i zrušený přístup

Před převzetím si vyžádejte testovací scénáře pro iOS a podporované verze Androidu. Nestačí jeden úspěšný pokus na vývojářově telefonu. Každý scénář má určit výchozí stav, očekávanou odpověď aplikace a kontrolu backendu.

1. Telefon bez podpory biometrie nebo bez zaregistrovaného otisku nabídne schválenou alternativu.
2. Uživatel zruší výzvu nebo dojde k dočasnému zablokování; aplikace neotevře chráněné údaje.
3. Relace vyprší nebo je zrušena na serveru; lokální ověření samo neobnoví neoprávněný přístup.
4. Po odhlášení a přihlášení jiného účtu se nepoužije tajemství předchozího uživatele.
5. Po změně biometrického nastavení se ověří chování klíče podle dohodnuté konfigurace.
6. Ztracený telefon a obnova účtu vedou ke kontrolovanému zrušení starého přístupu.
7. Opakovaná nebo neplatná odpověď přihlášení neprojde serverovou kontrolou.

Doplňte testy výpadku sítě a návratu z pozadí. Offline přístup k lokálním údajům může být záměrná funkce, musí však mít vlastní pravidla a ochranu. Pokud aplikace zobrazuje starší data, uživatel to má poznat. Backend a oprávnění ověřujte také podle přehledu bezpečnosti webové aplikace před spuštěním.

08Co dát do zadání a přejímky

Sepište seznam chráněných operací, podporovaných zařízení a dostupných alternativ. Přiložte tok registrace přihlašovacího prostředku, běžného přihlášení, obnovy i odhlášení. U každého kroku určete, co kontroluje telefon a co server.

Dodavatel má doložit uložení klíčů, vazbu na účet, pravidla relace a ověřené chování při selhání. Provozní tým potřebuje postup obnovy, možnost zrušit přístup a potřebné auditní události. U citlivých aplikací domluvte odbornou bezpečnostní kontrolu přiměřenou riziku.

Po spuštění sledujte podíl neúspěšných pokusů, důvody odmítnutí a požadavky na obnovu. Rozlišujte technickou chybu od zrušení uživatelem. Zlepšování pohodlí má vycházet z těchto konkrétních překážek, aniž by se bez rozmyslu oslabovala kontrola přístupu.

09Časté otázky k Face ID a otisku v aplikaci