[HTML][inne][JavaScript]Link aktywacyjny Opcje

[Niktoś]

Witam czy jest możliwe wychwycenie ip/nazwy domeny skąd nastąpiło kliknięcię w link aktywacyjny?
Np.Ktoś wchodzi na swoją pocztę na www.gmail.com i klika w link aktywacyjny.I teraz mam wątpliwości,czy gmail lub inny serwer pocztowy otwierając link w nowym oknie wysyła żądanie?Jeśli tak to chyba da rady byłoby wychwycić skąd nastąpiło kliknięcie.

Ten post edytował Niktoś 7.07.2012, 17:23:52

[SmokAnalog]

Poczytaj o $_SERVER['HTTP_REFERER'].

[Niktoś]

Wiem,że takie coś jest lecz czy wychwycone ip będzie klienta czy domeny z której nastąpiło kliknięcie?

[b4rt3kk]

To nie wychwytuje IP tylko bezpośredni adres z jakiego ktoś wszedł na stronę. Do IP służy co innego, leczy również z tablicy $_SERVER. Czyli jeśli ktoś wejdzie na stronę Twojego skryptu aktywacyjnego bezpośrednio z maila to $_SERVER['HTTP_REFERER'] zwróci przykładowo: http://gmail.com?dasdas=eqwewqeqq&dasdsa=eqwewq

Ten post edytował b4rt3kk 7.07.2012, 22:03:04

[Niktoś]

Dzięki właśnie o taką odpowiedź mi chodziło.
Można teraz filtrować osoby, które bezpośrednio klikneły w link aktywacyjny bezpośrednio z linku na serwerze pocztowym ,a intruzów, którzy kombinują z url'em.
Chciałem założyć taką filtrację, ale zanim zacznę kombinować to wolałem się upewnić.

Ten post edytował Niktoś 7.07.2012, 22:07:56

[markonix]

Też mi zabezpieczanie.

A jak korzystam z Outlook czy Thunderbird?

[b4rt3kk]

Hmm, zależy jak wygląda Twój link aktywacyjny, bo jeśli jest to coś w stylu:
link.php?user=adam_malysz
gdzie adam_malysz to nazwa użytkownika i to wystarczy do aktywacji to rzeczywiście to kiepski pomysł. Generuj jakiś losowy klucz, który zostanie przypisany do konta użytkownika, który będzie mógł poznać wchodząc tylko na maila i nawet jeśli wpisze go w adres przeglądarki to właśnie o to chodzi, bo czasem link może nie działać.

Możesz dodatkowo sprawdzać z jakiego IP się zarejestrował i z jakiego aktywuje, ale nie polecam.

[Mephistofeles]

Dzięki właśnie o taką odpowiedź mi chodziło.
Można teraz filtrować osoby, które bezpośrednio klikneły w link aktywacyjny bezpośrednio z linku na serwerze pocztowym ,a intruzów, którzy kombinują z url'em.
Chciałem założyć taką filtrację, ale zanim zacznę kombinować to wolałem się upewnić.

Ci intruzy, którzy kombinują z urlem to po prostu ludzie, którym nie wyświetlił się prawidłowo działający link. Niby dlaczego w każdym mailu aktywacyjnym jest wzmianka "lub skopiuj poniższy adres..."? Zły pomysł z tym filtrowaniem.

[Niktoś]

A jak korzystam z Outlook czy Thunderbird?
No fakt nie pomyślałem.Ale dla takich osób pozostanie ręczne wpisanie danych.Jeszcze pomyslę.

Hmm, zależy jak wygląda Twój link aktywacyjny, bo jeśli jest to coś w stylu:
link.php?user=adam_malysz

Jawnie to robić, aż taki tępy nie jestem-jakoś realizują linki aktywacyjne -na tym forum także-więc nie koniecznie to musi być sposób niebezpieczny.
Teraz pomyślałem -żadnej filtracji -tylko dwa dodatkowe pola weryfikujące dane, potem proces autoryzacji.

Ten post edytował Niktoś 7.07.2012, 22:52:52

[b4rt3kk]

W miarę prosta metoda:
1. tworzysz losowy klucz, hashujesz go

[PHP] pobierz, plaintext 
$key = md5(rand(10000,999999)); // oczywiscie tylko przyklad
[PHP] pobierz, plaintext 

2. przypisujesz klucz userowi w bazie danych, wysylasz link aktywacyjny na maila

[PHP] pobierz, plaintext 
$link = 'aktywuj.php?user='.$user.'&key='.$key;
[PHP] pobierz, plaintext 

3. sprawdzasz czy klucz pasuje do usera, jesli tak, konto aktywowane

[PHP] pobierz, plaintext 
$user = $_GET['user'];
$key = $_GET['key'];
$query = "SELECT COUNT(id) FROM users WHERE user='$user' AND key='$key'";
[PHP] pobierz, plaintext 

Ten post edytował b4rt3kk 7.07.2012, 23:20:03

