Zabezpečení správy hesel v podnikovém bankovnictví: vícealgoritmické hashování a upgrady s hsh

Manažerské shrnutí. Bankovní autentizace postavená proti modelu hrozeb z roku 2018 už není pod regulatorním režimem roku 2026 vhodná k účelu. GPU-akcelerované prolamování, hustota ASIC a blížící se postkvantový horizont zhroutily bezpečnostní rezervu PBKDF2 a raných parametrů scryptu; článek 5 DORA proměnil tento rozklad v odpovědnost před představenstvem. hsh, open-source čistě rustový rámec, řeší problém paralelně ve třech vrstvách: dispatcher verify_and_upgrade, který při každém úspěšném přihlášení přehashuje uložený přihlašovací údaj na aktuální parametry Argon2id bez údržbového okna; vrstva pepperingu propojená s HSM nebo KMS, díky níž samotné prolomení databáze nevynese nic prolomitelného; a paměťově bezpečný dodavatelský řetězec, který eliminuje útočnou plochu rozhraní cizích funkcí (FFI) vlastní C-podporovaným kryptografickým knihovnám. Výsledkem je podloží, které uspokojuje DORA, disciplínu provozního rizika Basel III, odpovědnost vrcholového managementu SM&CR i horizont postkvantové migrace NIST IR 8547 — bez programu hromadného resetu, který byl historicky nutný pro upgrade autentizační infrastruktury.

Většina autentizace v podnikovém bankovnictví stále spočívá na heslové vrstvě vytvrzené proti modelu hrozeb z roku 2018. Hardware, který ji láme, se posunul dál. Jak rostou GPU farmy a kryptograficky relevantní kvantové počítače (CRQC) se přibližují, starší hashování — PBKDF2, raný scrypt — slábne s každou hodinou výpočtů, kterou útočníci stráví na offline crack queue. Rozklad je tichý: nic v produkční databázi vám neřekne, že hash, který byl včera silný, už silný není.

Podle Nařízení o digitální provozní odolnosti (DORA) ponechání nerotovaných starších kryptografických aktiv v produkci už není technický dluh. Je to jmenovitě regulatorní odpovědnost.

hsh tuto mezeru uzavírá. Čistě rustový rámec spravuje více hash formátů vedle sebe a upgraduje slabé přihlašovací údaje za běhu během aktivních přihlašovacích relací. Autentizační infrastruktura odpovídá mandátům odolnosti roku 2026 bez údržbového okna, bez vynuceného resetu, bez jediné sekundy výpadku.

01. Problém kryptografického rozkladu v bankovnictví

Pochopit nezbytnost rámce jako hsh znamená pochopit životní cyklus hashe hesla. Algoritmy nestárnou s grácií; rozpadají se relativně k hardwaru, který je dokáže prolomit.

Mezera v ASIC/GPU akceleraci. Algoritmy jako PBKDF2 byly navrženy jako výpočetně náročné pro CPU. Útočníci dnes používají vysoce paralelizované GPU k provádění offline slovníkových útoků. Starší hash vygenerovaný v roce 2018 je proti soupeři z roku 2026 výrazně slabší.

Riziko big-bang migrace. Když se CISO rozhodne přejít z PBKDF2 na paměťově náročný algoritmus jako Argon2id, hashe nelze obrátit a znovu zašifrovat. Tradiční řešení — vynucené resety hesel u milionů uživatelů — způsobují masivní třenice se zákazníky a provozní riziko.

Dodavatelský řetězec C-knihoven. Bankovní middleware se historicky spoléhal na knihovny jako argonautica nebo přímá C bindingy pro hashování. Tyto knihovny nesou skryté riziko dodavatelského řetězce: jediné přetečení paměťového bufferu v autentizačním modulu může vést ke vzdálenému spuštění kódu (RCE) v nejvíce privilegované vrstvě bankovního stacku.

Srovnání algoritmů — odolnost vůči hardwaru a prostor pro ladění

Tři algoritmy, na které banka v migračním korpusu reálně narazí, se liší méně volbou kryptografické primitivy a více tím, jak stárnou pod tlakem hardwaru. Tabulka níže shrnuje praktickou pozici.

