Ochrona hasłem w usługach przesyłania plików: przegląd
Przegląd funkcji ochrony hasłem w usługach przesyłania plików: wymagania siły hasła, integracja z szyfrowaniem oraz doświadczenie użytkownika.
Ochrona hasłem w usługach transferu plików waha się od pozornej do kryptograficznie znaczącej. WeTransfer Pro dodaje bramkę hasłową sprawdzaną po stronie serwera przed odblokowaniem pobierania, ale plik pozostaje deszyfrujący przez WeTransfer. Smash, SwissTransfer i Dropbox Transfer stosują podobny model. Usługi takie jak Tresorit Send i HexaTransfer używają hasła (lub klucza pochodnego) jako wejścia do faktycznego szyfrowania pliku za pomocą PBKDF2 lub Argon2id — co oznacza, że bez hasła zaszyfrowany tekst jest matematycznie nieczytelny nawet dla samego dostawcy usług.
Bramki po stronie serwera a klucze kryptograficzne
Kluczowe znaczenie ma miejsce, w którym hasło jest sprawdzane. W modelu bramki po stronie serwera dostawca przechowuje hash hasła (mamy nadzieję, że bcrypt lub Argon2) i weryfikuje wpisaną wartość przed przesłaniem pliku. Sam plik jest zaszyfrowany kluczem przechowywanym przez dostawcę. Jeśli atakujący naruszy bazę danych lub sąd zmusi dostawcę, pliki wychodzą w postaci jawnej niezależnie od siły hasła.
W modelu klucza kryptograficznego hasło jest przekazywane przez funkcję derywacji klucza (KDF) — zazwyczaj PBKDF2 z ponad 600 000 iteracjami lub Argon2id z dostrojonym kosztem pamięci — aby wygenerować rzeczywisty klucz szyfrowania pliku. Brak hasła oznacza brak klucza, a brak klucza oznacza brak tekstu jawnego. Dostawca dosłownie nie może odszyfrować pliku bez hasła, nawet na podstawie nakazu sądowego.
WeTransfer Pro: wygodna bramka, nie szyfrowanie
WeTransfer wprowadził ochronę hasłem w planach Pro (ok. 10 €/miesiąc). Wpisz hasło przy przesyłaniu, przekaż je poza pasmem, odbiorca wpisuje je na stronie pobierania. Pod spodem WeTransfer hashuje i porównuje — plik jest szyfrowany AES-256 w spoczynku przy użyciu kluczy zarządzanych przez AWS KMS, a nie pochodnych od Twojego hasła.
Ten projekt jest odpowiedni dla zwykłej ochrony przed przekazywaniem linków, ale nie spełnia modeli zagrożeń, w których nie ufasz samemu WeTransfer ani dostawcy hostingu. Jest też podatny na brute-force online, chyba że istnieją limity liczby prób (WeTransfer nie dokumentuje publicznie swoich limitów).
Smash: hasło plus weryfikacja e-mail
Smash oferuje ochronę hasłem we wszystkich płatnych planach. Wyjątkowe jest połączenie z opcjonalną weryfikacją e-mail odbiorcy. Można wymagać, aby odbiorca udowodnił posiadanie określonego adresu e-mail (przez magic link) ORAZ wpisał hasło. Pokonuje to powszechny atak polegający na przekazaniu linku i przechwyceniu hasła.
Hasło nadal jest bramką po stronie serwera, a nie wejściem do derywacji. Jednak dwuskładnikowy charakter (coś co wiesz + coś do czego masz dostęp) znacznie podnosi poprzeczkę. Przy wysyłaniu umów do konkretnej strony to rozsądny kompromis między użytecznością a bezpieczeństwem.
SwissTransfer: proste, opcjonalne hasło
Pole hasła SwissTransfer jest opcjonalne i stosowane po stronie serwera. Usługa jest bezpłatna, nie wymaga konta i jest hostowana wyłącznie na szwajcarskiej infrastrukturze Infomaniak. Hasło chroni przed swobodnym udostępnianiem linków; nie zmienia historii szyfrowania (pliki są szyfrowane AES-256 w spoczynku przy użyciu kluczy zarządzanych przez usługę).
UX jest przejrzysty: jedno pole wyboru, jedno pole hasła, jedno potwierdzenie. Brak miernika siły hasła, brak minimalnych wymagań złożoności. Można wpisać „123" i zostanie zaakceptowane — co oznacza, że hasło jest tylko tak silne, jak je nadawca ustawi.
Dropbox Transfer: hasła z polityką administratora
Dropbox Transfer w planie Standard i wyższych obsługuje hasła z konfigurowalnymi przez administratora minimalnymi wymaganiami złożoności. Administratorzy mogą wymagać co najmniej 8 znaków, mieszanych wielkości liter, cyfr i symboli. Sprawdzanie hasła odbywa się po stronie serwera, zanim Dropbox prześle plik z regionu USA lub UE (w zależności od ustawień zespołu). Integracja SAML SSO dla Dropbox Business całkowicie zastępuje hasło uwierzytelnionym dostępem opartym na tożsamości.
Aspekt korporacyjny to rejestrowanie audytu: każda próba wpisania hasła jest rejestrowana, w tym nieudane próby mogące wskazywać na credential stuffing. Dla dowodów SOC 2 i ISO 27001 ten ślad ma znaczenie.
Tresorit Send: klucz szyfrowania pochodny od hasła
Tresorit Send stosuje podejście kryptograficzne. Gdy ustawiasz hasło, Tresorit przepuszcza je przez PBKDF2, aby wyprowadzić dodatkową warstwę szyfrowania na już zaszyfrowanym pliku. Bez hasła plik nie może być odszyfrowany nawet przez Tresorit. Firma ma siedzibę w Szwajcarii, posiada certyfikat ISO 27001 i publikuje swój whitepaper kryptograficzny.
Zachowanie widoczne dla użytkownika jest podobne do WeTransfer: wpisz hasło, udostępnij je. Ale matematyka jest fundamentalnie różna. Naruszenie bazy danych Tresorit ujawnia zaszyfrowany tekst i salty, a nie możliwe do odzyskania pliki.
HexaTransfer: klucz we fragmencie URL z opcjonalnym opakowaniem hasłem
Podstawowy model HexaTransfer używa 256-bitowego losowego klucza osadzonego w fragmencie URL (po znaku #), który przeglądarki nigdy nie przesyłają do serwera. Ten klucz odszyfrowuje zaszyfrowany tekst AES-256-GCM po stronie klienta po pobraniu. Gdy dodajesz hasło, PBKDF2 z 600 000 iteracjami opakowuje losowy klucz, wymagając hasła do jego użycia.
To warstwowe podejście oznacza, że do deszyfrowania muszą się spotkać trzy elementy: zaszyfrowany tekst (z serwera), fragment URL (z linku) i hasło (z kanału poza pasmem). Przechwycenie jakiegokolwiek jednego z nich z osobna nic nie daje. To model pierwotnie stosowany przez Firefox Send i dopracowany przez nowoczesne usługi dbające o prywatność.
Macierz porównawcza
| Usługa | Typ hasła | KDF | Min. siła | Ograniczenie prób | |---------|---------------|-----|--------------|--------------| | WeTransfer Pro | Bramka serwera | Brak | Nie egzekwowane | Nieudokumentowane | | Smash | Bramka + e-mail | Brak | Opcjonalna polityka | Tak | | SwissTransfer | Bramka serwera | Brak | Nie egzekwowane | Tak | | Dropbox Transfer | Bramka + SSO | Brak | Konfigurowalne | Tak | | Tresorit Send | Kryptograficzne KDF | PBKDF2 | Min. 8 znaków | Tak | | HexaTransfer | Kryptograficzne KDF | PBKDF2 600k | Egzekwowane | Tak |
Siła hasła i kwestia entropii
„Silne hasło" do transferu pliku powinno osiągać co najmniej 70 bitów entropii — cztery losowe słowa z dużego słownika (w stylu diceware) lub 12+ losowych znaków. PBKDF2 przy 600 000 iteracjach dodaje ok. 20 bitów efektywnej entropii przeciwko atakom offline, wprowadzając umiarkowanie silne hasło w obszar naprawdę trudny do złamania.
Słabym ogniwem jest zazwyczaj dostarczanie hasła. Wysyłanie hasła przez SMS na ten sam numer telefonu, na który wysyłasz link, niweczy sens ochrony. Używaj osobnego kanału: Signal dla linku, rozmowa telefoniczna dla hasła albo odwrotnie. W transferach B2B ustalaj hasła podczas istniejącej rozmowy wideo, zamiast tworzyć nowe kanały.
Kiedy hasło nie wystarczy
W przypadku naprawdę wrażliwych transferów — dokumentów finansowych M&A, kodu źródłowego, dokumentacji medycznej — należy rozważyć połączenie ochrony hasłem z weryfikacją e-mail odbiorcy, krótkim wygasaniem (24 godziny) i powiadomieniami o pobraniach. Jeszcze lepiej użyć usługi z natywnym uwierzytelnianiem odbiorcy przez magic link lub SSO.
Ochrona hasłem to użyteczna dodatkowa warstwa, a nie kompletny system kontroli dostępu. Należy ją łączyć z innymi kontrolami odpowiadającymi Twojemu modelowi zagrożeń i nie zakładać, że samo pole hasła oznacza, iż usługa nie może czytać Twoich plików — często nadal może.
Wypróbuj na hexatransfer.com — bezpłatnie, bez konta, do 10 GB.
Wysyłaj duże pliki bezpiecznie z szyfrowaniem end-to-end
Przesyłaj pliki do 10 GB za darmo z szyfrowaniem end-to-end. Bez rejestracji. Twoje pliki są szyfrowane w przeglądarce przed przesłaniem — nikt inny nie może ich odczytać.
Wyślij plik