Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:rbb2n0$8os$1$P...@n...chmurka.ne
t...
W dniu 2020-06-04 o 16:27, Krzysztof Halasa pisze:
> Piotr Gałka <p...@c...pl> writes:
>>> Wczoraj założyłem, że ponieważ (dawno temu ustalone) hasło nie
>>> spełniało obecnych wymogów mBanku to system wyłapuje takie konta i
>>> stopniowo je blokuje zmuszając do ustalenia hasła zgodnego z ich
>>> wymogami.
>
>> Typowo hasła są szyfrowane jednokierunkowo, bank musiałby to
>> sprawdzać
>> podczas logowania się klienta.

>Oczywiste, a nie pomyślałem o tym :(

>Od czasu jak niektóre banki wprowadziły maskowane hasła (czyli dość
>dawno) nabrałem wątpliwości:

Dokladnie.

>- czy oni przechowują hashe dla każdej kombinacji maskowania (sporo
wyjdzie),
>- czy po prostu przechowują całe hasło.

>Stąd (niby irracjonalny) pomysł, że system banku może znać hasło.

A dlaczego nie ?

>Ale to była tylko taka sobie hipoteza powstała po zauważeniu, że przy
>odblokowywaniu dostępu dotychczasowe hasło nie może być użyte.

To by mogli zalatwic pamietajac ostatnie hashe.

J.

do góry

W dniu 2020-06-04 o 18:07, J.F. pisze:

>> Stąd (niby irracjonalny) pomysł, że system banku może znać hasło.
>
> A dlaczego nie ?

Ze względów bezpieczeństwa w systemie banku nie powinny być
przechowywane hasła.
Jakby się zdarzył wyciek danych do logowania z systemu banku to nie
byłoby w nich haseł. Te dane nie pozwoliłyby komuś kto wszedł w ich
posiadanie zalogować się do żadnego konta.

Zanim pojawiły się hasła maskowane byłem pewien, że takie oczywiste
podejście jest realizowane przez każdy system logowania. Dlatego
uważałem, że nie ma żadnych przeciwwskazań aby stoswać to samo hasło do
wszystkich np. sklepów internetowych.
A tu przy okazji każdego wycieku danych do logowania (a było ich
ostatnio kilka - kojarzy mi się morele i chyba cyfrowe, ale mogę źle
pamiętać) zaraz się pisze, że hakerzy wykradli hasła i żeby wszędzie
zmieniać.
To nie powinno tak być.

Klient powinien móc stosować ten sam login i hasło do wszystkich
systemów i wyciek danych z dowolnego z nich nie powinien dawać żadnych
szans zalogowania się za pomocą tych danych do innego systemu.

Jedynym miejscem, gdzie atakujący mógłby poznać hasło użytkownika byłaby
jego klawiatura. Atak na jednego użytkownika nie naruszałby
bezpieczeństwa pozostałych.
Jak hasła są w systemie to atak na to jedno miejsce narusza
bezpieczeństwa mnóstwa osób.
A co najgorsze wyciek danych z takiego systemu narusza bezpieczeństwo
użytkownika (jeśli stosował (a powinien móc) to samo hasło) w innych
systemach, nawet jeśli one realizują to prawidłowo i nie przechowują
haseł użytkowników.

>> Ale to była tylko taka sobie hipoteza powstała po zauważeniu, że przy
>> odblokowywaniu dostępu dotychczasowe hasło nie może być użyte.
>
> To by mogli zalatwic pamietajac ostatnie hashe.
>

Tu nie chodziło o powtórzenie tego samego hasła tylko o wymóg, że hasło
ma zawierać co najmniej duże litery, małe litery i cyfry, a stare nie
spełniało go.

W pewnym sensie takie stare hasło można uznać za bezpieczniejsze. Skoro
atakujący wie jakie są wymogi dla haseł to atakując nie będzie sprawdzał
haseł nie spełniających tych wymogów :)
Tak w ogóle każde wymogi na hasło zmniejszają liczbę możliwych haseł -
czyli hasła stają się krótsze.
P.G.

do góry

Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:rbbbv3$dpp$1$P...@n...chmurka.ne
t...
W dniu 2020-06-04 o 18:07, J.F. pisze:
>>> Stąd (niby irracjonalny) pomysł, że system banku może znać hasło.
>> A dlaczego nie ?

>Ze względów bezpieczeństwa w systemie banku nie powinny być
>przechowywane hasła.
>Jakby się zdarzył wyciek danych do logowania z systemu banku to nie
>byłoby w nich haseł. Te dane nie pozwoliłyby komuś kto wszedł w ich
>posiadanie zalogować się do żadnego konta.

bank musi jakos hasla sprawdzac, wiec jest ryzyko, ze ktos te hasla
wyliczy.

