Bezpečné sdílení hesel v týmu: srovnání 5 metod

Ověřeno ke dni 2026-10-02. Výchozí uchovávání dat ve Slacku a údaje o výměně SIM karet uvádějí zdroje na konci tohoto průvodce. Chování LinkPilotu odpovídá stránce o architektuře zabezpečení.

Sdílené trezory ve správci hesel

Pro přihlašovací údaje, které platí měsíce, je správnou výchozí volbou sdílený trezor ve správci hesel (1Password, Bitwarden, Keeper, Psono a další). Heslo je na jednom místě, po změně se aktualizuje všem, přístup se uděluje po jednotlivých kolekcích, při odchodu člověka stačí odebrat licenci a týmové tarify přidávají protokoly událostí. Nevýhoda: každý, kdo heslo potřebuje, musí být v trezoru. Klientovi, freelancerovi nebo novému kolegovi, který ještě nemá účet, tak položku z trezoru předat nejde.

Jednorázový šifrovaný odkaz

Pro okamžik předání je správným nástrojem jednorázový tajný odkaz. Vložíte heslo, dostanete adresu URL a pošlete ji kanálem, který už používáte. Příjemce ji otevře jednou: obsah se zobrazí a pak zničí a adresa URL, která zůstane ve vlákně, už nikam nevede. Přidejte krátkou dobu platnosti, aby neotevřený odkaz sám vypršel, a heslovou frázi předanou druhým kanálem, aby samotný zachycený odkaz nebyl k ničemu. Vytvořit ho můžete hned teď a bez účtu. Stejný postup pro tokeny popisují stránky LinkPilot vs. Password Pusher a jak bezpečně sdílet klíče API.

Chatovací aplikace (Slack, Teams, Signal)

Chat působí pomíjivě, ale je to naopak. Podle dokumentace samotného Slacku se v placených tarifech „data ve výchozím nastavení uchovávají po celou dobu existence pracovního prostoru“ a vlastníci pracovního prostoru je mohou exportovat. Teams a Google Chat podléhají zásadám uchovávání a eDiscovery, které jsou navržené tak, aby zprávy nešlo nechat zmizet. Signal je na tom lépe (mizející zprávy, žádná historie na serveru), ale i tak je to kopie ve dvou telefonech se snímky obrazovky a zálohami, které nemáte pod kontrolou. Každý chatovací klient také zobrazí náhled odkazu hned po jeho vložení, a proto musí být jednorázový odkaz navržený tak, aby ho náhled nemohl zničit.

E-mail

Heslo poslané e-mailem leží jako prostý text na poštovním serveru odesílatele i příjemce, v zálohách obou a v každém zařízení, které schránku synchronizovalo. Přežije přeposlání, archivaci i napadení účtu a únik dat ze schránky i po letech odhalí všechny přihlašovací údaje, které jí kdy prošly. E-mailem můžete klidně poslat odkaz na tajnou zprávu, ale samotná tajná zpráva do e-mailu nikdy nepatří.

Ústně, telefonicky a přes SMS

Heslo přečtené nahlas ve stejné místnosti nevytvoří vůbec žádnou kopii. Je to jediná metoda na této stránce, která nezanechá žádnou stopu, a zároveň jediná, která nefunguje ve větším měřítku. SMS je její nebezpečný příbuzný: zpráva zůstává v obou telefonech i v záznamech operátora a telefonní čísla se kradou. Centrum FBI pro stížnosti na internetovou kriminalitu zaznamenalo jen v roce 2021 celkem 1611 stížností na výměnu SIM karty se ztrátami přes 68 milionů $, zatímco za celé období 2018–2020 jich bylo 320. SMS je přijatelná pro krátkou heslovou frázi, která je bez odděleně doručeného odkazu k ničemu. Pro samotné heslo přijatelná není.

Šifrování probíhá ve vašem prohlížeči

Od 29. září 2026 se obsah šifruje na straně klienta pomocí AES-GCM-256 s 256bitovým klíčem vygenerovaným ve vašem prohlížeči, ještě než se cokoli odešle. K nám dorazí jen šifrový text, a to do tabulky secret_links, která je oddělená od tabulek se statistikami kliknutí. Přiložené soubory se šifrují stejně, klíčem odvozeným z klíče tajné zprávy, takže jeden odkaz otevře obojí. Technické podrobnosti: šifrování na straně klienta při sdílení tajných zpráv.

Klíč je v části odkazu za znakem #

Sdílený odkaz vypadá takto: shrd.link/s/<slug>#k=<key>. Vše za znakem # je dešifrovací klíč a prohlížeče tuto část odkazu nikdy neposílají na žádný server: ani nám, ani síti CDN, která obsluhuje stránku pro zobrazení. Klíč nikdy nedostaneme, takže tajnou zprávu nemůžeme přečíst, obnovit, když se odkaz ztratí, ani adresu URL později znovu sestavit. Řečeno přímo: kdo má celý odkaz, má i klíč.

