Co byś zrobił, gdybyś zdał sobie sprawę, że Twój dostawca hostingu poczty e-mail widzi Twoje hasła?


31

W zeszłym roku otrzymaliśmy od naszego dostawcy hostingu wiadomość e-mail dotyczącą jednego z naszych kont - została ona przejęta i wykorzystana w celu zapewnienia dość hojnej pomocy w zakresie spamu.

Najwyraźniej użytkownik zresetował hasło do odmiany imienia (nazwisko jest czymś, co pewnie można się domyślić po raz pierwszy). Natychmiast została zhakowana w ciągu tygodnia - jej konto wysłało zalew 270 000 e-maili ze spamem - i było bardzo szybko zablokowany.

Jak dotąd nic szczególnego. Zdarza się. Zmieniasz hasła na coś bardziej bezpiecznego, edukujesz użytkownika i idziesz dalej.

Jednak coś mnie niepokoiło bardziej niż fakt, że jedno z naszych kont zostało przejęte.

Nasz dostawca hostingu, starając się być pomocnym, podał nam hasło w następującej wiadomości e-mail:

wprowadź opis zdjęcia tutaj

Jestem zdumiony. Niedługo mamy przedłużyć naszą umowę - i to wydaje się łamaczem umów.

Jak często dostawca hostingu może znaleźć rzeczywiste hasło używane na koncie?

Czy większość dostawców hostingu ma dział zajmujący się nadużyciami konta, który ma większy dostęp niż przedstawiciele pierwszej linii (i może wyszukiwać hasła, jeśli to konieczne), czy też ci faceci po prostu nie przestrzegają najlepszych praktyk, aby umożliwić każdemu z ich pracowników dostęp do użytkownika Hasła? Myślałem, że hasła powinny być zaszyfrowane i nie można ich odzyskać? Czy to oznacza, że ​​przechowują hasła wszystkich w postaci zwykłego tekstu?

Czy dostawca usług hostingowych może legalnie odkrywać hasła do konta w ten sposób? Wydaje mi się to po prostu niesamowite.

Zanim zastanowimy się nad zmianą dostawcy, chciałbym mieć pewność, że nie jest to powszechna praktyka i że nasz następny dostawca hostingu również prawdopodobnie nie miałby takich ustawień.

Czekamy na Wasze opinie na ten temat.


4
Choć oczywiście budzi to duże zaniepokojenie, wiadomo, że to jeden-dwa uderzenie przedstawiciela telefonu zapisującego nowe hasło na bilecie (czego nigdy nie powinni robić) i kolejny przedstawiciel widzi to w notatkach na bilecie. Masz prawo żądać odpowiedzi, ale w tej chwili nie wiesz, jak hasło zostało odzyskane.
Andrew B,

1
Wiem na pewno, że użytkownik ustawił hasło za pośrednictwem interfejsu internetowego. Wyjęli go z rejestrów na serwerze - nikt w biurze nie powiedział o tym przez telefon (poza tym uważam, że ten dostawca i tak ma wsparcie tylko przez e-mail)
Austin 'Danger' Powers

3
Co ja bym zrobił? Wzruszać ramionami. Wszystko, co robisz w systemach kontrolowanych przez kogoś innego, jest dla nich widoczne. Jeśli nie chcesz, aby ktoś inny miał dostęp do twoich systemów poczty e-mail, uruchom je i hostuj. Możesz nie zaakceptować tego, co robią z informacjami, które mają z definicji, ale jeśli nie ma na nich żadnych zobowiązań umownych, aby tego nie robić, dobrze, podpisałeś umowy.
MadHatter obsługuje Monikę

19
Przechowywanie hasła w postaci zwykłego tekstu jest złe (jak Time to find a new providerzłe!) - wiele osób to robi, ale nadal: ZŁE. Przesyłasz ci hasło w niezaszyfrowanym e-mailu ? CAŁY MÓJ NOPE . To świadczy o lekceważeniu bezpieczeństwa. Biegnij, nie idź do nowego dostawcy z pewnym zdrowym rozsądkiem ...
voretaq7,

2
Chciałbym rozwinąć to, co powiedział @MadHatter: Wiele osób tutaj koncentruje się na idei „przechowywania haseł w postaci zwykłego tekstu”. Prostym faktem jest to, że jeśli korzystam z serwera POP / IMAP, serwera SSH lub czegokolwiek innego, na czym możesz wpisać swoje hasło, można je skonfigurować tak, aby logowało się podczas wprowadzania hasła , niezależnie od tego, czy Przechowuję rzeczy zakodowane lub w postaci czystego tekstu. Google może zobaczyć twoje hasło, a Dropbox może zobaczyć twoje hasło, a Facebook może zobaczyć twoje hasło i tak dalej. Albo ufasz swojemu dostawcy, albo sam go hostujesz.
larsks

