(Nie)Bezpieczeństwo API przykładem BLIPa

Opublikował Kubofonista dnia 08.07.2009, w kategorii: Blip, Internet

blip80 Witajcie.

Muszę przyznać, że tego wpisu w ogóle nie planowałem. Jednakże sytuacja z raviciousem natchnęła mnie do tego aby opisać to, ponieważ problem wcale nie jest zbyt błahy a blipa nie używa znowu tak bardzo mało użytkowników. Zapraszam do lekturki

Co to jest API?

API jest to interfejs dla zewnętrznych aplikacji pozwalający na dostęp do konta użytkownika. Serwis dzięki posiadaniu API może być rozwijany również przez niezależnych użytkowników programistów. BLIP dzięki posiadaniu API ma bardzo wiele dodatków stworzonych właśnie przez niezależnych od twórców serwisu ludzi. Przykładowo szmerybajery umożliwia logowanie po ich stronie użytkownika i oni dokonują analizy danych z API w swoich funkcjach.

Uwierzytelnianie

Jak wiadomo skoro API działa na koncie użytkownika wymagana jest autoryzacja. Różne API robią to na przeróżny sposób:

Login i Hasło użytkownika – najgorszy sposób, a zarazem używany przez Blipa, wymaga zaufania użytkownika a także stawia szereg problemów dla serwisu wykorzystującego takowe API
ApiKey – nieco lepszy sposób, używany przez Flakera, jednakże niezbyt przyjazny dla użytkownika, ten podczas rejestracji w serwisie używającym takiego API może nie wiedzieć o jaki klucz jest pytany
OAuth – najlepszy sposób, używany przez Twittera, autoryzacja polega na tym, że serwer klienta API posiada własne keye wygenerowane przez API, a w momencie gdy chce uzyskać dostęp do konta użytkownika, ten ostatni jest odsyłany na oryginalną stronę serwisu w którym dodaje serwis kliencki API do listy dozwolonych, i od tego momentu key tego serwisu ma dostęp do jego konta, czasowy lub stały, zależnie od konfiguracji jednakże w tym przypadku co ważne całość po stronie serwisu klienta API odbywa się bez hasła użytkownika, więcej o tym możesz przeczytać na stronie Dev GGAPI

Problem bezpieczeństwa BLIPa

Jak wspomniałem wcześniej BLIP używa najgorszej z metod autoryzacji użytkownika w API – jego loginu i hasła. Taka sytuacja stawia dla programisty serwisu zewnętrznego poważny problem. Jestem twórcą BBoTa i mogę się wypowiedzieć nt. swoich problemów z tym związanych.

Problem 1 – Jak przechowywać hasło użytkownika?

Pierwszym problemem jest przechowywanie hasła użytkownika. Jak to zrobić? Skoro do API trzeba podstawić login i hasło użytkownika nie można go w swojej bazie zaszyfrować niczym jednostronnym np. MD5. Szyfrowanie musi być odwracalne, i tutaj można sobie własny sposób napisać (np kilka rot13, base64 itd.) , który sprawi, że bez kodu źródłowego baza będzie lekko utrudniona do przeczytania. I tu następna sprawa. Deszyfrator musi być na serwerze, bo przecież aplikacja musi to zdeszyfrować gdy przyjdzie użytkownik. To sprawia, że hasła użytkownika mało który serwis przechowuje, niektóre może plaintextem? Mój dodatek to bot na komunikatorze, więc hasła trzymać musi, aby użytkownik ich nie podawał za każdym razem, jak rozwiązałem tę kwestię – nie powiem.

Problem 2 – Zaufanie użytkownika

Kolejnym problemem jest zaufanie użytkownika takiej aplikacji osoby trzeciej. Skoro użytkownik podaje swoje hasło to ma prawo się o nie bać. I słusznie. Skoro problem1 pokazuje, że ciężko je przechowywać, to użytkownik prawdopodobnie go nie poda. W ten sposób użytkownik jest odcięty od aplikacji osób trzecich, a te aplikacje od użytkownika. Rozwiązanie? W moim bocie jest nim wersja bez hasła. Bot korzysta wtedy ze swojego konta, użytkownik jest “read-only” i ma zabronione tylko wysyłanie do blipa. Użytkownika sobie tu weryfikuję poprzez podesłanie mu pmem kodu aktywacyjnego. Ale to pokazuje, że bez zaufania nie będzie pełnej funkcjonalności.

A rozwiązanie jest proste…

Tak, rozwiązanie tych problemów jest proste. Nie wymagam od BLIPa dużo, w końcu jego właścicielem jest Gadu-Gadu. Wystarczyłby ApiKey który użytkownik by znalazł w swoim profilu. Zamiast loginu i hasła podawałby w aplikacji zewnętrznej ApiKey. Rozwiązało by to oba problemy za jednym razem. Przechowywanie ApiKeya nie musiałoby być tak ściśle tajne jak hasła, zaufanie nie byłoby tak trudne do zdobycia bo ApiKey nie umożliwiałby np skasowania konta. Nieco bardziej złożona wersja zakładałby, że użytkownik miałby opcję dodaj w ApiKeyach która powodowałaby przydzielenie mu kolejnego keya dostępu, nadawałby on mu własną nazwę. Dzięki temu mógłby odciąć dostęp jednej aplikacji a nie wszystkim. Najbardziej wymagająca wersja zakłada, że użytkownik mógłby poszczególnym ApiKeyom nadawać uprawnienia, powiedzmy następujące: odczytywanie pm, wysyłanie pm, wysyłanie dm, wysyłanie statusów, i opcje nie wyłączalną: odczytywanie statusów i dmów.

Inne rozwiązanie niż ApiKey to OAuth. Opisywałem na początku jak to działa. Nie wymagam od BLIPa tego rozwiązania. Minęły by lata świetlne zanim by to wprowadzili. Wspominałem już, że właścicielem BLIPa jest Gadu-Gadu. No to teraz ciekawostka: GG stosuje OAuth :) Nie wierzycie? No to click.

Fajny tekst? Podziel się ze znajomymi:

Zobacz inne ciekawe wpisy:

Tagi: api, bezpieczeństwo, blip

Udostepnij

« Poprzedni Wpis

Jabber – wolność jest w nas

Następny Wpis»

Jak przejść na Jabbera?

Kubofonista

@ sproject:
Owszem ;)
sproject

Zdaje się, że kiedyś o tym rozmawialiśmy...
Kubofonista

@ suda:
No właśnie, mimo wszystko, że GG od dawna stosuje OAuth, ale Api Key w wersji którą najmocniej rozpisałem też nie byłby zły
suda

Przy pisaniu eBlipa też się zastanawiałem nad bezpieczeństwem tego rozwiązania. Przechowuję tam mail i hasło do blipa (gdzie w 90% to hasło byłoby identyczne z mailowym), więc nie dziwił mnie brak zaufania userów. OAuth wydaje się być najlepszym rozwiązaniem, niestety Blip wygląda dziś prawie jak abaddonware, więc o implementacji można zapomnieć.