W dniu 2020-06-09 o 16:49, Krzysztof Halasa pisze:
>> Jeśli to jest po prostu wydłużanie hasła to według autorów tej książki
>> nie ma żadnego usprawiedliwienia dla nie stosowania tego wszędzie.
>
> I tam naprawdę coś takiego napisali? Przyznaję, że nie czytałem tej
> książki (ani pewnie nawet nie miałem jej w ręku), ale to brzmi
> przynajmniej kontrowersyjnie.
>
> Może napisali to tylko w tym konkretnym kontekście (np. szyfrowania
> dysków lokalnych)? Wtedy mogę się z tym zgodzić.

Poszukałem. Szkoda, że nie mam książki w pdf - byłoby łatwiej.
Napisali to w pobliżu dysku ale nie w kontekście.
Rozdział 22 - Przechowywanie tajemnic
22.1 Dysk - że można na dysku, ale trzeba jakoś zaszyfrować
22.2 Pamięć ludzka - dywagacje, co człowiekowi łatwo zapamiętać, a co nie.
22.2.1 Solenie i rozciąganie
Możliwe, że oni nie użyli określenia wydłużanie hasła, a tylko ja tak to
zapamiętałem (bo używają pojęcia długość).
Rozdział ten zaczyna się tak:
"Chcąc w haśle lub frazie kluczowej o ograniczonej entropii zawrzeć jak
najwięcej bezpieczeństwa, możemy użyć dwóch technik, których nazwy
kojarzą się ze średniowieczną izbą tortur. Techniki te są tak proste i
naturalne, że powinny być stosowane we wszystkich systemach haseł.
Ignorowanie ich nie ma żadnego wytłumaczenia."

> Albo tylko tak teoretycznie, co by było gdyby user koniecznie chciał
> stosować to samo hasło wszędzie i jak to zrobić?

To, że zastosowanie solenia i wydłużania (rozciągania) pozwalało by
stosować to samo hasło wszędzie to wyłącznie moja hipoteza. W książce
nie ma według mnie nic na ten temat. Nigdzie nie napisałem, że oni
sugerują taką możliwość. Jeśli coś tak zrozumiałeś to musiałem się
nieprecyzyjnie wypowiedzieć.

> Normalnie jednak
> korzyści wynikające z zastosowania tego lub podobnego algorytmu byłyby
> niewspółmiernie niskie w porównaniu do zagrożeń, jakie niesie ze sobą
> jedno hasło.

Oczywiście, ale praktyka jest o ile wiem taka, że ludzie do wszystkich
mało istotnych miejsc często stosują jakieś swoje jedno hasło, już
pomijając kwestię stosowania hasła '1234'.

>> Sprawdzenie pojedynczej hipotezy dotyczącej hasła (nie przeliczonego)
>> to jedna operacja. Sprawdzenie tego samego hasła ale przeliczonego
>> milion razy to milion operacji przeliczania + jedna operacja
>> porównania.
>
> Zakładam, że seed jest odpowiednio silny, bo jeśli nie, to tęczowe
> tablice mogą nam ten problem sprowadzić do prostego lookupu.
> Ale nawet z dobrym seedem, wszystko zależy od siły oryginalnego hasła.

To, że hasło powinno być silne nie ulega wątpliwości, ale tak ogólnie to
nie wiem o czym mówisz i nie mam czasu szukać.

>> Przeliczenie milion razy SHA256 na moim 10 letnim komputerze zajmowało
>> poniżej 1s. Milion to około 2^20. Po takim zabiegu atakujący to samo
>> hasło musi wykonać 2^60 operacji. Czyli długość hasła (przy przyjętej
>> definicji długości) zwiększyliśmy o 20 bitów.
>
> Ale atakujący może sobie postawić (dość tanim kosztem - są zdjęcia
> w sieci) 200 konsoli. Są też inne możliwości, moc obliczeniowa nie jest
> droga. Zauważ, że postęp techniczny powoduje, że jeśli nie uda się tego
> złamać dziś, to może uda się jutro.

Jeśli jutro do złamania nie wydłużanego hasła w rozsądnym czasie
wystarczy mu jeden komputer to do złamania w tym samym czasie hasła,
które zostało wydłużone będzie potrzebował miliona komputerów.
Tylko tyle i aż tyle.
A takie utrudnienia kosztuje nas sekundę przy każdym sprawdzaniu hasła.
To nie wygórowana cena.

>> Ja za autorami tej książki przyjąłem, że nie ma żadnego
>> usprawiedliwienia dla nie stosowania solenia i wydłużania we
>> wszystkich aplikacjach. A że czytałem to w 2004r, gdy pewnie nie
>> zrobiłem jeszcze żadnego zakupu przez internet więc jak zetknąłem się
>> pierwszy raz z tworzeniem sobie konta to byłem pewien, że tak to jest
>> wszędzie. Po prostu nie wyobraziłem sobie, że ktoś mógł nie zastosować
>> czegoś, co jest proste i nie ma usprawiedliwienia na nie stosowanie
>> tego.
>
> Nie wystarczy brak wad :-)
> Przede wszystkim, by zastosować jakieś rozwiązanie, musi być ku temu
> jakiś racjonalny powód. Często jest - i tam się takie rzeczy stosuje.
> Natomiast w przypadku serwerów w Internecie - co jest, Twoim zdaniem,
> takim racjonalnym powodem?

Jeśli jest jakiś powód stosowania haseł to jest też naturalne aby
złamanie było możliwie utrudnione. Konieczność przeliczenia milion razy
każdego hipotetycznego hasła przed wysłaniem aby sprawdzić czy zadziała
jest na pewno dodatkowym utrudnieniem przy znikomym koszcie tego
rozwiązania. Oczywiście jeśli serwer może w inny sposób ograniczyć pasmo
ataku czyniąc go beznadziejnym to wydłużanie (rozciąganie) wydaje się
zbędne. Ale jest też taka ogólna zasada, aby utrudnić wszędzie gdzie się
da, bo np. w nieprzewidziany dla nas sposób atakujący wejdzie w
posiadanie bazy z hashami haseł. Nie powinno mu to pozwolić znaleźć
haseł choćby dlatego, że hasła mogą pozwolić na wyciągnięcie wniosków co
do sposobu tworzenia haseł przez userów, co może być wykorzystane do
zaatakowania innego, ważniejszego systemu.

