W dniu poniedziałek, 21 stycznia 2013 10:21:35 UTC+1 użytkownik yamma napisał:
> No i jeszcze pasowałoby przedtem posolić, żeby z takich samych haseł nie
> wyszły identyczne "hasze". Ja zazwyczaj solę GUIDem, który jest
> identyfikatorem rekordu ale np. Microsoft w ASP.NETowym Membershipie tworzy
> dodatkowe pole z losowo wygenerowanym ciągiem znaków.

Określenia "posolić" używa się normalnie, czy tak sobie napisałeś?
Ja dodaje losowe znaki w kilku miejscach oryginalnego ciągu, potem
jakiś standardowy klucz sha, albo md5, albo nawet jakiś własny. Gdzieś
czytałem że md5 został rozpracowany - nie wiem znaczy słowo "rozpracowany",
ale tak czy inaczej do hashowania w poważnej kryptografii lepiej nie używać.

Pozdrawiam

do góry

On 2013-01-22, M.M. <m...@g...com> wrote:
> W dniu poniedziałek, 21 stycznia 2013 10:21:35 UTC+1 użytkownik yamma napisał:
>> No i jeszcze pasowałoby przedtem posolić, żeby z takich samych haseł nie
>> wyszły identyczne "hasze". Ja zazwyczaj solę GUIDem, który jest
>> identyfikatorem rekordu ale np. Microsoft w ASP.NETowym Membershipie tworzy
>> dodatkowe pole z losowo wygenerowanym ciągiem znaków.
>
> Określenia "posolić" używa się normalnie, czy tak sobie napisałeś?

Tego określenia się używa. I prawidłowo to się używa dedykowanej
biblioteki do haszowania haseł, a nie paprze ręcznie.

> Ja dodaje losowe znaki w kilku miejscach oryginalnego ciągu, potem
> jakiś standardowy klucz sha, albo md5, albo nawet jakiś własny.

Kolejny "insztalator" próbujący uprawiać własną kryptografię. Jaką niby
wartość kryptograficzną to co robisz ma dodawać?

> Gdzieś
> czytałem że md5 został rozpracowany - nie wiem znaczy słowo "rozpracowany",
> ale tak czy inaczej do hashowania w poważnej kryptografii lepiej nie używać.

Mój drogi, ty poważnej kryptografii nie widziałeś na oczy, więc się nie
wypowiadaj. Tobie używać gotowych bibliotek do wysokopoziomowych
zastosowań, a nie oceniać funkcje skrótu.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu wtorek, 22 stycznia 2013 08:13:50 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
> Moj drogi, ty powaznej kryptografii nie widziales˝ na oczy, wiec sie nie
> wypowiadaj. Tobie uzywac gotowych bibliotek do wysokopoziomowych
> zastosowan, a nie oceniac funkcje skrotu.
Czyli uwazasz funkcje skrotu MD5 za bezpieczna do zastosowan
kryptograficznych? Skoro ja bez widzenia na oczy powaznej kryptografii wiem
ze nie jest bezpieczna, to co Ty widziales? Chyba nic?
Pozdrawiam

do góry

On 2013-01-22, M.M. <m...@g...com> wrote:
> W dniu wtorek, 22 stycznia 2013 08:13:50 UTC+1 użytkownik Stachu 'Dozzie' K.
napisał:
>> Moj drogi, ty powaznej kryptografii nie widziales˝ na oczy, wiec sie nie
>> wypowiadaj. Tobie uzywac gotowych bibliotek do wysokopoziomowych
>> zastosowan, a nie oceniac funkcje skrotu.
> Czyli uwazasz funkcje skrotu MD5 za bezpieczna do zastosowan
> kryptograficznych?

*Niektórych*. Tylko trzeba wiedzieć które to. Po twoim poprzednim poście
wnioskuję, że nawet nie wiesz, o co chodziło w atakach na MD5 i rodzinę
SHA, ani tym bardziej jakie to ma konsekwencje.

Nie jest to oczywiście złe. Od tego są mądre głowy, które ogłaszają
standardy i protokoły kryptograficzne, żeby szeregowy programista nie
musiał być jednocześnie kryptologiem. Tylko że ty próbujesz jeszcze
wysuwać jakieś twierdzenia o funkcjach skrótu dla haseł, mimo braku
najmniejszego przygotowania do tego.

> Skoro ja bez widzenia na oczy powaznej kryptografii wiem
> ze nie jest bezpieczna, to co Ty widziales? Chyba nic?