Závěr pro migrační plán je úzký: PBKDF2 je stav verify-side, nikoli destinace write-side. Každé úspěšné přihlášení proti záznamu PBKDF2 by mělo na cestě ven vyprodukovat záznam Argon2id.

02. Architektonická optika hsh 2026

Rámec je strukturován v pěti jádrových vrstvách. Každá je navržena tak, aby zmírnila konkrétní kategorii provozního rizika.

Tabulka 1: Architektonické vrstvy hsh a zmírnění rizika

03. Cesta přehashování bez výpadku

Vzor verify_and_upgrade řeší migraci dat inteligentním, stav vědomým dispatch systémem, který nevyžaduje žádný výpadek databáze.

Když uživatel odešle své přihlašovací údaje, hsh přečte uložený řetězec Password Hashing Competition (PHC). Pokud obsahuje starší hash (např. zastaralou konfiguraci PBKDF2), systém vykoná následující tok:

1. Identifikace: Parsuje starší algoritmus a jeho konkrétní parametry.
2. Verifikace: Validuje kandidátní heslo proti staršímu hashi.
3. Upgrade v reálném čase: Po úspěšné shodě vezme plaintextové kandidátní heslo v paměti a okamžitě vypočítá nový hash pomocí vysoce bezpečné politiky Argon2id.
4. Persistence: Vrací nový PHC řetězec bankovní aplikaci, která přepíše starší záznam v databázi.

Tento proces je zcela transparentní pro koncového uživatele. Účinně migruje nejaktivnější účty do nejvyšší bezpečnostní úrovně už první den a organicky dramaticky zmenšuje útočný povrch banky v čase.

Sekvence níže ukazuje, co se odehrává během jediné přihlašovací události, když je uložený záznam na starším algoritmu. Uživatel nevidí žádnou změnu; autentizační prostředí banky se posiluje o jeden záznam.

sequenceDiagram
    actor User
    participant Frontend
    participant Auth as Authentication Service (hsh)
    participant DB as Database
    User->>Frontend: Submit username + password
    Frontend->>Auth: authenticate(user, password)
    Auth->>DB: SELECT password_hash FROM users
    DB-->>Auth: PHC string (legacy: PBKDF2)
    Note over Auth: Detect legacy algorithm prefix
    Auth->>Auth: verify(password, legacy_hash)
    Note over Auth: Re-hash with Argon2id
    Auth->>DB: UPDATE password_hash = new PHC
    DB-->>Auth: write confirmed
    Auth-->>Frontend: 200 OK
    Frontend-->>User: Login successful

Implementační vzor — dispatch verify_and_upgrade

Integrační plocha uvnitř autentizační služby je malá. Starší kódová cesta zůstává jako fallback; nová kódová cesta je dispatcher.

use hsh::{Hasher, UpgradeResult};

struct UserRecord {
    username: String,
    password_hash: String, // PHC string
}

async fn authenticate(user: UserRecord, password_attempt: &str) -> Result<bool, AuthError> {
    let hasher = Hasher::new();
    match hasher.verify_and_upgrade(password_attempt, &user.password_hash) {
        Ok(UpgradeResult::Verified(is_valid)) => Ok(is_valid),
        Ok(UpgradeResult::Upgraded(new_hash)) => {
            db::update_user_hash(&user.username, new_hash).await?;
            Ok(true)
        }
        Err(_) => Err(AuthError::InvalidCredentials),
    }
}

Záleží na třech vlastnostech:

• Stavová vědomost. verify_and_upgrade zkoumá prefix PHC řetězce. Pokud je marker algoritmu starší, rámec automaticky spustí přehashování proti nakonfigurované politice Argon2id. Žádné větvení ve volajícím kódu.
• Atomicita. Přehashování se odehrává teprve po úspěšné verifikaci starší verze, uvnitř stejné autentizační události. Žádná samostatná dávková úloha, žádné plánované migrační okno a žádná destruktivní hromadná migrace, kterou by bylo nutné vracet zpět.
• Persistence. Varianta UpgradeResult::Upgraded nese nový PHC řetězec. Aplikace jej perzistuje stejnou datovou cestou, jaká už pro starší záznam existuje — žádná paralelní zápisová plocha, žádný dvoufázový zápisový protokol.

