Bezpieczne logowanie: szyfrowanie klucza publicznego w PHP i Javascript

Question

Próbuję utworzyć "normalny" formularz logowania użytkownika/hasła w bezpieczny sposób, bez konieczności korzystania z HTTPS. Mój pomysł jest następujący:

• Serwer generuje parę kluczy dla pewnego asymetrycznego algorytmu szyfrowania. Przechowuje ten klucz w tymczasowej tabeli sortów (lub może lokalnych danych sesji).
• Serwer wysyła formularz do klienta i zawiera klucz publiczny.
• Użytkownik wypełnia formularz.
• Przed wysłaniem na serwer, JavaScript szyfruje hasło przy użyciu podanego klucza publicznego.
• Formularz został wysłany.
• Serwer odszyfrowuje hasło swoim kluczem prywatnym (który pobiera z tabeli tymczasowej, używając klucza publicznego, aby go znaleźć).

Co muszę wiedzieć, bo to jest:

• Która metoda szyfrowania jest najlepiej użyć? RSA?
• Jak mogę odszyfrować hasło w PHP?
• I chyba najtrudniejszy, jak mogę uczynić JavaScript zaszyfrować hasło?

Answer 1

Wcześniej: przykro mi, że jestem negatywny;

Wdrażanie własnego protokołu bezpieczeństwa jest dobrym pomysłem, jeśli nie jesteś dobrze wyszkolonym ekspertem ds. Bezpieczeństwa lub naprawdę nie zależy Ci na bezpieczeństwie i chcesz tylko stworzyć wrażenie bezpieczeństwa (marketing) i zatrzymaj dziecięce skrypty.

SSL zdecydowanie nie jest blokadą linii papilarnych, tak jak w komentarzach, JCryption i twoja propozycja są równe drzwiom, w których możesz wprowadzić dwucyfrowy kod, aby otworzyć drzwi i masz nieskończenie wiele prób. Ciężko jest się zepsuć, jeśli nie jesteś naprawdę zainteresowany i tylko przejeżdżasz, ale jeśli chcesz dostać się do tego domu (i prawdopodobnie to zrobisz, inaczej bezpieczeństwo nie będzie potrzebne), dostaniesz się.

Kolejny chodzi o to, że ludzie często zapominają wspomnieć o tym, co chcą osiągnąć. Bezpieczeństwo ma znane trzy komponenty o nazwie CIA, mianowicie poufność, integralność i dostępność. Czy dla Ciebie ważne jest to, że przesyłane dane są poufne lub czy są ważne dla integralności (np. Masz pewność, że przesłane dane pochodzą od tego, którego oczekujesz, a nie od człowieka w środku)?

W tym przypadku jedyną rzeczą, którą można tu osiągnąć, jest to, że pasywny napastnik nie może zobaczyć, co dzieje się na linii. Gdy tylko atakujący aktywuje się i zmienia wiadomości na trasie, całe twoje bezpieczeństwo się rozpada. Tak więc moją radą byłoby po prostu trzymać się rozwiązania, które wymyślili eksperci (w tym przypadku TLS, a nie ssl, ponieważ jest to stara wersja) i po prostu upewnij się, że twój serwer go obsługuje.

edit:

Btw, SSL/TLS nie może pracować bez certyfikatów. Cały klucz kryptograficzny klucza publicznego polega na tym, że przynajmniej pewna część zaufanej strony powinna być.

Z drugiej strony, jeśli nie obchodzi cię, że Twoi użytkownicy otrzymają wiadomość "nieprawidłowy certyfikat", możesz po prostu stworzyć swój własny certyfikat, który jest naprawdę łatwy. W takim przypadku Twój certyfikat nie jest zaufany przez przeglądarki, ale możesz być pewien, że przynajmniej twoja komunikacja jest bezpieczna (OK, są wyjątki w tym przypadku, ale nadal ...)

Argument, że certyfikaty powinno być za darmo jest rzeczywiście z punktu widzenia perspektywy. Sądzę, że osoby, które twierdzą, że są fałszywe/idiotyczne, nie wiedzą, co to znaczy być urzędem certyfikacji. Firmy te inwestują miliony w celu utrzymania bezpieczeństwa komunikacji i pewności, że zarabiają dobre pieniądze ze sprzedaży certyfikatów, ale hej to ich praca, a także zasługują na zarabianie pieniędzy, tak jak każdy inny.

Edit2: po komentarzach

I rzeczywiście powiedzieć, że masz bezpieczną komunikację. Tęsknisz jednak za tym, że z samopodpisanymi certyfikatami nie wiesz do kogo bezpiecznie rozmawiasz. Wyobraź sobie ciemny pokój, który jest całkowicie odizolowany od podsłuchiwania rozmowy. Teraz wyobraź sobie różnicę między takim pokojem ze światłem i bez niego. Jeśli pokój ma światło, możesz zobaczyć, do kogo mówisz bezpiecznie i tylko wybrać, aby porozmawiać z ludźmi, którym chcesz zaufać. Teraz wyobraź sobie, że robisz to samo w całkowicie ciemnym pokoju. Możesz tylko mieć nadzieję, że facet, z którym rozmawiasz w tym ciemnym pokoju, jest tylko sprzymierzeńcem, a nie przeciwnikiem. Jednak nie możesz tego wiedzieć, po prostu nadzieję, że jest w porządku. I chociaż twoja rozmowa jest bezpieczna, nikt nie może nasłuchiwać, nadal nie masz "pełnego" bezpieczeństwa.

Jeśli ja, będąc oszustem, wykonam atak pośredni, mogę utworzyć samopodpisany certyfikat bez powiadomienia użytkownika. Tak więc zaletą korzystania z TLS z samopodpisanymi certyfikatami jest to, że masz przynajmniej implementację protokołu corrent (a nawet wdrożenie tego nie jest łatwe). Ponadto można uniknąć brzydkich ostrzeżeń, doradzając użytkownikom, aby ręcznie zaufali certyfikatowi raz. Jest to jednak możliwe tylko wtedy, gdy masz stosunkowo małą grupę powracających gości, dla publicznej strony nie jest to rozwiązanie.

Answer 2

To bardzo dobry pomysł i już został zrobiony. Zobacz jCryption.

Answer 3

Wygląda na to, że wiele z tego, co chcesz zrobić, jest dostarczane przez wtyczkę jquery JCryption. Zakłada nawet, że PHP jest zapleczem, więc jest dla ciebie odpowiedni.

Answer 4

jCrypcja wygląda interesująco, nie widziałem tego wcześniej.

Ale muszę zapytać, co jest nie tak z SSL?

Kod szyfrowania jest notorycznie trudny do zrobienia, i można założyć, że implementacje SSL znalezione w przeglądarkach i serwerach http są znacznie bardziej rygorystycznie testowane i sprawdzane niż rzeczy jCryption.

To powiedziawszy, jCryption wygląda zgrabnie, jeśli absolutnie potrzebujesz uniknąć SSL, a Ty nie zajmujesz się bardzo wrażliwymi informacjami.

Answer 5

To nie wydaje się bezpieczne z punktu widzenia klienta. Dwa (powiązane) problemy:

1. W jaki sposób klient ufa serwerowi? W jaki sposób można sprawdzić, czy klucz, który przedstawia sever to ten, który należy do niego?
2. Możliwe jest wykonywanie ataków typu "man-in-the-middle". Złośliwy proxy może usunąć i zapisać klucz publiczny, zanim klient go zobaczy, zastępując go własnym, a następnie odszyfrowując hasło, gdy klient go uwierzytelni, zapisze i ponownie zaszyfruje i wyśle ​​odpowiedź, aby klient nie zdawał sobie sprawy coś jest nie tak.

Co jest nie tak ze zwykłym SSL? Musi być zgoda co do tego, że jest bezpieczna, w przeciwnym razie dostawcy i organizacje zrzekną się jej wsparcia z dnia na dzień.Dla kontrastu, większość prób wymyślenia nowego, funkowego sposobu na zapewnienie bezpieczeństwa "na tanie" zwykle pomija coś fundamentalnego.

Answer 6

Livejournal robi coś podobnego do tego, co chcesz, gdzie:

1. Server generuje ciąg prowokacji, to wstawia do formy. [1]
2. Klient generuje odpowiedź przez MD5, mieszając hasło, a następnie MD5 mieszając poprzedni skrót z wyzwaniem, które zostało przedłożone [2].
3. Serwer otrzymuje odpowiedź, sprawdza ważność wyzwania, a następnie robi to samo co krok 2, porównując wynik z odpowiedzią.

Answer 7

Zapisując hasła w metodzie zaszyfrowanej na serwerze, serwer może pobrać hasła i zweryfikować sumę kontrolną wysłaną przez klienta. Wyślij hasło sesji i zapytaj klienta, aby utworzyć skrót hasła sesji i hasło użytkownika, zrób to samo na serwerze i porównaj oba hashe.

To nie zabezpieczy użytkowników przed atakami MITM - lokalni administratorzy, NSA, telekomunikacja, przejmowanie ruterów, ale zachowa hasło w open wlan.