20:59
3/7/2012

Jeden z Wykopowiczów korzystający z mobilnej aplikacji do obsługi Wykopu spanikował, bo zauważył, że przechowuje ona hasło na telefonie jawnym tekstem.

Jak można przechowywać hasła w aplikacji mobilnej?

I co z tego, że hasło jest trzymane na komórce użytkownika w plain-text, chciałoby się rzec? Przy projektowaniu aplikacji mobilnej umożliwiającej dostęp do jakiegoś konta w serwisie internetowym, aplikacja może:

  • a) każdorazowo prosić użytkownika o wprowadzenie hasła (Podejście to jest bardzo bezpieczne, o ile ktoś nie podsniffuje tego hasła “w tranzycie” np. z powodu braku TLS/SSL lub przy pomocy ataku sslstripem. Jednocześnie jest to podejście niewygodne, zwłaszcza na telefonach komórkowych).
  • b) zapisać hasło w pliku (podejście mniej bezpieczne, ale czy niebezpieczne?)
Wykopowa aplikacja Hasło w wykopowej aplikacji

Wykopowa aplikacja na Androida - fot. michuck

No właśnie, hasło zapisać można:

  • 1) jawnym tekstem (dostęp do niego będzie miał każdy, komu pozwalają na to uprawnienia do pliku zapisanego w telefonie)
  • 2) zaszyfrowane symetrycznie (co oznacza, że aplikacja musi znać klucz/algorytm szyfrowania, aby w razie potrzeby odczytać sobie owo hasło na swoje potrzeby automatycznego logowania). Uwaga! W przeciwieństwie do przetrzymywania haseł po stronie serwera, tu, na kliencie, w grę nie wchodzi hashowanie, bo funkcje skrótu są funkcjami jednostronnymi (wykorzystuje się je do porównywania przekazanego przez użytkownika hasła z tym, które trzyma się w bazie)!

Oczywiście podejście 2) jest odrobinę bezpieczniejsze niż podejście 1), bo osoby bez zdolności z pogranicza reverse-engineeringu/debuggingu nie będą w stanie dojść do tego jak wygląda funkcja rozszyfrowywania hasła i koniec końców go nie przechwycą. Obfuskacja kodu utrudnia ale nie uniemożliwia poznanie tego jak działa (chociaż Skype trzyma się dzielnie, ale i “waży” dużo więcej niż powinien… Warto?).

Nie łudźmy się jednak, skoro jakiś program na kontrolowanym przez nas sprzęcie potrafi coś rozszyfrować, to my możemy poznać i zanalizować metodę, w jaki sposób to robi (i suma sumarum hasło uzyskać; kwestia umiejętności — lub ściągnięcia odpowiedniego programu-dekodera, bo zazwyczaj ktoś kto pierwszy rozwiąże zagadkę, szybko napisze i rozpowszechni odpowiednie narzędzie).

Dodatkowe wskazówki dla twórców aplikacji mobilnych

Twórcy aplikacji mobilnych powinni zastanowić się nad tym, czy ich aplikacja będąca klientem do serwisu internetowego powinna w ogóle umożliwiać dostęp/zarządzanie całym kontem użytkownika (móc wykonywać wszystkie akcje, czy tylko kilka?).

Warto także rozważyć generowanie osobnego hasła (tokena, por. OAuth) na potrzeby zewnętrznych klientów (w tym aplikacji mobilnych). W takim przypadku osoba logująca się na konto standardowo, przez przeglądarkę, powinna móc unieważnić token powiązanej z kontem aplikacji (co może się bardzo przydać w przypadku zgubienia telefonu).

Pamiętaj!
1. Nigdy nie implementuj własnej kryptografii. Skorzystaj z gotowych bibliotek kryptograficznych. Serio.
2. Security by obscurity to nie jest dobra metoda ochrony.
3. Algorytmy kryptograficzne są jawne/znane/open-source, a klucze są tajne.

Przede wszystkim jednak, pamiętajcie, żeby nikomu nie udostępniać swojego telefonu (wszystkie wyżej wymienione ataki wymagają od atakującego dostępu do telefonu, niekoniecznie fizycznego — można wyexploitować np. jakąś dziurę w Androidzie) i mieć unikalne hasła do każdego serwisu (wtedy potencjalny wyciek hasła z jednego z nich, nie wpłynie na bezpieczeństwo danych w innych serwisach).