Režimy selhání. Pokud během upgrade zápisu selže databáze nebo je KMS krátkodobě nedostupné, relace stále uspěje proti staršímu hashi a záznam zůstane na starém algoritmu. Příští úspěšné přihlášení upgrade zopakuje. Neexistuje žádný napůl migrovaný stav a žádné selhání viditelné pro uživatele — migrace je napříč přihlašovacími událostmi monotónní a cena selhaného upgradu na jeden záznam je přesně jedno opakování při příštím přihlášení.

04. Peppered hashe přes HSM / KMS interlock

Standardní hashování hesel chrání proti přímým únikům databáze. Pokud však útočník získá databázi celou (hashe i soli), může provádět offline prolamování.

hsh zavádí robustní vrstvu „peppered" zabezpečení. Integrací s Hardware Security Moduly (HSM) nebo cloud-native Key Management Services (KMS) je výstup Argon2id kryptograficky zabalen vysoce entropickým klíčem, který nikdy neopouští hranici zabezpečeného hardwaru. Pokud je uživatelská databáze exfiltrována, útočník vlastní pouze zašifrované bloby. Bez prolomení fyzicky izolované HSM infrastruktury banky nemůže začít prolamovat hesla.

Architektonický diagram níže sleduje cestu tajemství. Pepper se nikdy nedostane do databáze; databáze sama o sobě nedrží nic adresovatelného. Obě úložiště mohou selhat nezávisle — systém ztrácí důvěrnost pouze tehdy, selžou-li obě současně.

sequenceDiagram
    participant App as Application Server
    participant HSM as HSM (Hardware Security Module)
    participant DB as Database
    Note over HSM: Pepper sealed in hardware<br/>never exits boundary
    App->>HSM: get_secret("production-password-pepper")
    HSM-->>App: pepper (in-memory, request-scoped)
    Note over App: Argon2::new_with_secret(&pepper, ...)
    App->>App: hash(password + salt) consuming pepper
    Note over App: Pepper consumed via secret param<br/>not via string concat
    App->>DB: STORE PHC string (uncrackable blob)
    Note over App: Pepper dropped from memory
    Note over DB,HSM: DB breach alone yields<br/>nothing crackable

Implementační vzor — HSM-podporovaný peppered Argon2id

Pepper je čerpán z HSM v okamžiku požadavku, nikoli z konfiguračního souboru. Argon2::new_with_secret jej konzumuje prostřednictvím parametru tajemství algoritmu, nikoli řetězcovou konkatenací.

use argon2::{
    Argon2, Algorithm, Version, Params,
    PasswordHasher, PasswordVerifier,
    password_hash::{PasswordHash, SaltString, rand_core::OsRng},
};

async fn authenticate_with_hsm(
    user: UserRecord,
    password_attempt: &str,
) -> Result<bool, AuthError> {
    let pepper = hsm::client::get_secret("production-password-pepper").await?;
    let hasher = Argon2::new_with_secret(
        &pepper,
        Algorithm::Argon2id,
        Version::V0x13,
        Params::default(),
    )
    .map_err(|_| AuthError::Internal)?;

    let parsed = PasswordHash::new(&user.password_hash)
        .map_err(|_| AuthError::InvalidCredentials)?;
    if hasher.verify_password(password_attempt.as_bytes(), &parsed).is_ok() {
        if is_legacy_hash(&user.password_hash) {
            let new_hash = hasher
                .hash_password(
                    password_attempt.as_bytes(),
                    &SaltString::generate(&mut OsRng),
                )
                .map_err(|_| AuthError::Internal)?
                .to_string();
            db::update_user_hash(&user.username, new_hash).await?;
        }
        return Ok(true);
    }
    Err(AuthError::InvalidCredentials)
}

Z tohoto tvaru vyplývají tři důsledky sladěné s DORA:

