Szybki start

Od zera do działającego systemu w czterech krokach. Konfigurację generujesz w pełni offline — samo wdrożenie wymaga własnego hostingu z PHP.

#Krok 1 — Generowanie konfiguracji

Otwórz dashboard.html i przejdź do zakładki Konfiguracja.

#Krok 2 — Podział hasła algorytmem Shamira

Przejdź do zakładki Szyfrowanie w dashboard.html.

#Krok 3 — Wgranie na serwer

W pliku auth.php (folder app/) ścieżka do folderu /private/ występuje w 7 miejscach. Trzeba poprawić wszystkie, nie tylko pierwszy require_once:

// app/auth.php
require_once __DIR__ . '/../../../private/secret-key.php';
require_once __DIR__ . '/../../../private/rate-limit.php';
require_once __DIR__ . '/../../../private/lang.php';

define('LOG_FILE',    __DIR__ . '/../../../private/secret-key.log');
define('PRIVATE_DIR', __DIR__ . '/../../../private');

// ×2 (rememberDevice() i sprawdzanie zaufanego urządzenia)
$file = __DIR__ . '/../../../private/trusted_devices.json';

Domyślnie w każdym z tych miejsc stoi fragment /../../../private. Ścieżka jest liczona od folderu, w którym leży auth.php, więc dopasuj ją do swojej struktury katalogów. Przykład: auth.php leży w /public_html/twoja-domena/, a /private/ obok /public_html/, więc zmieniasz /../../../private na /../../private we wszystkich siedmiu miejscach (w edytorze użyj „Zamień wszystko”).

#Krok 4 — Generowanie i dystrybucja kart

Otwórz zakładkę Generator kart w dashboard.html. Wprowadź dane każdej osoby i udziały Shamira z pliku secret-key-shares.txt, a następnie pobierz karty jako PDF — gotowe do wydruku lub laminowania.

Algorytm Shamira

Shamir Secret Sharing — matematycznie gwarantuje, że mniejsza niż wymagana liczba fragmentów nie ujawnia żadnej informacji o sekrecie.

#Jak działa podział sekretu

Sekret kodowany jest 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ᵏ⁻¹  (mod p)

gdzie: a₀ = sekret (hasło główne)
       k   = wymagane minimum udziałów
       a₁..aₖ₋₁ = losowe współczynniki

#Przykład — podział 5/3

#Parametry implementacji

#Dobór parametrów

Karty Secret Key

Spersonalizowany nośnik dla każdej wyznaczonej osoby — drukowany PDF w formacie ISO ID-1 (85.6×54mm), jak karta kredytowa.

#Elementy karty

#Generator kart

Generator dostępny jest jako zakładka Generator kart w dashboard.html. Wymaga plików card-front.js i card-back.js w tym samym folderze.

#Specyfikacja techniczna

Architektura systemu

Wielowarstwowy przepływ weryfikacji — od wpisania loginu do odtworzenia hasła w przeglądarce.

#Przepływ autoryzacji

#Warstwy systemu

Warstwa autoryzacji (/app/)

Warstwa dostępu (/app/decrypt/)

Warstwa danych (/private/ — poza public_html)

Bezpieczeństwo

Dziewięć niezależnych warstw ochrony — kompromitacja jednej nie daje dostępu do systemu.

#Warstwy ochrony

#Gwarancja kryptograficzna Shamira

Niezależnie od siły wszystkich pozostałych warstw — bez wymaganej liczby udziałów odtworzenie hasła jest matematycznie niemożliwe. Nawet pełny dostęp do serwera, pliku konfiguracyjnego i logów nie ujawnia hasła głównego.

#Dobre praktyki wdrożeniowe

Ochrona przed zmową powierników