> Nie żeby "wydłużanie hasła" nie miało wad. Co powiesz o takiej
> psychologicznej - "skoro hasło jest wydłużane, to oryginalnie wystarczy
> byle co"?

Użytkownik nie musi wiedzieć, że jest wydłużane.
A jeśli przekazuje mu się tę wiedzę, to powinien usłyszeć, coś w stylu,
że obecnie hasła o długości krótszej niż 80 bitów są uznawane za zbyt
słabe. System przedłuża hasła o 20 bitów więc stosuj hasła o długości co
najmniej 60 bitów (czyli 12 znaków) a najlepiej dłuższe.
P.G.

do góry

Piotr Gałka <p...@c...pl> writes:

> Jeśli jutro do złamania nie wydłużanego hasła w rozsądnym czasie
> wystarczy mu jeden komputer to do złamania w tym samym czasie hasła,
> które zostało wydłużone będzie potrzebował miliona komputerów.
> Tylko tyle i aż tyle.

Ale dlaczego w tym samym czasie. To może być znacznie dłużej.
Np. niejaki John łamie proste hasła na moim starym firmowym komputerze
(czasem zdarza mi się analizować takie rzeczy) w ciągu sekund. Nie widzę
jednak żadnego problemu, by zostawić go z tym na nockę, albo i na
miesiąc.

Poza tym, są komputery i komputery. "Zwykły" komputer może być 10x
droższy i 100 razy wolniejszy w tym kontekście (ten mój powyższy też
jest "zwykły", nawet bardzo zwykły) :-)
Możliwe że zrobienie tego na dużych FPGAch byłoby jeszcze bardziej
efektywne niż układy graficzne. Tego typu algorytmy oprócz czasu
procesorów mogą używać dużych ilości pamięci. Obawiam się, że właściciel
serwera także może nie chcieć inwestować w RAM tylko z tego powodu.

> A takie utrudnienia kosztuje nas sekundę przy każdym sprawdzaniu hasła.
> To nie wygórowana cena.

Jeśli robimy to raz dziennie. Bo jeśli co sekundę, to owszem - jest
wygórowana.
Poza tym, jest też problem motywacji. Jaką motywację miałby mieć
właściciel serwera? To nie są jego hasła. On oczywiście nie chce, by
ktoś niepowołany dostał dostęp do takich danych, ale jeśli już dostanie,
to czy łamanie będzie trwało 2 sekundy, czy 200 lat, to już nie jego
zmartwienie.

> Jeśli jest jakiś powód stosowania haseł to jest też naturalne aby
> złamanie było możliwie utrudnione.

Nie widzę takiej implikacji. Czym innym byłoby podsłuchanie - wtedy
zgoda, ale złamanie czegoś, do czego tak czy owak nie ma dostępu?

> Ale jest też taka ogólna zasada, aby
> utrudnić wszędzie gdzie się da, bo np. w nieprzewidziany dla nas
> sposób atakujący wejdzie w posiadanie bazy z hashami haseł.

Nie, nie ma takiej zasady. Są zasady w efekcie dokładnie przeciwne.
W szczególności taka mówiąca o kosztach zabezpieczenia oraz ataku,
i jak się one mają do wartości danych / szkód.

> Nie
> powinno mu to pozwolić znaleźć haseł choćby dlatego, że hasła mogą
> pozwolić na wyciągnięcie wniosków co do sposobu tworzenia haseł przez
> userów, co może być wykorzystane do zaatakowania innego, ważniejszego
> systemu.

Przecież wszyscy doskonale znają sposoby tworzenia haseł przez userów.
Nawet napisałem o niektórych mechanizmach. W sieci są też statystyki
haseł.

> Użytkownik nie musi wiedzieć, że jest wydłużane.

No ale tego można się łatwo dowiedzieć. Standardowe systemy itd.
Poza tym, gdyby _wszyscy_ mieli to stosować, to wiadomo że to byliby
wszyscy.

> A jeśli przekazuje mu się tę wiedzę, to powinien usłyszeć, coś w
> stylu, że obecnie hasła o długości krótszej niż 80 bitów są uznawane
> za zbyt słabe.

Przecież dłuższe hasła też mogą być zbyt słabe - wystarczy sprawdzić
czego john szuka na początku.
Długość to jest tak średnio miara entropii.
To tak na marginesie, gdyby rzeczywiście wszyscy mieli stosować podobne
algorytmy.

Są zastosowania, gdzie bez czegoś takiego po prostu się nie da. Ale
stosowanie tego na siłę wszędzie nie wydaje mi się racjonalne. Inna
sprawa, że z takimi nieracjonalnymi decyzjami zdarza mi się czasem
spotykać.
--
Krzysztof Hałasa

do góry

W dniu 2020-06-10 o 22:44, Krzysztof Halasa pisze:

>> Jeśli jutro do złamania nie wydłużanego hasła w rozsądnym czasie
>> wystarczy mu jeden komputer to do złamania w tym samym czasie hasła,
>> które zostało wydłużone będzie potrzebował miliona komputerów.
>> Tylko tyle i aż tyle.
>
> Ale dlaczego w tym samym czasie.

Bo jeśli znalezienie hasła nie wydłużanego trwałoby na sprzęcie
posiadanym przez atakującego miesiąc to ma on realną szansę powodzenia.
Atakujący nie dożyłby końca ataku trwającego milion miesięcy więc aby
atak był skuteczny to powinien zaangażować więcej mocy obliczeniowej.

> To może być znacznie dłużej.
> Np. niejaki John łamie proste hasła na moim starym firmowym komputerze
> (czasem zdarza mi się analizować takie rzeczy) w ciągu sekund.

Jeśli ktoś stosuje aż tak słabe hasła to sam się prosi o problemy i
dlatego nie czuję się odpowiedzialny za złamanie jego hasła.
Miałem na myśli hasła, wymagające jednak jakiegoś realnego czasu na
złamanie.