• Rotace klíčů jako problém správy klíčů. Pepper žije za hranicí HSM/KMS, nikoli v databázi. Rotace se stává změnou ve správě klíčů, nikoli kampaní přehashování napříč uživatelskou základnou. Nové hashe se vážou na aktuální verzi pepperu; staré hashe se verifikují pod svou vázanou verzí, dokud přirozeně neproběhne jejich upgrade.
• Oddělení povinností. Servisní identita, která pepper čte, musí být auditovatelná a s nejmenšími nutnými oprávněními. Plná exfiltrace databáze bez odpovídajícího HSM grantu nepřinese nic prolomitelného. Kompromitace HSM grantu bez databáze nepřinese nic adresovatelného. Dopadový rádius kteréhokoli jednotlivého selhání je ohraničený.
• Eliminace length-extension a konkatenačních chyb. Použití parametru tajemství v Argon2 namísto řetězcové konkatenace odstraňuje z implementační plochy celou třídu kryptografických nástrah — length-extension, špatně typované UTF-8 konkatenace, chyby v pořadí salt/pepper.

05. Regulatorní soulad: DORA, Basel III a SM&CR

• DORA, články 5 a 6: Vyžaduje, aby finanční subjekty udržovaly rámce řízení ICT rizika. Strategie spoléhající na nerotované, deset let staré hashe hesel tyto principy porušuje. hsh poskytuje dokumentovaný, automatizovaný mechanismus pro kontinuální zvyšování kryptografické ochrany.
• Basel III: Spojuje regulatorní kapitál s pravděpodobností a závažností ztrátových událostí. Implementace Argon2id s HSM interlockem dramaticky snižuje závažnost úniku databáze, což podporuje kvantifikovatelné argumenty pro nižší alokaci kapitálu na provozní riziko.
• SM&CR odpovědnost: Schválení architektury, která aktivně sanuje kryptografický rozklad, poskytuje jmenovitým vrcholovým manažerům verifikovatelný a dokumentovatelný řetězec snižování rizika.

Často kladené otázky

Je hsh připraven do produkce pro autentizační cestu tier-1 banky? Knihovna je open-source, dokumentovaná a používá Argon2id přes stejný argon2 crate, který tvoří základ ekosystému hashování hesel RustCrypto. Nasazení v tier-1 prostředí následuje vlastní due-diligence banky: nezávislý code review, atestaci reprodukovatelného buildu, pinning stromu závislostí, integrační testování s dodavatelem HSM a schválení provozního rizika. hsh poskytuje podloží; banka certifikuje nasazení.

Jak verify_and_upgrade eliminuje riziko hromadné migrace? Verifikátor zkoumá PHC řetězec při parsování, spustí starší algoritmus k validaci hesla a — pokud uložený algoritmus nebo sada parametrů jsou pod aktuální úrovní — atomicky přehashuje plaintext pod Argon2id s vázaným HSM pepperem a zapíše nový PHC řetězec zpět. Uživatel zažívá normální přihlášení. Infrastruktura se posiluje o jeden záznam za úspěšnou autentizaci. Žádná resetovací kampaň, žádné údržbové okno, žádná událost provozního rizika.

Co se stane s neaktivními účty, které se nikdy nepřihlásí? Záznamy, které se neautentizují, se nikdy nepřehashují. Banky to řeší dvěma doplňujícími politikami: dokumentovaným prahem nečinnosti (často 18–24 měsíců), po kterém je účet administrativně rotován v rámci řízené resetovací kampaně, a syntetickým přehashováním během plánované údržby pro účty ve vymezených kohortách (vysoká hodnota, vysoké oprávnění, regulované). Obojí jsou politiky, nikoli chování knihovny; hsh zaznamenává rozhodnutí dispatche do auditní telemetrie, aby provozní vlastník mohl prokázat pokrytí.

Nezavádí HSM pepper jediný bod selhání na autentizační cestě? Stejné HSM, které podepisuje platební zprávy a rotuje klíče zálohované KMS, je na cestě. Riziko je shodné s existující pozicí banky; hsh ji dědí, nikoli zavádí. Mitigace jsou standardní: páry HSM v HA, KMS regiony hot-spare, načítání pepperu v rámci požadavku s circuit-breaker fall-back na režim read-only a explicitní provozní runbook pro nedostupnost HSM. Pepper je parametr tajemství argon2, konzumovaný v procesu a odhozený z paměti po použití.

