On 22.01.2013 10:55, Maciej Sobczak wrote:
> W dniu poniedziałek, 21 stycznia 2013 23:46:29 UTC+1 użytkownik Stachu 'Dozzie' K.
napisał:
>
>> Ano po to, Maćku, żeby utrata bazy haseł użytkowników z jednej
>> aplikacji czy serwisie nie prowadziła (zbyt łatwo) do kompromitacji kont
>> tych samych ludzi w innych serwisach.
>
> Rozumiem.
>
> Co prawda założenie, że baza haseł zostanie utracona, powoduje u
> mnie
> dyskomfort. Mówimy o systemie, który my sami tworzymy (bo tylko wtedy
> mamy wybór, jak przechować hasła) a skoro my sami go tworzymy, to jak
> możemy zakładać, że utracimy bazę? Rozumiem, że jest to część
> zarządzania ryzykiem i minimalizujemy straty w przypadku katastrofy,
> przed którą nie zapewniliśmy 100% ochrony.

Jeżeli masz serwis w sieci to niestety musisz założyć, że prędzej czy
później możesz wpaść na 0day w jakimś frameworku. Wtedy warto
minimalizować zniszczenia.

>
> Natomiast nadal pozostaje pytanie o pozostałą zawartość bazy. Czy
> jeżeli rozwiążemy *jakoś* (temat otwarty) problem tej pozostałej części,
> to czy nadal jest sens przejmować się hasłami, skoro rozwiązanie dla
> całej bazy może objąć również hasła?

Jedno z rozwiązań na klientów typu "dlaczego mamy wam zaufać w
bezpieczeństwie danych?" (w lekkim uproszczeniu):
- klucz generowany z hasła usera
- dane w bazie szyfrowane kluczem
- hasło przesyłane clear-textem po SSLu, generowany klucz, jak się nim
zdeszyfruje "access granted" to znaczy, że jest prawidłowe ;)

Zostaje jedna kwestia - klient musi podpisać, że "W przypadku zagubienia
hasła nie istnieje możliwość odzyskania danych. Zabezpieczenie to
zostaje włączone na życzenie Klienta i Klient w pełni zdaje sobie sprawę
z konsekwencji zagubienia hasła."

"... Ale serio - to jest maksymalnie bezpieczne więc jak zgubicie hasło
to jesteście udupieni i my nic nie damy rady zrobić... Poważnie...Przy
długim haśle kilkadziesiąt tysięcy i nawet kilka miesięcy..." Nagle
bezpieczeństwo przestaje być tak "kluczową" kwestią ;)

--
Pozdrawiam
Michoo