> Nie widzę
> jednak żadnego problemu, by zostawić go z tym na nockę, albo i na
> miesiąc.

Nawet przy takich założeniach jest różnica, czy po miesiącu masz złamane
hasło jednego użytkownika, czy miliona użytkowników.

>> A takie utrudnienia kosztuje nas sekundę przy każdym sprawdzaniu hasła.
>> To nie wygórowana cena.
>
> Jeśli robimy to raz dziennie. Bo jeśli co sekundę, to owszem - jest
> wygórowana.

Mówimy o logowaniu się użytkowników (ludzi) a nie użytkowników
(komputerów), bo w tym drugim przypadku nie ma problemu, aby hasło było
dowolnie długie i bez naleciałości językowych.


> Poza tym, jest też problem motywacji. Jaką motywację miałby mieć
> właściciel serwera? To nie są jego hasła. On oczywiście nie chce, by
> ktoś niepowołany dostał dostęp do takich danych, ale jeśli już dostanie,
> to czy łamanie będzie trwało 2 sekundy, czy 200 lat, to już nie jego
> zmartwienie.

Nigdy nie byłem właścicielem serwera, ale wyobrażam sobie, że ktoś
(jakieś służby) zupełnie inaczej ocenią wyciek danych w obu przypadkach.

>> Jeśli jest jakiś powód stosowania haseł to jest też naturalne aby
>> złamanie było możliwie utrudnione.
>
> Nie widzę takiej implikacji. Czym innym byłoby podsłuchanie - wtedy
> zgoda, ale złamanie czegoś, do czego tak czy owak nie ma dostępu?

Podobno często najsłabszym ogniwem systemu jest człowiek. Wystarczy
kogoś przekupić i już jest dostęp. No i wtedy jest pytanie ile kosztuje
wyciągnięcie interesujących informacji. Lepiej jak to jest milion razy
drożej.

>> Ale jest też taka ogólna zasada, aby
>> utrudnić wszędzie gdzie się da, bo np. w nieprzewidziany dla nas
>> sposób atakujący wejdzie w posiadanie bazy z hashami haseł.
>
> Nie, nie ma takiej zasady.

Może ująłem to zbyt skrótowo, ale za tą książką pamiętam coś w stylu, że
każdy fragment systemu ma się bronić sam nie licząc na obronę przez
pozostałe fragmenty. Czyli baza danych nie powinna zakładać, że nia ma
do niej dostępu - wręcz przeciwnie - zakłada, że jest dostęp i pytanie
czy się sama obroni.
Oni ogólnie pisali na podstawie swoich doświadczeń jako analitycy
bezpieczeństwa systemów bankowych. Może w 2003 gdy to pisali do innych
systemów nie było potrzeby podchodzić tak restrykcyjnie, ale uważam, że
obecnie to każdy system jest narażony i lepiej jak będzie lepszy niż gorszy.

> Są zasady w efekcie dokładnie przeciwne.
> W szczególności taka mówiąca o kosztach zabezpieczenia oraz ataku,
> i jak się one mają do wartości danych / szkód.

Kosztem zabezpieczenia, o którym ja piszę jest 1s pracy komputera usera
(bo to tam ma być hasło wydłużane/rozciągane) przy każdym logowaniu. No
i jedna sekunda czasu jego życia. Ja do banku loguję się kilka razy w
miesiącu.
Takim kosztem podnosimy koszt ataku milion razy (przy obecnych
komputerach pewnie 10 milionów razy).

>> Użytkownik nie musi wiedzieć, że jest wydłużane.
>
> No ale tego można się łatwo dowiedzieć. Standardowe systemy itd.
> Poza tym, gdyby _wszyscy_ mieli to stosować, to wiadomo że to byliby
> wszyscy.
>
>> A jeśli przekazuje mu się tę wiedzę, to powinien usłyszeć, coś w
>> stylu, że obecnie hasła o długości krótszej niż 80 bitów są uznawane
>> za zbyt słabe.
>
> Przecież dłuższe hasła też mogą być zbyt słabe - wystarczy sprawdzić
> czego john szuka na początku.

Dryfujesz w kierunku nie technicznych aspektów zagadnienia. Nie mam ani
wiedzy, ani czasu aby iść w tym kierunku dyskusji .


> Są zastosowania, gdzie bez czegoś takiego po prostu się nie da. Ale
> stosowanie tego na siłę wszędzie nie wydaje mi się racjonalne.

A mi się wydaje jak najbardziej racjonalne poświęcenie 1s przy logowaniu
aby podnieść koszt ataku milion (lub więcej) razy. I to w każdym systemie.

Jeszcze raz zacytuję co specjaliści napisali w 2003r: "Techniki te są
tak proste i naturalne, że powinny być stosowane we wszystkich systemach
haseł. Ignorowanie ich nie ma żadnego uzasadnienia."
Nie czytałem żadnej nowszej książki więc mogę nie wiedzieć, że coś w tym
względzie się zmieniło.

> Inna sprawa, że z takimi nieracjonalnymi decyzjami zdarza mi się czasem
> spotykać.

To brzmi jakbyś za nieracjonalne uważał to, co oni uważają że powinno
być stosowane we wszystkich systemach haseł.
P.G.

do góry

Piotr Gałka <p...@c...pl> writes:

> Mówimy o logowaniu się użytkowników (ludzi) a nie użytkowników
> (komputerów), bo w tym drugim przypadku nie ma problemu, aby hasło
> było dowolnie długie i bez naleciałości językowych.

Ależ oczywiście że ludzi. Komputery nie logują się raczej hasłami.
Tyle że mówimy o różnych sytuacjach. O logowaniu się do serwerów.
Z wieloma userami. Powtórzę jeszcze raz - w domowych zastosowaniach
takie algorytmy jak najbardziej powinny być stosowane, bo tam jest to
sensowna możliwość zapewnienia względnego bezpieczeństwa takich haseł.