>Zanim pojawiły się hasła maskowane byłem pewien, że takie oczywiste
>podejście jest realizowane przez każdy system logowania. Dlatego
>uważałem, że nie ma żadnych przeciwwskazań aby stoswać to samo hasło
>do wszystkich np. sklepów internetowych.
>A tu przy okazji każdego wycieku danych do logowania (a było ich
>ostatnio kilka - kojarzy mi się morele i chyba cyfrowe, ale mogę źle
>pamiętać) zaraz się pisze, że hakerzy wykradli hasła i żeby wszędzie
>zmieniać.
>To nie powinno tak być.

>Klient powinien móc stosować ten sam login i hasło do wszystkich
>systemów i wyciek danych z dowolnego z nich nie powinien dawać
>żadnych szans zalogowania się za pomocą tych danych do innego
>systemu.

>Jedynym miejscem, gdzie atakujący mógłby poznać hasło użytkownika
>byłaby jego klawiatura.

a jakis falszywy sklep ? A nawet prawdziwy, ale zalozony przez mafie ?
Czy zgrabna socjotechnika "dzien dobry, dzwonimy z portalu Sudoku na
Codzien, mial pan problem z logowaniem ? Czy moge prosic o uzytkownika
i haslo" ?
Albo zlosliwie - "widzę, ze jest zglaszany bład na piatym znaku
hasła - czy moze pan podać jaki to znak?"

To klient ma dbac, zeby hasla sie nie powtarzaly :-)

>Atak na jednego użytkownika nie naruszałby bezpieczeństwa
>pozostałych.

W zasadzie nie narusza. To tylko we wczesnym unixie kazdy uzytkownik
mogl odczytac hasla wszystkich innych ... ale zaszyfrowane.

>>> Ale to była tylko taka sobie hipoteza powstała po zauważeniu, że
>>> przy odblokowywaniu dostępu dotychczasowe hasło nie może być
>>> użyte.
>
>> To by mogli zalatwic pamietajac ostatnie hashe.
>
>Tu nie chodziło o powtórzenie tego samego hasła tylko o wymóg, że
>hasło ma zawierać co najmniej duże litery, małe litery i cyfry, a
>stare nie spełniało go.

Ale to moga sprawdzac przy wprowadzaniu hasla.
No chyba, ze zablokowali dostep, bo haslo bylo zbyt proste ... czyli
mieli mozliwosc sprawdzenia :-)

Choc pozostaja metody slownikowe - haslo pamietane w postaci
haszowanej jak w unixie,
a oni sprawdzaja milion najpopularniejszych hasel, i blokuja
trafionych uzytkownikow.

>W pewnym sensie takie stare hasło można uznać za bezpieczniejsze.
>Skoro atakujący wie jakie są wymogi dla haseł to atakując nie będzie
>sprawdzał haseł nie spełniających tych wymogów :)
>Tak w ogóle każde wymogi na hasło zmniejszają liczbę możliwych
>haseł - czyli hasła stają się krótsze.

niby tak, ale widac pozostaja wystarczajaco dlugie, a za to zmniejsza
sie mozliwosc trywialnych hasel :-)

swoja droga - Alior. Haslo dlugie, maskowane, ale loguje sie trzema
znakami.

To juz IMO stosunkowo latwo trafic.

Chyba, ze blokuja IP z ktorego jest za duzo pomylek ...


J.

do góry

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

> Od czasu jak niektóre banki wprowadziły maskowane hasła (czyli dość
> dawno) nabrałem wątpliwości:
> - czy oni przechowują hashe dla każdej kombinacji maskowania (sporo
> wyjdzie),
> - czy po prostu przechowują całe hasło.

A to tak, wtedy zapewne przechowują całe hasła.
Ale w dalszym ciągu blokowanie dostępu ze względu na słabość hasła to
strzał w kolano. Można zabraniać zmiany na słabe hasło, ale jak już ktoś
takie ma, to nie powinno się go (skutecznie) szykanować. W przeciwnym
przypadku - same problemy.
--
Krzysztof Hałasa

do góry

Użytkownik "Krzysztof Halasa" napisał w wiadomości grup
dyskusyjnych:m...@p...waw.pl...
Piotr Gałka <p...@c...pl> writes:
>> Od czasu jak niektóre banki wprowadziły maskowane hasła (czyli dość
>> dawno) nabrałem wątpliwości:
>> - czy oni przechowują hashe dla każdej kombinacji maskowania (sporo
>> wyjdzie),
>> - czy po prostu przechowują całe hasło.

