Często używam menedżera haseł do przechowywania i udostępniania haseł. Jest wielu menedżerów haseł, które mają tę funkcję.

Hasło jest udostępniane z jednego konta na drugie, z powiadomieniem o udostępnieniu wysyłanym pocztą elektroniczną do drugiej osoby, która może zaakceptować, odrzucić, lub po prostu zignoruj ​​udział. Przekazywanie hasła jest bezpieczne, a powiadomienie o udostępnieniu odbywa się za pośrednictwem mniej bezpiecznych kanałów, takich jak poczta e-mail, wykorzystując w ten sposób moc każdej metody bez narażania bezpieczeństwa. Niektóre produkty pozwalają na udostępnienie hasła bez ujawniania hasła odbiorcy. W takim przypadku unieważnienie hasła staje się możliwe.

Bardzo polecam używanie menedżera haseł do wszystkich haseł. Niektóre komercyjne to LastPass, 1Password lub Dashlane, ale istnieje również możliwość samodzielnego hostowania, jeśli nie chcesz nikomu ufać. Szybkie wyszukiwanie w Google hasła „menedżer haseł” powinno skierować Cię na właściwe tory.

Powszechną praktyką jest wysyłanie użytkownikowi początkowego hasła e-mailem, które jest ważne tylko przez bardzo krótki czas i należy je zmienić natychmiast podczas pierwszego logowania.

To też nie jest idealne. Osoba atakująca z dostępem do odczytu wiadomości e-mail użytkownika może przechwycić to początkowe hasło przed użytkownikiem i użyć go w swoim imieniu. Użytkownik zauważy to, gdy tylko spróbuje użyć swojego początkowego hasła. Powiadomiliby administratora, że ​​hasło jest błędne, administrator zbadałby i zauważyłby nielegalny dostęp. Ale atakujący miał już trochę czasu, aby uzyskać dostęp do konta, więc może już nastąpić uszkodzenie. Ale to nadal lepsze niż wysłanie trwale ważnego hasła.

Wymaga również, aby system to obsługiwał. Nie jest to więc praktyka powszechnie stosowana.

Jeśli nie ufasz swojemu dostawcy poczty e-mail w utrzymywaniu Twoich e-maili w tajemnicy (używasz gmail, usługi pocztowej finansowanej przez eksplorację danych treść wiadomości e-mail i zarabianie na wynikach), a następnie szyfrowanie wiadomości e-mail jest opcją. Jest stary dobry PGP, nowocześniejszy PEP, standard IETF S / MIME, a także kilka niestandardowych, zastrzeżonych rozwiązań. To miło w przypadku standardów: jest ich tak wiele do wyboru! Ale wszystkie mają jedną wspólną cechę: po prostu nie przyjmują. Nakłanianie partnerów biznesowych do szyfrowania wiadomości e-mail według schematu, który rozumiesz, może być irytującą i żmudną bitwą.

Dwa czynniki

Być może nie jest to dosłownie odpowiednie dla Twojej sytuacji, ale jednym rozsądnym sposobem przesyłania wrażliwych danych kanałami, które nie są całkowicie bezpieczne, jest zapewnienie, że dostęp do tych danych wymaga dwóch oddzielnych czynników i że są wysyłane różnymi kanałami. Na przykład widziałem podejścia, w których dane są wysyłane pocztą e-mail w zaszyfrowanym pliku zip, a hasło do tych danych jest wysyłane SMS-em. W ten sposób ani ktoś, kto ma ten adres e-mail, ani ktoś, kto ma dostęp do Twojego telefonu, nie może uzyskać dostępu do poufnych informacji.

W podobny sposób lepszą praktyką może być przesłanie informacji o połączeniu pocztą e-mail. a hasło można wypowiedzieć przez telefon (zwłaszcza jeśli jest to hasło) - ale wybór ten zależy głównie od organizacji wysyłającej dane (kto jest podobno interesariuszem, który potrzebuje tych danych do zachowania poufności ), a nie komuś, kto go właśnie otrzymuje.

Jeśli jej ufasz, onetimesecret (który jest open source) istnieje właśnie w tym celu.