Rozumiesz? Zastosowane rozwiązanie zależy od konkretnych wymagań.
Nie stosujemy niczego na ślepo, nie rozumiejąc całości zagadnienia,
tylko dlatego, że tak chyba czytaliśmy 15 lat temu w jakiejś książce.

> Nigdy nie byłem właścicielem serwera, ale wyobrażam sobie, że ktoś
> (jakieś służby) zupełnie inaczej ocenią wyciek danych w obu
> przypadkach.

Dane adresowe, numery kart kredytowych, numery telefonów, PESELe, dane
rodziców - to są dane problematyczne. Hasła - zapomnij.
Dane w bazie klientów muszą być chroniono, ich wyciek jest rodzajem
katastrofy. Hasła to sprawa drugorzędna - można je zmienić. Inne dane
zmienia się znacznie trudniej.

Np. ostatnio były wycieki danych osobowych z (przynajmniej dwóch)
uczelni. Myślisz że jakieś hasła, albo sposób ich szyfrowania, kogoś
zainteresowały?

> Może ująłem to zbyt skrótowo, ale za tą książką pamiętam coś w stylu,
> że każdy fragment systemu ma się bronić sam nie licząc na obronę przez
> pozostałe fragmenty.

Owszem. Zwykle jest to nazywane "defense in depth" ("defence"). Tyle że
to nie ma większego związku ze sprawą. Nie mówię że zupełnie - ale
większego.

> Czyli baza danych nie powinna zakładać, że nia ma
> do niej dostępu - wręcz przeciwnie - zakłada, że jest dostęp i pytanie
> czy się sama obroni.

Elementami "obronnymi" bazy jest np. to, że znajduje się na komputerze
(komputerach) odizolowanych od sieci publicznej, ruch jest kontrolowany,
pomieszczenia z serwerami są zabezpieczone, a dostęp do każdej bazy
wymaga autoryzacji.
Ale raczej nie to, że niektóre - te najmniej istotne zresztą - pola są
trudne do odczytania.

> Kosztem zabezpieczenia, o którym ja piszę jest 1s pracy komputera
> usera (bo to tam ma być hasło wydłużane/rozciągane) przy każdym
> logowaniu. No i jedna sekunda czasu jego życia. Ja do banku loguję się
> kilka razy w miesiącu.

Nic z tych rzeczy. To tak jakbyś napisał, że cena kłódki to 1 sekunda na
przekręcenie klucza. Weź pod uwagę, że kłódkę "złamać" zwykle dużo
łatwiej niż uzyskać dostęp do bazy np. klientów.
BTW w tym przykładzie obok drzwi z kłódką powinniśmy zrobić drugie drzwi
zamknięte na patyk, bo statystycznie główne zagrożenie dla haseł
i w ogóle dostępu do innych komputerów w sieci to komputery użytkowników
i sami użytkownicy (w tym używający tego samego hasła w różnych
miejscach, ale także uruchamiający programy "niewiadomego pochodzenia",
klikający w linki "nieznanego pochodzenia" i następnie nieweryfikujący
gdzie się znajdują itd).

> To brzmi jakbyś za nieracjonalne uważał to, co oni uważają że powinno
> być stosowane we wszystkich systemach haseł.

Nie czytałem tej książki, ale w obecnych realiach to nie tyle jest nawet
nieracjonalne, co po prostu niemożliwe. Mam też delikatne wrażenie, że
liczby są po mojej stronie - nie żeby to był dobry argument, ale czasem
kontakt z rzeczywistością jest potrzebny.

Natomiast jak najbardziej możesz zainteresować się "notatnikami haseł".
Tam możesz mieć wspólne "główne hasło" (albo PIN), generowane losowo
(mam nadzieję) hasła dla każdego serwisu, OTP, ECC itd. Może to służyć
jako klawiatura USB, nie trzeba przepisywać długich ciągów znaków,
niektóre programy (np. przeglądarki) mogą tego używać automagicznie
(notatnik prosi o potwierdzenie np. PINem).
--
Krzysztof Hałasa

do góry

W dniu 2020-06-13 o 15:06, Krzysztof Halasa pisze:
> Piotr Gałka <p...@c...pl> writes:
>
>> Mówimy o logowaniu się użytkowników (ludzi) a nie użytkowników
>> (komputerów), bo w tym drugim przypadku nie ma problemu, aby hasło
>> było dowolnie długie i bez naleciałości językowych.
>
> Ależ oczywiście że ludzi. Komputery nie logują się raczej hasłami.

Jak napisałeś o logowaniu co sekundę to potrafiłem sobie jedynie
wyobrazić, że komputer mógłby chcieć co sekundę utworzyć nową sesję, bo
człowiek raczej nie.

> Tyle że mówimy o różnych sytuacjach. O logowaniu się do serwerów.
> Z wieloma userami.

Ale ta kwestia straconej sekundy w czasie logowania dotyczy każdego
usera indywidualnie i czasu obliczeniowego na jego komputerze a nie
czasu serwera.

> Powtórzę jeszcze raz - w domowych zastosowaniach
> takie algorytmy jak najbardziej powinny być stosowane, bo tam jest to
> sensowna możliwość zapewnienia względnego bezpieczeństwa takich haseł.

Im więcej userów tym większa szansa, że się ktoś zainteresuje atakiem na
taki system.

>> Nigdy nie byłem właścicielem serwera, ale wyobrażam sobie, że ktoś
>> (jakieś służby) zupełnie inaczej ocenią wyciek danych w obu
>> przypadkach.
>
> Dane adresowe, numery kart kredytowych, numery telefonów, PESELe, dane
> rodziców - to są dane problematyczne. Hasła - zapomnij.

To jest logiczne.
Wychodziło by, że wydłużanie haseł cokolwiek da tylko wtedy, gdy
rozważamy, sytuację, że baza danych wyciekła i o tym nie wiemy, a celem
atakującego jest uzyskanie dostępu do kont klientów.
Nie może robić wielu prób logowania bo system zareaguje blokadą kont,
ale jakby poznał hasła....