48-godzinna blokada czasowa pobierania plików z alertem e-mail, przyciskiem awaryjnym („Panic Button") i opcjonalną weryfikacją hasła po stronie serwera, chroniąca przed zmową wyznaczonych powierników za życia właściciela.

#Dlaczego to potrzebne

Algorytm Shamira matematycznie pozwala wyznaczonym osobom odtworzyć samo hasło główne, jeśli się w tym celu zmówią — to nieunikniona własność każdego progowego systemu dzielenia sekretu, nie tylko tego. Do wersji z tym mechanizmem jedyną barierą przed nadużyciem były powiadomienia email wysyłane po fakcie — właściciel dowiadywał się o logowaniu, ale nic nie stało na przeszkodzie natychmiastowemu pobraniu bazy haseł. System dodatkowo blokuje fizyczny dostęp do plików na 48 godzin od momentu odzyskania hasła, dając właścicielowi realny czas na reakcję.

#Weryfikacja po stronie przeglądarki

Warunek sukcesu w przeglądarce sprawdza tylko, czy rekonstrukcja Shamira nie rzuciła wyjątku — czyste dzielenie sekretu nie ma wbudowanej integralności, więc błędne lub niewystarczające udziały i tak niemal zawsze zwracają jakiś niepusty, losowy ciąg zamiast błędu. Dodane zostały dwie niezależne metody weryfikacji klienckiej:

#Weryfikacja po stronie serwera (SECRET_HASH)

Od v3.1.0 arm-timelock.php nie ufa już bezkrytycznie sygnałowi z przeglądarki. Jeśli w configu ustawiona jest opcjonalna stała SECRET_HASH, serwer weryfikuje złożony sekret przez password_verify() — dokładnie tym samym mechanizmem co hasła logowania — zanim uzbroi blokadę czasową. Od v3.1.1 panel dołącza złożony sekret do żądania tylko wtedy, gdy SECRET_HASH jest ustawiony i blokada nie jest jeszcze uzbrojona — w pozostałych przypadkach hasło nie opuszcza przeglądarki:

define('SECRET_HASH', '$2y$10$...'); // bcrypt hash prawdziwego hasła

Rate-limiting niezależny od logowania

5 nieudanych prób weryfikacji / 30 minut, licznik per-konto (nie per-IP) — żeby jedna zablokowana osoba nie blokowała innej, logującej się z tej samej sieci w trakcie kryzysu. Blokuje wyłącznie kolejne próby weryfikacji sekretu — logowanie, przeglądanie panelu i edycja pola z kodami działają bez ograniczeń przez cały czas. Po przekroczeniu limitu panel prosi o odczekanie; te same (poprawne) udziały przejdą normalnie po zresetowaniu licznika.

Panel odzwierciedla to na żywo nowym, pośrednim stanem: hasło złożone lokalnie w przeglądarce nie pojawia się już natychmiast w zielonym polu — najpierw pokazuje się neutralny, niebieski komunikat „Weryfikuję hasło…", a zielone pole z hasłem pojawia się dopiero po potwierdzeniu przez serwer. Błędny sekret nigdy nie zdąży się pokazać jako poprawny — czerwony błąd zastępuje pośredni stan bezpośrednio.

#Cztery stany panelu pobierania

Panel na żywo wykrywa zmianę stanu (tl-status.php, odpytywanie co 10s) — Panic Button kliknięty w innej karcie, upływ czasu czy ręczny reset configu odświeżają widok automatycznie, bez akcji użytkownika.

#Panic Button — alert e-mail i jednorazowy link blokujący

Pierwsza potwierdzona udana rekonstrukcja sekretu w panelu (i, jeśli SECRET_HASH jest ustawiony, pozytywna weryfikacja serwerowa — patrz wyżej) automatycznie: tworzy stan blokady (private/timelock.json, 48h okno), loguje zdarzenie TIMELOCK ARMED i wysyła e-mail alarmowy do właściciela (patrz Konfiguracja treści i danych → Powiadomienie email). Mail zawiera jednorazowy link panic.php?token=... (token 256-bitowy, bez wymogu logowania — właściciel może nie mieć jak się szybko zalogować w sytuacji kryzysowej). Kliknięcie natychmiast i trwale blokuje pobieranie, niezależnie od tego, czy 48h już minęło, czy nie.

#Reset po Panic Button — automatyczny, bez ręcznej ingerencji

Ważność timelock.json jest powiązana z odciskiem (hashem) aktualnego $people w secret-key.php. Gdy właściciel po incydencie zmieni hasło główne i wygeneruje nowy config (co i tak musi zrobić), stary timelock automatycznie traci ważność przy najbliższym odświeżeniu panelu — bez potrzeby ręcznego kasowania pliku przez FTP/SSH w stresującej, powypadkowej sytuacji.

Struktura plików

Kompletne drzewo plików projektu — zarówno pliki serwera jak i lokalnych narzędzi offline.

#Pliki na serwerze

#Pliki poza public_html

#Pliki lokalne (narzędzia offline)

Wymagania

Co potrzebujesz, żeby uruchomić Secret Key na własnym serwerze.

#Serwer

#Konto SMSPlanet

System wysyła kody 2FA przez SMSPlanet API. Wymagane:

Treść SMS-a i autouzupełnianie kodu (WebOTP)

Treść wiadomości SMS składa się z dwóch części z osobnych źródeł: sam tekst kodu pochodzi z lang.php (klucz twofa_sms_body, przez t() — dokładnie ten sam mechanizm vsprintf co przy verify_attempts_left_*), a przyrostek do autouzupełniania WebOTP budowany jest w auth.php ze stałej ustawionej w secret-key.php:

// secret-key.php
define('SMS_AUTOFILL_DOMAIN', '@moja-domena.pl');

// private/lang.php — %s = kod, %d = ważność w minutach
'twofa_sms_body' => 'Kod weryfikacyjny: %s. Wazny %d min. Nie udostepniaj go nikomu.',

// auth.php — treść z lang.php + przyrostek WebOTP z secret-key.php
$msg = t('twofa_sms_body', $code, $ttlMin) . "\n\n" . SMS_AUTOFILL_DOMAIN . " #$code";

Ostatni fragment (@domena #kod) to nie literówka ani ozdobnik — to format wymagany przez WebOTP API. Dzięki niemu przeglądarka na telefonie (Chrome/Android, Safari/iOS) sama rozpoznaje kod w przychodzącym SMS-ie i automatycznie wypełnia pole na stronie logowania, bez kopiowania go ręcznie z aplikacji SMS.

#Narzędzia lokalne (offline)

Instalacja krok po kroku

Kompletny przewodnik od pobrania plików do działającego systemu na własnym serwerze.

#1. Konfiguracja offline

Pobierz pliki projektu i otwórz dashboard.html lokalnie w Chrome.

Zakładka Konfiguracja

Zakładka Szyfrowanie

#2. Wgranie plików na serwer

# Wgraj folder /app/ do public_html (zawiera też /decrypt/ wewnątrz)
scp -r ./app/ user@serwer:~/public_html/

# Wgraj konfigurację i teksty interfejsu POZA public_html
scp ./secret-key.php ./lang.php user@serwer:~/private/

#2a. Wyjątek w CDN/cache (jeśli używasz Cloudflare lub podobnego)

Jeśli Twoja domena ma włączony cache na poziomie całej strony (np. reguła typu „Cache Everything" w Cloudflare, albo podobny mechanizm u innego dostawcy CDN), musisz dodać wyjątek dla katalogu, w którym stoi system, zanim zaczniesz cokolwiek testować.

Przykład dla Cloudflare (Caching → Cache Rules):

#3. Konfiguracja ścieżki

W pliku auth.php (folder app/) ścieżka do folderu /private/ występuje w 7 miejscach. Trzeba poprawić wszystkie, nie tylko pierwszy require_once:

// app/auth.php
require_once __DIR__ . '/../../../private/secret-key.php';
require_once __DIR__ . '/../../../private/rate-limit.php';
require_once __DIR__ . '/../../../private/lang.php';

define('LOG_FILE',    __DIR__ . '/../../../private/secret-key.log');
define('PRIVATE_DIR', __DIR__ . '/../../../private');

// ×2 (rememberDevice() i sprawdzanie zaufanego urządzenia)
$file = __DIR__ . '/../../../private/trusted_devices.json';

Domyślnie w każdym z tych miejsc stoi fragment /../../../private. Ścieżka jest liczona od folderu, w którym leży auth.php, więc dopasuj ją do swojej struktury katalogów. Przykład: auth.php leży w /public_html/twoja-domena/, a /private/ obok /public_html/, więc zmieniasz /../../../private na /../../private we wszystkich siedmiu miejscach (w edytorze użyj „Zamień wszystko”).

#3a. Tryb testowy SMS

Przed wdrożeniem warto sprawdzić czy system działa poprawnie — bez wysyłania prawdziwych SMS-ów i zużywania tokenów SMSPlanet. Plik app/auth.php zawiera wbudowany tryb testowy.

// ── TRYB TESTOWY — usuń przed wdrożeniem na produkcję! ──
// $smsResult = true; $code = '123456';
// ────────────────────────────────────────────────────────

$smsResult = sendSmsCode($phoneFull, $code);

Aby włączyć tryb testowy — odkomentuj linię z $smsResult = true i zakomentuj wywołanie sendSmsCode():

// ── TRYB TESTOWY — usuń przed wdrożeniem na produkcję! ──
$smsResult = true; $code = '123456';  // ← odkomentuj
// ────────────────────────────────────────────────────────

// $smsResult = sendSmsCode($phoneFull, $code);  // ← zakomentuj

Po włączeniu trybu testowego — kod weryfikacyjny SMS będzie zawsze wynosił 123456, niezależnie od numeru telefonu. Możesz spokojnie przetestować cały przepływ logowania bez kosztów.

#4. Generowanie i dystrybucja kart

Konfiguracja treści i danych

Wszystko na tej stronie generuje dashboard.html (zakładka Konfiguracja) do jednego pliku — secret-key.php. Poniżej opisane jest, co faktycznie trafia do configu i po co, żebyś wiedział, co wypełniasz w formularzu (albo co zmieniasz, jeśli wolisz poprawić secret-key.php ręcznie).

#1. Osoby ($people)

$people to jedna tablica z jednym rekordem na osobę — login, hasło, dane kontaktowe i widoczność w panelu w jednym miejscu.

$people = [
  [
    'login'         => 'anna',
    'password'      => '$2y$10$...',  // hash bcrypt — generowany przez dashboard
    'first_name'    => 'Anna',
    'last_name'     => 'Nowak',
    'phone_cc'      => '+48',          // kierunkowy — osobno, dowolny kraj
    'phone'         => '123456789',   // sam numer lokalny, bez kierunkowego
    'show_in_panel' => true,
  ],
  // kolejne osoby...
];

#2. Pliki do pobrania ($downloads)

$downloads to jedno źródło zarówno dla przycisków pobierania w panelu, jak i białej listy w download.php — to dosłownie ta sama tablica, więc oba miejsca są zawsze zgodne ze sobą.

$downloads = [
  ['key' => 'baza-hasel', 'label' => 'Pobierz bazę haseł',     'filename' => 'moja-baza-hasel.kdbx'],
  ['key' => 'aegis',      'label' => 'Pobierz bazę kodów 2FA (Aegis)', 'filename' => 'moja-baza-aegis.json'],
  ['key' => 'program',    'label' => 'Pobierz KeePassXC',      'filename' => 'KeePassXC-2.7.9-Win64.msi', 'name' => 'KeePassXC'],
];

Obok samej listy plików, trzy dodatkowe zmienne kontrolują teksty tej sekcji panelu:

$download_heading = 'Pliki i program do odzyskania dostępu';  // zwykły tekst, nagłówek <h3>
$download_intro = 'Pobierz bazę haseł, bazę kodów 2FA oraz program...';  // zwykły tekst, akapit nad przyciskami
$alert_box_text = 'Pamiętaj: bez fizycznego klucza YubiKey...';  // zwykły tekst, niebieski box z ikoną

#3. Instrukcja ($instructions)

Kroki instrukcji w panelu też są danymi, nie kodem HTML. Każdy krok to jedno pole tekstowe z prostym formatowaniem — markdown-lite.

$instructions = [
  ['num' => '01', 'text' => '**Zbierzcie się razem.** Skontaktujcie się z osobami z listy — potrzebujecie minimum **3 osoby z 5**.'],
  ['num' => '02', 'text' => '**Wejdźcie na tę stronę razem.** Każda osoba potrzebuje swojej karty (np. *8015c7c4...*).'],
  // kolejne kroki...
];

#4. Powiadomienie email ($email_notify)

Panel może wysyłać email po każdym udanym logowaniu — z adresem IP, przeglądarką i czasem. Wszystkie dane nadawcy/odbiorcy trzyma jedna tablica, żeby domena nie powtarzała się osobno w nagłówkach From, Reply-To, Return-Path, X-Sender i Message-ID.

$email_notify = [
  'enabled'    => true,
  'to'         => 'jan@moja-domena.pl',
  'from_email' => 'no-reply@moja-domena.pl',
  'from_name'  => 'Secret Key',
  'panel_url'  => 'https://moja-domena.pl',
];

Temat: 🔐 Logowanie do Secret Key Panel — Jan Kowalski

Nowe logowanie do panelu Secret Key.

─────────────────────────────
Użytkownik:   Jan Kowalski (jan)
Data i czas:  01.05.2026 14:32:17
Adres IP:     89.123.45.67
Przeglądarka: Mozilla/5.0 (Windows NT 10.0...)
─────────────────────────────

Panel: https://moja-domena.pl

#5. SMS: token, nadawca i autouzupełnianie

Połączenie z SMSPlanet opisują dwie stałe na początku secret-key.php. Używa ich auth.php przy każdej wysyłce kodu 2FA:

define('SMSPLANET_TOKEN', 'twój-token-api');
define('SMS_SENDER',      'Secret Key');

Domena widoczna w treści SMS-a (do automatycznego wypełniania kodu na Android/iOS — patrz strona Wymagania) też jest teraz configiem, nie ręczną edycją auth.php:

define('SMS_AUTOFILL_DOMAIN', '@moja-domena.pl');

#6. Wymagany próg odzyskiwania (SHARES_REQUIRED)

Panel odzyskiwania (/decrypt/index.php) musi wiedzieć, ile kodów z kart wymaganych jest do złożenia hasła — czyli ten sam próg (K), który ustawiasz w zakładce dashboardu „Szyfrowanie" przy dzieleniu hasła głównego na udziały:

define('SHARES_REQUIRED', 4); // np. 4 z 7

#7. Weryfikacja hasła po stronie serwera (SECRET_HASH)

Opcjonalna, ale mocno zalecana stała — bcrypt hash prawdziwego hasła głównego, używany przez arm-timelock.php do weryfikacji złożonego sekretu przez password_verify(), zanim uzbroi blokadę czasową (patrz Ochrona przed zmową powierników → Weryfikacja na serwerze):

define('SECRET_HASH', '$2y$10$...'); // bcrypt hash prawdziwego hasła

#8. Limity i czasy (auth.php)

Wartości limitów prób, czasu ważności kodów i sesji nie są częścią secret-key.php — to stałe na początku pliku app/auth.php. Domyślne ustawienia są rozsądne dla typowego wdrożenia, ale możesz je zmienić, edytując plik ręcznie:

Teksty interfejsu (lang.php)

Cały widoczny tekst interfejsu — przyciski, etykiety, komunikaty błędów — jest wydzielony z kodu do jednego pliku, private/lang.php.

#Zasada działania

Jeśli chcesz uruchomić system w innym języku niż polski, edytujesz lang.php ręcznie — całość, jednorazowo — oraz przepisujesz treść w secret-key.php ($instructions, $download_intro, itd.) na ten sam język. To świadomy wybór prostoty zamiast rozbudowanej warstwy i18n, której i tak nikt by tu nie przełączał w locie.

#Klucze i funkcja t()

lang.php definiuje tablicę $lang — klucz w stylu snake_case na wartość tekstową. Kod odczytuje ją przez funkcję t() zdefiniowaną w auth.php:

// private/lang.php
$lang = [
  'login_submit_btn'   => 'Zaloguj się',
  'login_empty_fields' => 'Wpisz login i hasło.',
  // ...
];

// auth.php
function t(string $key, ...$args): string {
    global $lang;
    $text = $lang[$key] ?? $key;
    return $args ? vsprintf($text, $args) : $text;
}

t() wspiera też placeholdery w stylu sprintf — np. do poprawnej polskiej odmiany liczby pozostałych prób:

// w lang.php
'verify_attempts_left_1'    => 'Pozostało %d próba.',
'verify_attempts_left_few'  => 'Pozostało %d próby.',
'verify_attempts_left_many' => 'Pozostało %d prób.',

// wywołanie
t('verify_attempts_left_few', $remaining);

#Zmiana języka systemu

Żeby uruchomić system w innym języku:

FAQ

Najczęściej zadawane pytania dotyczące bezpieczeństwa, działania i wdrożenia systemu.

#Co jeśli zgubię kartę Secret Key?

Sama karta jest bezużyteczna bez dostępu do telefonu przypisanego do danego konta — logowanie wymaga weryfikacji SMS. Ryzyko jest ograniczone, jednak właściciel powinien zostać poinformowany i rozważyć wygenerowanie nowej konfiguracji z nowym zestawem udziałów. Po zastąpieniu pliku secret-key.php na serwerze, stare karty przestają działać.

#Czy posiadając kartę mogę samodzielnie odczytać hasło?

Nie. Jest to matematycznie niemożliwe. Pojedynczy udział nie ujawnia żadnej informacji o sekrecie — to własność algorytmu Shamira zwana information-theoretic security. Dopiero zebranie wymaganej liczby udziałów pozwala na odtworzenie hasła głównego.

#Co jeśli jedna z wyznaczonych osób umrze lub będzie niedostępna?

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.

#Czy hasło trafia na serwer podczas odszyfrowania?

Rekonstrukcja odbywa się w przeglądarce (JavaScript). Jeśli w configu ustawiłeś SECRET_HASH (zalecane), po jej zakończeniu hasło jest przesyłane przez HTTPS do Twojego serwera tylko po to, by password_verify() mogło je porównać z SECRET_HASH — serwer go nie zapisuje ani nie loguje. Bez SECRET_HASH hasło w ogóle nie opuszcza przeglądarki.

#Co jeśli powiernicy zmówią się i odzyskają hasło za mojego życia, bez mojej wiedzy?

Samo hasło im nie wystarczy. Pliki bazy danych leżą poza katalogiem publicznym serwera, a dostęp do nich kontroluje download.php. W momencie pierwszej udanej rekonstrukcji hasła w panelu system automatycznie blokuje pobieranie plików na 48 godzin i wysyła Ci e-mail z alertem oraz jednorazowym linkiem „Panic Button" — jedno kliknięcie trwale odcina dostęp, dając Ci czas na zmianę hasła głównego w spokoju. Szczegóły: Ochrona przed zmową powierników. Jeśli dodatkowo zabezpieczasz bazę haseł kluczem sprzętowym (np. YubiKey), sama znajomość hasła nie wystarczy do jej otwarcia nawet po odblokowaniu plików.

#Czy mogę używać systemu z innym menedżerem haseł niż KeePassXC?

Tak. Secret Key przechowuje i odtwarza dowolne hasło główne — niezależnie od używanego menedżera. Kompatybilny z KeePassXC, Bitwarden, 1Password i każdym innym programem obsługującym hasło główne.

#Jak wybrać próg — ile udziałów jest wymaganych?

Im wyższy próg, tym większe bezpieczeństwo — ale też trudniejsze zebranie się w sytuacji kryzysowej. Rekomendowany kompromis to 3 z 5 — pozwala na niedostępność dwóch osób przy zachowaniu dobrego poziomu ochrony. Wybrany próg wpisz też jako SHARES_REQUIRED w configu (pole „Wymagane kody" w zakładce Konfiguracja dashboardu) — patrz Konfiguracja treści i danych — inaczej panel odzyskiwania będzie żądał innej liczby kodów niż realnie potrzeba.

#Jak długo ważne są dane logowania z karty?

Bezterminowo — o ile właściciel nie wygeneruje nowej konfiguracji. Po zastąpieniu pliku secret-key.php na serwerze stare karty przestają działać i konieczne jest rozdanie nowych wszystkim wyznaczonym osobom.

#Dlaczego mail z alertem bezpieczeństwa (Panic Button) czasem trafia do spamu?

Ten alert wysyłany jest automatycznie po pierwszej udanej rekonstrukcji hasła w panelu — patrz Ochrona przed zmową powierników. Taki mail zawiera jednorazowy link z długim, losowym tokenem (panic.php?token=...) — automatyczne filtry antyspamowe często oznaczają linki tego kształtu, niezależnie od treści maila, bo pod względem struktury przypominają linki phishingowe. To dotyczy tylko maila z alertem — zwykłe powiadomienia o logowaniu (bez klikalnego linku z tokenem) zwykle trafiają do odebranych bez problemu.

Rozwiązanie: dodaj adres nadawcy (domyślnie no-reply@twoja-domena, skonfigurowany w $email_notify['from_email']) do białej listy w panelu poczty, na który przychodzą powiadomienia — w cPanel jest to sekcja „Biała lista" (Email → Biała lista), gdzie można dodać zaufanego nadawcę osobno dla wybranej skrzynki. Po dodaniu wyjątku mail z Panic Buttonem trafia już bezpośrednio do odebranych.

#Czy Secret Key zastępuje testament lub postępowanie spadkowe?

Nie. Secret Key nie jest narzędziem prawnym. Pieniądze z konta bankowego rodzina odzyska formalną drogą spadkową, a Secret Key uzupełnia ją tam, gdzie prawo nie pomoże: dostęp do poczty, chmury ze zdjęciami, kodów 2FA czy kryptowalut trzymanych na własnym kluczu. To nie jest porada prawna, a regulaminy niektórych usług mogą ograniczać udostępnianie haseł.

#Czy rodzina zobaczy całą moją prywatną korespondencję?

Secret Key niczego nie odszyfrowuje i nie ma dostępu do Twojej poczty ani komunikatorów. Dzieli tylko hasło główne do Twojej bazy haseł (np. KeePass, Bitwarden), a plik bazy leży na Twoim serwerze. Bliscy po zebraniu kworum, potwierdzeniu SMS i 48-godzinnej blokadzie pobierają ten plik, a to, co w nim jest, wybierasz Ty. Możesz przygotować osobną bazę awaryjną tylko z kontami, które mają trafić do rodziny.

#Czy to nie jest za skomplikowane? Czy nie wystarczy zaszyfrowany pendrive i kartka z hasłem?

Dla wielu osób pendrive z kartką wystarczy i jest prostszy. Secret Key jest dla tych, którzy nie chcą trzymać wszystkiego w jednym miejscu u jednej osoby: hasło jest dzielone między kilku zaufanych, a dostęp chroni SMS i 48-godzinna blokada, którą możesz anulować. Konfiguracja jest techniczna (własny serwer; dashboard offline i dokumentacja ją upraszczają), a Twoi bliscy dostają tylko karty i instrukcję.

Polityka bezpieczeństwa

Jak zgłaszać luki bezpieczeństwa i czego możesz oczekiwać w odpowiedzi.

Zwykłe błędy, literówki w dokumentacji czy propozycje ulepszeń zgłaszaj normalnie jako Issue na GitHubie — to standardowa droga i nie ma w tym nic tajnego. Ta strona dotyczy wyłącznie luk bezpieczeństwa (patrz zakres zgłoszeń niżej) — tych proszę nie zgłaszać publicznie.

#Jak zgłosić lukę

Wyślij szczegółowy opis na: dev@secretkey.website

#Czas odpowiedzi

#Zakres zgłoszeń

Przegląd dashboard

Dashboard to lokalny panel konfiguracyjny Secret Key — plik HTML otwierany bezpośrednio w przeglądarce bez serwera. Zawiera stronę główną (Home) i trzy zakładki narzędziowe: Szyfrowanie, Konfiguracja i Generator kart, a także przełącznik języka PL/EN.

#Interfejs główny

#Elementy interfejsu

#Wymagane pliki

Wszystkie pliki muszą znajdować się w tym samym folderze:

#Zalecana przeglądarka

Zakładka: Konfiguracja

Generuje plik secret-key.php — serce systemu. Zawiera zahashowane hasła bcrypt, dane wszystkich wyznaczonych osób, pliki do pobrania, instrukcję panelu i ustawienia powiadomienia email. Operacja w pełni offline — nic nie jest nigdzie wysyłane.

#Widok zakładki

#Elementy interfejsu

#Krok po kroku

Zakładka: Szyfrowanie

Dzieli hasło główne do bazy haseł na udziały algorytmem Shamira. Generuje plik secret-key-shares.txt z fragmentami klucza do rozdania wyznaczonym osobom.

#Widok zakładki

#Elementy interfejsu

#Krok po kroku

Zakładka: Generator kart

Tworzy spersonalizowane karty Secret Key w formacie ISO ID-1 (85.6×54mm) gotowe do wydruku lub laminowania. Każda karta zawiera dane logowania, udział Shamira i kod QR.

#Widok zakładki

#Elementy interfejsu

#Krok po kroku

Test przed rozdaniem kart

Lista kontrolna od początku do końca: tryb testowy, logowanie, rekonstrukcja, blokada i sprzątanie.

Zanim rozdasz karty, przejdź cały proces od początku do końca na konfiguracji testowej. Poniższa lista zbiera w jednym miejscu kroki, które są opisane osobno na stronach Instalacja krok po kroku, Ochrona przed zmową powierników i Zakładka: Szyfrowanie.

#Przygotowanie

#Logowanie i panel

#Rekonstrukcja i blokada

#Prawdziwy SMS i autouzupełnianie

Autouzupełnianie kodu (WebOTP) działa tylko z prawdziwym SMS-em, więc sprawdź je dopiero po wyłączeniu trybu testowego: zaloguj się z telefonu i zobacz, czy przeglądarka sama wypełnia pole kodu. Jeśli nie, najczęściej SMS_AUTOFILL_DOMAIN nie zgadza się z domeną panelu.

#Sprzątanie przed rozdaniem kart

#Gotowe do rozdania kart, gdy…

Aktualizacja do nowej wersji

Co wgrać po wydaniu nowej wersji i czego nie nadpisywać.

Aktualizacja polega zwykle na podmianie kilku plików PHP. Poniżej ogólne zasady oraz tabela, które pliki zmieniały się w kolejnych wydaniach. Pełna lista zmian jest w historii wersji.

#Zasady ogólne

#Które pliki w której wersji

#Masz własne tłumaczenie lang.php?

Nie nadpisuj go. Dopisz brakujące klucze do swojego pliku, w swoim języku. Przykład dla v3.1.2:

'person_locked'         => 'zaszyfrowane',
'footer_system_version' => 'WERSJA SYSTEMU:',

#Czego nie nadpisywać

Rozwiązywanie problemów

Objaw, przyczyna i co sprawdzić — SMS, tłumaczenia, weryfikacja hasła, limity, maile i pobieranie.

Najczęstsze objawy z przyczynami i sposobem sprawdzenia. Zdarzenia z serwera zapisują się w pliku private/secret-key.log — to pierwsze miejsce, w które warto zajrzeć.

#SMS z kodem nie dochodzi

#Panel pokazuje nazwy kluczy zamiast tekstu

Zamiast „zaszyfrowane” widzisz np. person_locked. Funkcja t() nie znalazła klucza w lang.php i pokazuje sam klucz. Najczęściej to efekt wgrania nowego index.php bez nowego lang.php (albo z własnym tłumaczeniem bez nowych kluczy). Wgraj lang.php razem z index.php lub dopisz brakujące klucze — patrz Aktualizacja do nowej wersji i Teksty interfejsu (lang.php).

#„Kody złożyły się poprawnie, ale to nie jest prawidłowe hasło”

#Panel żąda innej liczby kodów, niż potrzeba

Wartość SHARES_REQUIRED w configu musi być równa progowi K z zakładki Szyfrowanie. Dashboard nie sprawdza tego sam. Bez tej stałej panel przyjmuje 3, a najniższa dozwolona wartość to 2. Popraw wartość i wgraj config ponownie (patrz Konfiguracja treści i danych).

#Logowanie albo weryfikacja jest zablokowana

Wystarczy odczekać do końca okna. Liczniki są trwałe i leżą w private/rate_limits.json, więc odświeżenie strony ani usunięcie ciasteczek ich nie zeruje. Katalog private/ musi mieć prawo zapisu.

#Nie dostaję maila z powiadomieniem lub alertem Panic Button

#Przyciski pobierania są nieaktywne albo pobieranie zwraca błąd

#Po zmianie configu nikt nie może się zalogować

#Zmiany w panelu nie są widoczne

Jeśli domena działa za CDN z agresywnym cache (np. „Cache Everything” w Cloudflare), dodaj regułę „bypass” dla ścieżki systemu. Szczegóły w Instalacja krok po kroku (wyjątek w CDN/cache).

Po alercie Panic Button

Co zrobić po otrzymaniu maila z alertem: ocena sytuacji, blokada, sprawdzenie logu i reset.

Dostałeś mail z alertem Panic Button. Oznacza on, że ktoś w panelu po raz pierwszy złożył prawidłowe hasło główne i system uzbroił 48-godzinną blokadę pobierania plików. Mechanizm opisuje strona Ochrona przed zmową powierników. Ta strona mówi, co zrobić krok po kroku.

#Co jest w mailu

Mail podaje, kto uzbroił blokadę (imię i login), kiedy i z jakiego adresu IP, oraz zawiera jednorazowy link panic.php?token=…. Link nie wymaga logowania, żebyś mógł go użyć nawet bez dostępu do konta.

#Najpierw ustal, czy to oczekiwane

#Po kliknięciu linku

Pobieranie plików zostaje zablokowane trwale, niezależnie od tego, czy 48 godzin już minęło. Bezpośrednie wejście na download.php zwraca kod 403, a panel w ciągu około 10 sekund pokazuje stan „zablokowane”. W logu zobaczysz wpis PANIC BUTTON z adresem IP, z którego kliknięto link; nieprawidłowy lub nieaktualny token zapisuje PANIC BUTTON FAILED, a próby pobrania podczas blokady DOWNLOAD BLOCKED.

#Sprawdź log

W private/secret-key.log szukaj wpisów DECRYPT SUCCESS i TIMELOCK ARMED (kto, z jakiego IP i kiedy), logowań tych kont, wpisów DOWNLOAD (czy ktoś pobrał plik) oraz ewentualnych TIMELOCK ARM REJECTED — to próby podania fałszywego hasła przy ustawionym SECRET_HASH.

#Zmowa lub nadużycie

#Fałszywy alarm

Jeśli blokada uzbroiła się przez test lub pomyłkę i nikt nie kliknął Panic Button, usuń private/timelock.json z serwera (FTP lub SSH) albo wgraj nowy secret-key.php. Stan blokady zniknie, a kolejna prawdziwa rekonstrukcja uzbroi ją od nowa. Uprzedź bliskich, że był to test.

Słowniczek

Najważniejsze pojęcia w jednym miejscu.

Krótkie wyjaśnienia pojęć używanych w dokumentacji, z odsyłaczami do stron, na których temat jest opisany szerzej.

#Kryptografia

#Logowanie i panel

#Blokada czasowa

#Konfiguracja