Kiedy wysyłasz wrażliwe osoby informacje, takie jak hasła i prywatne linki wysyłane za pośrednictwem poczty e-mail lub czatu, są kopie tych informacji przechowywane w wielu miejscach. Jeśli zamiast tego użyjesz jednorazowego łącza, informacje zostaną zachowane dla jednego wyświetlenia, co oznacza, że ​​nie może ich później przeczytać ktoś inny. Pozwala to na wysyłanie poufnych informacji w bezpieczny sposób, wiedząc, że widzi je tylko jedna osoba. Pomyśl o tym jak o autodestrukcyjnej wiadomości.

Poczta e-mail nie jest dobrym mechanizmem udostępniania haseł w postaci zwykłego tekstu, biorąc pod uwagę jej naturalnie nieszyfrowany charakter.

Jeśli hasła są udostępniane w ten sposób, usługa powinna zapewnić zmianę hasła przy pierwszym logowaniu, aby zmniejszyć ujawnienie (i umożliwienie wykrycia, czy ktoś użył skradzionego hasła), nie jest to idealna opcja, ponieważ nadal pozwala komuś skorzystać z okna możliwości dostępu do witryny, ale lepiej niż nie wiedzieć, że ktoś inny ma hasło .

Ponieważ nie wydaje się to być opcją dla ciebie, biorąc pod uwagę twoją odpowiedź na komentarz Schroedera, sugerowałbym, abyś przyjrzał się mechanizmowi, który gwarantuje szyfrowanie hasła na całej drodze między klientem a tobą - albo poprzez pełne szyfrowanie treści wiadomości e-mail lub korzystanie z uwierzytelnionej i zaszyfrowanej witryny udostępniania, na której można zaszyfrować hasła w postaci zwykłego tekstu. Zastanów się również, czy naprawdę czujesz się komfortowo, gdy inne osoby (Twój klient, inni członkowie zespołu) znają Twoje hasło, co zależy od wymagań bezpieczeństwa aplikacji, do której uzyskujesz dostęp.

Główne ryzyko w tym przypadku bądź ten, kto oprócz Ciebie zna hasło. W Twoim przypadku byłaby to przynajmniej:

• Osoba w organizacji klienta, która wygenerowała hasło i wysłała je do Ciebie e-mailem
• Każdy, kto zarządza dowolną pocztą e-mail infrastruktura między klientem a tobą
• Każdy, kto ma dostęp do sieci na dowolnej ścieżce e-mail między klientem a tobą
• Pozostali członkowie zespołu, którzy pracują z tym samym kontem i hasłem (wywnioskowane z Twojej odpowiedzi na komentarz schroedera)
• Każdy, kto może mieć dostęp do Twojej skrzynki pocztowej (np. Twój komentarz dotyczący pozostawienia klienta poczty bez opieki)

Jeśli jedynym celem hasła jest uniknięcie nieautoryzowanego dostępu do usług B2B i czujesz się komfortowo, gdy inne osoby znają twoje hasło, możesz przyjrzeć się szyfrowaniu przy dystrybucji haseł. Podczas gdy wiele serwerów SMTP stosuje szyfrowanie do przesyłania danych między przeskokami serwerów poczty, nie ma gwarancji szyfrowania, a e-maile z natury nie są szyfrowane, więc hasło będzie przechowywane w postaci zwykłego tekstu przynajmniej podczas przetwarzania każdego przeskoku przesyłania poczty (SMTP).

Oznacza to, że musisz przyjrzeć się szyfrowaniu od końca do końca, aby upewnić się, że hasło nie jest dostępne dla nikogo, kto szpieguje, na przykład PGP, S / MIME lub inna zastrzeżona technologia szyfrowania asymetrycznego. Gwarantują one poufność hasła podczas przesyłania, a nadal możesz używać poczty e-mail do jego dystrybucji - kosztem trudnej konfiguracji i kosztów operacyjnych.

Możesz skompromitować i użyć czegoś w rodzaju zaszyfrowanego Plik ZIP lub dokument Office ze wstępnie zdefiniowanym hasłem szyfrowania, które jest udostępniane za pośrednictwem bezpiecznego kanału (np. Połączenie telefoniczne), co zmniejsza zarówno narzut operacyjny, jak i ochronę hasła. Podobnie plik hostowany w chmurze z hasłami i chroniony bezpiecznym współdzielonym sekretem miałby te same zalety / wady.

Nie rozumiem, dlaczego wysyłasz im hasła?

