W skrócie, w wyżej wymienionym artykule, kolega robi tak, że podczas zakładania konta generuje sobie token, który zawiera zahashowane informacje o loginie, haśle i coś tam jeszcze. I przy każdym requescie informacje usera (login, o zgrozo hasło jako zwykły text) + ten token (cały czas ten sam) wędruje sobie od serwera do clienta.
I moje problemy właśnie tutaj się zaczynają. Jakie to jest zabezpieczenie? Jeśli ktoś przechwyci token to ma wszystko, ma dostęp do serwera bo ten go uwierzytelni. To tak jakbym przesyłał login i hasło jawnie i ktoś to przechwycił. Moim zdaniem użycie tokena w taki sposób mało zmienia. Wygląda po prostu trochę groźniej.
Być może jestem nadwrażliwy, czegoś nie wiem i jestem głupcem, ale nurtuje mnie to bardzo. Stąd moje pytanie jak powinno się wykorzystywać tokeny do tego aby było bezpiecznie. Aby przechwycenie tokena nie powodowało, że posiadanie jednego tokena da możliwość dostępu do danego konta praktycznie na zawsze.
Czy może ja z braku swojej wiedzy nie wiem, że nie da się tak przechwycić takiego tokena. (Chociaż w to wątpie) Czy ktoś też miał takie "rozterki"? Może ktoś poratuje jakimś linkiem, który by to dobrze tłumaczył?
@takecare: Nie mogę już edytować:( Mam taki pomysł jak to zrobić. Przy logowaniu generować taki token z jakimś losowym dodatkiem do danych. To zapisać tymczasowo w bazie, i przesłać do clienta. I tam w jakimś czasie to sprawdzać.
I np ustawić, że token ma być ważdny godzine. Tylko nie wiem co zrobić jeśli użytkownik będzie miał otwartą stronę i przez godzine nie będzie nic tam robił. I po godzinie sobie kliknie
@takecare: To samo jesli chodzi o bezpieczenstwo masz z przechwyceniem sesji. Jesli uzywasz tokenow to masz bezstanowosc co jest podstawą REST'a. Ustaw sobie krótki czas waznosci tokena i za kazdym zapytaniem generuj nowy, asynchronicznie zaszyfrowany token. Jeden klucz na serwerze, drugi u klienta. Nikt Ci nic nie pozmienia, nikt nic nie odczyta, jesli przechwyci token, to pouzywa chwile aplikacji i tyle, a przed tym sie tak latwo nie obronisz.
@mleko321: Dzięki za odpowiedz! Jeden klucz na serwerze, drugi u klienta - chodzi Ci o kluczy prywatny i publiczny? Jeśli nie, to ma to jakąś nazwę? Krótki czas ważności? Masz na myśli to, że jeden token jest ważny np. 5 min? A co ma się dziać po upływie ważności? I jeszcze jedno pytanie. Jeśli zrobię tak, że przy każdym zapytaniu będę generował nowy token. To czy może zajść taka sytuacja: "ktoś
@takecare: Tak, chodzi o klucz publiczny i prywatny. W przypadku przechwycenia klucza, przechwycony zostaje dostep do aplikacji do momendu wygasniecia aktywnosci uzytkownika / wylogowania niestety. Tak samo jak w przypadku przechwycenia sesji.
@mleko321: Ok, jest to dla mnie akceptowalny poziom bezpieczeństwa;) A powiedz mi jeszcze o tych kluczach. Bo z tego co wiem publiczny szyfruje a prywanty rozszyfrowuje. To jak to wykorzystać w praktyce? Client szyfruje i przesyła? A co z komunikacją z serwera -> client?
@takecare: najprostsze i najbardziej skuteczne rozwiązanie: Https + session cookie. Jedynie podatne na Man in the Middle ale... to też da się zabezpieczyć.
@controll: A czy zamysł serwera restowego nie polega na tym, żeby własnie nie korzystać z cookisów? Nic nie sugeruje, mogę się mylić itp, tak tylko pytam dla lepszego zgłębienia tematu;)
@takecare: LOL? widziałeś gdzieś kiedyś taki serwis który nie korzysta z headerów do przesyłania sesji? Każde normalne Rest API autoryzacje przeprowadza poprzez cookie session, dla przykładu JIRA https://docs.atlassian.com/jira/REST/latest/#d2e456 - zapytanie "/rest/auth/1/session"
@takecare: głupie pytanie ale czemu login hasło itp masz wysyłać do klienta bo trochę nie ogarniam, co do bezpieczeństwa tego tokena - przecież siedzi on w sesji która jest unikalna dla każdego połączenia, jak chcesz więcej bezpieczeństwa to połącz te tokeny jeszcze z IP po stronie serwera/sesjami
Wczoraj pisałem odnośnie moich problemów z zabezpieczeniem przesyłania danych do serwera restowego. (http://www.wykop.pl/wpis/14163195/mirki-programisty-potrzebuje-powaznej-porady-na-pr/)
Przeczytałem wspomniany artykuł w wyżej wymienionym linku (http://code.tutsplus.com/tutorials/token-based-authentication-with-angularjs-nodejs--cms-22543) i pojawiło mi się kilka problemów i myśli związanych z tokenowym zabezpieczaniem połączenia.
W skrócie, w wyżej wymienionym artykule, kolega robi tak, że podczas zakładania konta generuje sobie token, który zawiera zahashowane informacje o loginie, haśle i coś tam jeszcze. I przy każdym requescie informacje usera (login, o zgrozo hasło jako zwykły text) + ten token (cały czas ten sam) wędruje sobie od serwera do clienta.
I moje problemy właśnie tutaj się zaczynają. Jakie to jest zabezpieczenie? Jeśli ktoś przechwyci token to ma wszystko, ma dostęp do serwera bo ten go uwierzytelni. To tak jakbym przesyłał login i hasło jawnie i ktoś to przechwycił. Moim zdaniem użycie tokena w taki sposób mało zmienia. Wygląda po prostu trochę groźniej.
Być może jestem nadwrażliwy, czegoś nie wiem i jestem głupcem, ale nurtuje mnie to bardzo.
Stąd moje pytanie jak powinno się wykorzystywać tokeny do tego aby było bezpiecznie. Aby przechwycenie tokena nie powodowało, że posiadanie jednego tokena da możliwość dostępu do danego konta praktycznie na zawsze.
Czy może ja z braku swojej wiedzy nie wiem, że nie da się tak przechwycić takiego tokena. (Chociaż w to wątpie)
Czy ktoś też miał takie "rozterki"? Może ktoś poratuje jakimś linkiem, który by to dobrze tłumaczył?
#programowanie #webdev
Mam taki pomysł jak to zrobić.
Przy logowaniu generować taki token z jakimś losowym dodatkiem do danych. To zapisać tymczasowo w bazie, i przesłać do clienta. I tam w jakimś czasie to sprawdzać.
I np ustawić, że token ma być ważdny godzine. Tylko nie wiem co zrobić jeśli użytkownik będzie miał otwartą stronę i przez godzine nie będzie nic tam robił. I po godzinie sobie kliknie
A zmienny token na zasadzie działania wyżej wymienionej?
Krótki czas ważności? Masz na myśli to, że jeden token jest ważny np. 5 min? A co ma się dziać po upływie ważności?
I jeszcze jedno pytanie. Jeśli zrobię tak, że przy każdym zapytaniu będę generował nowy token. To czy może zajść taka sytuacja: "ktoś
A powiedz mi jeszcze o tych kluczach. Bo z tego co wiem publiczny szyfruje a prywanty rozszyfrowuje. To jak to wykorzystać w praktyce? Client szyfruje i przesyła? A co z komunikacją z serwera -> client?
Nic nie sugeruje, mogę się mylić itp, tak tylko pytam dla lepszego zgłębienia tematu;)