Nie mam pojęcia jak to wygląda od strony serwera. Skoro zdarzają się
włamania to znaczy, że hakerzy potrafią obejść zabezpieczenia. Skąd
wiadomo, że ktoś się włamał i uzyskał dostęp do bazy danych. Może jest
tak dobry, że zatarł za sobą ślady i my nawet nie wiemy, że należy
piorunem zmieniać hasła, a on właśnie atakuje hasła aby mieć normalny
dostęp do kont użytkowników. W takiej sytuacji lepiej aby było mu milion
razy trudniej.

> Dane w bazie klientów muszą być chroniono, ich wyciek jest rodzajem
> katastrofy. Hasła to sprawa drugorzędna - można je zmienić. Inne dane
> zmienia się znacznie trudniej.

Ale zazwyczaj klient ma dostęp do swoich danych. Więc jak ktoś pozna
hasło to też ma dostęp do tych danych.

> Np. ostatnio były wycieki danych osobowych z (przynajmniej dwóch)
> uczelni. Myślisz że jakieś hasła, albo sposób ich szyfrowania, kogoś
> zainteresowały?

Nie mam pojęcia.
Ale czy takie wycieki nie zdarzają się przez to, że ktoś uzyskał dostęp
jako jeden z ważnych userów - w sensie poznał jego hasło (zakładając, że
login jest jawny).
Jeżeli system umożliwiał wykonanie tylko kilku prób (dziennie)
domniemanych haseł to faktycznie wydłużanie nic nie daje.

>> Może ująłem to zbyt skrótowo, ale za tą książką pamiętam coś w stylu,
>> że każdy fragment systemu ma się bronić sam nie licząc na obronę przez
>> pozostałe fragmenty.
>
> Owszem. Zwykle jest to nazywane "defense in depth" ("defence"). Tyle że
> to nie ma większego związku ze sprawą. Nie mówię że zupełnie - ale
> większego.

Możliwe.

> Natomiast jak najbardziej możesz zainteresować się "notatnikami haseł".
> Tam możesz mieć wspólne "główne hasło" (albo PIN), generowane losowo
> (mam nadzieję) hasła dla każdego serwisu, OTP, ECC itd. Może to służyć
> jako klawiatura USB, nie trzeba przepisywać długich ciągów znaków,
> niektóre programy (np. przeglądarki) mogą tego używać automagicznie
> (notatnik prosi o potwierdzenie np. PINem).

Domyślam się co to są notatniki haseł - miałem zamiar sobie samemu coś
takiego napisać.
Co do wpisywania długich ciągów znaków - robimy USB czytniki kart, które
udają klawiaturę i po zbliżeniu karty wyrzucają jej numer jakby ktoś
klepał w klawisze. Co jakiś czas się zdarza kolejny klient który wymyśla
sobie jakieś nowe potrzeby (gwiazdka na początku, TAB na końcu zamiast
ENTER itp.). Ostatnio zrobiliśmy konfigurowanie - 0 do 3 znaków z
przodu, 0 do 2 znaków na końcu (+ Enter lub nie). Zobaczymy, kiedy to
nie wystarczy.
Można by wypisywać nie numer karty a jakieś dane zapisane na karcie
krypto, ale na razie nie było takich pytań. Chyba słusznie, bo to raczej
nie ma sensu, aby tajne dane dobrze ukryte na karcie wyrzucać jawnie jak
klawiatura :)
P.G.

do góry

Piotr Gałka <p...@c...pl> writes:

> Ale ta kwestia straconej sekundy w czasie logowania dotyczy każdego
> usera indywidualnie i czasu obliczeniowego na jego komputerze a nie
> czasu serwera.

No ale pisałeś że w każdej sytuacji - a więc też na serwerze.
Rozumiem że masz na myśli sytuację tylko teoretyczną?
Jeśli tak, to naprawdę ta rada z notatnikiem jest dla Ciebie.

> Im więcej userów tym większa szansa, że się ktoś zainteresuje atakiem
> na taki system.

Nie wątpię nawet przez chwilę.

> To jest logiczne.
> Wychodziło by, że wydłużanie haseł cokolwiek da tylko wtedy, gdy
> rozważamy, sytuację, że baza danych wyciekła i o tym nie wiemy, a
> celem atakującego jest uzyskanie dostępu do kont klientów.
> Nie może robić wielu prób logowania bo system zareaguje blokadą kont,
> ale jakby poznał hasła....

A po co mu dostęp do kont klientów?
No bo w banku to rozumiem. Ale w sklepie? Zakładając, że już wszystko
o nich wie oczywiście. Chodzi o to, by łatwiej było go namierzyć po IP?
Nie mówię że na pewno nie może być żadnego powodu - ale w tej chwili nie
widzę żadnego praktycznego.

> Ale zazwyczaj klient ma dostęp do swoich danych. Więc jak ktoś pozna
> hasło to też ma dostęp do tych danych.

Ale jak dostanie bazę, to hasło jest mu zbędne.

> Ale czy takie wycieki nie zdarzają się przez to, że ktoś uzyskał
> dostęp jako jeden z ważnych userów - w sensie poznał jego hasło
> (zakładając, że login jest jawny).

Co za różnica czy ktoś zgubił laptopa czy może ktoś inny znalazł dziurę
w jakimś serwisie?

> Jeżeli system umożliwiał wykonanie tylko kilku prób (dziennie)
> domniemanych haseł to faktycznie wydłużanie nic nie daje.

Rozumiem jeszcze zagrożenie wynikające z używania jednego hasła do
różnych (niezwiązanych ze sobą) systemów, ale naprawdę myślisz, że ktoś
mógł łamać hasło w ten sposób? No bez przesady.
Tzn. oczywiście takie ataki są przeprowadzane cały czas, mimo że systemy
umożliwiają wykonanie dość ograniczonej w czasie liczby prób (raczej nie
tylko kilku dziennie).

> Domyślam się co to są notatniki haseł - miałem zamiar sobie samemu coś
> takiego napisać.

Tego akurat nie sugerowałem - chociaż oczywiście można to zrobić bez
żadnej kryptografii. Ale lepiej dokładnie wiedzieć co się robi,
i w szczególności ustalić założenia.

