Problem, który każdy zna
Ile razy w swojej karierze programisty i specjalisty od digital marketingu musiałem przekazać komuś hasło? Albo klucz API? Może dane dostępowe do testowego środowiska? Początkowo, jak pewnie większość z nas, robiłem to przez email. "Oto hasło do serwera..." - pisałem, nie zdając sobie sprawy z tego, jak niebezpieczne to może być. Email pozostaje w skrzynkach odbiorczych przez lata. Hasła i poufne informacje leżą sobie spokojnie w folderach "Wysłane", "Odebrane", czasem w kopii zapasowej na kilku urządzeniach. Kiedy uświadomiłem sobie, że moja skrzynka mailowa to praktycznie baza danych z setkami haseł i kluczy API, wiedziałem, że coś musi się zmienić.
Pierwsza próba rozwiązania - i dlaczego nie działała
Początkowo próbowałem korzystać z komunikatorów. Slack, Teams, WhatsApp - wydawało się, że to bezpieczniejsze niż email. Przynajmniej można było usunąć wiadomość po przeczytaniu. Ale tu też pojawiły się problemy: - Historia pozostawała na serwerach firm - Trudno było kontrolować, czy odbiorca rzeczywiście przeczytał wiadomość - W przypadku komunikatorów firmowych, administratorzy mogli mieć dostęp do historii - Mobilne kopie zapasowe często przechowywały wiadomości dłużej niż trzeba Szukałem więc czegoś prostego, bezpiecznego i - co najważniejsze - jednorazowego.Odkrycie świata jednorazowych wiadomości
Natknąłem się na kilka narzędzi do udostępniania jednorazowych wiadomości. Koncepcja była genialna: wiadomość, która niszczy się sama po przeczytaniu. Ale im więcej z nich testowałem, tym więcej problemów dostrzegałem:Problem 1: Złożoność i zależności
Większość rozwiązań wymagała skomplikowanej infrastruktury - bazy danych, Redis, kolejki, mikrousługi. Jako osoba, która często pracuje z małymi projektami i hostingiem współdzielonym, potrzebowałem czegoś prostszego.
Problem 2: Brak transparentności
Użytkownik nie wiedział, kiedy dokładnie wiadomość się zniszczy. Czy już? Czy za chwilę? Ta niepewność była frustrująca.
Problem 3: Słabe doświadczenie użytkownika
Interfejsy były często przestarzałe, niemiłe dla oka, nieresponsywne na mobile. Oczekiwałem czegoś więcej.
Problem 4: Wątpliwe bezpieczeństwo
Wiele rozwiązań nie było open source. Nie mogłem zweryfikować, jak naprawdę działa szyfrowanie, czy klucze nie są gdzieś logowane.
Moment "mam dość" - i narodziny pomysłu
Pracowałem nad projektem dla klienta i musiałem przekazać mu tymczasowe hasło do środowiska deweloperskiego. Skorzystałem z jednego z popularnych narzędzi online do jednorazowych wiadomości.
Po trzech godzinach otrzymałem telefon: "Marcin, to hasło nie działa". Okazało się, że wiadomość już się zniszczyła - bez żadnego ostrzeżenia, bez informacji o tym, kiedy to się stanie. Klient był zirytowany, ja byłem zaskoczony, a cały proces musiałem powtórzyć.
Tego dnia wieczorem usiadłem i zacząłem szkicować to, co później stało się Secret Links.Filozofia projektu - prostota ponad wszystko
Od początku miałem jasną wizję tego, czego chcę:1. Zero Dependencies - maksymalna prostota
Secret Links miał działać wszędzie gdzie jest PHP i serwer web. Żadnych baz danych, żadnych zewnętrznych usług, żadnych skomplikowanych konfiguracji. Wrzucasz pliki na serwer i działa. Dlaczego to było tak ważne? Bo sam często pracuję z projektami, które muszą działać na współdzielonym hostingu za 20 zł miesięcznie. Nie każdy może sobie pozwolić na VPS z Docker'em i pełną infrastrukturą.
2. Transparentność procesu
Użytkownik musi wiedzieć, co się dzieje. Kiedy wiadomość zostanie zniszczona? Za ile sekund? Czy już została przeczytana? Secret Links pokazuje to wszystko wizualnie - ustawiany countdown z progress barem, który nie pozostawia wątpliwości kiedy dana wiadomość ulegnie zniszczeniu.3. Prawdziwe bezpieczeństwo
Klucz szyfrowania nigdy nie trafia na serwer. Jest przekazywany w fragmencie URL (po znaku #), który przeglądarki nie wysyłają do serwera. Używam AES-256-CBC - tego samego algorytmu, co banki i rządy.4. Dobry interfejs
Nie ma usprawiedliwienia dla brzydkich interfejsów. Secret Links ma dość nowoczesny design z glassmorphism, animacje CSS, responsywność na mobile. Bezpieczeństwo nie musi oznaczać rezygnacji z estetyki.
Techniczna strona - jak to działa w praktyce
Gdy zastanawiałem się nad architekturą, miałem kilka kluczowych założeń:Szyfrowanie end-to-end:
1. Użytkownik wpisuje wiadomość2. JavaScript generuje losowy klucz (16 bajtów)
3. Wiadomość jest szyfrowana po stronie klienta (CryptoJS, AES-256-CBC)
4. Na serwer trafia tylko zaszyfrowana wiadomość
5. Klucz jest dodany do URL po znaku # (fragment)
6. Serwer nigdy nie widzi klucza deszyfrującego
To oznacza, że nawet ja, jako twórca i administrator, nie mogę odczytać wiadomości bez dostępu do pełnego URL-a z kluczem.
Inteligentne niszczenie
Każda wiadomość ma swój cykl życia:- Tworzona jako plik JSON w folderze `active/`
- Po przeczytaniu przenoszona do `expired/`
- Po 7 dniach usuwana na zawsze System ma też inteligentne cleanup:
- Lazy cleanup co 10 operacji
- Automatyczne czyszczenie co godzinę
- Forced cleanup gdy jest >100 plików
Bezpieczeństwo na każdym poziomie
- Rate limiting: 10 requestów na minutę na IP- CSRF protection: Wszystkie formularze zabezpieczone tokenami
- XSS prevention: Walidacja i sanitizacja wszystkich inputów
- Secure headers: Automatyczne ustawianie nagłówków bezpieczeństwa
- File permissions: Pliki z wiadomościami mają uprawnienia 0600
Jak Secret Links zmienił moją rutynę pracy
Dziś Secret Links to integralny element mojego workflow. Oto jak go używam na co dzień:- Udostępnianie haseł klientom
- Zamiast wysyłać hasła mailem, tworzę jednorazową wiadomość. Klient wie, że ma 24 godziny na przeczytanie (albo inny ustawiony czas), a po przeczytaniu hasło znika na zawsze. Żadnych śladów w mailach.- Przekazywanie kluczy API
- Przy pracy z zewnętrznymi API często muszę przekazać klucze deweloperskie. Secret Links jest idealny - klucz trafia bezpiecznie do dewelopera i od razu znika.- Wrażliwe informacje klienckie
- Czasem klienci przesyłają mi dane osobowe do testów - numery telefonów, adresy, dane testowych użytkowników. Secret Links pozwala na bezpieczne przekazanie tych informacji bez zostawiania śladów.- Współpraca z zespołem
- W projektach zespołowych często musimy udostępniać sobie tymczasowe dostępy. Secret Links stał się naszym standardowym narzędziem do tego celu.Wyzwania techniczne - czego nauczyłem się przy tworzeniu
Początkowo miałem problem z tym, że niektóre klienty mailowe automatycznie usuwają fragmenty z URL-ów. Musiałem dodać specjalne ostrzeżenie i instrukcje dla użytkowników.Obsługa mobile
Stworzenie dobrego UX na mobile przy kopiowaniu URL-ów z długimi kluczami było wyzwaniem. Rozwiązałem to dodając przycisk "Kopiuj link" z feedback'iem wizualnym.
Balansowanie bezpieczeństwa i użyteczności
Początkowo countdown był 30-sekundowy. Okazało się, że to za mało - ludzie nie zdążali przeczytać długich wiadomości. Zwiększyłem do 50 sekund z możliwością konfiguracji podczas instalacji.Test mode dla deweloperów
Podczas testowania ciągle tworzyłem wiadomości, które od razu się niszczyły. Dodałem tryb testowy, w którym wiadomości nie znikają - to znacznie ułatwiło development.
Otwarte źródło - dlaczego to było ważne
Secret Links od początku był projektem open source (MIT License). Dlaczego?- Transparentność bezpieczeństwa
- Każdy może sprawdzić, jak działa szyfrowanie, czy nie ma backdoor'ów, czy klucze rzeczywiście nie trafiają na serwer.- Możliwość self-hostingu
- Organizacje z wysokimi wymaganiami bezpieczeństwa mogą uruchomić własną instancję na swoich serwerach.Secret Links jest dostępny za darmo na https://boredmarcin.com/project/secret-links na licencji MIT. Możesz go używać, modyfikować i rozpowszechniać bez ograniczeń. Jeśli masz pytania albo chcesz podzielić się swoimi przypadkami użycia, napisz do mnie.