Klienci ustawiają swoje preferowane hasło, ty je haszujesz, przechowujesz skrót i nikt poza klientem / jego programem do zarządzania hasłami nie wie oryginalne hasło (nawet nie Ty), a gdy je zapomną, wyślesz im link do resetowania.

Jeśli jednak naprawdę musisz wysłać mu hasło, sugeruję, abyś wysłał mu link do dynamicznie generowanego strona internetowa, która wyświetla jego hasło (tylko raz).

musisz tymczasowo zapisać coś takiego w swojej bazie danych

  emailTocken char (32) hasło varchar + - -------------------------------- + ----------------- - + | emailTocken | hasło | + ---------------------------------- + -------------- ---- + | 202CB962AC59075B964B07152D234B70 | jhds7ytht_id | | CF297E613A7F7892A3BF348EE526ABAD | hdhdbdue874 # | | 8F14E45FCEEA167A5A36DEDD4BEA2543 | yeheb8cvddt5) | | 2510C39011C5BE704182423E3A695E91 | 6 # hdyd98_jee | | 8F14E45FCEEA167A5A36DEDD4BEA2543 | yhrtxbxv48_e | + ---------------------------------- + -------------- ---- +  

i wyślij mu wiadomość e-mail, w której ujawniasz tylko e-mailTocken, a nie hasło

  Witaj kliencie. Skorzystaj z tego łącza, aby zobaczyć swoje hasło https://example.com/showPassword?emailTocken=8F14E45FCEEA167A5A36DEDD4BEA2543

na serwerze internetowym, gdy ktoś zażąda tego linku, wykonaj następujące czynności

1. wybierz hasło który ma podany emailTocken
2. usuń jego rekord z bazy danych

Teraz pierwsza osoba, która zażąda tego linku, zobaczy coś takiego jak

  Witaj, kliencie, twoje hasło to yeheb8cvddt5) UWAGA: USUNIEMY TO HASŁO Z NASZYCH SERWERÓW, WIĘC MUSISZ JE PAMIĘTAĆ / ZAPISAĆ  

Jeśli ktoś później zażąda tego samego linku, zobaczy coś like

  Przepraszamy, to hasło nie istnieje lub było wcześniej przeglądane!  

Zalety tego podejścia w porównaniu z wysłaniem hasła w wiadomości e-mail:

