Secret Key
System awaryjnego dostępu

Secret Key

Self-hosted Shamir SSS bcrypt 2FA SMS Zero SQL

Wielowarstwowy system ochrony bazy haseł zaprojektowany tak, aby w sytuacji kryzysowej wyznaczone osoby mogły bezpiecznie przejąć kontrolę nad kontami cyfrowymi właściciela przy jednoczesnej ochronie przed nieautoryzowanym dostępem za jego życia.

Zobacz Demo GitHub — wkrótce
Przewiń
01 / Idea

Czym jest Secret Key?

Każdy z nas przechowuje dziesiątki haseł — do banków, mediów społecznościowych, poczty, subskrypcji. Co się z nimi stanie po naszej śmierci? Rodzina zostaje odcięta od kont, nie może anulować subskrypcji, zamknąć kont, odzyskać pieniędzy.

Secret Key rozwiązuje ten problem, tworząc bezpieczny plan awaryjny: główne hasło do bazy haseł jest podzielone kryptograficznie między wyznaczone, zaufane osoby. Żadna z nich nie zna hasła samodzielnie — dopiero wspólnie, w uzgodnionym momencie, mogą je odtworzyć.

System chroni właściciela za życia — każda próba dostępu wymaga weryfikacji SMS, a sam sekret nigdzie nie jest zapisany w całości. Dostęp bez wiedzy właściciela jest niemożliwy.

02 / Jak działa

Krok po kroku

W sytuacji kryzysowej wyznaczone osoby wykonują cztery kroki — od zebrania się, przez logowanie, po uzyskanie dostępu do bazy haseł.

01
Zebranie min. 3 osób
Każda wyznaczona osoba posiada kartę Secret Key z unikalnym fragmentem klucza. Żaden pojedynczy fragment nie ujawnia sekretu — dopiero 3 z 5 kart łącznie pozwalają bezpiecznie odtworzyć hasło główne do bazy haseł.
Algorytm Shamira — matematycznie niemożliwe odtworzenie sekretu z mniejszej liczby udziałów.
Shamir SSS
02
Logowanie z karty
Każda osoba loguje się danymi z karty Secret Key na własnej instancji systemu. Po poprawnym haśle system wysyła kod SMS na numer przypisany do konta — zabezpieczenie przed użyciem skradzionej karty przez osobę nieuprawnioną.
Bez telefonu przypisanego do konta — logowanie niemożliwe, nawet przy znajomości danych z karty.
2FA SMS
03
Kody do panelu
W panelu odszyfrowania każda osoba wpisuje swój kod Secret Key z karty lub skanuje kod QR telefonem. Po wprowadzeniu wymaganej liczby udziałów hasło główne zostaje automatycznie odszyfrowane lokalnie w przeglądarce.
Kod QR zawiera dokładnie ten sam udział co ciąg znaków — skanowanie eliminuje błędy przepisywania.
hex share
04
Dostęp do bazy haseł
Odtworzone hasło główne odblokowuje zaszyfrowaną bazę haseł właściciela — niezależnie od używanego menedżera haseł. Bazę można opcjonalnie wzmocnić dodatkowym kluczem sprzętowym USB lub plikiem klucza.
Kompatybilny z każdym menedżerem haseł — KeePassXC, Bitwarden, 1Password i innymi obsługującymi hasło główne.
dowolny menedżer
03 / Nośnik udziałów

Dowolny format przekazania

Wygenerowane udziały można przekazać wybranym osobom w dowolnej formie — wydruk na kartce, plik PDF lub autorska karta plastikowa. Niezależnie od formatu, każdy nośnik powinien zawierać te same cztery elementy.

Karta Secret Key — przód
Karta Secret Key — tył
🔑
Login i hasło
Unikalne dane dostępowe — każda wyznaczona osoba otrzymuje własne konto z przypisanym numerem telefonu do 2FA.
🔢
Udział Shamira
Fragment klucza hex — jeden z pięciu udziałów Shamira. Bez wymaganej liczby pozostałych fragmentów jest całkowicie bezużyteczny.
Kod QR
Opcjonalnie — ten sam udział zakodowany jako QR. Skanowanie telefonem eliminuje błędy ręcznego przepisywania.
🌐
Adres systemu
Adres własnej instancji systemu Secret Key — prowadzi prosto do panelu logowania i odszyfrowania hasła.
04 / Architektura

Flow systemu

