Zarządzanie hasłami w bankowości korporacyjnej: wieloalgorytmiczne hashowanie i aktualizacje z hsh

Streszczenie wykonawcze. Bankowe uwierzytelnianie zbudowane pod model zagrożeń z 2018 r. nie nadaje się już do reżimu regulacyjnego 2026 r. Łamanie akcelerowane GPU, gęstość ASIC i zbliżający się horyzont post-kwantowy zawaliły margines bezpieczeństwa PBKDF2 i wczesno-parametrowego scrypta; art. 5 DORA przekuł tę degradację w odpowiedzialność rozliczalną na poziomie zarządu. hsh, open-source'owy framework w czystym Rust, adresuje problem równolegle na trzech warstwach: dyspozytor verify_and_upgrade, który rehashuje przechowywane poświadczenie do bieżących parametrów Argon2id przy każdym pomyślnym logowaniu bez okna serwisowego; warstwa pieprzu z interlockiem HSM lub KMS, dzięki której samo naruszenie bazy danych nie daje niczego do złamania; oraz bezpieczny pod względem pamięci łańcuch dostaw, który eliminuje powierzchnię ataku przez FFI wpisaną w biblioteki kryptograficzne oparte na C. Rezultatem jest substrat spełniający DORA, dyscyplinę ryzyka operacyjnego Basel III, rozliczalność senior managerów SM&CR oraz horyzont migracji post-kwantowej NIST IR 8547 — bez kampanii masowego resetu historycznie wymaganej do aktualizacji bazy uwierzytelniania.

Większość systemów uwierzytelniania w bankowości korporacyjnej wciąż opiera się na warstwie haseł utwardzonej pod model zagrożeń z 2018 r. Sprzęt, który ją łamie, poszedł dalej. W miarę jak farmy GPU rosną, a kryptograficznie istotne komputery kwantowe (CRQC) się zbliżają, starsze hashowanie — PBKDF2, wczesny scrypt — degraduje się z każdą godziną mocy obliczeniowej, którą atakujący poświęcają na kolejkę offline'owego łamania. Degradacja jest cicha: nic w produkcyjnej bazie danych nie powie Państwu, że hash, który był silny wczoraj, dziś już nie jest.

Zgodnie z Digital Operational Resilience Act (DORA) pozostawianie nierotowanych, starszych aktywów kryptograficznych na produkcji to już nie dług techniczny. To wymieniona z nazwy odpowiedzialność regulacyjna.

hsh zamyka tę lukę. Framework w czystym Rust zarządza wieloma formatami hashy równolegle i aktualizuje słabe poświadczenia w locie podczas aktywnych sesji logowania. Infrastruktura uwierzytelniania dostosowuje się do mandatów odporności 2026 r. bez okna serwisowego, bez wymuszonego resetu, bez ani jednej sekundy przestoju.

01. Problem degradacji kryptografii w bankowości

Aby zrozumieć konieczność frameworka takiego jak hsh, trzeba zrozumieć cykl życia hasha haseł. Algorytmy nie starzeją się z gracją; degradują się względem sprzętu dostępnego do ich łamania.

Luka akceleracji ASIC/GPU. Algorytmy takie jak PBKDF2 zostały zaprojektowane tak, by były kosztowne obliczeniowo dla CPU. Dziś atakujący używają wysoce zrównoleglonych GPU do wykonywania offline'owych ataków słownikowych. Starszy hash wygenerowany w 2018 r. jest drastycznie słabszy wobec przeciwnika z 2026 r.

Ryzyko migracji big-bang. Gdy CISO decyduje o aktualizacji z PBKDF2 do algorytmu memory-hard takiego jak Argon2id, nie może odwrócić hashy, by je ponownie zaszyfrować. Tradycyjne rozwiązania — wymuszanie resetu haseł u wielomilionowej bazy użytkowników — powodują masowe tarcie po stronie klienta i ryzyko operacyjne.

Łańcuch dostaw bibliotek C. Historycznie middleware bankowy opierał się na bibliotekach takich jak argonautica lub surowych bindingach C do hashowania. Te biblioteki niosą ukryte ryzyko łańcucha dostaw: pojedyncze przepełnienie bufora w module uwierzytelniania może prowadzić do zdalnego wykonania kodu (RCE) na najbardziej uprzywilejowanej warstwie stosu bankowego.

Porównanie algorytmów — odporność sprzętowa i powierzchnia strojenia

Trzy algorytmy, z którymi bank realistycznie spotka się w korpusie migracyjnym, różnią się mniej wyborem prymitywu kryptograficznego, a bardziej tym, jak starzeją się pod presją sprzętową. Tabela poniżej podsumowuje praktyczną postawę.

