Jak bezpieczne jest wysyłanie poufnych danych przez https?

Question

Czy protokół SSL jest wystarczająco bezpieczny, aby używać poufnych danych (takich jak hasło) w ciągu zapytania? Czy są jakieś dodatkowe opcje do wdrożenia?

Answer 1

SSL zapewnia bezpieczne zabezpieczenie na poziomie transportu. Nikt między klientem a serwerem nie powinien być w stanie odczytać informacji.

Ale należy zmienisz zdanie na temat zapisywania danych wrażliwych w ciągu kwerendy. Pojawi się w historii przeglądarki i będzie widoczny na pasku adresu przeglądarki oraz w dziennikach na serwerze. Zobacz ten artykuł: How Secure Are Query Strings Over HTTPS?

Jeśli używasz ciągów zapytań to twoja jedyna opcja (wątpię w to), oto interesujący artykuł about securing query strings.

Answer 2

Nigdy nie należy wysyłać niczego krytycznie wrażliwego za pomocą ciągów zapytania!

Answer 3

Tak, jest wystarczająco bezpieczny. Chociaż zgadzam się, że zwykle nie jest to dobry pomysł na takie rzeczy w łańcuchu zapytań, to jest ok, jeśli nie jest to ciąg zapytania, który pojawi się na pasku adresu. Jeśli pojawi się na pasku adresu, z oczywistych względów stracisz poziom bezpieczeństwa (ludzie przechodzący obok, itp.)

Answer 4

Nie należy wysyłać haszowanych haseł? - nieważne, czy się mylę.

SSL to niemalże największe bezpieczeństwo, jakie można uzyskać.

Answer 5

Wrażliwe dane w ciągu zapytania są złym pomysłem, przypadkowi przechodnie mogą zobaczyć ciąg zapytania i istnieje pokusa, by utworzyć zakładkę, która naprawdę nie jest bezpieczna.

SSL jest dość bezpieczny, jeśli prowadzisz bankowość internetową i ufasz, że SSL będzie wystarczająco dobre dla ciebie.

Answer 6

zgodzić się z SSL jest bezpieczny * owski i querystring problem

pamiętać, że istnieją ograniczenia dotyczące SSL -

upewnić się, że jest root cert certyfikat.

niektóre okna 2000 maszyny muszą mieć sp stosowane do SSL 128 bit do pracy, jeśli jej nie ma to idzie do 40bit lub doenst obciążenia (jeśli dobrze pamiętam)

Niektóre zapory oprogramowanie, takie jak ISA - gdzie publikujesz bezpieczną stronę i certyfikujesz ją w środku - zachowuj się jak człowiek w środku.

Zabezpiecz do ISA, a następnie Zabezpiecz do sieci LAN. ale dużym faktorem jest tutaj "wtedy", ponieważ ISA wyloguje, wtedy logowanie jest problemem, ponieważ hasło na ciągu zapytania i postu jest widoczne - co oznacza, że ​​każdy (admin) może zobaczyć ...

Poszukaj bezpieczne algorytmy haszowania w Twoim języku, aby po prostu skasować hasło.

Answer 7

Nie ma "wystarczająco bezpiecznego", bezpieczeństwo nie jest statyczną rzeczą z właściwością bool, która jest fałszywa lub prawdziwa.

SSL jest dobry, ale zależy to od tego, jak bezpieczny jest klucz prywatny po stronie serwera, ile bitów ma klucz, zastosowany algorytm, jak wiarygodne są używane certyfikaty itp.

Ale jeśli korzystasz z protokołu SSL, wszystkie przesyłane dane są zaszyfrowane (z wyjątkiem docelowego adresu IP, ponieważ służy do kierowania paczką).

Inną kwestią, którą należy wziąć pod uwagę, jest: - ręczne wprowadzenie ciągu zapytań dotyczących hasła w przeglądarce może skończyć się lokalną pamięcią podręczną przeglądarki (w całkowicie niezaszyfrowanym pliku lokalnym). Więc lepiej wykorzystaj mechanizm POST i nie transferuj GET.

Jeśli naprawdę interesuje Cię bezpieczeństwo, polecam więcej badań na ten temat, ponieważ najczęściej algorytm nie jest najsłabszym punktem w bezpieczeństwie.

Answer 8

SSL jest bezpieczny, ale pamiętaj, że wszelkie szyfrowanie może zostać zerwane, jeśli masz wystarczająco dużo czasu i zasobów. Biorąc pod uwagę, że nie wiesz, które pakiety zawierają hasło, a które nie, musisz odszyfrować cały zaszyfrowany ruch, aby znaleźć właściwy. W ogólnym przypadku jest to niemożliwe.

Jednak formularz logowania wymaga wpisu [typ = tekst], aby go wprowadzić. Wymaga to "rozpakowania" tego i przekształcenia żądania w żądanie HTTP GET za pomocą ciągów zapytań, a nie POST z danymi w parametrach formularza. Nie mogę sobie wyobrazić, dlaczego ktoś by to zrobił. Po dostarczeniu hasła przez użytkownika (i uwierzytelnionego użytkownika), należy używać raczej uwierzytelniania niż przechowywania hasła. Jeśli chcesz zachować hasło, podszywaj się pod niego, najlepiej w bezpiecznym łańcuchu. Jeśli próbujesz wykonać jednokrotne logowanie (wpisz mój identyfikator/hasło raz dla wielu stron), użyj jakiejś centralnej usługi uwierzytelniania (CAS) - OpenID, WindowsLive - lub wprowadź własną.

Im mniej razy hasło przechodzi przez przewód, tym lepiej.

I zawsze istnieje pasek adresu przeglądarki, który należy wziąć pod uwagę, co mogłoby oznaczać, że konieczne jest szyfrowanie i kodowanie wrażliwych danych umieszczonych w łańcuchach zapytań, jak wspomniano wcześniej.

Answer 9

Certyfikaty z podpisem własnym to certyfikaty SSL, które są tworzone i podpisywane przez użytkownika. Oznacza to, że nie potrzebujesz zewnętrznego certyfikatu (CA) do podpisania certyfikatu, ale oznacza to, że przeglądarki domyślnie rzucają ostrzeżenie o tym, ponieważ samopodpisany certyfikat nie może niezawodnie (twoja przeglądarka ma lista zaufanych urzędów certyfikacji) sprawdź, czy osoba podpisująca certyfikat jest dokładnie tym, co mówi certyfikat.

Weź pod uwagę sytuację, w której tworzysz certyfikat SSL "w imieniu" określonej firmy programistycznej z siedzibą w Redmond. Teraz, jeśli twój serwer HTTP przedstawi klientowi ten certyfikat, który sam podpisałeś, agent użytkownika ostrzeże, że ten certyfikat może nie być faktycznie tym, za kogo się podaje. Instytucja certyfikująca zweryfikuje - poprzez papierkową robotę, rzeczywistą, rzeczywistą martwą choinkę - tożsamość strony żądającej podpisania, a zatem jest godna zaufania.

Mam nadzieję, że to pomoże.

Answer 10

ssl inspektor może otworzyć ssl handluje http://www.ssl-inspector.com/files/file/SSL%20Inspector%20Appliance%20Product%20Brief%20(2-11).pdf