>A to tak, wtedy zapewne przechowują całe hasła.
>Ale w dalszym ciągu blokowanie dostępu ze względu na słabość hasła to
>strzał w kolano. Można zabraniać zmiany na słabe hasło, ale jak już
>ktoś
>takie ma, to nie powinno się go (skutecznie) szykanować. W przeciwnym
>przypadku - same problemy.

Czemu nie ? Slabe haslo to tez problemy, i to wieksze.

A propos - mozna to wykrywac na etapie logowania do systemu.

Klientt wpisuje haslo, system szyfruje/haszuje, sprawdza z baza,
a potem ... wyswietla "zmien haslo na lepsze"
I dalej nie pusci bez zmiany :-)

Tak samo, jak okresową zmiane wymuszali ... ale chyba im przeszlo.

J.

do góry

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

> Ze względów bezpieczeństwa w systemie banku nie powinny być
> przechowywane hasła.

Tak teoretycznie powinno być. Aczkolwiek wyobrażam sobie, że taki wyciek
jest już wystarczającą klęską, nawet jeśli nie da się tych haseł (łatwo)
użyć.

> Zanim pojawiły się hasła maskowane byłem pewien, że takie oczywiste
> podejście jest realizowane przez każdy system logowania.

To, że nie przez każdy, to było raczej jasne od zawsze. Nawet jeśli nie
było to hasło w jawnej postaci - ale w takiej, która umożliwiała
zalogowanie się. Łatwo podać przykłady, i to nie takie wcale niszowe -
choćby (na pewnym etapie) Microsoft, Novell.

> Dlatego
> uważałem, że nie ma żadnych przeciwwskazań aby stoswać to samo hasło
> do wszystkich np. sklepów internetowych.

Oj oj oj. To już wniosek zbyt daleko idący. Każdy właściciel sklepu
mógłby się zalogować do banku - raczej nierozsądne.

> A tu przy okazji każdego wycieku danych do logowania (a było ich
> ostatnio kilka - kojarzy mi się morele i chyba cyfrowe, ale mogę źle
> pamiętać) zaraz się pisze, że hakerzy wykradli hasła i żeby wszędzie
> zmieniać.
> To nie powinno tak być.

Owszem. Powinno się zmieniać tylko tam, gdzie wykradli. Przecież nie
używamy takich samych haseł w różnych miejscach, nie?

> Klient powinien móc stosować ten sam login i hasło do wszystkich
> systemów i wyciek danych z dowolnego z nich nie powinien dawać żadnych
> szans zalogowania się za pomocą tych danych do innego systemu.

Nic z tych rzeczy.

> Jedynym miejscem, gdzie atakujący mógłby poznać hasło użytkownika
> byłaby jego klawiatura.

Nie. Hasło tak czy owak musi być przesłane do zdalnego systemu, by ten
mógł je zweryfikować. Np. policzyć hash i porównać z przechowywanym
w bazie. Ale to oznacza, że w pewnym momencie musi znać hasło.
Oczywiście istnieją systemy, gdzie hasło jest np. używane do uzyskania
(lokalnego) dostępu do klucza asymetrycznego, albo jest (znów lokalnie)
używane w jakimś challenge-response, ale to jakby inna bajka.

> Atak na jednego użytkownika nie naruszałby
> bezpieczeństwa pozostałych.

Nie narusza. "Atak" (kradzież) bazy to inna bajka.

> Jak hasła są w systemie to atak na to jedno miejsce narusza
> bezpieczeństwa mnóstwa osób.

To kwestia tego, czy atakujący ma dostęp "tylko do odczytu" (np. może
skopiować bazę, albo nawet ją zmodyfikować), czy też może wprowadzić
zmiany w oprogramowaniu systemu (lub np. śledzić jego wykonywanie).
W tym drugim przypadku może łatwo poznać hasła, hash czy nie hash.
--
Krzysztof Hałasa

do góry

"J.F." <j...@p...onet.pl> writes:

> W zasadzie nie narusza. To tylko we wczesnym unixie kazdy uzytkownik
> mogl odczytac hasla wszystkich innych ... ale zaszyfrowane.

Albo i nie. W wersji eksportowej przynajmniej niektórych systemów
(oczywiście takich bez shadow password suite) hasła były jawnie
w /etc/passwd :-) Aczkolwiek nie pamiętam już co się działo, jeśli ktoś
miał tam np. dwukropek.

> Choc pozostaja metody slownikowe - haslo pamietane w postaci
> haszowanej jak w unixie,
> a oni sprawdzaja milion najpopularniejszych hasel, i blokuja
> trafionych uzytkownikow.

To bez sensu. Aczkolwiek teraz wyobrażam sobie, że mogli sprawdzić
w taki sposób dane wykradzione z jakiegoś innego systemu, i poblokować
pasujące. To miałoby przypuszczalnie sens.