Użytkownik przechodzi przez kolejne warstwy weryfikacji zanim uzyska dostęp do chronionych zasobów. Każdy etap — od hasła, przez SMS, po rekonstrukcję sekretu — musi zostać pomyślnie ukończony.

Użytkownik
Wpisuje login + hasło · · · Wpisuje kod SMS · · · Wpisuje udziały
System PHP
· · · Weryfikuje hasło (bcrypt) · · · Tworzy sesję · · ·
SMS / 2FA
· · · · · · Wysyła kod SMS · · · · · ·
Przeglądarka
· · · · · · · · · · · · Odtwarza sekret (JS)
Warstwa autoryzacji
login.php — formularz logowania
auth.php — logika sesji i 2FA
verify.php — weryfikacja kodu SMS
logout.php — wylogowanie
Warstwa danych
secret-key.php — hashe bcrypt
trusted_devices.json — tokeny
secret-key.log — logi zdarzeń
Poza public_html — /private/
Warstwa dostępu
index.php — panel decrypt
log.php — logowanie akcji
.htaccess — ochrona folderów
SMSPlanet API — wysyłka kodów
05 / Moduły

Opis modułów

System składa się z czterech kluczowych modułów — każdy odpowiada za odrębną warstwę działania. Razem tworzą kompletny przepływ: od logowania, przez weryfikację, po odszyfrowanie sekretu.

login.php · auth.php
Login

Strona logowania z wieloma warstwami ochrony. Sprawdza poprawność hasła, blokuje nadmierne próby i zabezpiecza przed fałszywymi żądaniami CSRF.

Weryfikacja tokenu CSRF
Blokada po 3 błędnych próbach
Weryfikacja hasła bcrypt
Sprawdzenie zaufanego urządzenia
Wysyłka kodu SMS
verify.php · resend.php
2FA

Drugi etap weryfikacji — jednorazowy kod SMS ważny 10 minut. Liczba prób ograniczona, możliwość zapamiętania urządzenia na 7 dni.

Generowanie kodu 6-cyfrowego
Wysyłka SMS na numer przypisany do konta
Weryfikacja odporna na ataki czasowe
Zapamiętanie urządzenia na 7 dni
Odnowienie identyfikatora sesji
decrypt/index.php
Decrypt

Panel dostępny po pełnej weryfikacji. Łączy udziały Shamira i odtwarza hasło lokalnie w przeglądarce — dane nie trafiają na serwer.

Weryfikacja aktywnej sesji
Auto-logout po 30 min
Rekonstrukcja hasła z udziałów
Zapis zdarzeń w logu
Powiadomienie e-mail do właściciela
dashboard.html
Dashboard

Narzędzie offline do konfiguracji i podziału sekretu. Bez połączenia z serwerem, bez instalacji — czysty HTML + JS uruchamiany lokalnie na komputerze właściciela.

Szyfrowanie haseł użytkowników (bcrypt)
Generowanie pliku konfiguracyjnego serwera
Podział hasła głównego na udziały Shamira
Pobieranie gotowych plików na dysk
06 / Kryptografia

Shamir Secret Sharing

Algorytm podziału sekretu na dowolną liczbę udziałów — do odtworzenia potrzeba minimalnej wymaganej ich liczby. Żaden pojedynczy udział nie ujawnia sekretu.

Przykład: 3 z 5 udziałów
🔐   MojeSuperTajneHaslo2026!
Podział na 5 udziałów
✓   Wystarczą udziały S1 + S2 + S3  —  sekret odtworzony
Jak to działa

Sekret jest używany jako wyraz wolny wielomianu nad ciałem GF(2⁸). Każdy udział to punkt na tym wielomianie — znając wymaganą liczbę punktów można go jednoznacznie odtworzyć interpolacją Lagrange'a.

f(x) = a₀ + a₁x + a₂x² + ... + aₖ₋₁xᵏ⁻¹
Kompatybilność

System używa biblioteki secrets.js (tej samej co iancoleman.io/shamir) — format udziałów jest w pełni kompatybilny. Szyfrowanie i deszyfrowanie odbywa się całkowicie po stronie klienta (JavaScript).

Bezpieczeństwo

Posiadanie niewystarczającej liczby udziałów nie daje żadnej informacji o sekrecie (information-theoretic security). Dodany padding 1024 bitów uniemożliwia ataki na małe sekrety.

padding = 1024 bit  ·  GF(2⁸)
07 / Bezpieczeństwo

Warstwy ochrony

