Przede wszystkim NIE poprawia to bezpieczeństwa Twojej aplikacji (zakładając, że jest to aplikacja internetowa).
Używaj SSL (a właściwie TLS, który jest powszechnie nazywany SSL), nie jest zbyt drogi (zmierz czas poświęcony na znalezienie sposobu na obejście tego problemu i pomnóż go przez minimalną płacę, zakup certyfikatu prawie zawsze wygrywa).
Dlaczego jest to proste. TLS rozwiązuje problem (gdy jest używany z zakupionymi certyfikatami, a nie z podpisem własnym), który jest dość duży w kryptografii: Skąd mam wiedzieć, że serwer, z którym rozmawiam, jest serwerem, z którym rozmawiam? Certyfikaty TLS to sposób na powiedzenie: „Ja, urząd certyfikacji zaufany przez Twoją przeglądarkę, zaświadczam, że witryna internetowa pod adresem [url] ma ten klucz publiczny z odpowiednim kluczem prywatnym, który (klucz prywatny) zna tylko serwer. Podpisałem swój podpis na całym dokumencie, jeśli ktoś go zmienił, widać ”.
Bez TLS każde szyfrowanie staje się bezcelowe, ponieważ jeśli usiądę obok ciebie w kawiarni, mogę sprawić, że twój laptop / smartfon pomyśli, że jestem serwerem, a MiTM (Man in The Middle) ty. Dzięki TLS Twój laptop / smartfon będzie krzyczał „NIEUFANE POŁĄCZENIE”, ponieważ nie mam certyfikatu podpisanego przez urząd certyfikacji, który pasuje do Twojej witryny. (Szyfrowanie a uwierzytelnianie).
Zastrzeżenie: użytkownicy zwykle klikają bezpośrednio te ostrzeżenia: „Niezaufane połączenie? Co? Chcę tylko zdjęcia kociąt! Dodaj wyjątek Kliknij Potwierdź Kliknij TAK! Kocięta!”
Jeśli jednak naprawdę nie chcesz kupować certyfikatu, nadal wdrażaj haszowanie javascript po stronie klienta (i używaj do tego biblioteki standford (SJCL), NIGDY NIE WDRAŻAJ CRYPTO SAM ).
Czemu? Ponowne użycie hasła! Mogę łatwo ukraść plik cookie sesji (co pozwala mi udawać, że jestem Tobą) bez protokołu HTTPS (patrz firesheep). Jeśli jednak dodasz javascript do swojej strony logowania, który przed wysłaniem hashuje twoje hasło (użyj SHA256 lub jeszcze lepiej, użyj SHA256, wyślij im wygenerowany klucz publiczny, a następnie zaszyfruj zaszyfrowane hasło za jego pomocą, nie możesz użyć soli z tym), a następnie wysyła zaszyfrowane / zaszyfrowane hasło do serwera. REHASH hash na swoim serwerze z solą i porównaj to z tym, co jest przechowywane w Twojej bazie danych (zapisz hasło w ten sposób:
(SHA256(SHA256(password)+salt))
(zapisz sól również jako tekst jawny w bazie danych)). I wyślij swoje hasło w ten sposób:
RSA_With_Public_Key(SHA256(password))
i sprawdź swoje hasło w ten sposób:
if SHA256(RSA_With_Private_Key(SHA256(sent_password))+salt_for_username) == stored_pass: login = ok
Ponieważ, JEŻELI ktoś węszy Twojego klienta, będzie mógł zalogować się jako Twój klient (przechwytywanie sesji), ale NIGDY nie zobaczy hasła w postaci zwykłego tekstu (chyba że zmienią Twój javascript, jednak haker Starbucks prawdopodobnie nie będzie wiedział, jak to zrobić / będzie zainteresowany w tym.) Dzięki temu uzyskają dostęp do Twojej aplikacji internetowej, ale nie do swojego adresu e-mail / Facebooka / itp. (do którego użytkownicy prawdopodobnie będą używać tego samego hasła). (Adres e-mail będzie nazwą użytkownika lub będzie można go znaleźć w profilu / ustawieniach aplikacji internetowej).