Programiści aplikacji mobilnych, macie jeszcze coś do dodania?

PS. Tych których na poważnie interesuje bezpieczeństwo aplikacji (mobilnych i internetowych) zapraszamy na nasze szkolenia. Omawiamy tam nie tylko jak bezpiecznie projektować (web)aplikacje i jakich błędów unikać, ale przede wszystkim pokazujemy praktyczne ataki, narzędzia i metody ochrony, dzieląc się doświadczeniem zebranym podczas wykonywania testów penetracyjnych dla naszych klientów. Najbliższe szkolenie na które są jeszcze wolne miejsca to Warszawa 30-31 sierpniatutaj szczegóły.


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

67 komentarzy

Dodaj komentarz
  1. Można połączyć a) z b2) – zaszyfrować hasło PIN-em, każdorazowo wprowadzanym przez użytkownika.

    • Niestety, daje to niewiele więcej niż trzymanie tego “pinu”/klucza w aplikacji. Dlaczego? Ponieważ taki PIN musiałby być dość prosty, tak aby użytkownik chciał go wprowadzać za każdym razem. Niestety, aby szyfrowanie miało jakikolwiek sens klucz musi być dość silny, a więc z tego punktu widzenia ten PIN musiałby być równie dobry jak dobre hasło. Tak więc:
      1. Jeśli PIN będzie wygodny, to zwykły brute force znajdzie ten PIN w kilka minut.
      2. Jeśli PIN będzie dobry, to w zasadzie całe zapamiętywanie hasła mija się z celem, bo po to się zapamiętuje hasło by go nie wprowadzać za każdym razem.

      Oczywiście nasuwa się pomysł z ograniczeniem ilości prób, natomiast jeśli atakujący ma dostęp do telefonu (a skoro rozpatrujemy bezpieczeństwo przechowywania hasła na telefonie to mówimy własnie o tego typu dostępie) to może ten PIN brute’ować offline (czyli po prostu wyekstraktuje szyfrogram hasła, wyekstraktuje implementacje deszyfrowania, i podepnie pod to brute’a).

      Można by więc to rozwiązać sprzętowo i mieć jakiś safe storage na hasła wspomagany sprzętowo (zew. chip) – i to jest jakieś rozwiązanie (bodajże Google Wallet korzysta z takiego rozwiązania – patrz Secure Element).
      (wtedy pozostaje się martwić o te kilka osób na świecie, które wiedzą jak podejść do reverse engineeringu chipa, ale mam wrażenie, że wtedy koszt by przekroczył już wartość hasła na wykop ;p).

    • @Gynvael Coldwind – myślę że znacznie taniej wyszedłby ‘brute force’ – http://xkcd.com/538/ :>

    • @Gynvael Coldwind: Niekoniecznie. APka będzie miała dostęp przez API z oddzielnym kluczem, a np API automatycznie zablokuje każde konto po dwu-trzykrotnym wprowadzeniu złego klucza/hasła. Wtedy BFem możesz sobie nawet zdekodować wszystkie kombinacje – i tak masz tylko np 3 szanse (przy 4 znakowym pinie daje to szansę 3/1000 czyli 0,3% na poznanie klucza). Ciągle dużo, ale zdecydowanie lepiej, niż 100%.

    • Późno piszę, ale myślę że można połączyć a i b2 na zasadzie wężyka – łatwo i szybko, można go “wpisać”, nawet jak jest długi, a dzięki temu, że jest długi może być bezpieczniejszy niż PIN. Dodatkowo ograniczenie do 5 prób i potem usuwania hasła i konieczność podania go.

      Wydaje mi się, że dobrą metodą jest klucz (token) dla urządzenia i wykorzystanie sumy ID urządzenia, numeru IMEI i innych indywidualnych danych jako identyfikatora.

  2. 3. Opcja taka:
    Logujemy się na wykop.pl poprzez API. Wysyłamy tam hasło, no i w wyniku otrzymujemy klucz – wygenerowany losowo itp.
    Ten klucz zapisujemy na komórce, i następnym razem jak chcemy się zalogować, to użyjemy metody do logowania się tym kluczem (klucz ten też zapisany w bazie wykop.pl), a nie oryginalnym hasłem :)

  3. oj nie przeczytałem do końca, proszę usunąć mój komentarz ^

  4. Wydaje mi się, że trzymanie na komórce posolonego hasha i autoryzowanie się nim (zamiast liczenia hasha z hasła po stronie serwera) miałoby pewną zaletę – w przypadku poznania hasha do danego serwisu mamy dostęp, ale nadal nie wiemy, jakie to hasło. A mało kto używa kompletnie różnych haseł do każdego serwisu.

    • Na pewno utrudni to dostęp do hasła, ale nie do konta użytkownika przez “API komórkowe” (pojawia się pytanie czy jest jakiś identyfikator sesji w takim wypadku i czy zadziała on również via zwykła strona WWW).

      Natomiast… no właśnie – utrudni dostęp do hasła, ale niekoniecznie uniemożliwi – to, że hasło jest posolone niestety nie przeciwdziała zwykłym brute force czy też atakom słownikowym, więc jeśli hasło jest słabe, to i tak zostanie odkryte. Więc tutaj sporo zawierza się użytkownikowi, a raczej sile jego hasła.

      Kiedyś wpadł mi do głowy pomysł, żeby być trochę “wrednym” i użyć zamiast dobrego hasha jakiegoś prostego checksuma typu CRC32. Dlaczego? Ponieważ ten hash jest na tyle krótki, że liczba kolizji przy brute będzie bardzo wysoka, a więc trudniej będzie znaleźć oryginalny pre-image (ponownie: trudniej != że jest to niemożliwe), ale mimo wszystko ma się szanse tylko 1/2**32 na zgadnięcie hasha autoryzującego do mobilnego API ;p

      None the less, zamiast tak kombinować, lepiej po prostu w ogóle nie trzymać hasła w żadnej postaci na komórce, tylko użyć jakiegoś tokenu or sth (jak w newsie).

  5. Mozna trzymać md5 na urządzeniu, ale aplikacja webowa musi akceptować md5 zamiast czystego hasła. Jaki jest plus takiego rozwiązania? Owszem, gdy ktoś przechwyci md5 i tak może się zalogować, no ale hasła nie pozna (przy założeniu, że jest odpowiednio silne).

    • s/md5/hash – bo zakładam, że nie chcesz nikogo namawiać do korzystania z tej f. skrótu, a jedynie używasz jej jako synonim hashowania ;)

    • Problem w tym, ze hashujac hasla w bazie na serwerze w bardziej skomplikowany sposob niz md5 (sol, inny algorytm) rozdajesz to rozwiazanie razem z aplikacja Androidowa i w razie wycieku bazy masz w rekach od razu algorytm jakim zahashowane sa hasla – a trzymajac haslo czyste/szyfrowane na urzadzeniu tylko to jedno haslo jest zagrozone (i to o ile sam telefon dostanie sie w cudze rece).

    • Maciej, jak mam dostęp do hashy z bazy, to zakładam konto na serwisie z hasłem abc123, biorę na tapetę kilka “popularnych” metod tworzenia salta i patrzę, czy mi wychodzi równość. Patrząc po wynikach pentestów, które robimy, to wbrew pozorom, programiści nie są tacy błyskotliwi jak im się wydaje ;-)

      “Unikalne” metody saltowania, to niestety podejście typu “security by obscurity”, o którym jest odpowiednie zdanie w powyższym artykule.

      Celem hashowania z saltem jest *opóźnienie* a nie uniemożliwnienie ataku. Salt można trzymać w osobnej kolumnie w bazie, albo wyliczać algorytmicznie (lekko lepiej). A tak naprawdę “solenie” haseł to i tak złe podejście, bo funkcje hashujące (md5,shaN) to funkcje zoptymalizowane na czas (są szybkie) a w przypadku łamania haseł zależy nam na tym, aby atakujacy miał jak najmniejszą wydajność (hint: korzystać z bcrypt).

    • @Piotr Konieczny jak najbardziej. Tak sobie myśle, że od klienta mogło by wychodzić coś takiego hash(x || hasło) gdzie x to stała. Wówczas utrudniamy atak z wykorzystaniem tablic teczowych – trzeba wygenerować specjalne tablice dla x.

    • @Maciej a co za problem po stronie serwera potraktować hash od klienta “tajnym” algorytmem np. 500x sha256?

    • @Piotrku, BCrypt albo PBKDF2: http://www.codinghorror.com/blog/2012/04/speed-hashing.html

    • Albo zamiast scrypt zamiast bcrypt http://www.tarsnap.com/scrypt.html – a w ogóle warto zapoznać się ze świetną prezentacją Solar Designera
      http://www.openwall.com/presentations/PHDays2012-Password-Security/

    • Trochę off topic :)

      Usłyszałem niedawno bardzo fajny argument w dyskusji o bcrypt/etc (nie-cytat):
      “Co z tego, że hash liczy się 10000 razy wolniej, jeśli wystarczy, że atakujący dołoży 10000 maszyn do brute’a.”

      Oczywiście, wolniejszy hash ogranicza ilość potencjalnych atakujących do takich, co faktycznie mają dostęp do dużej ilości maszyn, ale… słyszałem, że te botnety ostatnio takie duże, a i wynająć je można dość tanio :)

      Tak więc bcrypt/scrypt/whatever nadal nie rozwiązuje problemu, chociaż jest pewnym “uwrednieniem” :)
      (innym uwrednieniem jest użycie md5() ze zmodyfikowaną tablicą T[] – pewnie parę minut się ugra zanim atakujący się zorientuje czemu jego brute/tables/whatever nie działa; natomiast… to co najwyżej kupi trochę czasu, i uda się tylko raz, ale również nie rozwiąże problemu ;>)

    • istotną cechą scrypta jest to, że oprócz zwykłego zwiększenia ilości operacji dodaje też względnie duży narzut na pamięc co istotnie ogranicza możliwość tworzenia hardware’owego równoległego łamacza (pamiętajcie, że na nowoczesnej karcie graficznej możemy sprawdzać miliardy skrótów na sekundę) – to nie jest różnica 10k ale 6-7 rzędów wielkości dalej.

    • “Tak więc bcrypt/scrypt/whatever nadal nie rozwiązuje problemu, chociaż jest pewnym “uwrednieniem” :)”

      Nic nie ‘rozwiązuje problemu’ tak naprawdę – w końcu całe szyfrowanie, zabezpieczenia, etc. opierają się na zasadzie wysiłku potrzebnego na ich załamanie i potencjalnego zysku.

    • @Gynvael: moim zdaniem rozwiązania typu bcrypt czy scrypt nie tyle mają rozwiązać problem (możliwość złamania hasła, jeśli atakujący dysponuje odpowiednią mocą obliczeniową), lecz raczej kupić czas na reakcję. Oczywiście zwiększają również koszt ataku, choć patrząc na crowdsourcing, który miał miejsce przy łamaniu hashy z LinkedIn, mam wątpliwość czy ten koszt jest wciąż tak istotnym parametrem (tak, można też wykorzystać botnet, ale to już obejmuje koszt stworzenia/wynajęcia botnetu).

    • @gynvael: przy okazji LinkedIna – hashe były “dziwne” (btw Twojego pomysłu na “modyfikacje”), 1 dzień i pojawił się patch na jtr… ;)

    • Przy założeniu, ze idea bezpieczeństwa polega na opóźnieniu działań złoczyńcy ukrywanie swoich metod ma sens. Coś w rodzaju “security enhanced by obscurity”. Dlaczego ktoś ma stosować dobrze znane metody w dobrze znany sposób skoro już jest N sposobów jego złamania? A dodać jakiegoś XORa albo Lookup Table a potem jeszcze zaszyfrować. Wtedy ktoś będzie się musiał jeszcze nagłowić przed zastosowaniem istniejących narzędzi. I nagle hash wyda się dziwny.

    • Daje to więcej czasu w przypadku wykrycia włamania. Co więcej, gdyby każdy system bezpieczeństwa miał swoja unikalną metodę, oczywiście opartą na zastosowaniu serii N przetestowanych algorytmów, takie ogólne narzędzie do łamania nie miało by racji bytu. Należy stosować tajne, mocne i różne hasła na każdym z serwisów. A dlaczego nie zastosować tej metody także do zabezpieczeń? I dlaczego jej nie zmieniać po każdym włamie, tak jak to się robi z hasłami?

  6. Pod Windows Phone jest sympatyczna klasa (ProtectedData), która może zaszyfrować dane używając kombinacji identyfikatora urządzenia/urzytkownika:

    http://msdn.microsoft.com/en-us/library/2c64xe0y(v=vs.95)
    A to z kolei można zapisać w IsolatedStorage :)

    Generalnie zawsze poczytać co oferuje producent i dostawca technologii, zanim zacznie się wynajdować koło ;-)

    • @PawelB Hmm ale przecież aplikacje mobilne nie kończą się na WP7 ba rzekłbym nawet że się tam nie zaczynają. Więc to że WP7 coś ma nie zmienia tego że większość platform tego jednak nie ma.

    • A jak trzymane jest hasło do Facebooka, Dropboxa, Google?
      Ja bym się przy zabezpieczaniu takich rzeczy zainteresował AccountManager

    • @rox: PK prosił, żeby jako dev mobilnych napisać jak sobie z tym radzimy, więc dostał odp. od wakacyjnego developera apek pod Windows Phone. Świat też nie kończy się na Andku czy iOSie ;-)

    • Pod iOS natomiast jest Keychain Services, gdzie można do szyfrowanego słownika wrzucić hasło/token OAuth, a dostępne będzie tylko dla aplikacji która je tam umieściła.

      Ważne jednak by takich wyciągniętych z jakiegoś ciemnego zakamarka haseł/tokenów nie przechowywać za długo i za często w pamięci. Do tych celów też poszczególne systemy raczej oferują specjalizowane klasy a’la string. Trudniej jest wtedy mając migawkę pamięci operacyjnej urządzenia uzyskać takie rozszyfrowane hasła.

  7. No shit, Sherlock. Pierwszą rzeczą (no, może drugą), jaką robię po zainstalowaniu aplikacji na Androidzie to sprawdzenie plików, odczytanie baz danych, czasem nawet dekompilacja. Wykop nie jest jedyny, ale – tak właściwie – to nie jest zbyt duże zagrożenie. Dopóki user nie zrobi roota, a potem nie przyzna uprawnień aplikacji, która będzie przygotowana specjalnie po to, by kraść dane użytkowników Wykopu, dopóty nikt tych danych przeczytać nie może. Isolated storage, tak się to zwie. Gorzej by było, gdyby to hasło siedziało w /sdcard/TU_JEST_HASLO_DO_WYKOPU.txt ;)

    • Ty się lecz człowieku

    • @Michał Surmaczewski
      Nie rozumiem Twojego komentarza. Tzn… ty tak nie robisz? ^_-

    • Gyn, Ja wiem, żeś jest ze środowiska reverse engineeringu, ale nie popadajmy w paranoje :D

    • Pierwszą rzeczą jaką robie po zainstalowaniu aplikacji na androidzie… oh wait przecież ja używam odpornej na ataki nokii 3310 a nie wykastrowanego PCta z jaką dziwaczną dystrubucją linuxa

  8. Tak samo robi aplikacja Plesk do administracji serwerami hostingu.

  9. Ehhh studenciki i licealiści z wykopu. W nocy śni im się zły plain text.

  10. W androidzie jest cały framework do uwierzytelniania i autoryzacji użytkowników, który jest również używany przez aplikacje Google’a. Więcej info tutaj: http://developer.android.com/reference/android/accounts/AbstractAccountAuthenticator.html

  11. Szczerze mówiąc w przypadku aplikacji mobilnych chyba optowałbym za uwierzytelnieniem typu challenge/response (coś opartego o HOTP/OCRA). Stosowną funkcjonalność można zaszyć w aplikacji, w związku z czym uwierzytelnienie się do serwisu sprowadzać się może do podania kodu PIN o długości np. 4 lub 6 znaków (nawet cyfr). Jest to zarówno wygodne dla użytkownika, jak i bezpieczne.

    Jeśli jedynym sposobem na zweryfikowanie poprawności podanego przez użytkownika kodu PIN jest wysłanie go do serwisu, do którego użytkownik chce się uwierzytelnić, wówczas ta niewielka przestrzeń możliwych kodów PIN nie jest realnym problemem, konto można blokować po kilku nieudanych próbach uwierzytelnienia. Większym problemem są błędy w implementacji, które pozwalają odzyskać PIN “offline”, na przykład na podstawie zapisanych lub nieopatrznie zalogowanych na urządzeniu danych. Mam kilka tego typu błędów na rozkładzie.

  12. Proponowałbym zamiast hasha, żeby aplikacja mobilna szyfrowała hasło za pomocą klucza publicznego serwera i tak zaszyfrowane hasło wysyłała na serwer. Serwer odszyfrowywał by to swoim kluczem prywatnym, hashował i wynik porównywał z hashem trzymanym w bazie. Moim zdaniem trudniejsze do złamania niż hash, ze względu na większą moc obliczeniową potrzebną do złamania bruteforcem.

    • A ja, jako wredny atakujący, zamiast robić to, czego Ty oczekujesz (próbować odszyfrować hasło), po prostu wyślę go do serwera w formie zaszyfrowanej :)

    • @krzysiek: Hm… a jak to rozwiązuje problem trzymania hasła na kliencie? ;)

    • @Paweł: Super. Możesz zakopać jakieś zdjęcia kotów i zwyzywać kogoś od lewaków. Ale hasła nie poznasz, więc nie masz solidnej(w większości wypadków) bazy do ataków na maila, bank, facebook, czy inne konta, które zawierają jakieś na prawdę użyteczne dane.

    • @Piotr – nie rozwiązuje problemu, ale z trojga złego (plain tekst, hash, hasło zaszyfrowane algorytmem asymetrycznym) wybieram opcję 3 :)

  13. ciekawe jak ten problem rozwiazal facebook ;) :P

    • OAuth

  14. Nie ma prostszego rozwiązania?
    Przepraszam, że opiszę w ten sposób, ale dopiero idę na studia :D

    1. Aplikacja hashuje hasło i wysyła do serwera.
    2. Serwer zapisuje hash.

    Przy autoryzacji:
    1. Serwer wysyła sól. Hashuje hash tą solą.
    2. Aplikacja hashuje dostarczoną solą zapisany w pamięci hash i odsyła.
    3. Zahashowane hashe pasują – hasło prawidłowe.

    W pamięci telefonu jest zapisane zaszyfrowane hasło, na serwerze też, a osoba przechwytująca ruch albo dostająca telefon w swoje ręce nie jest w stanie (w sensownym czasie) go poznać.

    • Średnio. Zakładając, że logowanie przez www jest klasyczne, to oryginalnego hasła atakujący “nie” pozna, ale w niczym nie przeszkodzi mu to w korzystaniu z mobilnej wersji, bo i tak będzie posiadał wszystkie konieczne składniki.

    • Ale osoba wybierająca opcję “Nie wylogowuj mnie” jest świadoma, że jeżeli telefon zostanie ukradziony to złodziej będzie zalogowany.

      Konto na wykopie ma małą wartość, ja w ramach ćwiczenia szukałem rozwiązania, które zapewni tą funkcjonalność, jednocześnie uniemożliwiając złodziejowi odczytanie hasła i użycie go do przeglądania poczty itp, a osobie pośredniczącej próbującej przechwycić hasło uniemożliwi logowanie się i jego odczytanie.

    • Ale bycie stale zalogowanym nie ma tu przecież nic do rzeczy. Atakujący będzie miał hash, będzie mógł zapytać serwer o challenge i bez problemu wykona response. W niczym nie uniemożliwi mu to zalogowania się. A to, że będzie posługiwał się hashem czy hasłem nie robi różnicy, bo będą równoważne.

  15. Najlepiej za każdym razem wpisywać hasło, wysyłanie szyfrowane i tyle w temacie. Sami jesteśmy odpowiedzialni za nasze bezpieczeństwo i wszelkie aplikacje instalujemy na własną odpowiedzialność. Czyż nie?

    • Wrodzona/nabyta paranoja mówi mi, że przy wpisywania hasła trzeba się upewnić, że nikt się nie interesuje tym co wpisujesz (nie zagląda przez ramię, etc). Więc… wpisywanie hasła “co chwile” tylko zwiększa prawdopodobieństwo, że ktoś kiedyś jednak spojrzy Ci przez ramię :)

      Więc… to też nie rozwiązuje problemu, szczególnie w przypadku urządzeń używanych w miejscach publicznych.

    • no to może coś a la pwsafe 4ndroid?

  16. Hm @Piotrze nie za bardzo rozumiem co masz na myśli wypowiadając takie słowa: “chociaż Skype trzyma się dzielnie”. O ile dobrze pamiętam to jakieś pierwsze wersje Skype posłużyły do zabawy przez niegrzecznych chłopców, zgadza się? Chodzi mi np. o przebadanie protokołu komunikacji chyba, że coś mnie ominęło :P

    • Generalnie reversowali, reversowali, dużo poznali, ale gdzieśtam się poddali z tego co pamiętam. Z braku czasu oczywiście. Chwalili natomiast Skype’a za obfuskacje i ganili za penalty jakie dawała wydajności ;)

    • Co jakiś czas temat wraca mi jak bumerang. Akurat konkretnie Skypem się nie interesuje jeżeli chodzi o reverse engineering aczkolwiek zdarza mi się przeglądać jakieś prezentacje na temat komunikacji robione zazwyczaj przez Amerykańskich studentów :P

      Przypomniało mi się jak w 2k8 roku “rozbroili” Xbox’a360 na części pierwsze :)

  17. Opera Mini (Java ME) też przechowuje hasła w plaintekscie na kliencie.

  18. /data/data (SharedPreferences) standardowo jest niedostępny dla userów i apek. Taki mały sandbox. Trzeba mieć roota – co oczywiście (uprzedzając przytomnych) nie stanowi dla bardziej wytrwałych problemu.
    Obawiam się, że sporo aplikacji może tam trzymać hasła.
    na Androidzie jest trochę opcji:
    http://developer.android.com/reference/android/accounts/AccountManager.html
    http://developer.android.com/reference/java/security/KeyStore.html

  19. Ludzie… problemem nie jest to czy tos to haslo wykorzysta do zalogowania sie w systemie tylko to ze w pierdziu duzo ludzi uzywa tego samego hasla do wszystkiego. Jak dasz komus dostep do swojego telefonu, albo go zgubisz to jasna sprawa ze zadne hashe itp nie pomoga bo najczesciej konta sa poustawiane na zapamietanie zalogowania. Bajzel zrobi sie wtedy kiedy okaze sie ze haslo z wykopu pasuje do konta banku ktorego numer ktos se zapisal w kontaktach ;)

    Trzymajac hasla w plainie wykop pokazuje jak dba o bezpieczenstwo swoich uzytkownikow nie tyle w obrebie swojego serwisu co w ogole.

  20. uff. To mnie filezilla trzymająca hasła czystym tekstem na moim prywatnym komputerze, którego nikt oprócz mnie nie używa, jest dobrze przemyślana i bezpieczna. A ja psy wieszałem…

    Dobrze, że nie odinstalowałem, tylko od 5 lat jej używam, bo teraz byłoby mi głupio.

  21. a nie można by tego załatwić tak jak z cookiesami się robi, przydzielić klucz sesji na jakiś czas (nie związany z hasłem) i wymagać ponownej autoryzacji raz na dłuższy czas?
    i wtedy nie da się hasła uzyskać, ani go np. zmienić bo dobrze zaprojektowane serwisy przed operacjami pozwalającymi przejąć konto wymagają indywidualnej autoryzacji tej operacji.

    • Alez mozna. Trick jest jednak taki ze wszystkie aplikacje ktore uzywaja WykopApi *NIE* loguja sie haslem, a specjalnym tokenem (przydzielanym dla kazdego uzytkownika danej aplikacji). Wyjatkiem jest tu oczywiscie… “firmowa” aplikacja mobilna. Ktora robi to co robi (i nie tylko to :)

  22. Tak odnośnie Skypea, to jego protokół został złamany jakiś czas temu przez nieznaną mi osobę , była analiza całego protokołu w internecie.

  23. Co do udostępniania telefonu osobom postronnym, coś mnie ruszyło.
    Jest rok 2012, a na telefonach komórkowych działają systemy wieloużytkownikowe (Linux), dziedziczące z tradycji UNIX, a ten z Multics. Na Multiksowych mainframe’ach pracowały setki osób naraz, a system dbał o odpowiednią separację przywilejów. Każdy musiał się uwierzytelnić.
    Dlaczego u diabła na telefonach nie ma możliwości stworzenia wielu userów i logowania się na nich? Blokuję ekran, daję koledze urządzenie zalogowane na “guest”, z tymczasowym systemem plików trzymanym w RAM. Reszta systemów plików jest szyfrowana, a klucz odblokowania podawany przy logowaniu. Czemu nikt jeszcze o tym nie pomyślał?

    • bo to wprowadza niepotrzebne skomplikowanie i 3sigma populacji nie będzie tego używać a ja jak celowo zepsuje telefon koledze moge zarobić w ryj i tyle

  24. Jeśli chodzi o Androida, to można wykorzystać API AccountManager.

  25. skype trzyma się dzielnie bo dużo wysiłku włożyli by ludzie nie poznali że aplikacja ich szpieguje

Odpowiadasz na komentarz CapaciousCore

Kliknij tu, aby anulować

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: