Nieładne Jamendo?

Dawno nie logowałem się na swój profil na Jamendo, zapomniałem więc hasła. Ale jest opcja przypominania. Zajrzałem do skrzynki pocztowej, otworzyłem e-mail i zobaczyłem swoje zapomniane hasło. Oj nie ładnie Jamendo, przechowujemy w bazie hasła jawnym (zdolnym do odkodowania) tekstem? czy nie powinno się przechowywać skrótów, a w przypadku przypomnienia, wygenerować jakieś losowe?

19 thoughts on “Nieładne Jamendo?

  1. Wysyłanie oryginalnego hasła (zamiast losowego tymczasowego) mailem może głupie, ale trzymanie hasła plaintekstem w bazie nie jest takie złe.
    – po pierwsze umożliwia migrację do innych mechanizmów uwierzytelniania, opartych na skrótach (Digest-MD5 itp, jeśli masz ‘hash z solą’, do tego nie zrobiony dla tego konkretnego protokołu, to pozostaje autoryzacja plain tekst).
    – po drugie, żeby zdobyć hasło z bazy trzeba dostać się do systemu i uzyskać w nim odpowiednie uprawnienia. W takim przypadku atakujący już i tak ma możliwość odczytania wykorzystywanych haseł użytkownika (po odebraniu z sieci i ewentualnym rozszyfrowaniu w warstwie TLS) i dostęp do wszystkich danych zabezpieczonych tym hasłem
    – ‘hash z solą’, jeśli się go masowo wyciągnie z bazy danych, niespecjalnie zabezpieczy słabe hasła. A gdy ktoś używa mocnych haseł, to pewnie tego samego hasła nie używa w innym serwisie. Zdobycie hasła do skompromitowanego serwisu to żaden sukces (bez niego już się otrzymało dostęp)
    – szyfrowanie całego dysku z bazą danych skutecznie zabezpieczy hasła (niezależnie czy plain text, czy ‘hasz z solą’) w wypadku fizycznego dostępu do dysku. Samo ‘szyfrowanie’ haseł zmienia niewiele.
    – gdy decydujemy się na odzyskiwanie haseł przez maila (co zwykle warto robić, ze względu na usability), to otwieramy całą masę innych problemów i ryzyko z jawnych haseł w bazie staje się jeszcze bardziej pomijalne
    – w praktyce Ci co krzyczą o tym jakie złe jest trzymanie haseł jawnym tekstem w swoich ‘profesjonalnych’ aplikacjach PHP+MySQL używają tylko prostego skrótu MD5 i mają masę poważniejszych problemów z bezpieczeństwem. To oczywiście nie dotyczy Ciebie Zal, bo widzę, że o przyprawie pamiętasz. 😉

    Sam w wielu przypadkach świadomie stosowałem hasła jawnym tekstem w bazie danych. Raz nawet wiązało się to ze skomplikowaną procedurą migracji haseł wcześniej zapisanych w postaci skrótów z solą — w tym przypadku służyło to zwiększeniu bezpieczeństwa systemu.

    Bezpieczeństwo to nie miejsce na dogmaty. Tu przede wszystkim liczy się rozsądek, chłodna kalkulacja, a przede wszystkim zrozumienie ryzyka i kosztów w każdym analizowanym przypadku.

    Like

  2. @Jajcuś: Dzięki za tak wyczerpującą odpowiedź 😀 Nie ukrywam, że posiadam wiedzę akademicką na ten temat wraz z teorią dotyczącą poszczególnych form zabezpieczeń. Taka wiedza praktyczna to nie jest coś, z czym można się spotkać na każdym kroku.

    Like

  3. Ja również jestem pod wrażeniem wypowiedzi – dziękuję. Jeśli jednak mnie pamięć nie myli, np. Magento – to taki engine dla sklepów internetowych – przechowuje swoje hasła jako hasze. Nie znam powodów. Tak się właśnie zastanawiałem, czy faktycznie takie rozwiązanie powinno być stosowane (stąd pytajnik w nazwie).
    Jeśli system weryfikujący, do otrzymanego hasła np. dodaje nazwę użytkownika i dopiero wtedy haszuje, to wymaga to od napastnika który takim skrótem dysponuje, przemielenia sporej ilości haseł, zanim znajdzie coś, co połączone z znanymi danymi da mu ten skrót. Czy nie tak powinno być? Oczywiście można się kłócić, czy to w ogóle opłacalne – podobnie jak Zal, w tym temacie dysponuje nieco nie wystarczającą wiedzą, choć mnie on trochę interesuje.

    Like

  4. Ostatnio musiałem się dogrzebać do konta, które kiedyś zakładałem na “portalu” IDG (tak, napisałem “portalu” w cudzysłowie, bo ten moloszek przyprawia mnie o niestrawność za każdym razem, kiedy tam trafiam). Niby serwis taki “pro-IT”, a przypomnienie hasła dostałem zwyczajnie mailem.

    W sumie i tak, jak ktoś się uprze, to z tablicami tęczowymi odpowiednich rozmiarów rozgryzie hashe (gorzej z “doprawionymi”). Ale to są wszystko rozważania teoretyczne, rzadko się zdarza, żeby z poważnego serwisu wyciekła baza hasłami/hashami. Hashowanie haseł zwiększa tylko bezpieczeństwo, chociaż nie daje 100% pewności bezpieczeństwa. Jest po prostu w “dobrym tonie” 😉

    Tak jak w tym starym dowcipie o matematyku lecącym samolotem: jeśli prawdopodobieństwo, że jeden pasażer wniósł na pokład bombę wynosi 0,0001, a prawdopodobieństwo że dwóch pasażerów ma swoje bomby wynosi 0,0000001, to co robi matematyk? Zwiększa bezpieczeństwo współpasażerów zabierając własną bombę.

    Ale co ja tam wiem… Tak czy siak na własne potrzeby używam w większości przypadków “czystego” sha-1 😉

    Like

  5. Swoją drogą, kiedyś zastanawiałem się nad sensem używania kombinacji w stylu sha1(identyfikator_użytkownika.sha1(hasło)) – czy zwiększa to bezpieczeństwo haseł użytkowników w przypadku wycieku? Można by polemizować, ale jeśli już zależy nam na bezpieczeństwie absolutnym, to standardowe rozwiązania pozostają w cieniu teoretycznej mocy “chmur obliczeniowych” 😉

    Like

  6. Jajcuś: Migrację można łatwo przeprowadzić stosując „okres przejściowy” – po zalogowaniu prosimy użytkowników o zmianę hasła i zapisujemy w nowy (np. bezpieczniejszy) sposób. Nie potrzeba ku temu pamiętać ich haseł.

    Oczywiście, są gorsze błędy niż trzymanie hasła w plaintekście. Co nie zmienia faktu, że moim zdaniem nadal jest to błędem. Nie potrafię sobie wyobrazić sytuacji gdzie mogłoby to zwiększyć bezpieczeństwo.

    „Sam w wielu przypadkach świadomie stosowałem hasła jawnym tekstem w bazie danych. Raz nawet wiązało się to ze skomplikowaną procedurą migracji haseł wcześniej zapisanych w postaci skrótów z solą — w tym przypadku służyło to zwiększeniu bezpieczeństwa systemu.”

    Mógłbyś napisać coś więcej o tym przypadku? Jak jawne hasła zwiększyły Ci bezpieczeństwo?

    Like

  7. Tak swoją drogą, jak często dokonuje się migracji? I czy nie wystarczyło by skopiować wszystkie ustawienia? A tak w ogóle, nie zauważyłem wcześniej, słabe, czy mocne hasło, hash jest ten sam.

    Like

  8. sharnik: Parę lat temu. Lokalny ISP, obsługujący kilka tysięcy użytkowników „sieci osiedlowych”. Użytkownicy mieli na naszym serwerze też konta mailowe. Oczywiście trzeba było zapewnić uwierzytelnianie. Większość klientów wtedy bezproblemowo radziło sobie tylko z uwierzytelnianiem plain text i to było najpierw zaimplementowane. Wtedy hasła były haszowane. Jednak trzeba było to zabezpieczyć… już nie tylko o to chodzi, że hasła latające po sieci plain tekstem są złe, bo są złe, ale po prostu już zdarzały się przypadki, że sąsiad sąsiadowi hasło podejrzał (jeden LAN… na początku to jeszcze switche były luksusem… a jak już były, to też można je było łatwo oszukać).
    Wymuszenie SSL, czy jakiegoś innego ‘bezpiecznego logowania’ odpadało. Nie było takiej konfiguracji, która zadziałałaby w każdym używanym kliencie, a poza tym w większości wypadków wymagałoby to specjalnej konfiguracji po stronie klienta. W prawdziwym świecie „zwykłych użytkowników” czegoś takiego po prostu nie można przeprowadzić. „Zepsuliście mi pocztę, to mi naprawcie! Ja u siebie nic nie będę zmieniał!” to podejście niespodziewanie wielkiej ilości użytkowników. Tłumaczenie im kwestii bezpieczeństwa jest na nic.
    Z drugiej strony, jednak wypadałoby umożliwić bezpieczne logowanie. W nielicznych klientach poczty mogłoby to nawet zadziałać automatycznie, jeśli serwer przedstawi taką możliwość. No i łatwiej to było osiągnąć za pomocą APOP i/lub DIGEST-MD5 niż StartTLS. Do APOP/DIGEST-MD5 nie można wykorzystać standardowych haseł ‘solonych’. Najprościej i skutecznie było więc przejść na hasła plain tekst w bazie. Wtedy przynajmniej użytkownicy którym zależy, albo którzy mieli sensowne oprogramowanie działało bezpieczne logowanie.
    Zgadzam się, że takiej konfiguracji daleko do ideałów bezpieczeństwa, ale „sieć osiedlowa” to nie korporacja, więcej się z userów nie wyciśnie.

    No i jeszcze jedna sprawa: Co właściwie w sieci mamy zabezpieczać? Dane użytkowników? Dostępność ich usługi? Czy treść ich haseł? Ja uważam, że pierwsze dwa, hasło to tylko narzędzie które to ułatwia. Jeśli ktoś uzyska dostęp do bazy danych haseł, to zwykle już i tak ma dostęp do danych użytkownika i może kontrolować ich usługę. To po co wtedy zabezpieczać hasło? BTW. we wspomnianym przeze mnie systemie hasła były plain-tekstem, ale dane osobowe (które z pewnych powodów były potrzebne w tym miejscu) już nie – te dane były zaszyfrowane kluczem, który nawet nie był dostępny na serwerze.

    Like

  9. Tak, się jeszcze zastanawiam, czy hashowanie haseł, nie powinno być też robione, ‘z grzeczności’, na tej zasadzie, co nie patrzenie na klawiaturę jak ktoś wpisuje hasło. I jest jeszcze jeden problem: backupy bazy, jak ktoś się dorwie do takiego, to ma listę haseł jawnym tekstem.

    Like

  10. Sigvatr: Bezpieczeństwa nie robi się „z grzeczności”. A backupy to zawsze jest coś co trzeba specjalnie chronić (szyfrować, zamykać w sejfie itp. oczywiście stosownie do sytuacji)… zadziwiająco wiele administratorów o tym zapomina.
    Pamiętaj, że wyciek ‘zaszyfrowanych’ haseł jest też problemem. Inaczej po co by kiedyś wprowadzili /etc/shadow?

    Like

  11. Nie zrozumiałeś. Dzięki temu nawet sam administrator nie może znać Twojego hasła. Wiem, że ma koleś uprawnienia i w ogóle. Po jakimś czasie może znajdzie ciąg znaków, który z solą, daje ten specyficzny hash właśnie, ale wciąż jest szansa, że to nie jest właściwie hasło, które jego właściciel stosuje np. na innych witrynach.
    Samo hasło też może trochę powiedzieć o człowieku, sugerować jaką ma koleś politykę bezpieczeństwa. Np. login_numerek, albo jak widać, że leci hasłami słownikowymi, ale np. z niemieckiego, bo chce być oryginalny.

    Like

  12. Ale ja jestem odpowiedzialny za system, którym zarządzam. Nie za „politykę haseł” użytkownika, czy jego hasła do obcych serwisów. Generalnie wolę sam użytkownikom wygenerować bezpieczne, losowe hasła, ale możliwość zmiany pozostawiam. Jak ktoś chce sobie strzelić w stopę ustawiając to samo hasło, co ma do banku, to może.
    Administrator hasło użytkownika i tak może zdobyć, szczególnie jeśli użyta metoda uwierzytelniania wykorzystuje hasła plain-tekst, a tak jest w większości przypadków (TLS/SSL dla administratora nic nie zmienia). Nie ma sensu udawać, że hasła nie są dostępne dla tych, co mają pełen dostęp do systemu. Lepiej „po prostu” dobrze zabezpieczyć system przed niepowołanym dostępem.

    Like

  13. W sumie masz rację, ale tak przypominając sobie wspomniane Magento, nie jest trudno go postawić, można też zamówić taką instalację, administracja tym jest względnie prosta, więc adminiem może być ktoś, powiedzmy średnio rozgarnięty – przesyłanego hasła nie podejrzy, a w bazie ma zahaszowane, czy to jest przykład systemu, gdzie warto stosować skróty? Być może tutaj to zabezpieczenie dla backupów. Zastanawia mnie, czemu tak wiele serwisów, jednak haszuje hasła.

    Like

  14. Jajcuś, dzięki za rozbudowany opis.

    „Generalnie wolę sam użytkownikom wygenerować bezpieczne, losowe hasła, ale możliwość zmiany pozostawiam.”

    Takie rozwiązanie chyba jest najlepsze, jak musisz mieć odczytywalne hasła.

    Sigvatr: „Zastanawia mnie, czemu tak wiele serwisów, jednak haszuje hasła.”

    Bo zwykle to nic nie kosztuje, a zwiększa bezpieczeństwo użytkownika. To jest taka defaultowa procedura bezpieczeństwa. Jeżeli nie zamierzasz haszować haseł, to powinieneś się zastanawiać – dlaczego?

    Like

  15. Czemu wiele serwisów szyfruje hasła?
    1. Jest dużo krzykaczy, którzy o to wołają. Jestem zapisanych na wiele list związanych z wieloma różnymi projektami, dość poważnymi zwykle. I wiele razy widziałem jak ktoś nowy się na liście pojawiał i wołał o szyfrowanie haseł, albo krytykował kogoś, kto wspomniał, że w swoim systemie ma nieszyfrowane. Wielki oczywiście flame-war powstawał… i jak była taka możliwość, to dla świętego spokoju ‘szyfrowanie’ było implementowane (jeśli nie było to zrobione wcześniej).
    2. W wielu wypadkach (pojedyncza aplikacja, szczególnie taka używająca mechanizmów plain tekst do uwierzytelniania) używając skrótów haseł nic się nie traci to i nie szkodzi zastosować.
    3. Właśnie gdy się robi aplikację dla laików. Taką co sobie ktoś skopiuje na swój hosting, uruchomi i nawet nie będzie wiedział jak działa. W takim wypadku zwykle nawet dostęp do bazy haseł nie jest specjalnie ograniczony i lepiej to wygląda, jak script-kiddie dostanie skróty zamiast samych haseł. Poza tym, patrz punkt 1. laicy lubią krzyczeć, gdy gdzieś ‘niezaszyfrowane’ hasło zobaczą… Krzyczą też, gdy zapomną i nie wiedzą jak ‘odszyfrować’ 😉

    Moim zdaniem optymalnie jest implementować w aplikacji obie opcje i pozostawić wybór temu, kto ma to wdrażać. I tak zwykle jest robione w „poważnych” aplikacjach, które mogą działać w skomplikowanych systemach…

    No właśnie wcześniej nie wspomniałem jeszcze o jednym powodzie trzymania plaintekstowych haseł: integracja systemów i aplikacji. Bazę haseł zapisanych czystym tekstem może wykorzystać sporo różnych aplikacji, z różnych źródeł. Jeśli chodzi o skróty haseł, różne aplikacje mogą mieć różne wymagania i po prostu nie będą w stanie korzystać z jednej bazy.

    Like

Comments are closed.