Kde stojí hsh vzhledem k postkvantové migraci? hsh je rámec pro hashování hesel a tajemství, nikoli primitiv pro key-encapsulation nebo podpis. Přechod PQC dokumentovaný v NIST IR 8547 cílí na ustavení klíčů (ML-KEM, FIPS 203) a podpisy (ML-DSA, FIPS 204; SLH-DSA, FIPS 205). Vrstva hashování, kterou hsh pokrývá, je s touto migrací z velké části ortogonální. Obě se sbíhají na úrovni podloží — obě chtějí paměťově bezpečný, auditovatelný, reprodukovatelný kryptografický dodavatelský řetězec — což je přesně pozice, kterou hsh dnes umožňuje.

Závěr

Deploy-and-forget hashování hesel je u konce. DORA posunula kryptografickou pasivitu z technického dluhu do jmenovité regulatorní odpovědnosti a hardwarová křivka je každý rok strmější. Příspěvkem hsh není silnější algoritmus — Argon2id je dostupný roky. Příspěvkem je provozní mechanika, která umožňuje na něj migrovat bez plánování výpadku, bez vynucených resetů uživatelů a bez svěření autentizační cesty banky C-based FFI shimům.

Zdrojový kód hsh je dostupný pod duální licencí MIT a Apache 2.0.

Reference

Basel Committee on Banking Supervision (2011). Basel III: A global regulatory framework for more resilient banks and banking systems. Bank for International Settlements. Dostupné z: https://www.bis.org/publ/bcbs189.pdf

Biryukov, A., Dinu, D., Khovratovich, D., a Josefsson, S. (2021). RFC 9106: Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications. Internet Engineering Task Force. Dostupné z: https://datatracker.ietf.org/doc/html/rfc9106

Evropský parlament a Rada (2022). Nařízení (EU) 2022/2554 o digitální provozní odolnosti finančního sektoru (DORA). Dostupné z: https://eur-lex.europa.eu/eli/reg/2022/2554/oj

Financial Conduct Authority (2015). Senior Managers and Certification Regime (SM&CR). Dostupné z: https://www.fca.org.uk/firms/senior-managers-certification-regime

National Institute of Standards and Technology (2024). Initial Public Draft — Transition to Post-Quantum Cryptography Standards (NIST IR 8547). Dostupné z: https://csrc.nist.gov/pubs/ir/8547/ipd

OWASP Foundation (2024). Password Storage Cheat Sheet. Dostupné z: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

Naposledy revidováno 2026-06-22.

Naposledy revidováno 2026-06-23.

# Zabezpečení správy hesel v podnikovém bankovnictví: vícealgoritmické hashování a upgrady s hsh — Sebastien Rousseau

> Originally published at [https://sebastienrousseau.com/cs/2026-06-22-hsh-zero-downtime-cryptographic-stewardship-rust-banking-2026/](https://sebastienrousseau.com/cs/2026-06-22-hsh-zero-downtime-cryptographic-stewardship-rust-banking-2026/)

hsh je čistě rustový kryptografický rámec, který umožňuje tier-1 bankám migrovat starší hashe hesel na Argon2id bez výpadku, integrovat HSM peppering a odstranit paměťové zranitelnosti C-based FFI — vše v souladu s DORA.

Read the full article on sebastienrousseau.com: https://sebastienrousseau.com/cs/2026-06-22-hsh-zero-downtime-cryptographic-stewardship-rust-banking-2026/

Zabezpečení správy hesel v podnikovém bankovnictví: vícealgoritmické hashování a upgrady s hsh — Sebastien Rousseau

hsh je čistě rustový kryptografický rámec, který umožňuje tier-1 bankám migrovat starší hashe hesel na Argon2id bez výpadku, integrovat HSM peppering a odstranit paměťové zranitelnosti C-based FFI — vše v souladu s DORA.

https://sebastienrousseau.com/cs/2026-06-22-hsh-zero-downtime-cryptographic-stewardship-rust-banking-2026/

Zabezpečení správy hesel v podnikovém bankovnictví: vícealgoritmické hashování a upgrady s hsh — Sebastien Rousseau

hsh je čistě rustový kryptografický rámec, který umožňuje tier-1 bankám migrovat starší hashe hesel na Argon2id bez výpadku, integrovat HSM peppering a odstranit paměťové zranitelnosti C-based FFI - vše v souladu s DORA.

Zde jsou klíčové strategické poznatky:

- 01. Problém kryptografického rozkladu v bankovnictví. Pochopit nezbytnost rámce jako hsh znamená pochopit životní cyklus hashe hesla.
- 02. Architektonická optika hsh 2026. Rámec je strukturován v pěti jádrových vrstvách.
- 03. Cesta přehashování bez výpadku. Vzor verify_and_upgrade řeší migraci dat inteligentním, stav vědomým dispatch systémem, který nevyžaduje žádný výpadek databáze.
- 04. Peppered hashe přes HSM / KMS interlock. Standardní hashování hesel chrání proti přímým únikům databáze.

Jaký je přístup vaší organizace k výzvám popsaným v tomto článku?

→ https://sebastienrousseau.com/cs/2026-06-22-hsh-zero-downtime-cryptographic-stewardship-rust-banking-2026/

#Hsh #RustKryptografie #HashováníHesel #Argon2id #BezpečnostBankovnictví

Sebastien Rousseau | CC-BY-4.0

@online{rousseau2026zabezpečení,
  author  = {Rousseau, Sebastien},
  title   = {{Zabezpečení správy hesel v podnikovém bankovnictví: vícealgoritmické hashování a upgrady s hsh — Sebastien Rousseau}},
  year    = {2026},
  url     = {https://sebastienrousseau.com/cs/2026-06-22-hsh-zero-downtime-cryptographic-stewardship-rust-banking-2026/},
  urldate = {2026}
}

TY  - GEN
AU  - Rousseau, Sebastien
TI  - Zabezpečení správy hesel v podnikovém bankovnictví: vícealgoritmické hashování a upgrady s hsh — Sebastien Rousseau
PY  - 2026
UR  - https://sebastienrousseau.com/cs/2026-06-22-hsh-zero-downtime-cryptographic-stewardship-rust-banking-2026/
ER  -

Rousseau S. Zabezpečení správy hesel v podnikovém bankovnictví: vícealgoritmické hashování a upgrady s hsh — Sebastien Rousseau. sebastienrousseau.com. 2026 Jun 22. Available from: https://sebastienrousseau.com/cs/2026-06-22-hsh-zero-downtime-cryptographic-stewardship-rust-banking-2026/

Rousseau, Sebastien. "Zabezpečení správy hesel v podnikovém bankovnictví: vícealgoritmické hashování a upgrady s hsh — Sebastien Rousseau." sebastienrousseau.com. June 22, 2026. https://sebastienrousseau.com/cs/2026-06-22-hsh-zero-downtime-cryptographic-stewardship-rust-banking-2026/.

Rousseau, S. (2026, June 22). Zabezpečení správy hesel v podnikovém bankovnictví: vícealgoritmické hashování a upgrady s hsh — Sebastien Rousseau. sebastienrousseau.com. https://sebastienrousseau.com/cs/2026-06-22-hsh-zero-downtime-cryptographic-stewardship-rust-banking-2026/

Zabezpečení správy hesel v podnikovém bankovnictví: vícealgoritmické hashování a upgrady s hsh — Sebastien Rousseau

hsh je čistě rustový kryptografický rámec, který umožňuje tier-1 bankám migrovat starší hashe hesel na Argon2id bez výpadku, integrovat HSM peppering a odstranit paměťové zranitelnosti C-based FFI — vše v souladu s DORA.

Originally published at https://sebastienrousseau.com/cs/2026-06-22-hsh-zero-downtime-cryptographic-stewardship-rust-banking-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU · FOUNDER · ENGINEER