Odpowiedzi:


33

Tak, dostawcy usług internetowych i dostawcy poczty e-mail często przechowują hasło w postaci zwykłego tekstu lub formatu, który można łatwo odzyskać w postaci zwykłego tekstu.

Powodem tego są między innymi protokoły uwierzytelniania używane w PPP (dialup i DSL), RADIUS (dialup, 802.1x itp.) I POP (email).

Kompromis polega na tym, że jeśli hasła są jednokierunkowo zaszyfrowane w bazie danych usługodawcy internetowego, wówczas jedynymi protokołami uwierzytelniającymi, które można zastosować, są te, które przesyłają hasło przewodowo w postaci zwykłego tekstu. Ale jeśli ISP przechowuje aktualne hasło, wówczas można użyć bezpieczniejszych protokołów uwierzytelniania.

Na przykład uwierzytelnianie PPP lub RADIUS może korzystać z protokołu CHAP, który zabezpiecza przesyłane dane uwierzytelniające, ale wymaga zapisania hasła w postaci zwykłego tekstu przez dostawcę usług internetowych. Podobnie z rozszerzeniem APOP do POP3.

Ponadto wszystkie różne usługi oferowane przez ISP korzystają z różnych protokołów, a jedynym czystym sposobem na ich uwierzytelnienie w tej samej bazie danych jest zachowanie hasła w postaci zwykłego tekstu.

Nie dotyczy to jednak kwestii, kto spośród pracowników ISP ma dostęp do bazy danych , i tego , jak dobrze jest zabezpieczony . Nadal powinieneś zadawać trudne pytania na ich temat.

Jak zapewne się już nauczyłeś, prawie nie jest narażone na atak na bazę danych dostawcy usług internetowych, podczas gdy indywidualni użytkownicy są zbyt często narażeni na atak. Tak czy inaczej, ryzykujesz.

Zobacz także Czy mam rację twierdząc, że hasła nigdy nie powinny być możliwe do odzyskania (skrót jednokierunkowy)? na naszej siostrzanej stronie Bezpieczeństwo IT


2
Protokół APOP jest w zasadzie martwym protokołem, a MSCHAPv2 nie potrzebuje serwera, aby dobrze znać hasło - tak naprawdę nie sądzę, aby istniał mnóstwo powodów, dla których usługodawca powinien zachować jasne hasła.
Shane Madden

1
@ShaneMadden Masz rację; to CHAP, a nie MSCHAP. I tak, te protokoły są cholernie bliskie śmierci, ale usługodawcy, którzy są już od zawsze, mogą nadal używać ich do starszych usług.
Michael Hampton

Tak - choć chciałbym myśleć, że więcej starszych dostawców usług ma stare, pełne skorupiaków LDAP {crypt}zamiast haseł z czystym tekstem (podejście stosowane przez osoby, które oglądałem za kulisami w przeszłości ). Choć może to być tylko pobożne życzenie.
Shane Madden

1
Uwaga dotycząca obowiązkowej kryptografii: „Kompromis polega na tym, że jeśli hasła są jednokierunkowo zaszyfrowane w bazie danych dostawcy usług internetowych, wówczas jedynymi protokołami uwierzytelniającymi, które można zastosować, są te, które przesyłają hasło przewodowo w postaci zwykłego tekstu. Ale jeśli dostawca usług internetowych przechowuje rzeczywiste hasło, wówczas można użyć bezpieczniejszych protokołów uwierzytelniania. ” nie jest ogólnie prawdą. Jest to prawdą tylko dlatego, że nie istnieją żadne protokoły, które pozwalają na bezpieczny schemat uwierzytelniania z hashowanymi hasłami.
orlp

1
@nightcracker w porównaniu do dowolnej ilości danych, które zamierzasz przesłać (również zaszyfrowane, mam nadzieję) niewielka ilość danych uwierzytelniających nie powinna ci tak bardzo niepokoić
Tobias Kienzler

12

Jest to niestety dość powszechne w przypadku hostów budżetowych i nie jest niespotykane - nawet w przypadku większych hostów. Rzeczy takie jak cpanel często potrzebują hasła w postaci zwykłego tekstu, aby móc zalogować się do różnych usług jako Ty itp.

Jedyne, co możesz zrobić, to zapytać z góry, czy hasła są zaszyfrowane.