Wniosek dla planu migracji jest wąski: PBKDF2 to stan po stronie weryfikacji, nie cel po stronie zapisu. Każde pomyślne logowanie na rekordzie PBKDF2 powinno wyprodukować rekord Argon2id w drodze wyjścia.

02. Soczewka architektoniczna hsh 2026

Framework jest ustrukturyzowany na pięciu warstwach rdzeniowych, z których każda została zaprojektowana, by zmitygować konkretną kategorię ryzyka operacyjnego.

Tabela 1: Warstwy architektoniczne hsh i mitygacja ryzyka

03. Ścieżka rehashowania bez przestojów

Wzorzec verify_and_upgrade rozwiązuje migrację danych przez inteligentny, świadomy stanu system dyspozycji, który nie wymaga żadnego przestoju bazy danych.

Gdy użytkownik przesyła swoje poświadczenia, hsh odczytuje przechowywany ciąg Password Hashing Competition (PHC). Jeśli zawiera starszy hash (np. nieaktualną konfigurację PBKDF2), system wykonuje następujący przepływ:

1. Identyfikacja: Parsuje starszy algorytm i jego konkretne parametry.
2. Weryfikacja: Waliduje hasło kandydata wobec starszego hasha.
3. Aktualizacja w czasie rzeczywistym: Po pomyślnym dopasowaniu bierze otwartotekstowe hasło kandydata w pamięci i natychmiast wylicza nowy hash przy użyciu wysoce bezpiecznej polityki Argon2id.
4. Utrwalenie: Zwraca nowy ciąg PHC do aplikacji bankowej, która nadpisuje starszy rekord w bazie danych.

Ten proces jest całkowicie przezroczysty dla użytkownika końcowego. Skutecznie migruje najaktywniejsze konta do najwyższego poziomu bezpieczeństwa pierwszego dnia, drastycznie ograniczając powierzchnię ataku banku organicznie w czasie.

Sekwencja poniżej pokazuje, co dzieje się podczas pojedynczego zdarzenia logowania, gdy przechowywany rekord opiera się na starszym algorytmie. Użytkownik nie widzi żadnej zmiany; baza uwierzytelniania banku wzmacnia się o jeden rekord.

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

Wzorzec implementacji — dyspozycja verify_and_upgrade

Powierzchnia integracji wewnątrz serwisu uwierzytelniania jest mała. Starsza ścieżka kodu pozostaje jako rezerwa; nowa ścieżka kodu to dyspozytor.

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),
    }
}

Trzy właściwości mają znaczenie:

• Świadomość stanu. verify_and_upgrade inspekcjonuje prefiks ciągu PHC. Jeśli marker algorytmu jest starszy, framework automatycznie wyzwala rehash wobec skonfigurowanej polityki Argon2id. Żadnych rozgałęzień w kodzie wywołującym.
• Atomowość. Rehashowanie zachodzi dopiero po pomyślnej weryfikacji starszego hasha, w tym samym zdarzeniu uwierzytelnienia. Nie ma osobnego zadania wsadowego, nie ma zaplanowanego okna migracji ani destrukcyjnej masowej migracji do wycofania.
• Utrwalenie. Wariant UpgradeResult::Upgraded niesie nowy ciąg PHC. Aplikacja utrwala go tą samą ścieżką danych, która już istnieje dla starszego rekordu — żadnej równoległej powierzchni zapisu, żadnego dwufazowego protokołu zapisu.

Tryby awarii. Jeśli zapis do bazy danych nie powiedzie się lub KMS jest chwilowo nieosiągalny podczas zapisu aktualizacji, sesja nadal kończy się sukcesem na starszym hashu, a rekord pozostaje na starym algorytmie. Następne pomyślne logowanie ponawia aktualizację. Nie ma stanu częściowej migracji ani widocznej dla użytkownika awarii — migracja jest monotoniczna w poprzek zdarzeń logowania, a koszt nieudanej aktualizacji na rekord to dokładnie jedna dodatkowa próba przy następnym logowaniu.

04. Hashe z pieprzem przez interlock HSM / KMS

Standardowe hashowanie haseł chroni przed bezpośrednimi wyciekami bazy danych, ale jeśli atakujący zdobędzie zarówno bazę danych (hashe i sole), może wykonać łamanie offline.