1. hasło jest ujawniane tylko 1 raz dla pierwszego widza, a nie dla tego, kto zobaczy wiadomość później .
2. jeśli ktoś inny zobaczył hasło jako pierwszy (człowiek pośrodku), uprawniony użytkownik nie będzie mógł go zobaczyć i poprosi o pomoc, co da nam znać, że istnieje stało się coś złego, lepiej niż ktoś inny to widzi, a my nawet nie wiemy. Mam nadzieję, że Twój program pocztowy nie zażąda tego automatycznie z jakiegokolwiek powodu :( .

wady tego podejścia w porównaniu z wysyłaniem hasła w wiadomości e-mail:

1. wymaga serwera WWW
2. prostego wysyłania hasła w e-mailu

Ponieważ ja powiedziałem ci wcześniej, nikt poza klientem nie powinien znać hasła i nigdy nie próbowałem tego podejścia, ale przynajmniej jest to lepsze niż ujawnianie hasła w postaci zwykłego tekstu w EMAILU, który może znajdować się na wielu komputerach / serwerach przez jakiś czas.

Mam mały projekt, który stworzyłem, i nazywam go „Bezpieczną usługą przesyłania wiadomości”, który pozwoli ci wpisać wiadomość i wygenerować łącze do wyświetlenia tej wiadomości. Po wyświetleniu wiadomości jest ona usuwana z bazy danych. Obsługuje nawet wysyłanie wiadomości e-mail po przeczytaniu wiadomości!

Wpisz wiadomość i naciśnij „wyślij”, nasz serwer wygeneruje identyfikator GUID oparty na uuidgenerator.net, losowym 8-znakowym haśle na passwordwolf.com (który nie jest przechowywany w naszej bazie danych) i zaszyfruje twoją wiadomość za pomocą AES-256-CBC. Następnie otrzymasz łącze zawierające identyfikator GUID i hasło umożliwiające wyświetlenie wiadomości (lub wysłanie do kogoś, kto przejrzy wiadomość), gdy tylko zostanie użyty link, wiadomość nie będzie już istnieć w naszej bazie danych.

Masz teraz możliwość wysłania przez naszą usługę wiadomości e-mail po przeczytaniu wiadomości przez odbiorcę. Kiedy podajesz swój adres e-mail, szyfrujemy go przed wstawieniem do naszej bazy danych przy użyciu tej samej metody szyfrowania, co Twoja tajna wiadomość, w tym tego samego hasła. To hasło nie jest przechowywane na naszym serwerze, jest podawane jako część łącza do wyświetlenia wiadomości.

Ponieważ wszystko wysyłane na nasz serwer jest szyfrowane za pomocą AES-256-CBC, a hasło istnieje tylko w podany link, co oznacza, że ​​tylko Ty i osoba, do której wyślesz łącze, mogą wyświetlić wiadomość. Jeśli ktokolwiek chciałby to zobaczyć, musi to brutalnie wykorzystać. Pięćdziesiąt superkomputerów, które mogłyby sprawdzić miliard miliardów (1018) kluczy AES na sekundę (gdyby takie urządzenie mogło kiedykolwiek powstać), wymagałoby teoretycznie około 3 × 1051 lat, aby wyczerpać 256-bitową przestrzeń klucza. Zrobiliśmy co w naszej mocy, aby te wiadomości nie były widoczne dla nikogo poza osobą mającą łącze, nawet jeśli ta osoba ma dostęp do bazy danych, ale nie gwarantujemy i nie odpowiadamy za jakiekolwiek szkody spowodowane korzystaniem z tej usługi.

Usługa bezpiecznego przesyłania wiadomości obsługuje również interfejs API, co oznacza, że ​​potencjalnie możesz automatycznie wygenerować i wysłać wiadomość e-mail do użytkowników rejestrujących się z łączem umożliwiającym wyświetlenie hasła.

W ten sposób dane w bazie danych jest przechowywana, jak widać, nie ma możliwości odzyskania treści wiadomości za pomocą informacji w tabeli, ponieważ wymaga to specjalnego hasła, które jest dołączane tylko do linku, który otrzymujesz podczas tworzenia wiadomość i nie jest przechowywana w bazie danych.

Przede wszystkim jest to zła sytuacja. Wygląda na to, że udostępniasz konta użytkowników. Czasami nie ma dobrej alternatywy, ale nie należy jej używać w przypadku niczego szczególnie wrażliwego, ponieważ znacznie trudniej jest skontrolować użycie zasobu, gdy wiele osób loguje się pod tą samą nazwą.

Jeśli naprawdę konieczne jest, aby wiele osób korzystało z tych samych kont, a następnie poświadczenia należy dostarczyć osobiście.

Prawdopodobnie nie jest to praktyczne, więc najlepszą opcją jest wysłanie ich za pośrednictwem telefonu stacjonarnego. (Przynajmniej w większości krajów). Telefony stacjonarne są stosunkowo trudne do przechwycenia, aw większości krajów operatorom telefonicznym nie wolno nasłuchiwać bez nakazu sądowego. Rządowe agencje szpiegowskie mogą nas słuchać, ale jeśli chcą twoich haseł, po prostu biją cię, dopóki ich nie przekażesz.

Mniej więcej na tym samym poziomie bezpieczeństwa są zaszyfrowane wiadomości e-mail przez GPG lub podobne. Osobom trzecim łatwiej jest przechwytywać i przechowywać dane, ale trudniej jest im je odczytać, dopóki nie będą miały wystarczająco dużo czasu na złamanie klucza. Pamiętaj, aby zmieniać hasło co kilka lat i upewnić się, że nie używasz tego samego listu seryjnego za każdym razem, ponieważ ułatwia to jego złamanie.

Jeśli nie możesz ich przyłączyć do tego, kod książki to Twój następny najlepszy zakład. Musi to być książka, którą i tak każdy ma i której używa przez cały czas, więc może to być trochę trudne. Typowy format to coś w rodzaju numeru strony-numeru akapitu-numeru słowa. Niech hasła będą składać się z czterech lub pięciu słów i będzie dobrze działać. Lub przeliteruj, używając pierwszej litery każdego określonego słowa, jeśli to konieczne.

Jeśli kod książki nie zadziała, dopóki hasło nie zawiera żadnych słów ani struktur przypominających słowa, do kryptogramów w gazecie wystarczą proste podstawienia lub szyfry transpozycyjne, takie jak najbardziej zdeterminowani napastnicy. Ale hasło musi składać się z losowych znaków, w przeciwnym razie analiza statystyczna szybko je obejmie i nadal musisz dostarczyć klucz szyfrowania przez bezpieczny kanał. Oczywiście tą metodą szyfrujesz tylko hasło, aby ograniczyć powierzchnię ataku i, najlepiej, w ogóle nie wspominasz o tym, że zaszyfrowałeś je w pozostałej części wiadomości e-mail. Cała dyskusja na temat faktu, że hasło jest zaszyfrowane i jak musi być przez bezpieczny kanał.

Istnieje typowy przypadek użycia dla rozproszonych zespołów programistycznych, w którym SysOps i TeamMembers tworzą poświadczenia do zasobu (DataBase, usługa, serwer) i muszą przekazać je zespołowi. JEŚLI dodasz nowego członka do zespołu:

• Nie możesz po prostu zaszyfrować hasła.
• Nie możesz po prostu zresetować hasła, bo przestanie ono działać dla reszty zespołu.

Używamy rozproszonego menedżera haseł. Dzięki temu możemy dodać nowe hasło i udostępnić je pojedynczym osobom lub grupom. Otrzymasz wiadomość e-mail, np. „BOFH-1 udostępnił hasło 'JenkinAdmin'”. Musisz się zalogować, aby zobaczyć prawdziwe hasło, które będzie przesyłane przez https.

Scentralizowane narzędzie może być przesadą w niektórych scenariuszach, ponieważ zmusza cię do instalacji i konfiguracji. To świetnie, jeśli cały dział używa go do aktualizacji. Tylko jedna osoba musi zaktualizować poświadczenie w menedżerze haseł. Używamy narzędzia open source, ale konkretne programy są dokładniej omówione w Zaleceniach dotyczących oprogramowania

Prawidłowo, wysyłanie hasła w wiadomości e-mail jest niebezpieczne.

Bezpieczny protokół początkowego konta jest następujący:

Wyślij użytkownikowi jednorazowe, wygasające hiperłącze i zezwól użytkownikowi ustawić swoje początkowe hasło z tego linku. Następnie opcjonalnie sprawdź, czy użytkownik skonfigurował drugi czynnik, a następnie opcjonalnie sprawdź tożsamość użytkownika w inny sposób (połączenie wideo?) Na koniec zapewnij kontu użytkownika dostęp, którego potrzebują.

Sugerowałbym użycie Signal do wysyłania i odbierania haseł. Jest to kompleksowo zaszyfrowana aplikacja do czatu.

Wiadomości i połączenia Signal są zawsze szyfrowane od końca do końca i starannie zaprojektowane, aby zapewnić bezpieczeństwo komunikacji. Nie możemy odczytać Twoich wiadomości ani zobaczyć Twoich połączeń, i nikt inny też nie może.

Żaden e-mail nie jest bezpieczny, ponieważ nawet jeśli używasz SSL na swoich serwerach pocztowych, istnieje zapis komunikat na dysku serwera, który może odczytać administrator. Tylko e-mail zaszyfrowany za pomocą PGP / GPG lub SMIME byłby bezpieczny.

Ktoś dodał następujący fragment do mojej odpowiedzi. Nie słyszałem o nich, więc nie mogę polecić.

Poza Signal - można skorzystać z innej szyfrowanej opcji wymiany wiadomości, która nie wymaga potwierdzania identyfikatora poprzez klikanie linków lub podawanie e-mail itp. To także wieloplatformowość, co jest bardzo ważne. Jest to

1. na Androida: aplikacja do konwersacji
2. dla systemu Linux i Windows: aplikacja Gajim

Może używać szyfrowania PGP lub OMEMO - wtyczka może wymagać zainstalowania osobno.

Jest też inna metoda, prawdopodobnie najlepsza w Twojej sytuacji.

Wymaga to posiadania strony z SSL i na stronie internetowej i osadzone pudełko. Ktoś może napisać wiadomość w tym polu i po wysłaniu wiadomość powinna zostać zaszyfrowana [tj.] Kluczem publicznym PGP, który można automatycznie odszyfrować tylko w e-mailu z komputera.

Poproś ich, aby zamiast tego podnieśli telefon i zadzwonili do Ciebie. Korzystanie z komunikacji poza pasmem znacznie zmniejsza prawdopodobieństwo uzyskania przez podsłuchującego dostępu do Twoich informacji. Dzieje się tak po części dlatego, że nie jest nieprawdopodobne, że osoba atakująca złamałaby twój system poczty e-mail lub system telefoniczny, ale szanse na to, że włamali się do obu, są niskie. jeśli możesz podzielić istotne informacje (np. nazwę użytkownika w e-mailu, hasło telefoniczne itp.), to staje się to trudniejsze dla atakującego, w porównaniu ze wzrostem wymaganej od Ciebie pracy.

Jeśli Twój adres e-mail jest wstępnie ustawiony przez firmę, rozwiązaniem jest całkowite wyeliminowanie hasła (hasło jest zapełnione długim, skomplikowanym itp. ciągiem, którego nikt nie zna).

Następnie zażądaj nowe (chociaż funkcja „Zapomniałem hasła”), która wysyła link do resetowania na Twój adres e-mail.

Stary dobry telefon to wypróbowana i prawdziwa metoda.

Poza tym uścisk dłoni SSH to dobra metoda ...

Zarówno Ty, jak i odbiorca generujecie klucz SSH. Generujesz hasło i szyfrujesz je za pomocą swojego klucza. Wysyłasz zaszyfrowane hasło do klienta. Dodają dodatkowe szyfrowanie do wiadomości za pomocą swojego klucza. Następnie wysyłają z powrotem podwójnie zaszyfrowaną wiadomość. Odszyfrowujesz tę wiadomość, pozostawiając tylko hasło zaszyfrowane kluczem odbiorcy. Odsyłasz tę wiadomość. Odszyfrowują go, używając swojego hasła, aby uzyskać hasło. W ten sposób niezaszyfrowane dane nigdy nie trafiają do sieci.

OAuth jest alternatywą dla dostępu do systemów stron trzecich bez konieczności konfigurowania uwierzytelniania hasłem w tych systemach i eliminuje potrzebę wymiany haseł. Oczywiście wymagałoby to od systemów obsługi OAuth, co nie zawsze ma miejsce.

Pierwszą rzeczą, która przychodzi mi do głowy, jest szyfrowanie asymetryczne (np. GPG). Może to być szczególnie przydatne bez zbytniego komplikowania rzeczy.

Znajdź lub skonfiguruj serwer kluczy publicznych i pozwól wszystkim udostępniać klucze publiczne. Następnie, gdy chcesz udostępnić konkretnemu odbiorcy coś poufnego, możesz złapać jego klucz i zaszyfrować zawartość. Nikt inny nie pozna oryginalnej treści poza odbiorcą.

Przykładowy e-mail wyglądałby następująco:

Cześć iBug,

Oto Twoje dane logowania do Wymiana stosu bezpieczeństwa informacji. Jest zaszyfrowany Twoim kluczem DEADBEEF znalezionym na naszym firmowym serwerze kluczy.

  < GPG Encrypted Message >  

Możesz użyć SendPass ( https://sendpass.app)

Moim zdaniem dwa największe zagrożenia związane z wysyłaniem haseł w postaci zwykłego tekstu to to, że mogą one znajdować się w archiwizuje się, loguje lub nadal w skrzynce pocztowej użytkownika, a druga to przechwycenie hasła i faktyczny odbiorca o tym nie wie (a zatem nie powiadamia administratora).

Aby stawić czoła tym zagrożeniom, stworzyłem bezpłatną aplikację, której możesz użyć do wysłania jednorazowego kodu, którego może użyć odbiorca w celu odzyskania hasła. Opublikowałem SendPass, aby pomóc innym, zwłaszcza osobom nietechnicznym, ale może się przydać również tobie.

SendPass oferuje darmowy, łatwy i bezpieczny sposób udostępniania haseł. SendPass działa poprzez generowanie unikalnego, jednorazowego kodu, który możesz wysłać do swojego odbiorcy. Kodu można użyć tylko raz, po czym hasło zostanie natychmiast usunięte.