> swoja droga - Alior. Haslo dlugie, maskowane, ale loguje sie trzema
> znakami.
>
> To juz IMO stosunkowo latwo trafic.
>
> Chyba, ze blokuja IP z ktorego jest za duzo pomylek ...

36 (małe litery łacińskie i cyfry) ^ 3 = 46656. Nawet, jeśli trzeba
zmieniać IP co chwilę, to to nie jest nijak bezpieczne. Można się
zapewne zalogować na wielu klientów w pierwszej próbie.

Inną kwestią jest to, co następnie można zrobić. Ale samo uzyskanie
dostępu nie powinno także mieć miejsca.

Może identyfikator nie jest prostą liczbą i może jest traktowany jako
tajny - ale tak się nie powinno robić.
--
Krzysztof Hałasa

do góry

W dniu 04.06.2020 o 19:45, Piotr Gałka pisze:
> Klient powinien móc stosować ten sam login i hasło do wszystkich
> systemów i wyciek danych z dowolnego z nich nie powinien dawać żadnych
> szans zalogowania się za pomocą tych danych do innego systemu.

To jest możliwe, jeśli te systemy by stosowały 2FA, czyli coś
dodatkowego. Np. klucz sprzętowy (niebezpiecznik sprzedaje po 150zł)
albo aplikację w smartfonie. Banki u nas poszły we własne apki, i chyba
żeście o tym zapomnieli bo wszyscy dodali swoje komputery jako zaufane.
Ale od czasu PSD2 (niecały rok) banki są zobowiązane do logowania
dwuskładnikowego. Więc w zasadzie znajomość hasła nie wystarczy, żeby
się zalogować do banku na cudze konto.
No i są apki do drugiego składnika firm trzecich - słowo kluczowe OTP.

--
Alf/red/

do góry

"J.F." <j...@p...onet.pl> writes:

> Czemu nie ? Slabe haslo to tez problemy, i to wieksze.

Wątpię. No chyba że klasy hasło = login, wtedy może tak.

> A propos - mozna to wykrywac na etapie logowania do systemu.

Ale to zły moment na zmuszanie do zmiany.

> Klientt wpisuje haslo, system szyfruje/haszuje, sprawdza z baza,
> a potem ... wyswietla "zmien haslo na lepsze"
> I dalej nie pusci bez zmiany :-)

A klient właśnie wsiada do samolotu, albo się Windows zawiesił itp.
I co dalej?
--
Krzysztof Hałasa

do góry

Alf/red/ <a...@u...waw.pl> writes:

> To jest możliwe, jeśli te systemy by stosowały 2FA, czyli coś
> dodatkowego. Np. klucz sprzętowy (niebezpiecznik sprzedaje po 150zł)
> albo aplikację w smartfonie.

To w żadnym razie nie może być uznane za panaceum na takie problemy.
Poza tym, gdyby klienci powszechnie stosowaliby wspólne hasło dla
różnych systemów, to to hasło straciłoby swoją rolę, i równie dobrze
można byłoby je zlikwidować, co redukowałoby mechanizm do 1FA, tyle że
w innej postaci, i kompletnie poza kontrolą klienta (a często także
banku). Coś a la primary - backup reversion.

> Banki u nas poszły we własne apki, i
> chyba żeście o tym zapomnieli bo wszyscy dodali swoje komputery jako
> zaufane. Ale od czasu PSD2 (niecały rok) banki są zobowiązane do
> logowania dwuskładnikowego. Więc w zasadzie znajomość hasła nie
> wystarczy, żeby się zalogować do banku na cudze konto.

Chyba że mamy dostęp do tego "zaufanego urządzenia". Jeśli ktoś przejął
hasło np. ze sklepu internetowego (bo klient używał tego samego hasła)
to ok. Ale jeśli ktoś podsłuchał mu to hasło na jego osobistym pececie,
to jest problem.

> No i są apki do drugiego składnika firm trzecich - słowo kluczowe OTP.

One time password?
No pewnie są takie apki, kiedyś się drukowało listy takich haseł. Weźmy
np. takie S/Key, to już ma prawie (jak widzę) 40 lat.

Zasadniczo, jak już mamy w ogóle pozwalać na wykonywanie obcego kodu, to
lepiej to zrobić bezpieczniej. W szczególności, OTP nie zabezpiecza
przed atakiem MITM. Aplikacja bankowa powinna być w stanie zrobić
challenge/response podczas logowania, a każde zlecenie powinno być
podpisane kluczem klienta (niedostępnym dla banku, przynajmniej
teoretycznie).
Tylko co z przypadkiem, gdy ktoś straci telefon (np. z oczu na chwilę),
albo gdy ktoś mu się tam włamie itp.?
--
Krzysztof Hałasa

do góry