Jak zabezpieczyć hasła przez HTTP?

FireCubez

2018-11-09 19:57:16 UTC

view on stackexchange narkive permalink

Powiedz, że moje hasło to abc . Chcę wysłać go do serwera przez HTTP.

Mógłbym wysłać go w postaci zwykłego tekstu i pozwolić serwerowi go zaszyfrować i porównać z wpisami w swojej bazie danych, ale wtedy każdy, kto może zobaczyć ruch przez to połączenie zobaczyłby hasło w postaci zwykłego tekstu.

Więc mógłbym wtedy zaszyfrować je po stronie klienta i pozwolić serwerowi po prostu porównać je bez mieszania, ponieważ jest już zaszyfrowane (lub serwer mógłby nawet podwoić hash, ale bez różnicy w ta sytuacja). Ale z drugiej strony każdy, kto widzi ruch, zobaczy zaszyfrowane hasło, a następnie wyśle zaszyfrowane hasło do serwera, a serwer je zaakceptuje.

Jak wysyłać hasła przez HTTP? Czy muszę zaimplementować jakiś algorytm szyfrowania, taki jak szyfrowanie z kluczem publicznym RSA? A może to niemożliwe?

Metoda powinna być dostępna w każdej przeglądarce.

Dlaczego nie możesz po prostu użyć TLS?Naprawdę nie ma innego sposobu, aby zrobić to bezpiecznie.

@AndrolGenhald Mógłbym, to tylko dowód słuszności koncepcji.Jeśli nie ma innego sposobu, aby zrobić to bezpiecznie, to jest odpowiedź, której szukałem.Powinieneś zamieścić to jako odpowiedź

Nie potrzebujesz natywnego TLS - teoretycznie możesz zaimplementować TLS przez HTTP - ale nie byłoby to praktycznie praktyczne.

@AndrolGenhald Nie ma dobrego powodu, aby nie używać TLS, ale uważam, że istnieje wiele innych sposobów, aby zrobić to bezpiecznie.Na przykład można tunelować http przez ssh.

Może spróbuj użyć ECDHE do bezpiecznej wymiany kluczy?

@emory Plakat wyjaśnił, że kontekstem jest komunikacja między przeglądarką internetową a serwerem HTTP, a nie niestandardowa aplikacja do serwera niestandardowego.

Czy to prawdziwy problem, z którym się mierzysz, czy tylko eksperyment myślowy?

@whatsisname Stwierdziłem, że w poprzednim komentarzu to tylko eksperyment

Chociaż nienawidzę, gdy pytasz A, a ludzie odpowiadają „po prostu użyj B”, będę musiał zgodzić się z wieloma odpowiedziami „po prostu użyj TLS”, ponieważ jest to najprostszy sposób rozwiązania praktycznego problemu.Powiedziałeś teraz, że _nie_ chodzi o problem praktyczny, ale „tylko do eksperymentu”, więc możesz przeczytać o [protokołach zerowej wiedzy] (https://en.wikipedia.org/wiki/Zero-knowledge_proof), które robią cochcesz.

Oryginalna implementacja hasła programu MSN Messenger była odpowiednia dla tego scenariusza.Serwer wysłał Ci „sól”, za pomocą której zaszyfrowałeś swoje hasło i odesłałeś hash z powrotem na serwer.Ponieważ serwer znał Twoje hasło, mógł wykonać te same obliczenia.Serwer był odpowiedzialny za upewnienie się, że nie użyje ponownie soli

FWIW, nawet jeśli uda Ci się bezpiecznie przesłać hasła, nic nie osiągniesz.Reszta sesji jest niezaszyfrowana, można ją łatwo ukraść lub zmodyfikować.Nawet jeśli możesz bezpiecznie udowodnić, że jesteś Bobem, w momencie, gdy to się stanie, Alicja może ukraść twoją sesję i być Bobem tak długo, jak zechce.

@curiousguy Jeśli OP uruchomił `ssh -L 127.0.0.1:8080:intra.example.com:80 gw.example.com`, a następnie przeszedł do http://127.0.0.1:8080, połączenie zostanie zaszyfrowane, a hasła zabezpieczone.(1) Zakłada się, że OP może ssh do gw.example.com i (2) może serwer WWW nie odpowiada na żądania lokalne.Ten przykład może / może nie działać dla OP, ale twierdzenie, że TLS jest jedynym sposobem, jest błędne.

@emory Czy to nie _w efekcie_ przy używaniu TLS, ale po prostu mając `ssh` zrobi to zamiast implementować go bezpośrednio w kliencie?I czy połączenie z „gw.example.com” do prawdziwego serwera WWW nadal byłoby podatne na podsłuchiwanie?

@TripeHound Poleciłbym tylko używanie TLS i nie martwienie się o te problemy.Ale jeśli w efekcie używa TLS, ale ssh robi to zamiast implementować go bezpośrednio w kliencie, wtedy połączenie z prawdziwym serwerem WWW nie byłoby podatne na podsłuchiwanie.