Pewnie że nic. Szkolony z tego byłem przez pół okresu studiów (w moim
pierwszym podejściu) przez ludzi pracujących w tym obszarze. Pewnie że
nic nie widziałem.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu wtorek, 22 stycznia 2013 09:41:50 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
> > W dniu wtorek, 22 stycznia 2013 08:13:50 UTC+1 użytkownik Stachu 'Dozzie' K.
napisał:
> >> Moj drogi, ty powaznej kryptografii nie widziales˝ na oczy, wiec sie nie
> >> wypowiadaj. Tobie uzywac gotowych bibliotek do wysokopoziomowych
> >> zastosowan, a nie oceniac funkcje skrotu.
> > Czyli uwazasz funkcje skrotu MD5 za bezpieczna do zastosowan
> > kryptograficznych?
>
>
>
> *Niektórych*. Tylko trzeba wiedzieć które to. Po twoim poprzednim poście
> wnioskuję, że nawet nie wiesz, o co chodziło w atakach na MD5 i rodzinę
> SHA, ani tym bardziej jakie to ma konsekwencje.
I dobrze wnioskujesz. Szczegolowo nie wiem, dlatego uzylem okreslenia
"rozpracowano" i to w cudzyslowie. Kiedys czyalem historie atakow
na MD5, z tego co pamietam, zaczelo sie na testach kolizji, a skonczylo
na (prawie)analitycznym wzorze. Jesli mozna w krotkim czasie obliczyc
ciag ktory generuje taka sama wartosc funkcji skrotu, to MD5
moze miec zastosowania jedynie w jakis testach poprawnosci transmisji, w
testach uszkodzen danych na nosnikach - wszedzie tam, gdzie nie
podejrzewamy celwego zlosliwego dzialania osob trzecich.


> Nie jest to oczywiście złe. Od tego są mądre głowy, które ogłaszają
> standardy i protokoły kryptograficzne, żeby szeregowy programista nie
> musiał być jednocześnie kryptologiem.
Mnie sie zdarzylo tak, ze bylo potrzebne rozwiazanie troche lepsze niz
standardowe, a na "madra glowe" trzeba byloby wydac 5 razy wiecej niz
budzet calego projektu. Wymyslilem wiec sam w moze dwa dni. I wiem, ze
nawet jak ktos ukradnie hasla i nawet brutforcem sprawdzi wszystkie
ciagi, to sie do systemu nie wlamie. Musialby zrobic jeszcze cos.


> Tylko że ty próbujesz jeszcze wysuwać jakieś twierdzenia o funkcjach
> skrótu dla haseł, mimo braku najmniejszego przygotowania do tego.
Jedyne czego probowalem, to sprowokowac ludzi do dalszej rozmowy.


> > Skoro ja bez widzenia na oczy powaznej kryptografii wiem
> > ze nie jest bezpieczna, to co Ty widziales? Chyba nic?

> Pewnie że nic. Szkolony z tego byłem przez pół okresu studiów (w moim
> pierwszym podejściu) przez ludzi pracujących w tym obszarze. Pewnie że
> nic nie widziałem.
Najechales na mnie po tym, jak wypowiedzialem sie ze MD5 nie jest
dobra funkcja skrotu do zastosowan kryptograficznych. Mozna to
odebrac tak, jakbys uwazal ja za dobra. Jesli chcesz sie pochwalic
swoja wiedza na ten temat, to mozna to zrobic, bez uciekania sie do
dziwnych metod. Z tego co piszesz o swojej wiedzy, kazdy na pewno
przeczyta z zaciekawieniem.

Pozdrawiam

do góry

On 2013-01-22, M.M. <m...@g...com> wrote:
>> Nie jest to oczywiście złe. Od tego są mądre głowy, które ogłaszają
>> standardy i protokoły kryptograficzne, żeby szeregowy programista nie
>> musiał być jednocześnie kryptologiem.
> Mnie sie zdarzylo tak, ze bylo potrzebne rozwiazanie troche lepsze niz
> standardowe, a na "madra glowe" trzeba byloby wydac 5 razy wiecej niz
> budzet calego projektu. Wymyslilem wiec sam w moze dwa dni. I wiem, ze
> nawet jak ktos ukradnie hasla i nawet brutforcem sprawdzi wszystkie
> ciagi, to sie do systemu nie wlamie. Musialby zrobic jeszcze cos.

Mój drogi, każdy głupi jest tak mądry, żeby opracować kryptosystem,
którego sam nie umie złamać. Tylko że to za mało dla obrony przed
prawdziwym adwersarzem. Nie wiem co chciałeś pokazać w tym akapicie.

>> Tylko że ty próbujesz jeszcze wysuwać jakieś twierdzenia o funkcjach
>> skrótu dla haseł, mimo braku najmniejszego przygotowania do tego.
> Jedyne czego probowalem, to sprowokowac ludzi do dalszej rozmowy.