28
To bardzo tani gospodarz ... Wiedziałem, że to zbyt piękne, aby mogło być prawdziwe. To mnie oszalało. W każdym razie dzięki za wysunięcie szyi z odpowiedzią. Na początku myślałem, że to wysokie zamówienie, ale podniosłeś się do tej okazji. Takie odpowiedzi pomagają tej witrynie osiągnąć nowy poziom. Myślałem o zaznaczeniu tego jako najlepszej odpowiedzi, ale to kark i kark.
Austin 'Danger' 'Powers

7

Prawdopodobnie przechowują hasła w postaci zwykłego tekstu lub używają pewnego rodzaju odwracalnego szyfrowania.

Jak można się domyślić, jest to bardzo złe.

Z powodu złośliwości lub zaniedbania pracowników lub naruszenia bezpieczeństwa systemów przez podmiot zewnętrzny niewłaściwe użycie haseł tekstowych stwarza poważne ryzyko - nie tylko dla ich systemów, ale także dla innych systemów, na których ludzie mogliby używać tego samego hasła.

Odpowiedzialne przechowywanie haseł oznacza stosowanie jednokierunkowych funkcji haszujących zamiast szyfrowania odwracalnego, z dodatkiem soli (danych losowych) do danych wejściowych użytkownika, aby zapobiec użyciu tęczowych tabel .

Gdybym był w twoich butach, zadałbym dostawcy trudne pytania dotyczące tego, w jaki sposób dokładnie przechowują hasła i jak dokładnie ich przedstawiciel pomocy technicznej mógł odzyskać hasło. Może to nie oznaczać, że przechowują hasła w postaci zwykłego tekstu, ale może logują je gdzieś po zmianie - jest to również ogromne ryzyko.


1
Zadam im kilka pytań i wrócę tutaj, jeśli powie coś ciekawego. Moim największym zmartwieniem jest to, że potencjalnie mogliby 1) przeczytać dowolny z naszych e-maili 2) czytając nasze e-maile, zobacz odniesienie do osobistego konta e-mail 3) jeśli użytkownik używa tego samego hasła do pracy i osobistego e-maila, wtedy jego osobisty e-mail mógłby też być narażonym na szwank.
Austin 'Danger' 'Powers

@ Austin''Danger''Powers ”może potencjalnie 1) przeczytać dowolny z naszych e-maili „ Każdy host może to zrobić - bez wyjątków (zakładając, że sama treść poczty nie była zaszyfrowana przez nadawcę - ale to inna historia).
orlp

Myślałem, że zwykle jest to możliwe tylko w przypadku wsparcia na najwyższym poziomie. Jeśli przeglądanie haseł jest czymś, co może zrobić każdy z ich przedstawicieli wsparcia, wzrasta ryzyko, że nieuczciwy / znudzony pracownik przejrzy nasze e-maile.
Austin 'Danger' 'Powers

5

Wszystkie pozostałe odpowiedzi są świetne i mają bardzo dobre punkty historyczne.

Jednak żyjemy w czasach, w których przechowywanie haseł w postaci zwykłego tekstu powoduje ogromne problemy finansowe i może całkowicie zniszczyć firmy. Wysyłanie haseł w postaci zwykłego tekstu za pomocą niepewnych wiadomości e-mail również wydaje się śmieszne w czasach, gdy NSA wysysa wszystkie przekazywane dane.

Nie musisz akceptować faktu, że niektóre stare protokoły wymagają haseł w postaci zwykłego tekstu. Jeśli wszyscy przestaniemy akceptować takie usługi, prawdopodobnie usługodawcy zrobiliby coś z tym i ostatecznie zaniechali starożytnej technologii.

Niektórzy ludzie pamiętają, że kiedy chcesz wsiąść do samolotu i lecieć do innego kraju, dosłownie po prostu wejdziesz do samolotu z parkingu przy ulicy. Żadnego bezpieczeństwa, co kiedykolwiek. W dzisiejszych czasach ludzie zdali sobie sprawę, że wymagane są odpowiednie środki bezpieczeństwa i wszystkie lotniska je wprowadziły.

Przejdę na innego dostawcę poczty e-mail. Wyszukiwanie w „bezpiecznym dostawcy e-mail” daje wiele wyników.

W komentarzach było kilka dobrych punktów. Prawdopodobnie poszukiwanie „bezpiecznego dostawcy poczty e-mail” miałoby sens, ponieważ wszyscy dostawcy poczty e-mail mogliby się pochwalić, że są bezpieczni. Nie mogę jednak polecić konkretnej firmy i prawdopodobnie nie jest to również dobry pomysł. Jeśli zidentyfikujesz konkretną firmę, zadając najpierw twarde pytanie dotyczące bezpieczeństwa, dobrze będzie zrobić.