> Można by wypisywać nie numer karty a jakieś dane zapisane na karcie
> krypto, ale na razie nie było takich pytań. Chyba słusznie, bo to
> raczej nie ma sensu, aby tajne dane dobrze ukryte na karcie wyrzucać
> jawnie jak klawiatura :)

Klawiatura nie "wyrzuca jawnie danych" - w przeciwnym przypadku hasła
byłyby bezużyteczne. Problemem jest to, że takie urządzenie nie wie, czy
to jest akurat dobry moment na wysłanie danych.
--
Krzysztof Hałasa

do góry

Można kodem kreskowym i czytnikiem.
No ale to byłoby zapisanie na kartce papieru.


-----
> robimy USB czytniki kart, które udają klawiaturę i po zbliżeniu karty wyrzucają jej
numer jakby ktoś klepał w klawisze.

do góry

W dniu 2020-06-14 o 00:06, Krzysztof Halasa pisze:

>> To jest logiczne.
>> Wychodziło by, że wydłużanie haseł cokolwiek da tylko wtedy, gdy
>> rozważamy, sytuację, że baza danych wyciekła i o tym nie wiemy, a
>> celem atakującego jest uzyskanie dostępu do kont klientów.
>> Nie może robić wielu prób logowania bo system zareaguje blokadą kont,
>> ale jakby poznał hasła....
>
> A po co mu dostęp do kont klientów?
> No bo w banku to rozumiem. Ale w sklepie? Zakładając, że już wszystko
> o nich wie oczywiście. Chodzi o to, by łatwiej było go namierzyć po IP?
> Nie mówię że na pewno nie może być żadnego powodu - ale w tej chwili nie
> widzę żadnego praktycznego.

Z punktu widzenia użytkownika sklepu też nie widzę co miałby dać
atakującemu dostęp do kont klientów. Dlatego ochronę swoich kont w
sklepach nie uważałem, za jakoś nadzwyczaj ważną i do sklepów miałem
jedno hasło.
Ale z punktu widzenia sklepu to już wygląda inaczej. Wyobraźmy sobie
tysiące fikcyjnych zamówień (opłacanych przy odbiorze). Po co hacker
miałby to robić - może jest wynajęty przez konkurencyjny sklep.

Sądzę, że jak oni w tej książce pisali o stosowaniu tego we wszystkich
systemach haseł to mieli na myśli:
- systemy bankowe,
- systemy firmowe.

Zapewne sklepy nie zgłaszały się do nich ze zleceniami kontroli
bezpieczeństwa ich serwerów, a poza tym chyba wtedy sklepy jeszcze nie
były tak popularne jak obecnie.
A firmie tak jak bankowi powinno zależeć, aby ktoś się nie zalogował i
nie pobrał sobie np. dokumentacji najnowszego drona bojowego.

>> Ale zazwyczaj klient ma dostęp do swoich danych. Więc jak ktoś pozna
>> hasło to też ma dostęp do tych danych.
>
> Ale jak dostanie bazę, to hasło jest mu zbędne.

Chyba, że baza jest lepiej zaszyfrowana niż hasła. Albo dostanie bazę
tylko haseł, a nie całą. Nie mam zielonego pojęcia jak to jest w
serwerach. Czasem pojawiają się informacje, że coś wyciekło, ale
wyciekło tylko to i to a do tamtego to się atakującym nie udało uzyskać
dostępu.

>> Ale czy takie wycieki nie zdarzają się przez to, że ktoś uzyskał
>> dostęp jako jeden z ważnych userów - w sensie poznał jego hasło
>> (zakładając, że login jest jawny).
>
> Co za różnica czy ktoś zgubił laptopa czy może ktoś inny znalazł dziurę
> w jakimś serwisie?

Nie pamiętam kontekstu tego fragmentu dyskusji.
Jak ktoś chce zaatakować system to:
- może ukraść laptopa - ale tam nie powinno być hasła do systemu więc
nic mu to nie da.
- może szukać dziury w systemie - i o tym chyba rozmawiamy.

>> Jeżeli system umożliwiał wykonanie tylko kilku prób (dziennie)
>> domniemanych haseł to faktycznie wydłużanie nic nie daje.
>
> Rozumiem jeszcze zagrożenie wynikające z używania jednego hasła do
> różnych (niezwiązanych ze sobą) systemów, ale naprawdę myślisz, że ktoś
> mógł łamać hasło w ten sposób? No bez przesady.

Nie rozumiem słowa 'łamać' w kontekście tego samego hasła w różnych
systemach.
Ale pamiętam informacje, że wyciekły hasła (kojarzy mi się morele.net i
cyfrowe.pl) i użytkownicy, którzy używali tego samego hasła w innych
systemach powinni je jak najszybciej zmienić.
Ja używałem tego samego, ale tylko do sklepów i na zasadzie, że nie
widzimy zagrożenia dla usera wynikającego z zalogowania się przez kogoś
do sklepu nie chciało mi się zmieniać. Jaka jest teraz sytuacja - ktoś,
kto ma te hasła może zapewne się w wielu sklepach zalogować na wiele
kont - to jest potencjalne zagrożenie dla tych wszystkich innych sklepów
spowodowane według mnie przez to, że 'wyciekły hasła'. Zagrożenia by nie
było, gdyby wyciekły wydłużone i posolone hasła.
Dlatego uważałem, że wszyscy mają w bazie tylko posolone i wydłużone
hasła i się zdziwiłem, że nie.

Skojarzyło mi się zagrożenie dla usera. W takich sklepach jak allegro
ktoś logujące się jako użytkownik, może chyba poprzez jakieś wystawiane
opinie itp narobić smrodu użytkownikowi.

>> Domyślam się co to są notatniki haseł - miałem zamiar sobie samemu coś
>> takiego napisać.
>
> Tego akurat nie sugerowałem - chociaż oczywiście można to zrobić bez
> żadnej kryptografii. Ale lepiej dokładnie wiedzieć co się robi,
> i w szczególności ustalić założenia.

