Jak bezpiecznie wysłać hasło przez HTTP przy użyciu Javascript przy braku HTTPS?

Rozwiązaniem jest nie wysyłanie hasła w ogóle. Użyj wyzwanie/odpowiedź.

W oryginalnej formie Dołącz duży blok losowego tekstu wraz z kluczem. Przechowuj oryginalny losowy tekst w sesji na podstawie klucza na serwerze. Kiedy klient przesyła formularz, użyj JS, aby zahaszować losowy tekst i hasło razem. Następnie wyślij nazwę użytkownika, klucz i zaszyfrowany losowy tekst na serwer. Nie wysyłaj hasła. Na serwerze użyj klucza, aby wyszukać oryginalny losowy tekst, wykonaj tę samą operację hashowania z zapisanym hasłem. Jeśli wartość zaszyfrowana serwera odpowiada wartości zaszyfrowanej klienta, to wiesz, że klient wprowadził odpowiednie hasło bez wysyłania hasła do serwera.

Niezależnie od tego, czy hasło jest poprawne, czy nie, Usuń klucz i losowy tekst, aby każdy z nich był jednorazowy.

Jeśli naprawdę chcesz zagłębić się w to, spójrz na Diffie-Hellman key exchange, która została stworzona, aby "umożliwić dwóm stronom, które nie mają wcześniejszej wiedzy o sobie nawzajem, wspólne ustanowienie tajnego klucza przez niepewny kanał komunikacyjny"

Nie jestem jednak ekspertem w kryptografii, więc nie do końca wiem, czy jest to naprawdę bezpieczne, jeśli atakujący ma zarówno Klienta (Kod źródłowy JavaScript), jak i mechanizm transportu (sniffer pakietów)

Możesz użyć implementacji JavaScript RSA do zaszyfrowania hasła przed wysłaniem. (Oto przykład RSA w Javascript.)

Ale wierzę, że zarówno ten, jak i korzystanie z funkcji hash będzie podatne na ataki replay . Więc bądź ostrożny.

Niestety nie będzie możliwości zapewnienia bezpieczeństwa nieszyfrowanego żądania. Każdy, kto ma dostęp do twojego javascript, będzie po prostu mógł go inżynierii wstecznej / manipulować przy nim, a każdy z snifferem pakietów będzie mógł obserwować niezaszyfrowany ruch. Te dwa fakty razem oznaczają:

Brak SSL? Żadnej ochrony.

Każda transmisja, którą posiadasz, będzie czysta; oznacza to, że bez SSL twoje krytyczne informacje zostaną ujawnione. Warto omówić ten punkt z właścicielem witryny. Innymi słowy, najlepiej jest podjąć niezbędne środki w celu wzmocnienia transmisji danych, A SSL jest jednym z podstawowych, tanich kroków, które możesz podjąć.

Nie sądzę, że problemem jest tutaj technologia, ale jak wyjaśnisz znaczenie SSL. Zapewnij im wiarygodne materiały do czytania, jestem pewien, że w sieci jest ich wiele.

Rozwiązanie wymaga, aby klient był w stanie zaszyfrować hasło za pomocą tajnego klucza szyfrującego znanego tylko klientowi i serwerowi.

SSL osiąga to, wymagając, aby zarówno serwer, jak i przeglądarka internetowa klienta miały własne asymetryczne public / private keypair, których używają do szyfrowania i przesyłania losowego klucza sesji między nimi. Następnie reszta rozmowy używa tego bezpiecznego klucza sesji.

Więc pytasz jak rozwiązać ten sam problem jako SSL bez korzyści z posiadania tajnego klucza, który jest znany tylko klientowi i serwerowi. Nie jestem ekspertem, ale wygląda na to, że nie da się tego zrobić, a przynajmniej nie łatwo.

Jeśli nie masz dostępu do SSL, MD5 powinno być odpowiednie, aby zapobiec przypadkowemu odkryciu haseł(np. w pliku dziennika sieciowego lub czymś takim). Wszystko inne byłoby stratą czasu. Po prostu upewnij się, że aplikacja nie daje dostępu do poufnych informacji (np. numery kart kredytowych, historia medyczna itp.).

