Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
atari.area forum » Sprawy atari.area » Dlaczego nie ma certyfikatu ssl na stronie ?
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
Jest to niebezpieczne używanie www bez certyfikatu ssl.
Wszyscy to wiemy, kierownik też wie i nie trzeba mu przypominać co pół roku ;-)
nie do pomyslenia jak ludzie zyli bez certyfikatow...
Zastanawiam się co to za zagrożenia czyhają na użytkownika forum kiedy serwer nie ma certyfikatu i jak można w ogóle używać forum bez certyfikatu długimi miesiącami?
Bo przyjdzie mityczny "hakier" i nas wszystkich zhakieruje. I będziemy musieli się przesiąść na C64.
nie do pomyslenia jak ludzie zyli bez certyfikatow...
Certy sa darmowe Let’s Encrypt
Zastanawiam się co to za zagrożenia czyhają na użytkownika forum kiedy serwer nie ma certyfikatu i jak można w ogóle używać forum bez certyfikatu długimi miesiącami?
Hakier ukradnie ciastko i Ci go zje. Co ta miesiącami?! Latami, żeby nie powiedzieć od dekad ponad już dwóch.
mono napisał/a:Zastanawiam się co to za zagrożenia czyhają na użytkownika forum kiedy serwer nie ma certyfikatu i jak można w ogóle używać forum bez certyfikatu długimi miesiącami?
Hakier ukradnie ciastko i Ci go zje. Co ta miesiącami?! Latami, żeby nie powiedzieć od dekad ponad już dwóch.
Pacman lubi cookies :P
Ssl jest po to, żeby dać ludziom fałszywe poczucie bezkarności i prowokować ich do wywnętrzniania się. Gdyby to było skuteczne, to by było zabronione (vide Telegram).
Hasła można przesyłać bezpiecznie - przecież jest javascript czy inne rozwiązania - można tego użyć do zamiany hasła na cokolwiek, zanim się to prześle internetami.
@qbahusak
A nie po to żeby uniemożliwić łatwe przechwytywanie haseł podczas logowania? :]
Edit: skoro już edytowałeś... Co ma JS do tego co napisałeś? Po co w ogóle używać JS do opisanego przypadku? Chodzi tylko i wyłącznie o jawność/niejawność danych pomiędzy klientem a serwerem.
A nie po to żeby uniemożliwić łatwe przechwytywanie haseł podczas logowania? :]
Temu dokładnie służy - ochronie transmisji przed wścibskimi, w tym danych niejawnych, jak: hasła, numery kart płatniczych, ciasteczka itp.
Jest bardzo prawdopodobne, że duża część ludzi uznaje SSL, jako ochronę prywatności, bo często jest to tak przedstawiane. U mnie trzy z czterech stron, będącymi pierwszymi wynikami wyszukiwania hasła "ssl prywatność", przedstawia SSL jako:
Certyfikat SSL potwierdza, że strona, którą odwiedzamy korzysta z bezpiecznego połączenia. Bezpieczne – szyfrowane – połączenie zapewnia autentyczność, prywatność i integralność przesyłanych danych.
Powyżej ewidentnie pomylono prywatność z możliwością przechwycenia transmitowanych danych.
Hasła można przesyłać bezpiecznie - przecież jest javascript czy inne rozwiązania - można tego użyć do zamiany hasła na cokolwiek, zanim się to prześle internetami.
Jeżeli masz na myśli zamianę po stronie klienta hasła w coś innego (np. hash) i przesłanie w takiej formie, to nie jest to żadne zabezpieczenie. Żaden szanujący się system nie trzyma hasłem w otwartej postaci - zawsze są to hashe. I to właśnie one, a nie hasła, są porównywane podczas uwierzytelniania.
SSL to szyfrowanie komunikacji między przeglądarką a hostingiem strony w celu uniemożliwienia odczytania tego co jest przesyłane.
W przypadku strony/forum jak nasze głównie chodzi o ochronę haseł (hashowanie haseł czy dowolne zabezpieczenie w JS nie daje żadnej ochrony, wydłużają tylko proces obchodzenia zabezpieczeń) przed wyciekiem, ale w przypadku np. sklepów można by wykraść numery kart kredytowych, numery dowodów osobistych, itp.
Trzeba też używać SSL w najnowszej wersji, bo starsze zostały złamane i nie dają żadnej ochrony.
Pytanie czy ktoś się boi, że ukradną jego hasło i będą pisać pod jego nickiem np. kiełbasę wyborczą :)
Ale za to powinien się poważnie bać ten, kto używa tego samego hasła na forum i np. w banku. Bo prędzej czy później botnety zaczną tym hasłem się posługiwać.
Trzeba też używać SSL w najnowszej wersji, bo starsze zostały złamane i nie dają żadnej ochrony.
A co to za dziwne stwierdzenie? Czyżby algorytm liczb pierwszych został właśnie odkryty?
Obecnie używa się TLS, ale to po prostu rozszerzenie SSL.
To tylko skrót myślowy, chodziło mi oczywiście o szereg podatności w TLS 1.2 i wcześniejszych
Boszsz.... Jak komuś przeszkadza - nie musi korzystać z atariarea. Nie widzę tu milionów nowych "nicków" dziennie, jest to małe, raczej prawie zamknięte środowisko...
Niniejszym piszę, że wiem jak działa SSL, wiem po co jest, wiem co zapewnia i wiem, że jest do podsłuchania/obejścia po jednej ze stron łącza (właściwie po obu, ale łatwiej po stronie użytkownika). Ponadto klucze były upraszczane swego czasu, niektóre metody szyfrowania zostały zaklasyfikowane jako niebezpieczne, i zalecono używać krótszych, "bezpieczniejszych" kluczy. Więc _domyślam się_ że podsłuch może się odbywać również na pośredniczących routerach; a na pewno logowanie i później ew. deszyfracja offline wybranych pakietów.
A co ma JS? ano to, że serwer wysyła określony kod szyfrujący JS z określonymi kluczami publicznymi, haszuje i szyfruje hasło, wysyła na serwer, a serwer kluczem prywatnym (i publicznym) sobie to odszyfrowuje i porównuje hasz. Nie wiem, czy takie rozwiązania są stosowane pewnie tak. Ale jest to jak najbardziej możliwe i bezpieczne, jeśli nie będzie luk.
Nie rozumiem haszowania hasła po stronie klienta (JS), szczególnie, że jedno hasło może wygenerować różne hasze (+ jakaś sól) a samo hasło może pasować do różnych haszy (kolizja). Jedyną właściwą drogą jest na serwerze sprawdzenie zgodności hasła do hasza. Porównanie hasza do hasza jest nieprawidłową i skrajnie niebezpieczną praktyką. Tak się nie robi. I nie trzeba do tego JS. Chyba, że chodzi o JS na backendzie, ale to jest już node.
Ja już o to kkiedyś pytałem i nie rozumiem w czym problem. Wystarczy na koncie hostingowym kliknąć "włącz SSL" i wygenerować sobie darmowy certyfikat Let's Encrypt. Całość nie powinna przekroczyć 3 minut.
Niniejszym piszę, że wiem jak działa SSL, wiem po co jest, wiem co zapewnia i wiem, że jest do podsłuchania/obejścia po jednej ze stron łącza (właściwie po obu, ale łatwiej po stronie użytkownika).
Dane, przed wysłaniem i po odebraniu, są w postaci niezaszyfrowanej, więc nie ma za bardzo sensu ich podsłuchiwania - wystarczy po nie sięgnąć. Przed tym procederem powinien chronić antywirus, którego skuteczność nie jest przedmiotem tej dyskusji.
Ponadto klucze były upraszczane swego czasu, niektóre metody szyfrowania zostały zaklasyfikowane jako niebezpieczne, i zalecono używać krótszych, "bezpieczniejszych" kluczy.
Tak, osłabiono algorytm A5/1 stosowany w sieciach GSM na potrzeby eksportowe USA do krajów z ograniczeniami importowania produktów z funkcjami szyfrowania. Najpopularniejsze algorytmy szyfrowania symetrycznego używają kluczy: 56-bitowych (DES), 112 (3DES), 128/256 (AES), więc długość klucza jest wydłużana. W przypadku szyfrowania asymetrycznego początkowo stosowano klucze 768-bitowe, ale od wielu lat zaleca się stosowanie 2048-bitowych i dłuższych.
Więc _domyślam się_ że podsłuch może się odbywać również na pośredniczących routerach; a na pewno logowanie i później ew. deszyfracja offline wybranych pakietów.
Może i nazywa się Man In The Middle, z tym że próba podsłuchiwania wymaga podmiany certyfikatów wykorzystywanych do ustalenia klucza symetrycznego, co kończy się informacją o błędnym certyfikacie serwera. Zebranie danych zaszyfrowanych, aby rozszyfrować je off-line mija się z celem, ze względu na czas potrzebny do tej czynności.
A co ma JS? ano to, że serwer wysyła określony kod szyfrujący
Musisz mieć możliwość zweryfikowania, czy otrzymany "kod szyfrujący" pochodzi z właściwego źródła. Do tego służą certyfikaty. Inaczej zły człowiek przechwyci transmisję, w miejsce "kodu szyfrującego" serwera wstawi własny i prześle do klienta. Dalej mamy klasyczne MITM.
jedno hasło może wygenerować różne hasze (+ jakaś sól) a samo hasło może pasować do różnych haszy (kolizja).
Odwrotnie, to samo hasło zawsze da ten sam hash. Dopiero dodawanie losowej soli do hasła daje różne hashe. Kolizja jest wtedy, gdy dwie różne dane dają ten sam skrót.
Jedyną właściwą drogą jest na serwerze sprawdzenie zgodności hasła do hasza. Porównanie hasza do hasza jest nieprawidłową i skrajnie niebezpieczną praktyką. Tak się nie robi.
Jak chcesz "hasło" porównać z "610881de40fac65b12445aef6c603234" (MD5 tylko dla przykładu)? :-) Trzymanie haseł w postaci jawnej jest skrajnie nieodpowiedzialne. Przechowuje się hashe i ew. sól. Podczas uwierzytelniania do przesłanego hasła dodawana jest sól, z tego obliczany jest skrót i dopiero to jest sprawdzane.
Wystarczy na koncie hostingowym kliknąć "włącz SSL" i wygenerować sobie darmowy certyfikat Let's Encrypt. Całość nie powinna przekroczyć 3 minut.
Certyfikaty Let's Encrypt ważne są trzy miesiące i dobrze jest mieć narzędzie do automatycznego odnawiania. Poza tym na hoscie trzeba mieć możliwość włączenia szyfrowania spełniającego współczesne wymogi. :-p
@Lizard
Nigdzie nie pisałem o trzymaniu hasła w postaci jawnej, po to właśnie są hashe :)
Już na spokojnie, bo pisanie jednym ciągiem wprowadza trochę bałaganu. W bazie trzymany jest hash (np. Argon2id). Porównanie odbywa się na serwerze, który ma od klienta hasło i hash z bazy.
I jak najbardziej algo generuje różne hashe dla tego samego ciągu, tu przykład Bcrypt:
https://bcrypt-generator.com/
ciąg: ccwrc
wygenerowane hashe:
$2a$12$oigG3gG7jlroHTTzTL/beeCRVxi7FNj1rkGw3dseHv3K8gbksxbIC
$2a$12$5boL5FfyLKNSlyNHKFTLCO6vumXUVJ04afwfXJnvTU9ICEmVyn6K2
$2a$12$DrL6oFP9qz98Mbss1VRh5OtnrDvIL8ite1TDvet2km8brYa84qiWK
Jak chcesz, możesz dodatkowo sprawdzić zgodność hasha z hasłem (ccwrc) na innej stronie:
https://bcrypt.online/
Może pewne zamieszanie wynikać z tego, że checksum (np. MD5) jest mylone z hashem a to zupełnie inne rzeczy. Checksum zawsze da taki sam ciąg wyjściowy dla określonego ciągu wejściowego.
@Lizard - korzystam z różnych hostingów dla siebie i klientów i jeszcze się nie spotkałem, by Let's Encrypt się autmatycznie nie przedłużał. No i zdradź termin "szyfrowanie spełniające współczesne wymogi"? Raczej wszystkie firmy hostingowe korzystają z najnowszych wersji oprogramowania z racji oczywistych :)
Jeżeli masz na myśli zamianę po stronie klienta hasła w coś innego (np. hash) i przesłanie w takiej formie, to nie jest to żadne zabezpieczenie. Żaden szanujący się system nie trzyma hasłem w otwartej postaci - zawsze są to hashe. I to właśnie one, a nie hasła, są porównywane podczas uwierzytelniania.
Żaden szanujący się system (sieciowy) nie porównuje ani haseł ani ich hashy podczas uwierzytelniania.
@Lizard - korzystam z różnych hostingów dla siebie i klientów i jeszcze się nie spotkałem, by Let's Encrypt się autmatycznie nie przedłużał.
Wszystko zalezy co hostingowa firma zaproponowala. Jesli ma w ofercie SSL certy z np Let's Encrypt'a to zazwyczaj jest tez dzialajaca funkacja automatycznego odnawiania, a i tez to wszsytko zalezy od roznych czynnikow jak czy SSL cert jest dla jednego url'a, czy jest SAN czy jest wildcard.
Od tego jaki typ to jest certa, zalezy metoda uwiezytelnienia podacz generowania certa - np. wildcard mozna tylko uwiezytlnic po przez rekod(y) w DNS'ie a DNS mozna trzymac w firmie hostingowej tam gdzie sie hostuje strone, albo tam gdzie sie kupilo domene, i w tym drugim przypadku juz tak latwo automatycznie donowic certa z Let's Encrypt sie nie da.
Kolega Lizard piszac ze cert trzeba odnawiac co 3 miesiace podal poprostu ogolna zasade jaka sie taki cert zadzi (wygasa co 3 miesiace).
Ja np hostuje swoje zeczy sam na moim serwerze i calosc musze ogarniac po swojemu.
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Sprawy atari.area » Dlaczego nie ma certyfikatu ssl na stronie ?
Wygenerowano w 0.028 sekund, wykonano 56 zapytań