adres URL https z parametrem token: jak jest bezpieczny?

Użyłbym do tego ciastka. Workflow powinien wyglądać tak:

1. Użytkownik pojawia się na twojej stronie po raz pierwszy.
2. strona ustawia plik cookie
3. Użytkownik wprowadza dane. Dane są przechowywane w DB przy użyciu klucza, który jest przechowywany w pliku cookie.
Kiedy użytkownik odejdzie, wysyłasz mu wiadomość e-mail z linkiem https: link
4. gdy użytkownik wraca, witryna odkrywa plik cookie i może przedstawić użytkownikowi stare dane.

Teraz użytkownik chce korzystać z innej przeglądarki na inna maszyna. W takim przypadku zaproponuj przycisk "Przenieś". Gdy użytkownik kliknie ten przycisk, otrzyma "token". Może użyć tego tokena na innym komputerze, aby zresetować plik cookie. W ten sposób użytkownik decyduje o tym, jak bezpiecznie chce przenieść token.

SSL zabezpiecza zawartość przesyłanych danych, ale nie jestem pewien adresu URL.

Niezależnie od tego, jednym ze sposobów na złagodzenie atakującego ponownego użycia tego tokenu URL jest upewnienie się, że każdy token może być użyty tylko raz. Możesz nawet ustawić plik cookie, aby uprawniony użytkownik mógł nadal korzystać z łącza, ale po pierwszym dostępie będzie działał tylko dla kogoś z plikiem cookie.

Jeśli wiadomość e-mail użytkownika zostanie naruszona, a atakujący dostanie link jako pierwszy, Cóż, jesteś zablokowany. Ale użytkownik również ma większe problemy.

E-mail jest z natury niepewny. Jeśli ktoś może kliknąć ten link i dostać się do danych, tak naprawdę nie chronisz go.

Cóż token jest bezpieczny, gdy jest przekazywany przez SSL. Problem, który będziesz miał, polega na tym, że jest dostępny dla osób (tych, dla których nie jest przeznaczony), dzięki możliwości wyświetlenia adresu URL.

Jeśli są to prywatne informacje, takie jak SSN, nie sądzę, bym wysłał URL przez e-mail. Wolałbym, aby stworzyli nazwę użytkownika i hasło do witryny. Zbyt łatwo jest skompromitować wiadomość e-mail z tego rodzaju informacjami dla Ciebie i dla nich. Jeśli czyjeś konto jest comprimized to przyjdzie do pytania, czyja to wina naprawdę jest. Im bezpieczniej, tym lepiej z punktu widzenia CYA.

Naprawdę nie uznałbym tego za wystarczająco bezpieczne w sytuacji, w której istnieją poważne problemy z prywatnością. Fakt, że wysyłasz adres URL w (prawdopodobnie cleartext) e-mail jest zdecydowanie najsłabszym ogniwem. Po tym jest ryzyko ataków brute force na tokeny ,które (brak struktury prawdziwego mechanizmu uwierzytelniania) mogą być bardziej podatne na ataki niż dobrze skonstruowana nazwa użytkownika i hasło.

Nie ma żadnych problemów z parametrami w https Prośba, nawiasem mówiąc.

Tak jak jest, to byłby zły pomysł. Będziesz scarify bezpieczeństwa z łatwym użyciu. Jak wspomniano wcześniej SSL będzie chronić tylko transfer informacji między serwerem a przeglądarką klienta i zapobiegnie tylko atakowi środkowego człowieka. E-maile są bardzo ryzykowne i niebezpieczne.

Najlepsze byłoby uwierzytelnianie nazwy użytkownika i hasła, aby uzyskać dostęp do informacji.

Podoba mi się pomysł z ciasteczkami mniej więcej. Należy również zaszyfrować informacje o plikach cookie. Należy również wygenerować token z salt i frazą kluczową oraz $_SERVER ['HTTP_USER_AGENT'], aby ograniczyć prawdopodobieństwo ataku. Przechowuj jak najwięcej niewrażliwych informacji o kliencie w pliku cookie w celu weryfikacji użytkowania.

Fraza kluczowa może być przechowywana w pliku cookie w celu łatwego użycia, ale należy pamiętać, że również plik cookie może zostać skradziony =(.

Lepiej pozwól klientowi wpisać frazę kluczową, którą podał, która jest również przechowywana w bazie danych wraz z jego danymi.

Lub, klucz może być użyty w przypadku osoba używa innej maszyny, która różni się parametrami $_SERVER['HTTP_USER_AGENT'] lub po prostu pomija plik cookie. Tak więc plik cookie można przenieść lub ustawić.

Upewnij się również, że poufne dane są szyfrowane w bazie danych. Nigdy nie wiadomo;)

Zdajesz sobie sprawę, że jeśli jakiś haker uzyska dostęp do twojej bazy danych, wiele osobistych informacji może być dowolnie podanych ?

Potem powiedziałbym, że to nie jest zły pomysł. Nie użyłbym MD5 ani SHA1, ponieważ nie są one zbyt bezpieczne do haszowania. Można je dość łatwo" odszyfrować " (wiem, że to nie szyfrowanie).

W przeciwnym razie może użyłbym drugiej informacji, która nie byłaby wysyłana przez e-mail typu hasło. Powód jest dość prosty, jeśli ktoś ma dostęp do użytkownika e-mail (dość łatwe z hotmail, jeśli nie zabić sesji) będzie miał dostęp do wszelkich informacji użytkownik wysłał.

Zauważ, że HTTPS zabezpieczy i zaszyfruje dane wysyłane z twojej witryny do użytkownika końcowego. Nic więcej, potraktuj to jako bezpieczny tunel. Nic więcej, nic mniej.

Z tego co rozumiem twój pomysł, w teorii ktoś mógłby wpisać losowy ciąg znaków 40 lub hash MD5 i uzyskać komuś szczegóły. Chociaż może to być bardzo mało prawdopodobne, musi się to zdarzyć tylko raz.

Lepszym rozwiązaniem może być wysłanie użytkownikowi tokena, a następnie poproszenie go o podanie niektórych danych, takich jak imię i nazwisko, kod pocztowy, ssn lub ich kombinacja.