Heslová fráze přidává druhý faktor

V tarifu Pro se heslová fráze posílí pomocí PBKDF2-SHA256 (210 000 iterací) a pomocí HKDF-SHA256 se zkombinuje s klíčem z odkazu, takže tajnou zprávu nedešifruje samotný odkaz ani samotná heslová fráze. Zvlášť se odešle hash heslové fráze SHA-256, aby server mohl odmítnout vrátit šifrový text tomu, kdo frázi nezná. Samotnou heslovou frázi nikdy nezapisujeme do databáze ani do protokolů. Počet pokusů je omezen na 5 za minutu z jedné adresy IP u každé tajné zprávy a každý neúspěšný pokus se zapíše do auditního protokolu. Pro srovnání: NIST SP 800-63B vyžaduje, aby se uložená hesla solila a hashovala funkcí pro odvození klíče, například PBKDF2, s alespoň 10 000 iteracemi.

„Zničit po přečtení“ funguje atomicky

Odkaz se zapnutou volbou „Zničit po přečtení“ dává příjemci jedinou příležitost obsah vidět. Zobrazení se zaznamená jedinou databázovou funkcí se zamykáním řádků, takže dva lidé, kteří odkaz otevřou ve stejném okamžiku, si ho nemohou přečíst oba. Po dosažení limitu zobrazení se stav změní na zničeno a uložený obsah se přepíše hodnotou [REDACTED]. Při dalších návštěvách se vrátí HTTP 410 a srozumitelná stránka s oznámením „už zobrazeno“. Tajné zprávy, kterým vypršela platnost nebo které byly zneplatněny, se přepisují stejně a obnovit je záměrně nejde.

Náhledy odkazů ho nemohou zničit

Požadavek GET na koncový bod pro zobrazení vrací jen metadata: stav a informaci, zda je potřeba heslová fráze. Zobrazení se zaznamená výhradně při výslovném požadavku POST, který spustí člověk kliknutím na „Zobrazit“, a každá odpověď se zobrazeným obsahem nese hlavičku Cache-Control: no-store. Chatovací klienti a e-mailové bezpečnostní brány stahují odkazy obyčejnými požadavky GET, takže jejich náhledy nic nevidí a nic nezničí. Test, který si můžete vyzkoušet: skenery odkazů a jednorázové tajné zprávy.

Co stále vidíme: tři poctivá omezení

1. Tajné zprávy vytvořené před 29. zářím 2026 byly až do vypršení platnosti uloženy jako prostý text. Nikdy jsme je potichu nepřepsali: fungovaly dál jako dřív a s vypršením platnosti zanikly. Provozovatel mohl kteroukoli z nich přečíst, dokud byla aktivní. Přílohy nahrané před tímto datem zůstaly uložené jako nešifrované soubory.
2. Kdo má celý odkaz, má i klíč. Šifrování na straně klienta vyřazuje z okruhu důvěry nás, naši databázi i naši okrajovou síť. Nechrání ale odkaz, který někdo přeposlal, zachytil na snímku obrazovky nebo který se zaznamenal v protokolu na straně příjemce.
3. Název, velikost a typ souboru vidíme i nadále. Jsou uložené ve sloupcích s metadaty, obsah souboru ne. U každého pokusu o zobrazení si také ukládáme časové razítko, hashovanou adresu IP (SHA-256 s denně měněnou solí, zkrácenou), přibližnou polohu a user agent. Nikdy ne tajnou zprávu, samotnou heslovou frázi ani nezahashovanou adresu IP a u příjemce žádné cookies.

1. Hesla, klíče API, tokeny a připojovací řetězce se nikdy nepíšou do e-mailu, chatu ani SMS. Ani jednou, ani „jen tentokrát“.
2. Dlouhodobé sdílené přihlašovací údaje jsou v týmovém trezoru. Sdílí se položka v trezoru, ne hodnota.
3. Jednorázová předání probíhají jednorázovým tajným odkazem s nejkratší použitelnou dobou platnosti a se zapnutou volbou „Zničit po přečtení“.
4. Odkaz a heslová fráze putují různými kanály (odkaz e-mailem, heslová fráze telefonicky nebo soukromou zprávou v chatu) a heslová fráze se nikdy nepoužívá znovu.
5. Při nástupu dostane nový kolega úvodní přihlašovací údaje jednorázovými odkazy a při prvním přihlášení je změní. Při změně role nebo odchodu se přístup do trezoru upraví ještě týž den a všechny přihlašovací údaje, které člověk měl mimo trezor, se změní.
6. Cokoli, co se kdy dostalo do chatu nebo e-mailu, se změní, jakmile se s tím příště pracuje, a zpráva v chatu se smaže. Každé neočekávané zobrazení na časové ose tajné zprávy znamená okamžitou změnu.