[Niktoś]

Dzięki,zrobię to na podobny sposób-jednak będzie to troszeczkę bardziej restrykcyjne

[markonix]

Nie prościej md5 z nicku + jakiś klucz zamiast zaśmiecać mysql?
Klucz i tak zapisany wyłącznie w FTP więc przyjmując, że nikt do FTP nie ma dostępu jest to równie skuteczne.
Gdyby ktoś jednak włamał się na FTP to by go ten klucz i tak by go mało obchodził.

Edit:
Albo md5(username + klucz + ID usera).

Ten post edytował markonix 8.07.2012, 11:05:42

[redeemer]

Klucz i tak zapisany wyłącznie w FTP więc przyjmując, że nikt do FTP nie ma dostępu jest to równie skuteczne.
Gdyby ktoś jednak włamał się na FTP to by go ten klucz i tak by go mało obchodził.

Gwoli ścisłości FTP to protokół. Pliki zapisywane są na dysku, a FTP to jedna z możliwości (zresztą mało bezpieczna, bo hasło przesyłane jest jawnie) zdalnego dostępu do nich.

[markonix]

Przyznaje. Skrót myślowy.

[Niktoś]

Nie prościej md5 z nicku + jakiś klucz zamiast zaśmiecać mysql?

Właśnie będzie tak jak mówisz-dane w url będą kodowane i dekodowane po unikalnym dla każdego użytkownika kluczu.Zero zapisu do bazy i dodatkowo weryfikowane przez dwa dodane pola textowe. Po praidłowej weryfikacji będzie autoryzacja i przekierowanie na całkiem inną stronę, która dla nikogo nie będzie dostępna bez procesu autoryzacji.

Ten post edytował Niktoś 8.07.2012, 13:10:44

[markonix]

Jak coś jest dekodowane to to nie jest bezpieczne.

[Niktoś]

Jak coś jest dekodowane to to nie jest bezpieczne.

A powiedz mi dlaczego?Jakieś argumenty?

[markonix]

A jaki jest argument aby cokolwiek dekodować?
Przy logowaniu dekodujesz hasła czy porównujesz hashe?

[Niktoś]

Przy logowaniu dekodujesz hasła czy porównujesz hashe?

Porównujesz hashe,ale hash zapisujesz także w bazie danych.Ma to na celu niejawne przechowywanie danych w tym przypadku hasła w bazie danych.
Ma to na celu zwiększenie bezpieczeństwa bazy danych i ochrony klienta z poziomu bazy danych.W razie wykradnięcia danych z bazy,hasło wciąż pozostaje bezpieczne.
Dekodowanie danych moim zdaniem jest tak samo bezpieczne jak generowanie hashy.Żeby odkodować dane musisz znać 1.algorytm kodujący
2.klucz kodujący
3.dane które tym kluczem chcesz odkodować.

Więc jak widzisz zadanie aby cos tkiego zrobić nie należy do najłatwiejszych.

Próbowałeś łamać zabezpieczenia kodowanych archiwów rar?Tam przeważnie jest używany algorytm AES ,a i tak nie udało mi się nigdy złamać takich pliczków.Najwidoczniej słaby ze mnie haćkor.

Ten post edytował Niktoś 8.07.2012, 15:50:30

[markonix]

Sprawdzasz ID usera, który aktywujesz przy okazji sprawdzając czy user w ogóle istnieje.
Generujesz hash (user + id + stała) i porównujesz z tym w linku, jeżeli ok aktywujesz (znasz już ID).

Nie widzę tu sensu dekodowania jakichś danych z linku choćby dlatego, że jak ktoś by poznał klucz to może zrobić więcej szkód.
Poza tym generowanie hasha wg mnie jest znacznie szybsze, aniżeli rozkodowywanie stringów (na chłopski rozum).

[Niktoś]

Strona o niższym priorytecie prowadząca do systemu komentarzy.Korzystać będą z niej niezarejestrowani userzy.Wprowadzanie do bazy danych dodatkowego pola z hashem dla usera,gdzie dane jego będą przechowywane przez pewien okres wydaje mi się nieoptymalne.W przypadku kodowania/dekodowania nie muszę tworzyć dodatkowej kolumny dla hasha w bazie danych.

U mnie będzie to tak wyglądać:
1.Kodowanie danych za pomocą unikalnych kluczy i wysłanie na email w linku aktywacyjnym.
2.W momencie klknięci w link przez usera dekodowanie stringa i weryfikacja o dwa dodatkowe pola tekstowe.
3.Jeśli dane są zgodne ,autoryzacja i przekierowanie na zabezpieczoną stronę.

Myślę,że sposób dobry na stronę o niższym priorytecie(stronę z komentarzami).Wydaje mi się dość bezpieczne.

Ten post edytował Niktoś 8.07.2012, 16:15:34

[markonix]

Ale ja nic nie mówiłem o zapisywaniu hasha w bazie.
Hash jest w linku.