Wysuwając jakieś twierdzenia o funkcjach skrótu, mimo braku
przygotowania do tego.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu wtorek, 22 stycznia 2013 10:07:46 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
> Mój drogi, każdy głupi jest tak mądry, żeby opracować kryptosystem,
> którego sam nie umie złamać. Tylko że to za mało dla obrony przed
> prawdziwym adwersarzem. Nie wiem co chciałeś pokazać w tym akapicie.
Jest odporny na wszystkie ataki jakich zazyczyl sobie klient, jestem
odpowiedzialny za to i nie mam z tego tytulu problemow.


> >> Tylko że ty próbujesz jeszcze wysuwać jakieś twierdzenia o funkcjach
> >> skrótu dla haseł, mimo braku najmniejszego przygotowania do tego.
> > Jedyne czego probowalem, to sprowokowac ludzi do dalszej rozmowy.
>
> Wysuwając jakieś twierdzenia o funkcjach skrótu, mimo braku
> przygotowania do tego.

Wystarczy ze Ty masz takie przygotowanie.
Pozdrawiam

do góry

On 2013-01-22, M.M. <m...@g...com> wrote:
> W dniu wtorek, 22 stycznia 2013 10:07:46 UTC+1 użytkownik Stachu 'Dozzie' K.
napisał:
>> Mój drogi, każdy głupi jest tak mądry, żeby opracować kryptosystem,
>> którego sam nie umie złamać. Tylko że to za mało dla obrony przed
>> prawdziwym adwersarzem. Nie wiem co chciałeś pokazać w tym akapicie.
> Jest odporny na wszystkie ataki jakich zazyczyl sobie klient, jestem
> odpowiedzialny za to i nie mam z tego tytulu problemow.

"Jest odporny". Kto to oceniał? Ty? Klient? Mądra głowa, kosztująca
pięciokrotność budżetu? Społeczność kryptologów na podstawie publikacji
naukowej?

Nadal nie widać dowodu czy uzasadnienia, że kryptosystem (to był
w ogóle kryptosystem? bo IMO nie było to jasno powiedziane) został
przygotowany prawidłowo.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu poniedziałek, 21 stycznia 2013 23:53:49 UTC+1 użytkownik Stachu 'Dozzie' K.
napisał:

> >> A po co?

> > Poza tym - dziwne pytania zadajesz.

Nie. To mnie nurtuje, bo zwykle widzę uzasadnienia, które mnie nie przekonują.

Bogusław podał scenariusz, gdzie admini/programiści naśmiewają się z haseł i to jest
powód, żeby te hasła kodować. OK, nie przyszło mi to do głowy. Myślałem, że celem ma
być ochrona przed stronami trzecimi - ale jeśli celem ma być ochrona użytkownika
przed moim własnym zespołem, to faktycznie można małym kosztem ten drobiazg załatwić.
Piszę "drobiazg", bo hasła to nie jest żaden temat do naśmiewania się - w każdym
systemie, który do czekogolwiek służy, w bazie są znacznie ciekawsze i znacznie
bardziej wrażliwe treści. Pomyśl o portalu randkowym, szpitalu, banku, itd. Naprawdę
sądzisz, że nieuczciwy admin/programista czerpałby radość z naśmiewania się z haseł w
bazie, skoro już ma dostęp do całej bazy?

Ale OK. Jest to drobiazg, ale skoro koszt jest żaden, to kupuję takie wyjaśnienie.

> Jak rozumiem, Maciek nie ma zbyt dokładnego przygotowania
> z bezpieczeństwa IT, a chciał poznać parę rzeczowych argumentów.

Dokładnie tak. Przygotowania nie mam, ale słabe argumenty, które zwykle widuję w tej
okolicy, wykrywam.
Dlatego temat uważam za otrwarty - jeżeli jest jakiś powód, żeby kodować hasła w
bazie, oprócz pozbawienia programistów frajdy z ich wyśmiewania, to nadal chętnie ten
powód poznam.

> > Skoro ludzie opracowują algorytmy
> > challenge-respone po to, żeby *systemy* *między* *sobą* nie wymieniały się
> > jawnymi hasłami,

Ja rozumiem, że wartość tych systemów nie polega na tym, że hasła nie latają na
golasa, tylko na tym, że za każdym razem lata co innego. To jest rozwiązanie zupełnie
innego problemu, którego hashowanie haseł w ogóle nie podejmuje.

> Maciek oczekiwał konkretnego powodu.

I dostałem. Ale jeśli są inne powody, to dalej oczekuję.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

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.

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?

Powiedzmy, że robię serwis. Chciałbym napisać użytkownikom, że dbam o bezpieczeństwo
*całej* bazy i wszystkich informacji, które tam wprowadzą, a nie tylko o same hasła.
Intuicja podpowiada mi, że w kontekście bezpieczeństwa informacji szczególne
traktowanie jednego tylko elementu, np. hashowanie haseł, jest albo a)
niewystarczające albo b) niepotrzebne.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry