I tu się mylisz - token nie musi być przechowywany nigdzie
🙂 - kłania się Bezpieczeństwo danych. Wystarczy odpowiednia funkcja haszująca i jej skrót lub ostatni token.
Eeee... no możesz sobie nawet 20 razy to wszystko przehashować i przeszyfrować, ale nie zmienia to faktu, że musisz coś trzymać na karcie, racja? Jak inaczej chciałbyś utrzymać sesję z serwerem? A jeśli jest to na karcie, to można to odczytać. A jeśli można odczytać, to można to wykorzystać w ten sam sposób, w jaki oryginalny klient to robi i się zautoryzować. Żadne hashe Cię przed tym nie uratują.
Generalnie mam wrażenie, że w ogóle nie zrozumiałeś, o co mi chodzi. Jeśli nie chcesz pytać użytkownika każdorazowo o hasło, klient musi zapamiętać po swojej stronie coś, po czym będzie się autoryzował. Zapamiętywanie hasła obniża bezpieczeństwo, więc zazwyczaj jest tak, że klient bądź serwer generuje totalnie losowy token, po czym obie strony go zapamiętują i wykorzystują do autoryzacji. Takie rozwiązanie ma sporo zalet i wydaje mi się, że jest stosowane także przez Googla.
Hashowanie tego tokenu by nie miało żadnego sensu: po jaką cholerę zamieniać jeden losowy ciąg w inny? Mało tego, to by nawet obniżyło nieznacznie bezpieczeństwo ze względu na kolizje.
Jeżeli mówimi o tokenie, to nie musi być przechowywany
Opisz mi algorytm, dzięki któremu będziesz w stanie zautoryzować klienta bez żadnej informacji zapamiętanej przez niego oraz bez podawania żadnego hasła przez użytkownika. Lub ewentualnie taki, w którym klient coś zapamiętuje, ale osoba atakująca nie ma szans tego wykorzystać do zautoryzowania siebie. Rozwiązania typu DRM odrzucamy.
pytanie jest inne, jak będziemy generować nasz token ? na PC można ale co jak zablokujemy sobie komórkę - i nie ma nas w chacie !?
Tego w ogóle nie zrozumiałem :-/
---------- Post dołączono o 16:13 ---------- Poprzedni post napisano o 15:02 ----------
No wygląda na to, że moje przypuszczenia są słuszne:
http://code.google.com/apis/gdata/docs/auth/overview.html
Każda z trzech metod autoryzacji korzysta z tego mechanizmu tokenowego, który opisałem powyżej.
A wyciągając wnioski i przekładając na trochę bardziej ludzki język. Jeśli zaiwanią Ci komórkę z Andkiem, to:
Zrób dokładnie to samo, co przy stracie np. dowodu osobistego - zadzwoń jak najszybciej do Googla i poproś o zablokowanie wszystkich zautoryzowanych sesji z Androida. Z jakiegoś niezrozumiałego dla mnie powodu Google daje możliwość zarządzania tokenami tylko jednej z trzech metod autoryzacyjnych:
https://www.google.com/accounts/IssuedAuthSubTokens , więc wygląda na to, że samemu nie da rady tych Androidowych zablokować i trzeba dzwonić.
Nie bój się wykonać powyższego kroku - w przeciwieństwie do tego przykładowego dowodu osobistego, nic Cię ta blokada nie kosztuje. Jeśli 10 minut po zablokowaniu się okaże, że komórka zwyczajnie wpadła za łóżko, to nie będziesz musiał nigdzie wydzwaniać, coś odblokowywać, tłumaczyć się, itp. - po prostu będziesz musiał się ponownie zalogować do konta Google.
Warto mieć zdalny wipe w odwodzie. Na pewno masz na komórce więcej prywatnych informacji, choćby zautoryzowane sesje w innych serwisach, stronach WWW, itp. Jednak jest to metoda niepewna - wystarczy, że znalazca komórki wie, co robić: wyłączy ją od razu i tyle masz z zabezpieczenia.
Aha, warto też zwrócić uwagę, że te problemy nie dotyczą jedynie komórki, a również np. laptopy. Chociaż na nich łatwiej zadbać o bezpieczeństwo, gdyż można zaszyfrować cały dysk. Tylko ile ludzi to tak naprawdę robi? ;-)