Wiem, że nie sugerowałeś, ale mi po prostu od lat chodzi to po głowie.
Jak coś potrafię zrobić sam to lubię to zrobić traktując to jako formę
uczenia się.
Ale nie rozumiem, jak można by zrobić notatnik haseł bez kryptografii.
Przecież to nie miałoby sensu. Hasła byłyby w pliku zapisane jawnie.
Chyba, że źle się domyślam co to jest notatnik haseł. Ja myslałem o
programie, który zapisuje wiele haseł w jednym (dobrze zabezpieczonym)
pliku do którego dostęp uzyskuje się poprzez podanie hasła.

>> Można by wypisywać nie numer karty a jakieś dane zapisane na karcie
>> krypto, ale na razie nie było takich pytań. Chyba słusznie, bo to
>> raczej nie ma sensu, aby tajne dane dobrze ukryte na karcie wyrzucać
>> jawnie jak klawiatura :)
>
> Klawiatura nie "wyrzuca jawnie danych" - w przeciwnym przypadku hasła
> byłyby bezużyteczne. Problemem jest to, że takie urządzenie nie wie, czy
> to jest akurat dobry moment na wysłanie danych.
Nie rozumiem co chcesz powiedzieć.
Klawiatura wyrzuca jawnie właśnie naciśnięty klawisz. No chyba, że masz
na myśli jakieś inne rodzaje klawiatur a nie zwykłe podłączone do USB
komputera.
Udający klawiaturę czytnik (przynajmniej nasz) zamienia zbliżenie karty
na serię naciśnięć klawiszy - więc 'wyrzuca jawnie tę serię klawiszy'.
P.G.

do góry

Piotr Gałka <p...@c...pl> writes:

> Ale z punktu widzenia sklepu to już wygląda inaczej. Wyobraźmy sobie
> tysiące fikcyjnych zamówień (opłacanych przy odbiorze). Po co hacker
> miałby to robić - może jest wynajęty przez konkurencyjny sklep.

No, czyli to co napisałem - żeby go było łatwiej namierzyć.
Przecież do złożenia fikcyjnych zamówień nie trzeba się nigdzie
włamywać, wystarczy je po prostu złożyć.

> Sądzę, że jak oni w tej książce pisali o stosowaniu tego we wszystkich
> systemach haseł to mieli na myśli:
> - systemy bankowe,
> - systemy firmowe.

A to błąd. Bo to jest potrzebne głównie w:
- systemach domowych :-)

W systemach firmowych (w tym bankowych) można to zrobić lepiej.

>> Ale jak dostanie bazę, to hasło jest mu zbędne.
>
> Chyba, że baza jest lepiej zaszyfrowana niż hasła. Albo dostanie bazę
> tylko haseł, a nie całą. Nie mam zielonego pojęcia jak to jest w
> serwerach. Czasem pojawiają się informacje, że coś wyciekło, ale
> wyciekło tylko to i to a do tamtego to się atakującym nie udało
> uzyskać dostępu.

No ale można w ciemno założyć, że jeśli wycieknie baza userów, to
wycieknie wszystko poza ew. numerami kart (bo tych tam zwykle nie ma).
A jeśli wyciekną też karty, to może przynajmniej bez CVC2 (bo tych nie
wolno tam trzymać). Zresztą teraz często 3DS, a karty można zastrzec.

> Nie pamiętam kontekstu tego fragmentu dyskusji.
> Jak ktoś chce zaatakować system to:
> - może ukraść laptopa - ale tam nie powinno być hasła do systemu więc
> nic mu to nie da.

Kontekst jest taki, że cenne informacje to nie są hasła. I tyle.

> Ale pamiętam informacje, że wyciekły hasła (kojarzy mi się morele.net
> i cyfrowe.pl) i użytkownicy, którzy używali tego samego hasła w innych
> systemach powinni je jak najszybciej zmienić.

Nie. Nie powinni mieć tego samego hasła. Natomiast zmienić powinni
wszyscy, którzy używali danych serwisów.

> Ale nie rozumiem, jak można by zrobić notatnik haseł bez kryptografii.
> Przecież to nie miałoby sensu. Hasła byłyby w pliku zapisane jawnie.

Dlaczego nie miałoby to sensu? To zależy od założeń - być może taki
notatnik miałby być używany tylko w bezpiecznym miejscu.

> Chyba, że źle się domyślam co to jest notatnik haseł. Ja myslałem o
> programie, który zapisuje wiele haseł w jednym (dobrze zabezpieczonym)
> pliku do którego dostęp uzyskuje się poprzez podanie hasła.

Taki notatnik to raczej urządzenie, które przechowuje hasła w swojej
pamięci. Jest na tyle proste, że nie odpala się tam "dowolnego" softu,
i na tyle bezpieczne, że bez zgody usera nie wystawi na zewnątrz żadnych
niejawnych informacji.

> Nie rozumiem co chcesz powiedzieć.
> Klawiatura wyrzuca jawnie właśnie naciśnięty klawisz. No chyba, że
> masz na myśli jakieś inne rodzaje klawiatur a nie zwykłe podłączone do
> USB komputera.

No to moja klawiatura nie "wyrzuca jawnie" naciśniętego klawisza -
przesyła go tylko względnie tajnym kanałem do (również niezbyt jawnego)
komputera. Ale gdyby tak można było jej wyjście skierować np. do paska
przeglądarki, albo np. do treści emaila, w taki sposób, bym tego nie
widział, to może byłoby to problemem.

W przypadku klawiatury zwykłego peceta jest to dość oczywiste, ale
zupełnie inaczej wygląda to wtedy, gdy mamy "klawiaturę" komputera
(np. czytnik kart), którego ekranu nie widzimy.
--
Krzysztof Hałasa

do góry

W dniu 2020-06-15 o 17:03, Krzysztof Halasa pisze:
> Piotr Gałka <p...@c...pl> writes:
>
>> Ale z punktu widzenia sklepu to już wygląda inaczej. Wyobraźmy sobie
>> tysiące fikcyjnych zamówień (opłacanych przy odbiorze). Po co hacker
>> miałby to robić - może jest wynajęty przez konkurencyjny sklep.
>
> No, czyli to co napisałem - żeby go było łatwiej namierzyć.
> Przecież do złożenia fikcyjnych zamówień nie trzeba się nigdzie
> włamywać, wystarczy je po prostu złożyć.