hsh wprowadza solidną warstwę bezpieczeństwa „z pieprzem". Integrując się z Hardware Security Modules (HSM) lub natywnymi chmurowo usługami zarządzania kluczami (KMS), końcowy wynik Argon2id jest kryptograficznie opakowany kluczem o wysokiej entropii, który nigdy nie opuszcza granicy bezpiecznego sprzętu. Jeśli baza danych użytkowników zostanie wyeksfiltrowana, atakujący posiada wyłącznie zaszyfrowane bloby. Nie może rozpocząć łamania haseł bez równoległego naruszenia fizycznie wyizolowanej infrastruktury HSM banku.

Diagram architektury poniżej śledzi ścieżkę sekretu. Pieprz nigdy nie ląduje w bazie danych; baza danych nigdy nie przechowuje niczego adresowalnego samodzielnie. Oba magazyny mogą zawieść niezależnie — system traci poufność wyłącznie wtedy, gdy oba zawiodą jednocześnie.

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

Wzorzec implementacji — Argon2id z pieprzem wspieranym przez HSM

Pieprz jest pozyskiwany z HSM w czasie żądania, a nie z pliku konfiguracyjnego. Argon2::new_with_secret konsumuje go przez parametr sekretu algorytmu, a nie poprzez konkatenację łańcuchów.

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)
}

Trzy konsekwencje dopasowane do DORA wynikają z tego kształtu:

• Rotacja kluczy jako problem zarządzania kluczami. Pieprz żyje za granicą HSM/KMS, a nie w bazie danych. Rotacja staje się zmianą w zarządzaniu kluczami, a nie kampanią rehashowania w poprzek bazy użytkowników. Nowe hashe wiążą się z bieżącą wersją pieprzu; stare hashe weryfikują się pod swoją związaną wersją, dopóki nie zaktualizują się naturalnie.
• Separacja obowiązków. Tożsamość serwisowa, która odczytuje pieprz, musi być audytowalna i działać z najmniejszymi uprawnieniami. Pełna eksfiltracja bazy danych bez odpowiadającego nadania HSM nie daje niczego do złamania. Kompromitacja nadania HSM bez bazy danych nie daje niczego do zaadresowania. Promień rażenia każdej pojedynczej awarii jest ograniczony.
• Unikanie błędów length extension i konkatenacji. Użycie parametru sekretu Argon2 zamiast konkatenacji łańcuchów usuwa z powierzchni implementacyjnej całą klasę kryptograficznych pułapek — length-extension, błędnie typowaną konkatenację UTF-8, błędy kolejności sól/pieprz.

05. Dopasowanie regulacyjne: DORA, Basel III i SM&CR

• DORA art. 5 i 6: Wymaga od podmiotów finansowych utrzymywania frameworków zarządzania ryzykiem ICT. Strategia opierająca się na nierotowanych, dziesięcioletnich hashach haseł narusza te zasady. hsh zapewnia udokumentowany, automatyczny mechanizm ciągłego podnoszenia ochrony kryptograficznej.
• Basel III: Łączy kapitał regulacyjny z prawdopodobieństwem i dotkliwością zdarzeń strat. Implementując Argon2id z interlockiem HSM, dotkliwość naruszenia bazy danych jest drastycznie zredukowana, wspierając kwantyfikowalne argumenty za niższą alokacją kapitału na ryzyko operacyjne.
• Odpowiedzialność SM&CR: Zatwierdzenie architektury aktywnie naprawiającej degradację kryptografii zapewnia wymienionym z nazwy senior managerom weryfikowalny, udokumentowany łańcuch redukcji ryzyka.

Najczęściej zadawane pytania

Czy hsh jest gotowy produkcyjnie dla ścieżki uwierzytelniania w banku tier-1? Biblioteka jest open-source, udokumentowana i wykorzystuje Argon2id przez tę samą skrzynkę argon2, która stanowi podstawę ekosystemu hashowania haseł RustCrypto. Adopcja tier-1 podlega własnej due-diligence banku: niezależnemu przeglądowi kodu, atestacji powtarzalnych buildów, przypięciu drzewa zależności, testom integracyjnym dostawcy HSM oraz akceptacji ryzyka operacyjnego. hsh zapewnia substrat; bank certyfikuje wdrożenie.

Jak verify_and_upgrade unika ryzyka migracji masowej? Weryfikator inspekcjonuje ciąg PHC w czasie parsowania, uruchamia starszy algorytm do walidacji hasła i — jeśli przechowywany algorytm lub zestaw parametrów jest poniżej bieżącego poziomu — rehashuje otwarty tekst pod Argon2id z powiązanym pieprzem HSM i zapisuje nowy ciąg PHC atomowo. Użytkownik doświadcza normalnego logowania. Baza wzmacnia się o jeden rekord na każde pomyślne uwierzytelnienie. Bez kampanii resetu, bez okna serwisowego, bez zdarzenia ryzyka operacyjnego.