System łączy kilka niezależnych mechanizmów bezpieczeństwa — kompromitacja jednej warstwy nie daje dostępu do systemu. Każdy etap weryfikacji działa autonomicznie, tworząc ochronę przed różnymi wektorami ataku.

🔒
BCrypt

Hasła są przechowywane w postaci jednokierunkowych skrótów kryptograficznych — niemożliwych do odwrócenia. Nawet uzyskanie dostępu do pliku konfiguracyjnego systemu nie ujawnia oryginalnych haseł. Weryfikacja jest odporna na ataki czasowe.

cost=10$2y$timing-safe
🛡️
CSRF Protection

Każda akcja przesyłania danych wymaga unikalnego tokenu bezpieczeństwa powiązanego z sesją użytkownika. Uniemożliwia to wykonanie nieautoryzowanych operacji przez osoby trzecie z innych stron internetowych.

64 znaki hexrandom_byteshash_equals
🚫
Brute-Force

Trójwarstwowa ochrona przed atakami słownikowymi: maksymalnie 3 próby logowania na adres IP, 3 próby na konto użytkownika w ciągu 15 minut oraz 3 błędne kody weryfikacyjne SMS w ciągu godziny. Każde zablokowanie jest rejestrowane.

3 próby/IP3 próby/user15 min okno
💻
Trusted Devices

System może zapamiętać zaufane urządzenie na 7 dni, eliminując konieczność każdorazowej weryfikacji SMS. Token identyfikujący urządzenie jest przechowywany poza katalogiem publicznym serwera i automatycznie wygasa po upływie terminu.

SHA-256HttpOnly7 dni
⏱️
Session Security

Sesja użytkownika wygasa automatycznie po 30 minutach nieaktywności. Po każdej udanej weryfikacji identyfikator sesji jest odnawiany, co zapobiega atakom polegającym na przechwyceniu sesji. Każde logowanie generuje powiadomienie e-mail do właściciela.

30 min timeoutregenerate_idemail alert
📱
2FA via SMS

Jednorazowy kod 6-cyfrowy jest generowany kryptograficznie i wysyłany SMS-em. Kod jest ważny przez 10 minut, a między kolejnymi wysyłkami obowiązuje 60-sekundowy odstęp. Numer telefonu odbiorcy jest maskowany w interfejsie.

random_int10 min TTLSMSPlanet
08 / FAQ

Często zadawane pytania

Odpowiedzi na najważniejsze pytania dotyczące systemu Secret Key.

Sama karta jest bezużyteczna bez dostępu do telefonu przypisanego do danego konta — logowanie wymaga weryfikacji SMS. Ryzyko jest więc ograniczone, jednak właściciel powinien zostać poinformowany o zgubieniu karty i rozważyć wygenerowanie nowego zestawu udziałów.
System jest zaprojektowany z nadmiarowością — wystarczy zebrać minimalną wymaganą liczbę udziałów (np. 3 z 5). Niedostępność jednej lub dwóch osób nie blokuje procedury awaryjnej, o ile pozostałe osoby są w stanie się zebrać.
Nie. Jest to matematycznie niemożliwe. Pojedynczy udział Shamira nie ujawnia żadnej informacji o sekrecie — to właściwość algorytmu zwana information-theoretic security. Dopiero zebranie wymaganej liczby udziałów pozwala na odtworzenie hasła.
Panel odszyfrowania wymaga połączenia z serwerem do logowania i weryfikacji SMS. Sam proces łączenia udziałów i odtwarzania hasła odbywa się jednak po stronie przeglądarki (JavaScript) — dane nie są przesyłane na serwer.
KeePassXC to darmowy, otwartoźródłowy menedżer haseł działający lokalnie na komputerze — nie wymaga konta ani połączenia z chmurą. Link do pobrania programu oraz plik bazy haseł są dostępne bezpośrednio w panelu systemu po pomyślnym odszyfrowaniu hasła głównego.
Klucz sprzętowy USB to dodatkowa, niezależna warstwa ochrony bazy haseł. Nawet jeśli ktoś pozna hasło główne odtworzone z udziałów, nie będzie w stanie otworzyć bazy haseł bez fizycznego klucza podpiętego do urządzenia. To zabezpieczenie przed scenariuszem, w którym hasło zostałoby wykradzione.
Dane logowania są ważne bezterminowo, o ile właściciel systemu nie wygeneruje nowej konfiguracji i nie zastąpi pliku secret-key.php na serwerze. W takim przypadku stare karty przestają działać i konieczne jest rozdanie nowych.
Projekt w przygotowaniu — publikacja wkrótce