Czy aby na pewno?
Tysiące zamówień z jednego konta - na pewno nie wyślą tylko nabiorą
podejrzeń.
Tysiące nowych kont (do każdego inny mail) i zamówienie z każdego konta
- też podejrzane.
Tysiące zamówień z tysięcy od lat działających kont jest najmniej
podejrzane. Szczególnie jak w okresie wzmożonych zamówień - typu przed
świętami.

>
>> Sądzę, że jak oni w tej książce pisali o stosowaniu tego we wszystkich
>> systemach haseł to mieli na myśli:
>> - systemy bankowe,
>> - systemy firmowe.
>
> A to błąd. Bo to jest potrzebne głównie w:
> - systemach domowych :-)

Nie wiem co to są systemy domowe, o których już chyba drugi raz piszesz.
Nikt sobie w domu nie robi chyba systemu do którego mu się może masa
ludzi logować.

> No ale można w ciemno założyć, że jeśli wycieknie baza userów, to
> wycieknie wszystko poza ew. numerami kart (bo tych tam zwykle nie ma).

Ja nie mam takiej wiedzy, abym mógł cokolwiek w ciemno zakładać więc
staram się nic nie zakładać. Ani nie zakładam, że wycieknie wszystko,
ani, że tylko dane logowania. Biorę po prostu pod uwagę że może być
zarówno tak jak i tak. Jeśli w jakiejkolwiek sytuacji (którą dopuszczam
jako możliwą) się okaże, że solenie/wydłużanie coś daje to przyjmuję, że
nie ma uzasadnienia aby tego nie robić.

>> Ale pamiętam informacje, że wyciekły hasła (kojarzy mi się morele.net
>> i cyfrowe.pl) i użytkownicy, którzy używali tego samego hasła w innych
>> systemach powinni je jak najszybciej zmienić.
>
> Nie. Nie powinni mieć tego samego hasła.

Jeśli nawet ja (generalnie dosyć ostrożny) stosowałem to samo hasło do
sklepów to nie ma podstaw, aby przyjąć, że wszyscy robią tak jak
powinni. Wręcz podejrzewam, że nie tylko nie jestem wyjątkiem, ale wręcz
jestem w większości.
Czyli chcę powiedzieć: Masz rację, ale praktyka jest chyba inna. Zamiast
kwestionować tę praktykę lepiej zrobić tak, aby była dopuszczalna
(oczywiście jeśli jest to możliwe i nie kosztuje za wiele).

> Natomiast zmienić powinni
> wszyscy, którzy używali danych serwisów.

O popatrz. Jeszcze nie zmieniłem, bo nie miałem akurat potrzeby tam
zaglądać. Zakładam, że może jak mieli wyciek to po prostu poblokowali
wszystkie hasła i jak kiedyś będę chciał się zalogować to mnie
przeczołgają przez procedurę utworzenia nowego hasła.

>> Ale nie rozumiem, jak można by zrobić notatnik haseł bez kryptografii.
>> Przecież to nie miałoby sensu. Hasła byłyby w pliku zapisane jawnie.
>
> Dlaczego nie miałoby to sensu? To zależy od założeń - być może taki
> notatnik miałby być używany tylko w bezpiecznym miejscu.

W bezpiecznym miejscu to sobie mogę hasła napisać w dowolnym pliku
tekstowym. Nie potrzebuję do tego specjalnego programu.

>> Chyba, że źle się domyślam co to jest notatnik haseł. Ja myslałem o
>> programie, który zapisuje wiele haseł w jednym (dobrze zabezpieczonym)
>> pliku do którego dostęp uzyskuje się poprzez podanie hasła.
>
> Taki notatnik to raczej urządzenie, które przechowuje hasła w swojej
> pamięci. Jest na tyle proste, że nie odpala się tam "dowolnego" softu,
> i na tyle bezpieczne, że bez zgody usera nie wystawi na zewnątrz żadnych
> niejawnych informacji.

Czyli notatnik haseł to urządzenie, a nie program - zmienia postać
rzeczy. Ale podobno 'wyszlifowanie' danych z dowolnej pamięci potaniało
już tak, że nie uważałbym przechowywanych tak niezaszyfrowanych haseł
jako bezpiecznych. Urządzenie zawsze można zgubić lub mieć ukradzione.

Jak zrobiłem sobie generator kluczy to zadbałem o to, aby po wydaniu
klucza nie została w pamięci żadna informacja o jego wartości.
Przy założeniu, że zapisanie nowych danych w komórce pamięci flash
niszczy jej poprzednią zawartość (co nie jest do końca prawdą bo odczyt
analogowy pozwala podobno stwierdzić ślad poprzedniego zapisu).

> No to moja klawiatura nie "wyrzuca jawnie" naciśniętego klawisza -
> przesyła go tylko względnie tajnym kanałem do (również niezbyt jawnego)
> komputera. Ale gdyby tak można było jej wyjście skierować np. do paska
> przeglądarki, albo np. do treści emaila, w taki sposób, bym tego nie
> widział, to może byłoby to problemem.

Ja rozumiałem, że chodzi o coś, co w momencie kiedy się trzeba zalogować
udaje, że wpisałeś na klawiaturze komputera hasło. Czyli, że komputer ma
dostać znaki tak jakyś to wpisywał na klawiaturze.

> W przypadku klawiatury zwykłego peceta jest to dość oczywiste, ale
> zupełnie inaczej wygląda to wtedy, gdy mamy "klawiaturę" komputera
> (np. czytnik kart), którego ekranu nie widzimy.

Czy ekranu nie widzimy, czy widzimy okienko logowania na którym w
miejscu hasła pojawiają się gwiazdki to wychodzi na to samo. Istotne
jest czy dane są na jakimś etapie jawne i czy można się w to miejsce wciąć.
P.G.

do góry