Co dzieje się z kontami uśpionymi, które nigdy się nie logują? Rekordy, które nigdy się nie uwierzytelniają, nigdy się nie rehashują. Banki adresują to dwiema komplementarnymi politykami: udokumentowanym progiem uśpienia (często 18–24 miesiące), po którym konto jest administracyjnie rotowane w ramach kontrolowanej kampanii resetu, oraz syntetycznym uruchomieniem rehashowania podczas zaplanowanej konserwacji dla kont w zdefiniowanych kohortach (wysokiej wartości, wysokich uprawnień, regulowanych). Obie to polityki, a nie zachowania biblioteki; hsh zapisuje decyzję dyspozycji w telemetrii audytowej, by właściciel operacyjny mógł udowodnić pokrycie.

Czy pieprz HSM wprowadza pojedynczy punkt awarii na ścieżce uwierzytelniania? Ten sam HSM, który podpisuje wiadomości płatnicze i rotuje klucze wspierane przez KMS, jest na ścieżce. Ryzyko jest identyczne z istniejącą postawą banku; hsh je dziedziczy, a nie wprowadza. Mitygacje są standardowe: pary HSM w HA, regiony KMS w trybie hot-spare, pobieranie pieprzu w zasięgu żądania z circuit-breakerem do trybu tylko-do-odczytu oraz jawny runbook operacyjny dla niedostępności HSM. Pieprz to parametr sekretu argon2, konsumowany w procesie i porzucany z pamięci po użyciu.

Gdzie hsh plasuje się względem migracji post-kwantowej? hsh to framework hashowania haseł i sekretów, a nie prymityw enkapsulacji kluczy ani sygnatur. Przejście PQC udokumentowane w NIST IR 8547 celuje w ustanawianie kluczy (ML-KEM, FIPS 203) i sygnatury (ML-DSA, FIPS 204; SLH-DSA, FIPS 205). Warstwa hashowania, którą pokrywa hsh, jest w dużej mierze ortogonalna do tej migracji. Obie zbiegają się na poziomie substratu — obie chcą bezpiecznego dla pamięci, audytowalnego, powtarzalnego w buildach łańcucha dostaw kryptografii — co jest dokładnie postawą, którą hsh umożliwia już dziś.

Wnioski

Hashowanie haseł w trybie wdróż-i-zapomnij się skończyło. DORA przeniosła kryptograficzną pasywność z długu technicznego do wymienionej z nazwy odpowiedzialności regulacyjnej, a krzywa sprzętowa robi się stromsza z każdym rokiem. Wkład hsh to nie silniejszy algorytm — Argon2id jest dostępny od lat. Wkład to maszyneria operacyjna umożliwiająca migrację do niego bez planowania przestoju, bez wymuszania resetu użytkowników i bez powierzania ścieżki uwierzytelniania banku shimom FFI w C.

Kod źródłowy hsh jest dostępny na podwójnej licencji MIT i Apache 2.0.

Bibliografia

Bazylejski Komitet Nadzoru Bankowego (2011). Basel III: A global regulatory framework for more resilient banks and banking systems. Bank Rozrachunków Międzynarodowych. Dostępne pod adresem: https://www.bis.org/publ/bcbs189.pdf

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

Parlament Europejski i Rada (2022). Rozporządzenie (UE) 2022/2554 w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA). Dostępne pod adresem: https://eur-lex.europa.eu/eli/reg/2022/2554/oj

Financial Conduct Authority (2015). Senior Managers and Certification Regime (SM&CR). Dostępne pod adresem: https://www.fca.org.uk/firms/senior-managers-certification-regime

Narodowy Instytut Standardów i Technologii (2024). Initial Public Draft — Transition to Post-Quantum Cryptography Standards (NIST IR 8547). Dostępne pod adresem: https://csrc.nist.gov/pubs/ir/8547/ipd

OWASP Foundation (2024). Password Storage Cheat Sheet. Dostępne pod adresem: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

Ostatni przegląd 2026-06-22.

Ostatnia weryfikacja 2026-06-23.

# Zarządzanie hasłami w bankowości korporacyjnej: wieloalgorytmiczne hashowanie i aktualizacje z hsh — Sebastien Rousseau

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

hsh to framework kryptograficzny napisany w czystym Rust, umożliwiający bankom tier-1 migrację starszych hashy haseł do Argon2id bez przestojów, z pieprzeniem HSM i bez podatności pamięciowych FFI w C, zgodnie z DORA.

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