1
Jednym z powodów, dla których nasz ostatni webmaster polecił tego dostawcę, było to, że miał on być „bezpieczniejszy” niż nasz poprzedni. Wkrótce odkrył, że nie pozwalają one pewne znaki specjalne w haśle, które wykorzystywane będzie w stanie po użyciu, a później, że ich pracownicy mieli dostęp do naszych haseł. Jedynym powodem, dla którego są „bezpieczniejsze”, jest to, że zmuszają nas do spełnienia pewnych minimalnych wymagań dotyczących długości / złożoności hasła - wielka sprawa.
Austin 'Danger' 'Powers

Każdy nazywa swoją usługę „bezpieczną”, ale okazuje się, że nie zawsze może to oznaczać to, co myślisz. System powinien to uniemożliwić. Pracowałem dla dostawcy usług internetowych wiele lat temu i chociaż mogłem zresetować hasło e-mail dowolnego klienta, nie miałem sposobu, aby zobaczyć, jakie jest obecne. Ci faceci teoretycznie mogliby czytać nasze e-maile bez naszej wiedzy ... Nie powinienem polegać na zaufaniu .
Austin 'Danger' 'Powers

1
Czy egzekwują maksymalną długość? To prawie zawsze kanarek do przechowywania hasła w postaci zwykłego tekstu.
Mels

1
„Wyszukaj w„ bezpiecznym dostawcy poczty e-mail ”daje wiele wyników”. - tak i ile witryn, które przechowują hasła w postaci zwykłego tekstu, znajdą się poniżej tych wyników, ponieważ uważają się za bezpieczne. Nie wybieraj hostingu dla usługi, którą chcesz zabezpieczyć na podstawie kilku wyników wyszukiwania.
Rob Moir

1
@RobM: Dokładnie. Co to jest korzystanie z prośbą dostawcy, jeśli uważają ich własna usługa jest bezpieczna? 100% z nich powie „tak”. Wyszukiwanie w sieci takiego ogólnego terminu to całkowita strata czasu. Właściwie wydaje się to dość naiwnym podejściem do całego problemu: „ Czy twoje systemy są bezpieczne? Ok, fantastycznie. Dziękujemy za wyjaśnienie. W takim przypadku subskrybujemy twoje usługi bez wahania.
Austin „Niebezpieczeństwo”

3

Radzę odejść i zapytać następnych, jakie są ich zasady!
Jeśli czujesz się dobrze, możesz powiedzieć starym dostawcom, dlaczego wyjeżdżasz.


Również w odpowiedzi na stwierdzenie innej odpowiedzi minęły dni tablic tęczowych. Zostały one zastąpione przez procesory graficzne o dużej mocy i zajmują zbyt dużo miejsca do przechowywania (oczywiście skróty binarne nie kompresują się dobrze; i tak nie można ich przechowywać w ASCII). Szybsze jest (ponowne) obliczenie skrótu na GPU niż odczytanie go z dysku.

W zależności od zastosowanego algorytmu skrótu i ​​procesora graficznego, można oczekiwać, że nowoczesny komputer do łamania haseł wyniesie około 100 milionów do miliarda skrótów na sekundę. Zgodnie z tym (co jest nieco przestarzałe w stosunku do tego, co według niego może zrobić komputer / superkomputer), oznacza to, że każde 6-znakowe hasło może zostać złamane w kilka sekund. Tabele dla skrótów 7 i 8 znaków we wszystkich różnych algorytmach (MD5, SHA-1, SHA-256, SHA-512, Blowfish itp.) Zajmowałyby nadmierną ilość miejsca na dysku (należy pamiętać, że należy je przechowywać na dysku SSD , a nie talerz magnetyczny, dla prędkości dostępu) i możesz zobaczyć, dlaczego ataki słownikowe przy użyciu karty graficznej szybciej przyniosą hasła.

Miłym artykułem dla tych, którzy wchodzą na scenę, jest to, jak zostałem łamaczem haseł w Ars Technica.


Jeśli twój drugi akapit jest naprawdę prawdziwy, oznaczałoby to, że solenie stało się bezużyteczne. Czy to twoja osobista opinia czy oparta na faktach?
Tobias Kienzler,