Jak sugerowali inni komentatorzy, poważny napastnik będzie w stanie złamać każdy rodzaj zabezpieczeń na stronie. Nawet SSL jest małą barierą, ponieważ większość użytkowników korzysta z łatwego do odgadnięcia hasła, ponowne użycie tych samych haseł wszędzie, poda swoje hasło każdemu, kto zapyta, lub może zostać oszukany, aby zrezygnować z hasła przez skopiowaną stronę lub telefon "wsparcie techniczne".

-- polski -- myślę w czymś, ale nie wiem, czy to może być naprawdę bezpieczne. Jeśli możesz umieścić swój formularz w pliku php, możesz utworzyć algorytm do tworzenia ciągu opartego na czasie lub w czymś innym, a następnie umieścić ten ciąg w swoim html.

Gdy użytkownik wpisuje hasło w polu wprowadzania hasła, podczas debugowania nie widać wartości wpisanej przez użytkownika, więc przed wysłaniem informacji przez post lub get, można użyć użytkownika hasła jako podpowiedzi do zaszyfrowania zaszyfrowanego string previosly wygenerowany, a następnie, po prostu wysłał go wpisując hasło wpisane przez użytkownika.

W ten sposób atakujący nie mają całego kodu js, więc będą musieli odkryć algorytm, który tworzysz, aby go odszyfrować.

To tylko pomysł, więc jeśli możesz mi powiedzieć, jak to nie może być bezpieczne, byłbym wdzięczny.

-- Hiszpański -- Se me acaba de ocurrir algo que puede servir, pero no se si realmente sea algo seguro. Por medio de php puedes generar un algoritmo que cree un string en base al timestamp o algo más, y después colocar esta cadena en el html.

Note que cuando alguien escribe una contraseña en un campo input tipo password, con un debug no se puede ver el valor que tecleo el usuario (no se si exista manera pero no quise investigar más), asi que podemos utilizar la contraseña que el usuario escribió como palabra clave para encriptar la cadena de texto que previamente habiamos generado con php, por medio de un algoritmo en js. Sería algo así como encriptar lo encriptado. Posteriormente lo que estariamos enviado no sería la contraseña tecleada, si no esta última cadena resultante.

Buscando un contra, lo único que se me ocurra es que el atacante tendrá que dedicarle mucho tiempo para tratar de encontrar el agoritmo que creamos por medio de php y poder decriptar la cadena final, o tendrá que hackear el servidor para acceder al php y obtener el algoritmo.

Esto es solo una idea, por lo que si pueden decirme como esto puede no ser seguro, se los agradecería.

Jak wspomniano, nic z tego nie jest zabezpieczone przed spoofingiem serwera, ponieważ wymaga to zaufania do Javascript po stronie klienta. Ale jeśli jesteśmy pewni, że serwer nie może być sfałszowany (signed cert, hash signing, length-extension, itp.) ale nie że połączenie jest odporne na podsłuchiwaczy, oto jak to zaimplementowałbym.

Myślę, że najbezpieczniejszym sposobem jest, zamiast przechowywać H (Hasło), Gdzie H jest twoją wybraną funkcją hash, przechowuj g^H (password ) tzn. Użyj hasła jako klucza prywatnego do wymiany kluczy Diffiego-Hellmana. (Powinieneś też prawdopodobnie użyć losowego g dla różnych użytkowników-staje się Twoją solą.) Następnie, aby zweryfikować, generujesz nonce b, wysyłasz użytkownikowi g^b i Oblicz (g^H(hasło))^B. użytkownik nie musi znać g--musi tylko obliczyć (g^b)^h(Hasło) = (g^H ( Hasło))^B. teraz masz numer, który obie strony znają iff użytkownik wpisał hasło, a konstruowanie dowodu zero-knowledge challenge-response na podstawie znajomości poprawnej liczby jest trywialne, podczas gdy losowa liczba używana jako "klucz prywatny" serwera sprawia, że podejście jest odporne na ataki replay.