Zarządzanie hasłami w bankowości korporacyjnej: wieloalgorytmiczne hashowanie i aktualizacje z hsh — Sebastien Rousseau

hsh to framework kryptograficzny napisany w czystym Rust, umożliwiający bankom tier-1 migrację starszych hashy haseł do Argon2id bez przestojów, z pieprzeniem HSM i bez podatności pamięciowych FFI w C, zgodnie z DORA.

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

Zarządzanie hasłami w bankowości korporacyjnej: wieloalgorytmiczne hashowanie i aktualizacje z hsh — Sebastien Rousseau

hsh to framework kryptograficzny napisany w czystym Rust, umożliwiający bankom tier-1 migrację starszych hashy haseł do Argon2id bez przestojów, z pieprzeniem HSM i bez podatności pamięciowych FFI w C, zgodnie z DORA.

Oto kluczowe strategiczne wnioski:

- 01. Problem degradacji kryptografii w bankowości. Aby zrozumieć konieczność frameworka takiego jak hsh, trzeba zrozumieć cykl życia hasha haseł.
- 02. Soczewka architektoniczna hsh 2026. Framework jest ustrukturyzowany na pięciu warstwach rdzeniowych, z których każda została zaprojektowana, by zmitygować konkretną kategorię ryzyka operacyjnego.
- 03. Ścieżka rehashowania bez przestojów. Wzorzec verify_and_upgrade rozwiązuje migrację danych przez inteligentny, świadomy stanu system dyspozycji, który nie wymaga żadnego przestoju bazy danych.
- 04. Hashe z pieprzem przez interlock HSM / KMS. Standardowe hashowanie haseł chroni przed bezpośrednimi wyciekami bazy danych, ale jeśli atakujący zdobędzie zarówno bazę danych (hashe i sole), może wykonać łamanie offline.

Jakie jest podejście Twojej organizacji do wyzwań opisanych w tym artykule?

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

#Hsh #KryptografiaRust #HashowanieHaseł #Argon2id #BezpieczeństwoBankowości

Sebastien Rousseau | CC-BY-4.0

@online{rousseau2026zarządzanie,
  author  = {Rousseau, Sebastien},
  title   = {{Zarządzanie hasłami w bankowości korporacyjnej: wieloalgorytmiczne hashowanie i aktualizacje z hsh — Sebastien Rousseau}},
  year    = {2026},
  url     = {https://sebastienrousseau.com/pl/2026-06-22-hsh-zero-downtime-cryptographic-stewardship-rust-banking-2026/},
  urldate = {2026}
}

TY  - GEN
AU  - Rousseau, Sebastien
TI  - Zarządzanie hasłami w bankowości korporacyjnej: wieloalgorytmiczne hashowanie i aktualizacje z hsh — Sebastien Rousseau
PY  - 2026
UR  - https://sebastienrousseau.com/pl/2026-06-22-hsh-zero-downtime-cryptographic-stewardship-rust-banking-2026/
ER  -

Rousseau S. Zarządzanie hasłami w bankowości korporacyjnej: wieloalgorytmiczne hashowanie i aktualizacje z hsh — Sebastien Rousseau. sebastienrousseau.com. 2026 Jun 22. Available from: https://sebastienrousseau.com/pl/2026-06-22-hsh-zero-downtime-cryptographic-stewardship-rust-banking-2026/

Rousseau, Sebastien. "Zarządzanie hasłami w bankowości korporacyjnej: wieloalgorytmiczne hashowanie i aktualizacje z hsh — Sebastien Rousseau." sebastienrousseau.com. June 22, 2026. https://sebastienrousseau.com/pl/2026-06-22-hsh-zero-downtime-cryptographic-stewardship-rust-banking-2026/.

Rousseau, S. (2026, June 22). Zarządzanie hasłami w bankowości korporacyjnej: wieloalgorytmiczne hashowanie i aktualizacje z hsh — Sebastien Rousseau. sebastienrousseau.com. https://sebastienrousseau.com/pl/2026-06-22-hsh-zero-downtime-cryptographic-stewardship-rust-banking-2026/

Zarządzanie hasłami w bankowości korporacyjnej: wieloalgorytmiczne hashowanie i aktualizacje z hsh — Sebastien Rousseau

hsh to framework kryptograficzny napisany w czystym Rust, umożliwiający bankom tier-1 migrację starszych hashy haseł do Argon2id bez przestojów, z pieprzeniem HSM i bez podatności pamięciowych FFI w C, zgodnie z DORA.

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

SEBASTIEN ROUSSEAU · FOUNDER · ENGINEER