@TobiasKienzler Rzeczywiście, solenie przy użyciu wartości przechowywanej w danych wyjściowych jest bardzo bezużyteczne, ale solenie przy użyciu wartości prywatnej pozostaje realną obroną przed atakami słownikowymi. To nie jest moja osobista opinia, to spostrzeżenie (poczynione przez innych) na temat obecnego zachowania włamywaczy haseł. Trochę też zaktualizowałem odpowiedź.
Nicholas Shanks,

2
Czy jako wartość prywatna masz na myśli pieprz ? W każdym razie wymagane właściwości dobrej funkcji skrótu to: a) są one bardzo czasochłonne, a nawet lepiej b) można je nakładać dowolnie dużą ilość razy w celu zwiększenia wymaganego czasu. Tak więc, chociaż zgadzam się, że przestarzały skrót / sól jest podatny na pękanie, nie ma takiego o odpowiednio zwiększonej złożoności. Powiązane: Hasło Hashing dodać sól + pieprz czy wystarczy soli?
Tobias Kienzler,

@TobiasKienzler Tak, nie byłem pewien, jak konkretnie mogę być z tobą :) Oczywiście witryny powinny być używane w bcrypt()tych dniach, ale chodzi raczej o łamanie skrótów tych, którzy tego nie robią.
Nicholas Shanks,

1
Cóż, w takim przypadku zgadzam się, ale zły / przestarzały / słaby skrót (np. MD5) jest po prostu niewybaczalny w kontekście bezpieczeństwa.
Tobias Kienzler,

1

To się zdarzyło!

Kilka lat temu moja tożsamość została naruszona, gdy mój dostawca hostingu (który był wówczas również moim dostawcą poczty e-mail) doznał naruszenia bezpieczeństwa. Obudziłem się, że nie mogłem sprawdzić adresu e-mail, ponieważ moje hasło zostało zresetowane. Pod kontrolą mojego adresu e-mail próbowali zresetować moje hasło w Amazon i PayPal. Zgadnij, co było dalej, prawda? Fałszywe opłaty za karty kredytowe!

Na szczęście byłem w stanie dość szybko dowiedzieć się, co się dzieje, zadzwonić do mojego dostawcy hostingu i skrupulatnie zweryfikować swoją tożsamość pomimo zmiany informacji o koncie i pytań bezpieczeństwa (wszystko to w ciągu kilku godzin). Podczas tej rozmowy przedstawiciel obsługi klienta był w stanie powiedzieć mi moją historię haseł, kiedy została zmieniona i do czego. To wszystko, co musiałem usłyszeć, aby wiedzieć, że absolutnie muszę zmienić dostawców.

Nie ma powodu, dla którego powinno się to zdarzyć, nasza firma!

Miałem podejrzenia co do staranności tej firmy, jeśli chodzi o bezpieczeństwo, rzeczy, które zauważyłem tu i tam przez lata, kiedy się nimi zajmowałem. Ale zawsze byłem przekonany, że to nie jest wielka sprawa, a może się myliłem. Nie pomyliłem się i ty też nie jesteś!

Gdybym działał, kiedy po raz pierwszy podejrzewałam, że nie traktują poważnie bezpieczeństwa, cały mini-koszmar nigdy by się nie wydarzył. Pomyśleć, co może się zdarzyć w przypadku naruszenia wartościowego konta firmowego? Łatwo by ci było, gdyby tylko wysłali SPAM. Firma, w której pracowałem w tym czasie, również korzystała z tego usługodawcy i priorytetem było jak najszybsze wycofanie się.

Zaufaj instynktowi! Nie rezygnuj z migracji z lenistwa lub ponieważ istniejąca konfiguracja „działa dobrze”. Najbardziej szkodliwą częścią nisko wiszących niedopatrzeń w zakresie bezpieczeństwa, takich jak przechowywanie haseł w postaci czystego tekstu, niewłaściwe konfigurowanie serwerów itp., Jest to, że mówią one o ogólnej niekompetencji i / lub lenistwie w ich kulturze technicznej, a to kultura, której nie chciałbym, aby misja mojej firmy była krytyczna umowa serwisowa w pobliżu.


0

Widzę alternatywne wyjaśnienie, w którym Twoje hasło jest rzeczywiście zakodowane na serwerach Twojego dostawcy.

Gdy dostawca skontaktował się z Tobą zaledwie dzień później, prawdopodobnie (i to przypuszczenie) wyciągnął go z dzienników serwera, ponieważ jego skrypt zmieniający hasło przesyła dane metodą GET.

To brzmi prościej niż Twój dostawca, który ma bazę danych zawierającą informacje o tym, kiedy, kto i jak zmienił hasło. Znasz brzytwę Ockhama ...;)

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.