Czego brakuje Flakerowi i Blipowi?
Jednym z ważnych czynników dzięki którym jest możliwy tak dynamiczny rozwój Twittera jest jego otwarte API. Dzięki niemu nad zwiększeniem atrakcyjności platformy pracują nie tylko programiści Twittera, ale również masa entuzjastów -- zarówno hobbystów, jak i ludzi myślących o zarobieniu pieniędzy na szale mikrobloggingowym. Dzięki API mogła powstać np. gra Spymaster, w której twitterowa sieć społeczna jest bardzo istotnym elementem.
Nasze rodzime twitteroidy, Blip i Flaker, również udostępniają swoje API. Są one bardzo sensownie zaprojektowane, nie jest też trudne napisanie dla nich odpowiednich bibliotek klienckich (sam jestem autorem klienta Flakera dla języka Python). Do Blipa istnieje już całkiem sporo dodatków (sporo można ich obejrzeć na bliplabs.pl. Dla Flakera jest ich trochę mniej, lecz po pierwsze jest to mniej popularny serwis, po drugie część funkcjonalności, które w Blipie trzeba implementować za pomocą dodatków jest już tam dostępna na starcie (np. publikacja notek na podstawie RSS-ów).
Niestety, w obecnej chwili nie mogą powstać dodatki do Blipa na miarę Spymastera, a na przeszkodzie stoją względy albo techniczne, albo etyczne, w zależności od tego jak na to patrzeć. O co chodzi?
Niebezpieczna autoryzacja
Jedynym sposobem, w jaki można dokonać autoryzacji przy pomocy API Blipa (co umożliwia nam dodawanie wpisów, wysyłanie wiadomości prywatnych, itp.) jest poprzez podanie swojego loginu i hasła. Sprawia to, że by móc skorzystać z dodatku korzystającego z tych funkcji muszę dać mu pełną kontrolę nad swoim kontem. I nie chodzi już tylko o to, że dodatek może zacząć wysyłać spam za pomocą mojego konta. Bardziej niepokojące jest to, że może bez mojej wiedzy i zgody zmienić hasło, kradnąc tym samym moją blipową tożsamość (przynajmniej dopóki nie zresetuję sobie hasła przy pomocy odpowiedniego formularza). Straty wizerunkowe spowodowane przez takie zdarzenie mogą być nie do odrobienia... Co gorsza, nie będę miał sposobu aby przekonać się, która aplikacja jest winna całemu zamieszaniu.
Oczywiście, daleki jestem od oskarżania autorów dodatków o złą wolę. Tym niemniej, jeżeli aplikacja nie ma pytać użytkownika o hasło za każdym razem, kiedy z niej korzysta, musi przechować je w swojej bazie danych. To z kolei świadczy albo o braku szacunku dla danych swoich użytkowników, albo o braku elementarnej wiedzy na temat bezpieczeństwa. Trzymając niezaszyfrowane hasła w bazie sprawiamy, że dowolny napastnik który uzyska dostęp do bazy może przejąć nad nimi kontrolę. Nie musi się w tym celu włamywać na serwer produkcyjny -- jak najbardziej wystarczą niezbyt stare kopie zapasowe. Warto o tym pamiętać: podając w dowolnym serwisie login i hasło do innego serwisu zachowujemy się nieodpowiedzialnie i narażamy się na kradzież swojej cyfrowej tożsamości.
Twórcy Flakera traktują bezpieczeństwo swoich użytkowników nieco poważniej i przy okazji powstania dodatku Reimess wprowadzili możliwość użycia do autoryzacji tzw. kodu API. Jest to ciąg alfanumeryczny wygenerowany przy pomocy jakiejś kryptograficznej funkcji skrótu, który co więcej umożliwia autoryzację jedynie przy pomocy API (czyli nie daje np. możliwości zmiany hasła).
Niestety, rozwiązanie przyjęte przez Netguru ma kilka bardzo poważnych wad. Po pierwsze, po wygenerowaniu nowego kodu stary traci ważność. Nie mogę odciąć dostępu tylko jednej aplikacji: muszę wszystkim. Po drugie, rozwiązanie to jest zupełnie bez sensu pod względem usability. Aby móc go zastosować, autor dodatku musi wysłać wysłać użtkownika pod inny URL i poprosić, aby przekopiował do formularza ciąg znaków. Ilu użytkowników będzie chciało bawić się w takie ceregiele? Niestety, niewielu. Dla tych kilku bystrych paranoików nie warto pisać aplikacji.
By użyć nieco bardziej mniej technicznej metafory: gdyby Blip wydawał kartę kredytowe, aby zapłacić rachunek w restauracji musiałbym dać kelnerowi równoważną kopię swojej karty i odpowiedni PIN. Gdyby to Flaker wydawał karty kredytowe, nie dawałbym kelnerowi karty matki, a kartę z limitem i PIN. Wszystkie karty dla kelnerów byłyby identyczne i miały taki sam PIN, ale aby zapłacić za każdym razem musiałbym składać podanie. Ze znaczkiem skarbowym, na odpowiednim druczku i dwiema pieczątkami.
Prosto, a jednak bezpiecznie: OAuth
Czy istnieje zatem jakiś sposób, aby umożliwić aplikacjom zewnętrznym dostęp do konta użytkownika, tak aby to było używalne, a jednocześnie bezpieczne? Tak! Umożliwia to stworzony na potrzeby Twittera w 2006 roku protokół, OAuth.
OAuth jest bardzo prosty w obsłudze z punktu widzenia użytkownika. Kiedy aplikacja zewnętrzna (zwana konsumentem) chce uzyskać dostęp do danych użytkownika na innym serwisie (dostawcy), wysyła go pod specjalny adres internetowy, kontrolowany przez dostawcę. Tam użytkownik jest proszony o zalogowanie się (jeżeli nie był wcześniej zalogowany) i informowany o tym, że taki a taki serwis chce uzyskać dostęp do jego danych. Jeśli się zgadza, jest z powrotem przekierowywany do serwisu konsumenta, który otrzymuje specjalny kod dostępu. Odtąd może go używać do wykonywana różnych czynności w imieniu użytkownika. Każdy konsument ma osobny kod dostępu, jest więc możliwe odcięcia jednego serwisu bez żadnego wpływu na pozostałe. W bardziej zaawansowanych scenariuszach jest możliwe np. wydanie kodu dostępu który będzie ważny tylko przez określony czas, np. przez 2 godziny.
Typowym przykładem podawanym aby zademonstrować możliwości OAuth jest następująca sytuacja: Alicja wróciła z wakacji i wrzuciła swoje zdjęcia na serwis FooPhoto. Niestety, jej babcia nie umie korzystać z komputera, a Alicji bardzo zależy na tym, aby staruszka miała szanse je obejrzeć. W związku z tym wchodzi na stronę BarPrint. BarPrint prosi o dostęp do plików na FooPhoto przy pomocy OAuth. Alicja jest wysyłana na odpowiednią stronę, gdzie wybiera, które pliki mają być udostępnione BarPrint na najbliższe dwie godziny. Następnie FooPhoto przekierowuje Alicję z powrotem na BarPrint, gdzie wybiera sobie format i rodzaj papieru, na którym mają zostać wydrukowane.
OAuth jest coraz bardziej popularny. Wspierają go Twitter, Yammer, Google, Yahoo, Netflix... Z polskich serwisów od sierpnia 2008 roku wspiera go, uwaga-uwaga... Gadu-Gadu, czyli właściciel Blipa! Tym bardziej dziwi kulawe pod względem bezpieczeństwa API. No ale cóż, 2 lata (GG przejęło Blipa 11 czerwca 2007 roku, jeśli wierzyć Wikipedii) to najwyraźniej za mało na zintegrowanie bazy kodu Blipa i GG...
Oczywiście, OAuth nie jest protokołem pozbawionym wad. Odpowiednie skonfigurowanie konsumenta OAuth nie jest niestety zupełnie trywialne od strony technicznej. Zrobienie tego dla Netfliksa zajęło mi niemal 5 dni, ale było to nie bez związku z tym, że w kilku sytuacjach Netflix nieco nagina protokół do swoich potrzeb (choć to akurat temat na inną notkę). W kwietniu tego roku znaleziono niewielką lukę w protokole (ciekawie opisano to tutaj - linka podrzucił mi Ols). Mimo tej luki protokół wciąż jest o niebo bezpieczniejszy niż alternatywa, czyli wysyłanie gołego hasła.
Co dalej?
Obecna sytuacja strasznie mnie frustruje. Mam kilka pomysłów na wykorzystanie API zarówno Blipa jak i Flakera (np. marzy mi się integracja komentarzy na Gryziemy z Flakerem). Niestety, nie realizuję ich, ponieważ API Blipa nie jest bezpieczne, a token zbyt niewygodny w obsłudze. Jeśli Blip do tej pory nie ma OAuth, to chyba nie ma co się łudzić, że jego obsługa zostanie dodana w najbliższym czasie. Flaker jednak wciąż dość szybko się rozwija. Nie tracę więc nadziei, że chłopaki i dziewczyny z Netguru jakoś niedługo pójdą po rozum do głowy i zastąpią swoje rozwiązanie na pół gwizdka sensownym standardem.
Do dyskusji zapraszam najchętniej na flakerze.
-
29-06-09, 21:50
Ciekawy i potrzebny wpis.
Od kilku dni testuję BlipFoxa i bardzo irytujące jest że w konsoli JS co kilkanaście sekund widzę błąd JS
"Błąd: błąd składni
Plik źródłowy: http://login:haslo@api.blip.pl/dashboard...
Kod źródłowy:
[]"
Oczywiście hasło i login są przesyłane jawnie po http.
Domyślam się że wszystkie dodatki tak działają.
Zatem domorosły hakier skanujący pakiety może zrobić ciekawe zamieszanie na blipie kiedy tylko będzie chciał. -
30-06-09, 23:01
I właśnie z tego powodu Sekretarka i inne SzmeryBajery.pl nie mają autologowania czy innych fajnych funkcji. Kombinuję z jakimś szyfrowaniem przy okazji prac nad nową wersją, ale korzystanie z takich dodatków wciąż wymaga pewnego zaufania do twórcy...
-
02-07-09, 22:52
@Tomasz Topa:
Niestety, jakiekolwiek szyfrowanie niejednostronne haseł użytkownika to jest tylko security through obscurity, bardziej lub mniej wyrafinowane... -
03-07-09, 07:59
Fajny ten Wasz blog.
Co do tematu to czekam od kiedy będzie możliwość na Twitterze wysyłania smsów z polskich komórek w polskich cenach.
A tak na marginesie co sądzicie o tym, że twórcy Twittera chcą zacząć zarabiać na nim dzieląc się zyskami z wysłanych smsów z operatorami ? Wg mnie to głupie, bo wiele opów nie pobiera opłat za smsy (de facto ich też nic nie kosztuje wysłanie smsa).
-
05-07-09, 13:54
Czytam o aplikacjach z opadajaca szczeka.
Dzieki za podzielenie sie cenna wiedza i uwagami. -
06-07-09, 20:29
hola hola drodzy maruderzy. czy wy w ogole zdajecie sobie sprawe jak dziala api blipa? wykorzystuje REST (http://pl.wikipedia.org/wiki/REST) a on wykorzystuje tylko i wylacznie HTTP. dzieki temu api jest "lekkie" i latwe w implementacji (nie wymaga zewn. bibliotek).
czyli wszystko jest ok, nie rozumie jak ktos moze ukrasc ci tozsamosc? no chyba ze cie zesniffuje, ale to juz przestepstwo ;) -
06-07-09, 20:40
<blockquote>Oczywiście hasło i login są przesyłane jawnie po http.
Domyślam się że wszystkie dodatki tak działają.</blockquote>E, nie. Poczytaj <a href="http://www.blip.pl/api-0.02.html">API</a>.
@Tomasz Topa
Jeśli chodzi o PokaPulpit, to napisałem kod, który pobiera ostatni status z kokpitu danego usera. Jeśli wpisze poprawny login i hasło, to jest mu przypisywana sesja. Hasło nigdzie nie jest trzymane.No ale Sekretarka to co innego, ona musi mieć dostęp do kokpitu, żeby odczytać wiadomości. I zgadzam się z Ryszardem, lepiej nic nie szyfrować.
-
06-07-09, 21:01
W ramach sprostowania ani API Blipa ani Flakera nie pozwala na zmianę danych użytkownika (wliczając w to zmianę hasła).
Z drugiej strony ani Blip ani Flaker nie loguje po SSL-u; więc ten artykuł to trochę burza w szklance wody :D -
07-07-09, 01:05
Ryszardzie, nie wiem kogo chcesz wkręcić, ale babcia Alicji umarła w listopadzie. Żadnych wakacji nie było.
-
08-07-09, 00:49
"Niestety, w obecnej chwili nie mogą powstać dodatki do Blipa na miarę Spymastera"
pytanie po kiego takie dodatki.
dalej: "niewielka luka" przyprawiła ćwierć internetu o ciężką sraczkę: http://www.readwriteweb.com/archives/... - kto wie, ile jeszcze ich się tam kryje
@blas - "domorosły haker skanujący pakiety" to prędzej się zainteresuje hasłem do profilu google niż jakimśtam niszowym serwisikiem
w ogóle to nie wiem, jak można poważnie myśleć o wykorzystaniu api blipa, skoro są tam takie kwiatki jak:
"Administratorzy serwisu Blip.pl rezerwują sobie prawo do wyłączenia części lub całości API, blokowania użytkowników bez podawania przyczyn i dowolnej modyfikacji zasad dostępu oraz wprowadzania ograniczeń, przede wszystkim z powodu nadużyć różnej formy."
- gdzie tu otwartość na pomysły entuzjastów - zarówno hobbystów, jak i ludzi myślących o zarobieniu pieniędzy na szale mikrobloggingowym? zamiast integrować bazy kodu administratorzy wolą rzucać arbitralne kłody pod nogi entuzjastom! -
09-07-09, 01:36
@Jakub Fiorczyk - no i co z tego, że nie można zmienić hasła przez API? Co przeszkadza potencjalnemu napastikowi który uzyskał dostęp do bazy danych dodatku po prostu zalogować się na czyjeś konto za pomocą przeglądarki i tam zmienić hasło?
-
09-07-09, 01:52
@ols - ta sraczka i styl w jakim sobie z problemem poradzili wyjątkowo dobrze świadczą o społeczności OAuth. Luka nie była jakoś strasznie hardkorowa - napastnik mógł wygenerować sobie link autoryzacyjny do swojej haksorskiej aplikacji, wysłać go ofierze, ofiara musiała w niego kliknąć, nie zauważyć, że nazwa aplikacji jest trefna i się zalogować (to w skrócie). Dodam, że do zrobienia aplikacji konsumenckiej potrzeba tokenu i sekretu od providera, więc od razu byłoby wiadomo, kto za tym stoi. Swoją drogą, dzięki za ten artykuł, fajny jest, podlinkuję go w treści posta.
-
31-08-09, 15:20
OK, zastanawiają mnie dwie rzeczy:
- traktowanie serwisu typu Blip równie poważnie, jak np. konta w banku :/
- "paranoja" dotycząca możliwości przechwytywania hasła na taki serwis (w tym, założenie, że przechowywanie go na dysku komputera jest bardzo niebezpieczne).A przechowywanie haseł w przeglądarce czy programie pocztowym jest bezpieczne? Też nie, a 99% użytkowników z tego korzysta. To raz.
Dwa, ja bym się raczej zajął takim bezpieczeństwem stacji roboczej, żebym mógł na niej przechowywać cokolwiek i nie martwić się o bezpieczeństwo. Jak tego dokonać? Otóz:
1. Nie instalujemy BADZIEWIA na komputerze - które może zawierać trojany, backdoory itd.
2. Szyfrujemy CAŁY dysk twardy (Truecrypt lub np. szyfrowanie wolumenów w Linuksie).
3. Instalujemy wszystkie poprawki bezpieczeństwa.
4. Mam skomplikowane hasła, możliwe do zapamiętania dzięki mnemotechnice - proste, można poczytać w sieci.
5. Odchodząc od komputera, albo go wyłączamy, albo przynajmniej blokujemy ekran (np. pod Windows kombinacja klawiszy Windows-L).I tak, na stacji roboczej trzymamy zazwyczaj masę ważnych, prywatnych danych, więc to, czy ktoś ukradnie hasło do Blipa brzmi.. no głupio zwyczajnie w zestawieniu z resztą.
A jeśli stacja robocza jest dobrze zabezpieczona i posługujemy się nią "z głową", to hasło do Blipa możemy trzymać w pliku *.txt na desktopie. :)
-
22-09-09, 12:10
Zapraszam do testowania OAuth na Blipie.
-
24-09-09, 16:58
@Marcin - thx!
-
29-09-09, 20:35
MacGość ukłony, zgadzam się co do joty.
