Wczoraj się zdarzyło, że dostęp (żony do ST mBanku) zablokowany - odblokuj.
Nigdy wcześniej nie spotkaliśmy się z tym.
Prawdziwa strona mBanku (odcisk palca się zgadza).

Czy gdzieś w ST da się znaleźć informację jaki był powód zablokowania?
P.G.

Konto jest blokowane po 3 następujących po sobie błędnych logowaniach lub po 50 błędnych pojedynczych logowań od początku założenia konta ewentualnie lub zmiany hasła. Jednym zdaniem
3x pod rząd - blokada
50x - też blokada.
Po odblokowaniu (możesz zrobić to samemu) liczniki idą od nowa.

W dniu 2020-06-01 o 13:30, zaqu pisze:

Konto jest blokowane po 3 następujących po sobie błędnych logowaniach lub po 50 błędnych pojedynczych logowań od początku założenia konta ewentualnie lub zmiany hasła. Jednym zdaniem
3x pod rząd - blokada
50x - też blokada.
Po odblokowaniu (możesz zrobić to samemu) liczniki idą od nowa.

Napisałeś, tak jakbyś miał pewną wiedzę, że tak to jest.

Z tego wynika że albo:
- wczoraj ktoś obcy 3 razy próbował się zalogować,
- co jakiś czas zdarza się komuś próbować zalogować i wczoraj zdarzyło się to 50-ty raz.

Powstaje pytanie, czy coś takiego mogło być przypadkiem.
Faktem jest, że raz (kilka lat temu) zdarzyło mi się pomyłkowo wpisać zły identyfikator. W ten sposób podniosłem komuś stan tego licznika liczącego do 50. Chyba raz też zdarzyło mi się błędne wpisanie hasła - czyli podniosłem swój licznik.
Ale:
- żebym taką samą pomyłkę zrobił 50 razy - wydaje się nieprawdopodobne,
- żeby 50 osób trafiło przez pomyłkę w ten sam identyfikator - też wydaje się nieprawdopodobne (ja podniosłem licznik jednej osobie i sobie, jeśli każdy podniósłby jednej osobie i sobie to wartość oczekiwana tych liczników do 50 jest 2 - prawdopodobieństwo odchyłki, że na jakimś numerze jest aż 50 wydaje się bliskie 0),
- żeby trzy razy pod rząd wpisać nie swój identyfikator również wydaje się niemożliwe - przecież po błędzie sprawdza się czy dane są prawidłowe.

Wychodzi mi, że jest mała szansa na to, że to był przypadek. Jak nie przypadek to co?

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.
Ale (zakładając, że podajesz sprawdzoną wiedzę) to teraz nie wiem co o tym myśleć.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

- żebym taką samą pomyłkę zrobił 50 razy - wydaje się nieprawdopodobne,
- żeby 50 osób trafiło przez pomyłkę w ten sam identyfikator - też

Dlaczego? Pomyśl, że to nie musiało się zdarzyć "wczoraj" tylko licznik
sobie stopniowo rósł przez 5-10 lat. Ty nie byłeś tego świadomy, aż
wczoraj pyknęło "50"

KJ



--
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

Użytkownik "Kamil "Jońca""  napisał w wiadomości grup dyskusyjnych:87d06jezkj.fsf@alfa.kjonca...
Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

- żebym taką samą pomyłkę zrobił 50 razy - wydaje się nieprawdopodobne,
- żeby 50 osób trafiło przez pomyłkę w ten sam identyfikator - też

Dlaczego? Pomyśl, że to nie musiało się zdarzyć "wczoraj" tylko licznik
sobie stopniowo rósł przez 5-10 lat. Ty nie byłeś tego świadomy, aż
wczoraj pyknęło "50"

Albo druga wersja - ktos wczoraj probowal sie 3x zalogowac.
Wcale nie dziwne - wystarczy ze mu sie numerek pomylil.

J.

- żebym taką samą pomyłkę zrobił 50 razy - wydaje się nieprawdopodobne,
- żeby 50 osób trafiło przez pomyłkę w ten sam identyfikator - też

Dlaczego? Pomyśl, że to nie musiało się zdarzyć "wczoraj" tylko licznik
sobie stopniowo rósł przez 5-10 lat. Ty nie byłeś tego świadomy, aż
wczoraj pyknęło "50"

Albo druga wersja - ktos wczoraj probowal sie 3x zalogowac.
Wcale nie dziwne - wystarczy ze mu sie numerek pomylil.

Najczęściej to się zdarza, jak identyfikatorem od jednego banku ktoś próbuje się zalogować do innego. Przyznam się, że komuś tak dostęp zablokowałem, ale nie w mBanku, z którym dałem sobie spokój już bardzo dawno.

--
Grzexs

W dniu 2020-06-01 o 14:32, Kamil Jońca pisze:

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

- żebym taką samą pomyłkę zrobił 50 razy - wydaje się nieprawdopodobne,
- żeby 50 osób trafiło przez pomyłkę w ten sam identyfikator - też

Dlaczego? Pomyśl, że to nie musiało się zdarzyć "wczoraj" tylko licznik
sobie stopniowo rósł przez 5-10 lat. Ty nie byłeś tego świadomy, aż
wczoraj pyknęło "50"

Tak jak pisałem opierałem się na tym ile ja podniosłem tych liczników i na założeniu, że proces jest statystycznie losowy - czyli, że stan liczników ma rozkład Gaussa ze szczytem dla 2.

Ale jeśli założyć, że ktoś ma podobny numer i tendencję do szybkiego wpisywania i przy tym dwie cyferki klikną mu się odwrotnie to faktycznie w ciągu tych nastu lat mogło mu się to 50 razy zdarzyć.
P.G.

Mnie po prawie 6 latach udało się uzyskać 50 błędnych logowań, o ile login to raczej wpisuję bezbłędnie, to z hasłem czasem gdzieś się obsunie palec i już błędny login.

Jakiś czas temu była informacja na której stronie w serwisie transakcyjnym o ostatnim prawidłowym i błędnym logowaniu.

Mnie po prawie 6 latach udało się uzyskać 50 błędnych logowań, o ile login to raczej wpisuję bezbłędnie, to z hasłem czasem gdzieś się obsunie palec i już błędny login.

Jakiś czas temu była informacja na którejś stronie w serwisie transakcyjnym o ostatnim prawidłowym i błędnym logowaniu.

"Piotr Gałka" rb2tpj$n34$1$PiotrGalka@news.chmurka.net

Tak jak pisałem opierałem się na tym ile ja podniosłem tych liczników

Nie każdy jest Tobą -- mądrej głowie dość po słowie...
Rozejrzyj się -- znajdziesz upartych/wytrwałych do przesady...

-=-

W FM banku (różnie nazywanym: BIZ, Smart, Nest...) zablokowałem
dostęp wielokrotnie, choć logowałem się tam niezbyt często; do
mBanku chyba ani razu nie zablokowałem dostępu, choć konta tam
mam od dawna; do Millennium chyba też loguję się bezproblemowo
i do matki, i do swego... W SyneCku logowałem się do kont: matki
swego i ojca...

Niedawno do mBanku z bezpośrednim logowaniem na matki konta miałem
problem, ale być może nie logowałem się tam od początku, bo mam do
matki rachunków upoważnienia...

--
 _._     _,-'""`-._      .`'.-.         ._.                              .-.     )\._.,-- ....,'``.
(,-.`._,'(  coma |\`-/|  .'O`-'      .,; o.'      eneuel@gmail.com      '.O_'   /,   _.. \   _\  (`._ ,.
    `-.-' \ )-`( , o o)  `-:`-'.'.   `\.'.' '~'~'~'~'~'~'~'~'~'~'~'~'~' o.`.,  `._.-(,_..'-- (,_..'`-.;.'  Felix Lee
-bf-      `-    \`_`"'-.o'\:/.d`|'.;.p \ ;' http://www.eneuel.w.duna.pl ;\|/... https://eneuel.oferty-kredytowe.pl/

"Eneuel Leszek Ciszewski" 5ed53f1b$0$525$65785112@news.neostrada.pl

W FM banku (różnie nazywanym: BIZ, Smart, Nest...) zablokowałem
dostęp wielokrotnie, choć logowałem się tam niezbyt często; do
mBanku chyba ani razu nie zablokowałem dostępu, choć konta tam
mam od dawna; do Millennium chyba też loguję się bezproblemowo
i do matki, i do swego... W SyneCku logowałem się do kont: matki
swego i ojca...

Do ePUAPu matki loguję się od lat bezproblemowo, ale do swego
i ojca -- stale blokuję na 10 minut bez widocznej przyczyny...

Do Orange i Play (by sprawdzić numeryczne terminy) -- OK...

--
 _._     _,-'""`-._      .`'.-.         ._.                              .-.
(,-.`._,'(       |\`-/|  .'O`-'      .,; o.'      eneuel@gmail.com      '.O_'
    `-.-' \ )-`( , o o)  `-:`-'.'.   `\.'.' '~'~'~'~'~'~'~'~'~'~'~'~'~' o.`.,
-bf-      `-    \`_`"'-.o'\:/.d`|'.;.p \ ;' http://www.eneuel.w.duna.pl ;\|/...

"Eneuel Leszek Ciszewski" 5ed6cacc$0$514$65785112@news.neostrada.pl

Do Orange i Play (by sprawdzić numeryczne terminy) -- OK...

Właśnie zablokowałem w Orange -- aby zmienić hasło... ;)
Hasło poprawnie zmieniłem, ale kolejne logowanie
wykazuje, że nie zmieniłem... Teraz muszę pamiętać dwa hasła?...

--
 _._     _,-'""`-._      .`'.-.         ._.                              .-.
(,-.`._,'(       |\`-/|  .'O`-'      .,; o.'      eneuel@gmail.com      '.O_'
    `-.-' \ )-`( , o o)  `-:`-'.'.   `\.'.' '~'~'~'~'~'~'~'~'~'~'~'~'~' o.`.,
-bf-      `-    \`_`"'-.o'\:/.d`|'.;.p \ ;' http://www.eneuel.w.duna.pl ;\|/...

W dniu 2020-06-01 o 14:32, Kamil Jońca pisze:

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

- żebym taką samą pomyłkę zrobił 50 razy - wydaje się nieprawdopodobne,
- żeby 50 osób trafiło przez pomyłkę w ten sam identyfikator - też

Dlaczego? Pomyśl, że to nie musiało się zdarzyć "wczoraj" tylko licznik
sobie stopniowo rósł przez 5-10 lat. Ty nie byłeś tego świadomy, aż
wczoraj pyknęło "50"

A można gdzieś sprawdzić do ilu błędnych się dobiło?
Bo do mbanku loguję się rzadko, ale prawie zawsze z błędem -
z rozpędu wpisuję stare hasło. Więc login swój bez błędu wpisuję ale błędnym hasłem to już dawno musiałem 50 przekroczyć a blokady nie doświadczyłem.

On Mon, 1 Jun 2020 14:25:19 +0200, Piotr Gałka<piotr.galka@cutthismicromade.pl> wrote:

- żeby 50 osób trafiło przez pomyłkę w ten sam identyfikator - też wydaje się nieprawdopodobne

Mi od początku istnienia mBanku zdarzyło się to 3 krotnie. O raczej sam sobie niż ktoś mi.

--
Marek

Piotr Gałka <piotr.galka@cutthismicromade.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. Normalnie takie testy przeprowadza się
jednak podczas zmiany hasła, w innych przypadkach nie ma to sensu
(np. w ogóle wymuszanie zmiany hasła powoduje, że część osób utraci
dostęp, nowe hasło może nie być przechowywane bezpiecznie itp).
--
Krzysztof Hałasa

W dniu 2020-06-04 o 16:27, Krzysztof Halasa pisze:

Piotr Gałka <piotr.galka@cutthismicromade.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:
- 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.
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.
P.G.

Użytkownik "Piotr Gałka"  napisał w wiadomości grup dyskusyjnych:rbb2n0$8os$1$PiotrGalka@news.chmurka.net...
W dniu 2020-06-04 o 16:27, Krzysztof Halasa pisze:

Piotr Gałka <piotr.galka@cutthismicromade.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.

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.

Użytkownik "Piotr Gałka"  napisał w wiadomości grup dyskusyjnych:rbbbv3$dpp$1$PiotrGalka@news.chmurka.net...
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.

"J.F." <jfox_xnospamx@poczta.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

Użytkownik "Krzysztof Halasa"  napisał w wiadomości grup dyskusyjnych:m3a71ipq5f.fsf@pm.waw.pl...
"J.F." <jfox_xnospamx@poczta.onet.pl> writes:

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.

Dlaczego bez sensu ?
Stwierdzasz w banku np rosnaca ilosc kradziezy gdzie klient twierdzi, ze to nie on,
i chcesz sprawdzic, czy klienci nie maja ich zbyt prostych.
A masz hasla tylko hashowane.

Oczywiscie mozna tez wymusic zmiane hasla na wszystkich, i sprawdzac nowe czy dobre :-)

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ć.

Teraz to raczej niewiele. Ba - nawet sie nie zalogujesz.
Ale .. np poznanie danych klienta - grozne czy nie ?

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

mozna podejrzec, mozna wyciagnac z klienta, a 8 cyfr przy milionach klientach to nie jest duze zabezpieczenie ..

J.

"J.F." <jfox_xnospamx@poczta.onet.pl> writes:

Dlaczego bez sensu ?
Stwierdzasz w banku np rosnaca ilosc kradziezy gdzie klient twierdzi,
ze to nie on,
i chcesz sprawdzic, czy klienci nie maja ich zbyt prostych.
A masz hasla tylko hashowane.

Ale raczej nie spodziewasz się, że komuś udało się trafić te hasła na
chybił-trafił? To po co to w ogóle sprawdzać?
Jeśli jednak spodziewasz się, to obawiam się, że słabe hasła nie są
głównym problemem.

Teraz to raczej niewiele. Ba - nawet sie nie zalogujesz.
Ale .. np poznanie danych klienta - grozne czy nie ?

Wystarczy, że nieakceptowalne.

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

mozna podejrzec, mozna wyciagnac z klienta, a 8 cyfr przy milionach
klientach to nie jest duze zabezpieczenie ..

"Nie jest prostą liczbą" = nie jest to 8 cyfr, ale oczywiście
identyfikator nie jest tajny i bazowanie na jego tajności jest bez
sensu.
--
Krzysztof Hałasa

W dniu 2020-06-04 o 20:39, J.F. pisze:

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

Wyliczenie z hash-ów powinno być na tyle kosztowne, że nie opłacalne (komputery kwantowe nie zeszły jeszcze pod strzechy).

a jakis falszywy sklep ? A nawet prawdziwy, ale zalozony przez mafie ?

Ale to nie działa tak, że jak pojawi się nowy sklep to wszyscy się rzucają zakładać tam konta. Więc (tak jak w przypadku fałszywych bankomatów) liczba pokrzywdzonych powinna być ograniczona.

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?"

Podatni na taki atak nie powinni chyba w ogóle korzystać z dostępu do czegokolwiek przez internet :)

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

Ale wiadomo, że łatwiej zapamiętać jedno.
Ja założyłem na początku, że wszystkie sklepy robią to według mnie prawidłowo (naiwne założenie, że jak ktoś się na czymś nie zna to się za to nie bierze) i że zakładam sobie konta tylko w niewielkiej liczbie sklepów i nigdy w 'istniejących od tygodnia', nawet jak coś jest w super atrakcyjnej cenie.
Uważałem, że (stosując jedno hasło) jestem bezpieczny bo nie założę sobie konta w jakimś niepewnym sklepie. I tak myślałem dopóki nie pojawiły się informacje o wyciekach haseł. Najpierw myślałem, że to są błędne informacje, bo przecież nikt haseł nie przechowuje, ale stopniowo zacząłem podejrzewać, że jednak przechowują.

W każdym razie niedawno podjąłem decyzję o stosowaniu innego hasła do każdego sklepu.

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

W zasadzie nie narusza.

Ja pisałem o tym, że wtedy daje się zaatakować tylko pojedynczego użytkownika (na jego klawiaturze) i 'nie naruszałby' należało rozumieć jako 'nie narusza', ale użyłem takiej formy bo pisałem o hipotetycznym zdarzeniu, a nie faktycznie mającym miejsce.

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 ...

Pozostaje bezpieczne pod warunkiem ograniczenia 'pasma ataku'. Zablokowanie konta po 3 nieudanych próbach to takie ograniczenie.
P.G.

Użytkownik "Piotr Gałka"  napisał w wiadomości grup dyskusyjnych:rbd5ea$ih1$1$PiotrGalka@news.chmurka.net...
W dniu 2020-06-04 o 20:39, J.F. pisze:

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

Wyliczenie z hash-ów powinno być na tyle kosztowne, że nie opłacalne (komputery kwantowe nie zeszły jeszcze pod strzechy).

No widzisz - DES z Unixa wydawal sie bezpieczny, a juz od dawna nie jest.

a jakis falszywy sklep ? A nawet prawdziwy, ale zalozony przez mafie ?

Ale to nie działa tak, że jak pojawi się nowy sklep to wszyscy się rzucają zakładać tam konta. Więc (tak jak w przypadku fałszywych bankomatów) liczba pokrzywdzonych powinna być ograniczona.

moze i ograniczona, ale nadal moze byc duza :-)

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

Ale wiadomo, że łatwiej zapamiętać jedno.
Ja założyłem na początku, że wszystkie sklepy robią to według mnie prawidłowo (naiwne założenie, że jak ktoś się na czymś nie zna to się za

bardzo naiwne

to nie bierze) i że zakładam sobie konta tylko w niewielkiej liczbie sklepów i nigdy w 'istniejących od tygodnia', nawet jak coś jest w super atrakcyjnej cenie.

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

W zasadzie nie narusza.

Ja pisałem o tym, że wtedy daje się zaatakować tylko pojedynczego użytkownika (na jego klawiaturze) i 'nie naruszałby' należało rozumieć jako 'nie narusza', ale użyłem takiej formy bo pisałem o hipotetycznym zdarzeniu, a nie faktycznie mającym miejsce.

Ale chodzi mi o to, ze atak na jednego uzytkownika, np podsluchanie klawiatury, nie narusza innych uzytkownikow.
Bo co z tego, ze mozesz sie zalogowac na tego uzytkownika do sklepu ?

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 ...

Pozostaje bezpieczne pod warunkiem ograniczenia 'pasma ataku'. Zablokowanie konta po 3 nieudanych próbach to takie ograniczenie.

Ale nie bede probowal 3 razy. Sprawdze raz i odloze na miesiac.
A w miedzyczasie sprawdze milion innych uzytkownikow.
I gdzies trafie ..

J.

W dniu 2020-06-05 o 13:21, J.F. pisze:

No widzisz - DES z Unixa wydawal sie bezpieczny, a juz od dawna nie jest.

W systemach należy stosować algorytmy, dla których przewiduje się, że będą bezpieczne przez przewidywany czas użytkowania systemu - czyli rzędu następne 10..20 lat.

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

W zasadzie nie narusza.

Ja pisałem o tym, że wtedy daje się zaatakować tylko pojedynczego użytkownika (na jego klawiaturze) i 'nie naruszałby' należało rozumieć jako 'nie narusza', ale użyłem takiej formy bo pisałem o hipotetycznym zdarzeniu, a nie faktycznie mającym miejsce.

Ale chodzi mi o to, ze atak na jednego uzytkownika, np podsluchanie klawiatury, nie narusza innych uzytkownikow.
Bo co z tego, ze mozesz sie zalogowac na tego uzytkownika do sklepu ?

Obaj piszemy o tym samym.

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

Pozostaje bezpieczne pod warunkiem ograniczenia 'pasma ataku'. Zablokowanie konta po 3 nieudanych próbach to takie ograniczenie.

Ale nie bede probowal 3 razy. Sprawdze raz i odloze na miesiac.
A w miedzyczasie sprawdze milion innych uzytkownikow.
I gdzies trafie ..

Masz rację - powinni wykrywać i blokować IP.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

W dniu 2020-06-05 o 13:21, J.F. pisze:

No widzisz - DES z Unixa wydawal sie bezpieczny, a juz od dawna nie jest.

W systemach należy stosować algorytmy, dla których przewiduje się, że
będą bezpieczne przez przewidywany czas użytkowania systemu - czyli
rzędu następne 10..20 lat.

Taaa. Jasne. I oczywiście przewidzisz, że nikt Twojego super-duper
bezpiecznego algorytmu nie złamie.
[...]

Pozostaje bezpieczne pod warunkiem ograniczenia 'pasma
ataku'. Zablokowanie konta po 3 nieudanych próbach to takie
ograniczenie.

Ale nie bede probowal 3 razy. Sprawdze raz i odloze na miesiac.
A w miedzyczasie sprawdze milion innych uzytkownikow.
I gdzies trafie ..

Masz rację - powinni wykrywać i blokować IP.

W dobie vpc za $5/mon, tworzonych automatycznie w mniej niż 10min?
Co ci to da?
KJ

--
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

W dniu 2020-06-05 o 13:53, Kamil Jońca pisze:

W systemach należy stosować algorytmy, dla których przewiduje się, że
będą bezpieczne przez przewidywany czas użytkowania systemu - czyli
rzędu następne 10..20 lat.

Taaa. Jasne. I oczywiście przewidzisz, że nikt Twojego super-duper
bezpiecznego algorytmu nie złamie.

Nie mojego, tylko jakiegoś opracowanego i sprawdzonego przez znających się na tym i umiejących oszacować ich bezpieczeństwo.
Nie mam na myśli złamania na skutek błędu w algorytmie tylko złamanie siłowe na skutek rozwoju możliwości komputerów.
Oczywiście jak odkryty zostałby błąd w algorytmie to byłby problem, ale jeśli znający się na tym szukają od lat błędów w znanych algorytmach i nic nie znajdują to mogę jedynie ufać, że jest też duża szansa, że w najbliższych latach nie znajdą.

Masz rację - powinni wykrywać i blokować IP.

W dobie vpc za $5/mon, tworzonych automatycznie w mniej niż 10min?
Co ci to da?

Na tym się nie znam i nie za dokładnie wiem o czym piszesz. Ale jeśli to oznacza, że każdy kolejny atak (czy kilka po których nastąpi zablokowanie) można przeprowadzić co 10 minut to jednak jest to bardzo istotne ograniczenie pasma ataku.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

W dniu 2020-06-05 o 13:53, Kamil Jońca pisze:

W systemach należy stosować algorytmy, dla których przewiduje się, że
będą bezpieczne przez przewidywany czas użytkowania systemu - czyli
rzędu następne 10..20 lat.

Taaa. Jasne. I oczywiście przewidzisz, że nikt Twojego super-duper
bezpiecznego algorytmu nie złamie.

Nie mojego, tylko jakiegoś opracowanego i sprawdzonego przez znających
się na tym i umiejących oszacować ich bezpieczeństwo.
Nie mam na myśli złamania na skutek błędu w algorytmie tylko złamanie
siłowe na skutek rozwoju możliwości komputerów.
Oczywiście jak odkryty zostałby błąd w algorytmie to byłby problem,
ale jeśli znający się na tym szukają od lat błędów w znanych
algorytmach i nic nie znajdują to mogę jedynie ufać, że jest też duża
szansa, że w najbliższych latach nie znajdą.

sha-1, md5 też były opracowane przez "znających się". I co? A może
myślisz, że ludzie od SSL v3 celowo zrobili go słabym i podatnym na
złamanie?

Masz rację - powinni wykrywać i blokować IP.

W dobie vpc za $5/mon, tworzonych automatycznie w mniej niż 10min?
Co ci to da?

Na tym się nie znam i nie za dokładnie wiem o czym piszesz. Ale jeśli
to oznacza, że każdy kolejny atak (czy kilka po których nastąpi
zablokowanie) można przeprowadzić co 10 minut to jednak jest to bardzo
istotne ograniczenie pasma ataku.

Nie, to tego nie oznacza. Oznacza, to tyle, że każdy, mający trochę[1]
wiedzy może szybko stać się zarządcą sieci wielu IP. Już pomijam
możliwość stworzenia botnetu.

KJ

[1] naprawdę trochę, wcale nie tak dużo.

--
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

W dniu 2020-06-05 o 15:48, Kamil Jońca pisze:

Nie mojego, tylko jakiegoś opracowanego i sprawdzonego przez znających
się na tym i umiejących oszacować ich bezpieczeństwo.
Nie mam na myśli złamania na skutek błędu w algorytmie tylko złamanie
siłowe na skutek rozwoju możliwości komputerów.
Oczywiście jak odkryty zostałby błąd w algorytmie to byłby problem,
ale jeśli znający się na tym szukają od lat błędów w znanych
algorytmach i nic nie znajdują to mogę jedynie ufać, że jest też duża
szansa, że w najbliższych latach nie znajdą.

sha-1, md5 też były opracowane przez "znających się".

Ale co z nimi?
Są tam jakieś błędy, czy po prostu w wyniku rozwoju możliwości obliczeniowych komputerów stały się 'za słabe' i zgodnie z tym co piszę musiały być wymienione na silniejsze.

I co? A może
myślisz, że ludzie od SSL v3 celowo zrobili go słabym i podatnym na
złamanie?

Jak działa SSL to nie wiem (a chciałbym wiedzieć).
Nie ogarnąłem kryptografii asymetrycznej.
Nie wiem na czym polegała słabość SSL v3.

Z lektury "Kryptografii w praktyce" Ferguson, Schneier utkwiła mi informacja, że asymetryczna jest potrzebna tylko wtedy, gdy strony nie mogą się wcześniej spotkać no i odbywa się to kosztem konieczności zaufania trzeciej stronie.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

W dniu 2020-06-05 o 15:48, Kamil Jońca pisze:

Nie mojego, tylko jakiegoś opracowanego i sprawdzonego przez znających
się na tym i umiejących oszacować ich bezpieczeństwo.
Nie mam na myśli złamania na skutek błędu w algorytmie tylko złamanie
siłowe na skutek rozwoju możliwości komputerów.
Oczywiście jak odkryty zostałby błąd w algorytmie to byłby problem,
ale jeśli znający się na tym szukają od lat błędów w znanych
algorytmach i nic nie znajdują to mogę jedynie ufać, że jest też duża
szansa, że w najbliższych latach nie znajdą.

sha-1, md5 też były opracowane przez "znających się".

Ale co z nimi?
Są tam jakieś błędy, czy po prostu w wyniku rozwoju możliwości
obliczeniowych komputerów stały się 'za słabe' i zgodnie z tym co
piszę musiały być wymienione na silniejsze.

Znaleziono błędy.
KJ


--
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

kjonca@poczta.onet.pl (Kamil Jońca) writes:

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

W dniu 2020-06-05 o 15:48, Kamil Jońca pisze:

Nie mojego, tylko jakiegoś opracowanego i sprawdzonego przez znających
się na tym i umiejących oszacować ich bezpieczeństwo.
Nie mam na myśli złamania na skutek błędu w algorytmie tylko złamanie
siłowe na skutek rozwoju możliwości komputerów.
Oczywiście jak odkryty zostałby błąd w algorytmie to byłby problem,
ale jeśli znający się na tym szukają od lat błędów w znanych
algorytmach i nic nie znajdują to mogę jedynie ufać, że jest też duża
szansa, że w najbliższych latach nie znajdą.

sha-1, md5 też były opracowane przez "znających się".

Ale co z nimi?
Są tam jakieś błędy, czy po prostu w wyniku rozwoju możliwości
obliczeniowych komputerów stały się 'za słabe' i zgodnie z tym co
piszę musiały być wymienione na silniejsze.

Znaleziono błędy.

Wróć. Nie tyle błędy co, pokazano, że nie są takie silne jak się
wydawało.
KJ

--
http://wolnelektury.pl/wesprzyj/teraz/

W dniu 2020-06-05 o 17:06, Kamil Jońca pisze:

Znaleziono błędy.

Wróć. Nie tyle błędy co, pokazano, że nie są takie silne jak się
wydawało.

Najpierw odpowiedziałem na tamto a potem przeczytałem to.

Moje wiedza o krypto opiera się tylko na tej jednej książce. Uważam, że autorzy się bardzo dobrze znali na tym o czym pisali.
Oni tam sugerowali (w roku 2003), aby nie używać MD5.
Poza tym tylko na podstawie tego, że mifareClasic jest niejawny stwierdzili, że zapewne wkrótce zostanie złamany.
No i sugerowali stosowanie trybu CTR, który był mało popularny, bo nie był podobno wymieniony wśród standardowych trybów dla DESa.

Dlatego też ja stosuję wyłącznie CTR.
Wydaje mi się, że kilka lat temu obiła mi się o oczy jakaś informacja, że gdzieś (może w SSL) ze względu na bezpieczeństwo postanowiono pzrejść na tryb CTR. To było kilka lat temu, a oni o tym pisalie w 2003r.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Dlatego też ja stosuję wyłącznie CTR.
Wydaje mi się, że kilka lat temu obiła mi się o oczy jakaś informacja,
że gdzieś (może w SSL) ze względu na bezpieczeństwo postanowiono
pzrejść na tryb CTR. To było kilka lat temu, a oni o tym pisalie w
2003r.

Ale Ty cały czas nie chcesz zrozumieć jednej rzeczy: w momencie
opracowyawania i wdrażania tych algorytmów one BYŁY uważane za
bezpieczne. Na owe 20 lat, tak jak chciałeś. Tylko, przed upływem owych
20 lat stwierdzono luki. Tego nie chcesz zrozumieć, że nie wszystko da
się przewidzieć/oszacować.

jak to było? "Przewidywanie jest trudne, zwłaszcza jeśli dotyczy przyszłości"
Kj

--
http://wolnelektury.pl/wesprzyj/teraz/

W dniu 2020-06-05 o 18:24, Kamil Jońca pisze:

Ale Ty cały czas nie chcesz zrozumieć jednej rzeczy: w momencie
opracowyawania i wdrażania tych algorytmów one BYŁY uważane za
bezpieczne. Na owe 20 lat, tak jak chciałeś. Tylko, przed upływem owych
20 lat stwierdzono luki. Tego nie chcesz zrozumieć, że nie wszystko da
się przewidzieć/oszacować.

OK.
Nie wiem kiedy MD5 było wdrażane.
Dziwi mnie, że ktoś przewidywał, bezpieczeństwo tego na więcej jak 10 lat (przewidzieć 10 lat wydaje mi się bardzo trudno, a 20 to już chyba niemożliwe).
Nie wiem kiedy (po ilu latach od wdrożenia) odkryto te słabości.

Do tej pory rozumiałem, że odkryto po ładnych paru latach używania - czyli, że odkryto jak i tak w sumie wypadało zmienić.

Po prostu - mam za mało danych/wiedzy.
P.G.

W dniu 2020-06-05 o 17:05, Kamil Jońca pisze:

sha-1, md5 też były opracowane przez "znających się".

Ale co z nimi?
Są tam jakieś błędy, czy po prostu w wyniku rozwoju możliwości
obliczeniowych komputerów stały się 'za słabe' i zgodnie z tym co
piszę musiały być wymienione na silniejsze.

Znaleziono błędy.
KJ

W książce o której pisałem (napisana w 2003r) autorzy sugerowali używanie co najmniej sha256. Z tym, że nie podobała im się 'mała odległość' między zmianami na końcu hashowanych danych a końcowym hashem dlatego sugerowali użycie sha256d = sha256(sha256()).

Ja stosuję sha256d.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Z lektury "Kryptografii w praktyce" Ferguson, Schneier utkwiła mi
informacja, że asymetryczna jest potrzebna tylko wtedy, gdy strony nie
mogą się wcześniej spotkać no i odbywa się to kosztem konieczności
zaufania trzeciej stronie.

Są różne scenariusze, ale generalnie nie ma takiego ograniczenia - to by
było bez sensu.
--
Krzysztof Hałasa

W dniu 2020-06-07 o 16:32, Krzysztof Halasa pisze:

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Z lektury "Kryptografii w praktyce" Ferguson, Schneier utkwiła mi
informacja, że asymetryczna jest potrzebna tylko wtedy, gdy strony nie
mogą się wcześniej spotkać no i odbywa się to kosztem konieczności
zaufania trzeciej stronie.

Są różne scenariusze, ale generalnie nie ma takiego ograniczenia - to by
było bez sensu.

Nie rozumiem o jakim ograniczeniu piszesz.
Ja pisałem 'jest potrzebna' w sensie, 'jest niezbędna' a nie w sensie, że w innych wypadkach nie wolno jej stosować.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Nie rozumiem o jakim ograniczeniu piszesz.
Ja pisałem 'jest potrzebna' w sensie, 'jest niezbędna' a nie w sensie,
że w innych wypadkach nie wolno jej stosować.

Nie ma konieczności zaufania trzeciej stronie.
W najprostszej wersji można zaufać zbiorowi (dowolnie dużemu) trzecich
stron, co jest jednak zupełnie inną sprawą niż ufanie pojedynczej
osobie.
Zasadniczo, w życiu musimy komuś ufać - w sensie nie możemy zakładać, że
wszyscy nas chcą zgodnie oszukać.
--
Krzysztof Hałasa

Krzysztof Halasa napisał(a) :

Zasadniczo, w życiu musimy komuś ufać - w sensie nie możemy zakładać, że
wszyscy nas chcą zgodnie oszukać.

Zgodnie nie. Każdy z osobna ;-)

--
Pozdrawiam
    Zbyszek
PGP key: 0xDCEF4E65

"Zbynek Ltd." <sp2scf.spamstoper@poczta.onet.pl> writes:

Zasadniczo, w życiu musimy komuś ufać - w sensie nie możemy zakładać, że
wszyscy nas chcą zgodnie oszukać.

Zgodnie nie. Każdy z osobna ;-)

Aaa, to wtedy asym crypto nas zabezpiecza (może zabezpieczyć) :-)
--
Krzysztof Hałasa

Użytkownik "Piotr Gałka"  napisał w wiadomości grup dyskusyjnych:rbdb6r$meb$1$PiotrGalka@news.chmurka.net...
W dniu 2020-06-05 o 13:21, J.F. pisze:

No widzisz - DES z Unixa wydawal sie bezpieczny, a juz od dawna nie jest.

W systemach należy stosować algorytmy, dla których przewiduje się, że będą bezpieczne przez przewidywany czas użytkowania systemu - czyli rzędu następne 10..20 lat.

A za 10 lat co ? System nadal dziala, to ulepszamy algorytm ?
A jak nie ulepsza i hackerzy sie dorwa do Twoich hasel ?

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

W zasadzie nie narusza.

Ja pisałem o tym, że wtedy daje się zaatakować tylko pojedynczego użytkownika (na jego klawiaturze) i 'nie naruszałby' należało rozumieć jako 'nie narusza', ale użyłem takiej formy bo pisałem o hipotetycznym zdarzeniu, a nie faktycznie mającym miejsce.

Ale chodzi mi o to, ze atak na jednego uzytkownika, np podsluchanie klawiatury, nie narusza innych uzytkownikow.
Bo co z tego, ze mozesz sie zalogowac na tego uzytkownika do sklepu ?

Obaj piszemy o tym samym.

No to w starym unixie naruszal, bo mogac sie zalogowac do systemu mozna odczytac zahaszowane hasla wszystkich,
ale w wiekszosc wspolczesnych systemow juz niewiele da - dostap do jednego uzytkownika w sklepie, banku, poczcie, grze - innych nie naraza.

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

Pozostaje bezpieczne pod warunkiem ograniczenia 'pasma ataku'. Zablokowanie konta po 3 nieudanych próbach to takie ograniczenie.

Ale nie bede probowal 3 razy. Sprawdze raz i odloze na miesiac.
A w miedzyczasie sprawdze milion innych uzytkownikow.
I gdzies trafie ..

Masz rację - powinni wykrywać i blokować IP.

Gorzej, jak to jakis zbiorczy, z Plusa czy Orange :-(

J.

W dniu 2020-06-05 o 14:33, J.F. pisze:

W systemach należy stosować algorytmy, dla których przewiduje się, że będą bezpieczne przez przewidywany czas użytkowania systemu - czyli rzędu następne 10..20 lat.

A za 10 lat co ? System nadal dziala, to ulepszamy algorytm ?

Tak. np. wydłużamy klucze.

A jak nie ulepsza i hackerzy sie dorwa do Twoich hasel ?

Każdym systemem ktoś zarządza - powinien mieć określone obowiązki i się z nich wywiązywać.
P.G.

Użytkownik "Piotr Gałka"  napisał w wiadomości grup dyskusyjnych:rbdi30$qji$1$PiotrGalka@news.chmurka.net...
W dniu 2020-06-05 o 14:33, J.F. pisze:

W systemach należy stosować algorytmy, dla których przewiduje się, że będą bezpieczne przez przewidywany czas użytkowania systemu - czyli rzędu następne 10..20 lat.

A za 10 lat co ? System nadal dziala, to ulepszamy algorytm ?

Tak. np. wydłużamy klucze.

A jak nie ulepsza i hackerzy sie dorwa do Twoich hasel ?

Każdym systemem ktoś zarządza - powinien mieć określone obowiązki i się z nich wywiązywać.

Ale go zwolnili rok wczesniej :-)

Albo mu za malo placa, albo nie zasluguje na swoja pensje :-)

J.

"J.F." <jfox_xnospamx@poczta.onet.pl> writes:

No widzisz - DES z Unixa wydawal sie bezpieczny, a juz od dawna nie
jest.

Masz na myśli crypt()? Jasne że jest wystarczająco bezpieczny - i zawsze
będzie. W typowym zastosowaniu przynajmniej. Po prostu inne metody są
znacznie łatwiejsze, łamanie DES to ostateczność.

Przykład: łatwiej podmienić procedurę sprawdzającą hasło na taką, która
je sobie także gdzieś zapisuje.

Słabość DES może się ujawnić tylko wtedy, gdy mamy dostęp RO do hasha
- ew. klient musiałby się nie logować itp. W typowym przypadku - bez
znaczenia.

Ale nie bede probowal 3 razy. Sprawdze raz i odloze na miesiac.
A w miedzyczasie sprawdze milion innych uzytkownikow.
I gdzies trafie ..

Owszem. Pewnie nawet ileś razy.
--
Krzysztof Hałasa

Dnia Sun, 07 Jun 2020 16:30:16 +0200, Krzysztof Halasa napisał(a):

"J.F." <jfox_xnospamx@poczta.onet.pl> writes:

No widzisz - DES z Unixa wydawal sie bezpieczny, a juz od dawna nie
jest.

Masz na myśli crypt()? Jasne że jest wystarczająco bezpieczny - i zawsze
będzie. W typowym zastosowaniu przynajmniej. Po prostu inne metody są
znacznie łatwiejsze, łamanie DES to ostateczność.

W zastosowaniu do hasel.

Kiedys, lamanie to mogly byc lata na pojedynczym komputerze.

Dzis to nie wiem czy nie godziny.

Przykład: łatwiej podmienić procedurę sprawdzającą hasło na taką, która
je sobie także gdzieś zapisuje.

Ale to musisz byc administratorem. Albo zdolnym hackerem.
Ale w sumie ... jeden nieuczciwy administrator i wszystkie inne konta
zagrozone.

Ale nie bede probowal 3 razy. Sprawdze raz i odloze na miesiac.
A w miedzyczasie sprawdze milion innych uzytkownikow.
I gdzies trafie ..

Owszem. Pewnie nawet ileś razy.

J.

Piotr Gałka <piotr.galka@cutthismicromade.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

W dniu 2020-06-04 o 21:41, Krzysztof Halasa pisze:

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ć.

Owszem, ale zawsze powinno być tak, że nawet jak uważamy, że wszystkie elementy ssystemu są bezpieczne to złamanie jednego nie powinno dawać nic względem innych.

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.

Ja o tym nie wiedziałem. Zakładałem (wiem - naiwnie), że wszystko jest robione prawidłowo.

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.

Pisałem tylko o jednakowym haśle do sklepów, nie banków.
Poza tym moje założenie (nie znam się na internecie) było takie, że to przeglądarki jak są w trybie z kłódeczką to wymuszają logowanie w taki sposób, że hasło jest hashowane (z loginem i solą) na miejscu i hasło nie wychodzi poza mój komputer. Tak między innymi rozumiałem znaczenie tej kłódeczki - że jestem w bezpiecznym połączeniu i przeglądarka tego pilnuje, że jest ono bezpieczne między innymi nie dopuszczając do wycieku mojego hasła.
Zakładałem, że jak ktoś definiował protokół dla bezpiecznego połączenia dającego prawo wyświetlenia kłódeczki to o to zadbał.

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

Chyba jesteś naiwny :)

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.

Ja podtrzymuję, że powinien móc i świat powinien być tak zorganizowany, że jest to w sumie bezpieczne.

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,

Według mnie nie.

by ten
mógł je zweryfikować. Np. policzyć hash i porównać z przechowywanym
w bazie.

Hash powinien być liczony w komputerze użytkownika.

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.

Hash powinien być liczony w komputerze użytkownika. Hasło nigdy nie powinno być przesyłane do serwera.

Takie jest moje zdanie i ja się z nim zgadzam :)
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Poza tym moje założenie (nie znam się na internecie) było takie, że to
przeglądarki jak są w trybie z kłódeczką to wymuszają logowanie w taki
sposób, że hasło jest hashowane (z loginem i solą) na miejscu i hasło
nie wychodzi poza mój komputer. Tak między innymi rozumiałem znaczenie
tej kłódeczki - że jestem w bezpiecznym połączeniu i przeglądarka tego
pilnuje, że jest ono bezpieczne między innymi nie dopuszczając do
wycieku mojego hasła.
Zakładałem, że jak ktoś definiował protokół dla bezpiecznego
połączenia dającego prawo wyświetlenia kłódeczki to o to zadbał.

Nie zadbał. SSL (obecnie TLS) dba wyłącznie o to, by niedobry Mallory
nie mógł uzyskać dostępu do danych transmitowanych między Alicją
i Bobem.

A tak w ogóle, to TLS jest tylko częścią techniczną, zaś całą reszta
infrastruktury (PKI) jest podatna na takie ataki, że z kłódeczką nie
wiązałbym zbyt wielkich gwarancji.

by ten
mógł je zweryfikować. Np. policzyć hash i porównać z przechowywanym
w bazie.

Hash powinien być liczony w komputerze użytkownika.

I co dalej? Wystarczyłoby uzyskać ten hash (np. z jakiegoś serwera),
i następnie używać go zamiast hasła. Przecież nie trzeba liczyć hasha,
można użyć znanego - to się dzieje pod kontrolą atakującego, na jego
własnym komputerze.

Hash powinien być liczony w komputerze użytkownika. Hasło nigdy nie
powinno być przesyłane do serwera.

Niestety tak się nie da dobrze zrobić. Jeśli idziemy w tym kierunku, to
racjonalne jest użycie kryptografii asymetrycznej, nie tylko tak jak to
jest robione w TLS, ale także do autoryzacji wszelkich operacji. Z tym,
że jeśli "typowy klient" (a nawet nietypowy) nie jest w stanie opanować
bezpieczeństwa przeglądarki i w ogóle swojego komputera, to nie wiem jak
miałby panować nad certyfikatami, kluczami itd.
--
Krzysztof Hałasa

W dniu 2020-06-07 o 17:02, Krzysztof Halasa pisze:

Nie zadbał. SSL (obecnie TLS)

Dla mnie TLS od zawsze oznaczało "Trzy Literowe Skróty". Głównie w kontekście zauważenia, jakie one się zrobiły popularne.

Hash powinien być liczony w komputerze użytkownika.

I co dalej? Wystarczyłoby uzyskać ten hash (np. z jakiegoś serwera),
i następnie używać go zamiast hasła.
Przecież nie trzeba liczyć hasha,
można użyć znanego - to się dzieje pod kontrolą atakującego, na jego
własnym komputerze.

Ale ten hash jest dobry tylko dla tego jednego serwera. Skoro ten serwer został tak zaatakowany, że ktoś wydobył te hashe to ten serwer już i tak jest stracony.
Mi chodzi o to, żeby zaatakowanie jednego serwera nie dawało nic w stosunku do innych.
Przy takiej organizacji według mnie nie powinno być żadnych przeciwwskazań aby użytkownik posługiwał się jednym hasłem do wielu serwerów.
Znaczy jakieś by się znalazły, ale potencjalny wyciek danych z serwera nie byłby takim przeciwwskazaniem.

Hash powinien być liczony w komputerze użytkownika. Hasło nigdy nie
powinno być przesyłane do serwera.

Niestety tak się nie da dobrze zrobić. Jeśli idziemy w tym kierunku, to
racjonalne jest użycie kryptografii asymetrycznej,

Żałuję, że za słabo 'czuję' asymetryczna, aby wdawać się w dyskusje.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Ale ten hash jest dobry tylko dla tego jednego serwera. Skoro ten
serwer został tak zaatakowany, że ktoś wydobył te hashe to ten serwer
już i tak jest stracony.

Eee, wcale nie ma takiej gwarancji. Istnieje klasa ataków, np. pasywny
podsłuch, gdzie taki atak dawałby atakującemu dostęp do naszego konta,
natomiast klasyczny mechanizm challenge-response jest bezpieczny.
--
Krzysztof Hałasa

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/

Alf/red/ <alf_2005@ump.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

W dniu 2020-06-04 o 22:43, Krzysztof Halasa pisze:

Alf/red/ <alf_2005@ump.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.

Nie wiem co to 1FA, czy 2FA, ale nie rozumiem dlaczego klient nie może stosować tego samego hasła (moje założenie - hasło nigdy nie wychodzi poza komputer klienta).
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Nie wiem co to 1FA, czy 2FA, ale nie rozumiem dlaczego klient nie może
stosować tego samego hasła (moje założenie - hasło nigdy nie wychodzi
poza komputer klienta).

To założenie wymaga odpowiedniego mechanizmu challenge - response.
Normalne strony WWW nie przewidują czegoś takiego - hasło musi im być
wysłane w całości (lub np. tylko niektóre znaki). Dopiero na serwerze
ew. liczone są jakieś tam skróty itp.

Teoretycznie dałoby się to robić po stronie klienta (np. w JS). Pewnie
nawet dałoby się to zrobić dobrze (tak, by nie użyć np. skrótu, który
pozwala na wielokrotne logowanie itp). Ale to w dalszym ciągu
pozostawałoby pod kontrolą strony WWW, wystarczyłaby modyfikacja kodu
strony.
--
Krzysztof Hałasa

W dniu 2020-06-04 o 22:07, Alf/red/ pisze:

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.

Nie wiem co to 2FA, ale uważam, że spełnienie mojego postulatu nie wymaga żadnego dodatkowego sprzętu.

System wysyła do komputera użytkownika swoją sól. Komputer użytkownika hashuje jego login+hasło+sól i to odsyła do systemu I tylko to system zna (czy zna login, czy nie - nie wnikam - ważne, że hasła nigdy nie widzi).
W czasie definiowania hasła to też komputer użytkownika ma sprawdzić, czy wpisane dwa razy jest takie samo i czy spełnia ewentualne dodatkowe wymagania narzucone aby zapobiec stosowaniu haseł typu 1234. Po sprawdzeniu liczy hash i tylko to trafia do serwera.

Banki u nas poszły we własne apki, i chyba żeście o tym zapomnieli bo wszyscy dodali swoje komputery jako zaufane.

Nie prawda. Nie wszyscy. Co najmniej jedna osoba (ja) nie dodała żadnego komputera jako zaufanego.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

System wysyła do komputera użytkownika swoją sól. Komputer użytkownika
hashuje jego login+hasło+sól i to odsyła do systemu I tylko to system
zna (czy zna login, czy nie - nie wnikam - ważne, że hasła nigdy nie
widzi).

Czyli w gruncie rzeczy ten hash jest hasłem, które wystarcza do
zalogowania. Innymi słowy, znów przechowujesz niezaszyfrowane hasło
w bazie serwera, każdy kto je przejmie itd.
--
Krzysztof Hałasa

Dnia Sun, 07 Jun 2020 17:07:36 +0200, Krzysztof Halasa napisał(a):

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

System wysyła do komputera użytkownika swoją sól. Komputer użytkownika
hashuje jego login+hasło+sól i to odsyła do systemu I tylko to system
zna (czy zna login, czy nie - nie wnikam - ważne, że hasła nigdy nie
widzi).

Czyli w gruncie rzeczy ten hash jest hasłem, które wystarcza do
zalogowania. Innymi słowy, znów przechowujesz niezaszyfrowane hasło
w bazie serwera, każdy kto je przejmie itd.

Ale - oryginalne haslo jest nieznane. Czyli inne konta pozostaja bezpieczne ...

J.

"J.F." <jfox_xnospamx@poczta.onet.pl> writes:

Czyli w gruncie rzeczy ten hash jest hasłem, które wystarcza do
zalogowania. Innymi słowy, znów przechowujesz niezaszyfrowane hasło
w bazie serwera, każdy kto je przejmie itd.

Ale - oryginalne haslo jest nieznane. Czyli inne konta pozostaja bezpieczne ...

Ale to bez znaczenia, bo nie używamy tych samych haseł w różnych
miejscach :-)
--
Krzysztof Hałasa

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

Ale to bez znaczenia, bo nie używamy tych samych haseł w różnych
miejscach :-)

Kto nie używa ten nie używa :)

W tej gałęzi wątku twierdzę, że powinniśmy móc używać tych samych haseł.
Jeśli komputery mogą nam to załatwić to powinno to (dla ogólnego bezpieczeństwa) być tak zrobione. Najlepiej 'od zawsze'.
Nie widzę uzasadnienia dlaczego nie jest.

Chyba, że jest jakiś problem powodujący, że tak tego nie można zorganizować, ale na razie nie spotkałem takiej informacji (przekonującej).

Moje założenie, że hasło jest hashowane w komputerze użytkownika, chyba wzięło się z lektury tej jednej książki. Z niej chyba wynikało, że tak to musi być i ja to przyjąłem jako pewnik.

Pamiętam opisywany tam przykład błędu w oprogramowaniu. Ktoś prawidłowo wydłużył i posolił hasło, ale aby użytkownik nie musiał czekać około 1s aby się dowiedzieć, że się pomylił w haśle to programista zrobił sobie tabelkę CRC32 haseł użytkowników i najpierw sprawdzał to CRC.
W ciągu sekundy (na zwykłym PC) daje się wydłużyć hasło o około 20 bitów, a tym zabiegiem skrócił je o 32 bity.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

W tej gałęzi wątku twierdzę, że powinniśmy móc używać tych samych haseł.
Jeśli komputery mogą nam to załatwić to powinno to (dla ogólnego
bezpieczeństwa) być tak zrobione. Najlepiej 'od zawsze'.
Nie widzę uzasadnienia dlaczego nie jest.

Napisałem - dlatego, że HTTPS nie przewiduje takiego mechanizmu.
Dlatego, że obecnie musiałoby to być zrobione w JS, a do tego nie można
mieć zaufania. Poza tym, gdyby ktoś chciał to zrobić (w ogóle takie
rzeczy występują, tylko że nie w HTTPS), to należałoby to zrobić lepiej.

Moje założenie, że hasło jest hashowane w komputerze użytkownika,
chyba wzięło się z lektury tej jednej książki. Z niej chyba wynikało,
że tak to musi być i ja to przyjąłem jako pewnik.

Czy ja dobrze kojarzę, że ta książka to "Applied Crypto" Schneiera?
Naprawdę coś takiego tam napisał? W którym miejscu?

Pamiętam opisywany tam przykład błędu w oprogramowaniu. Ktoś
prawidłowo wydłużył i posolił hasło, ale aby użytkownik nie musiał
czekać około 1s aby się dowiedzieć, że się pomylił w haśle to
programista zrobił sobie tabelkę CRC32 haseł użytkowników i najpierw
sprawdzał to CRC.
W ciągu sekundy (na zwykłym PC) daje się wydłużyć hasło o około 20
bitów, a tym zabiegiem skrócił je o 32 bity.

"Wydłużyć" to IMHO nie jest najszczęśliwsze sformułowania. Dodatkowo, ta
np. "1s" jest korzystna, by trudniej było złamać słabe hasło - zobacz
np. PBKDF2.
--
Krzysztof Hałasa

W dniu 2020-06-08 o 16:33, Krzysztof Halasa pisze:

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

W tej gałęzi wątku twierdzę, że powinniśmy móc używać tych samych haseł.
Jeśli komputery mogą nam to załatwić to powinno to (dla ogólnego
bezpieczeństwa) być tak zrobione. Najlepiej 'od zawsze'.
Nie widzę uzasadnienia dlaczego nie jest.

Napisałem - dlatego, że HTTPS nie przewiduje takiego mechanizmu.
Dlatego, że obecnie musiałoby to być zrobione w JS, a do tego nie można
mieć zaufania. Poza tym, gdyby ktoś chciał to zrobić (w ogóle takie
rzeczy występują, tylko że nie w HTTPS), to należałoby to zrobić lepiej.

To są argumenty dlaczego nie zrobiono.
Mi chodzi o to czy są jakieś argumenty mówiące dlaczego 'nie da się zrobić'.

Moje założenie, że hasło jest hashowane w komputerze użytkownika,
chyba wzięło się z lektury tej jednej książki. Z niej chyba wynikało,
że tak to musi być i ja to przyjąłem jako pewnik.

Czy ja dobrze kojarzę, że ta książka to "Applied Crypto" Schneiera?

Nie to 'Practical Cryptography' Ferguson, Schneier.

Naprawdę coś takiego tam napisał? W którym miejscu?

Jestem prawie pewien (ale nie mam czasu szukać), że gdy omawiali potrzebny na wydłużenie czas to właśnie pojawiła się kwestia wydajności komputera użytkownika a nie serwera. I była chyba mowa o przyjęciu rozwiązania skalowalnego w tym sensie, że wraz z przyspieszaniem komputerów użytkowników należy zwiększać wydłużenie tak, aby czas był zawsze maksymalny akceptowalny przez użytkownika.

W ciągu sekundy (na zwykłym PC) daje się wydłużyć hasło o około 20
bitów, a tym zabiegiem skrócił je o 32 bity.

"Wydłużyć" to IMHO nie jest najszczęśliwsze sformułowania.

Mi to się z niczym nie kłóci. Trzeba tylko rozumieć, że 8 znakowe hasło przeliczone przez SHA512 nie jest wydłużone do 512 bitów a zostało tylko wydłużone o 1 bit. A przeliczone milion razy jest wydłużone o około 20 bitów.

  Dodatkowo, ta

np. "1s" jest korzystna, by trudniej było złamać słabe hasło - zobacz
np. PBKDF2.

Na pierwszy rzut oka wygląda mi to po prostu na wydłużenie hasła.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

To są argumenty dlaczego nie zrobiono.
Mi chodzi o to czy są jakieś argumenty mówiące dlaczego 'nie da się zrobić'.

Różne rzeczy da się zrobić, ale jeśli nie wystarcza nam TLS, to zamiast
robić takie solone skróty, lepiej użyć zwykłego podpisu asymetrycznego.
Wymagamy wtedy mniej-więcej tyle samo wiedzy od klienta (no niestety),
ale uzyskujemy dużo więcej - np. niezaprzeczalność złożenia zlecenia.

Jestem prawie pewien (ale nie mam czasu szukać), że gdy omawiali
potrzebny na wydłużenie czas to właśnie pojawiła się kwestia
wydajności komputera użytkownika a nie serwera. I była chyba mowa o
przyjęciu rozwiązania skalowalnego w tym sensie, że wraz z
przyspieszaniem komputerów użytkowników należy zwiększać wydłużenie
tak, aby czas był zawsze maksymalny akceptowalny przez użytkownika.

A więc chodzi o coś w stylu PBKDF2. Stosuje się to głównie tam, gdzie
w ogóle nie ma żadnych serwerów, a musimy mieć klucz o znacznej
długości. Standardowy przykład to szyfrowanie dysków. To jest kompromis.
Każde "prawdziwe" rozwiązanie kryptograficzne będzie lepsze.

W przypadku serwerów wcale nie zależy nam na tym, by policzenie takiej
funkcji trwało długo. Przeciwnie, serwer ma obsłużyć jak najwięcej zadań
(w tym także jak najwięcej sprawdzań hasła). Owszem, możemy sztucznie
zwiększyć czas wykonania procedury, by trudniej było nas atakować - ale
to nie ma pochłaniać czasu CPU. Jeśli włamywacz uzyskał dostęp do haseł
(nawet zaszyfrowanych) - to jest to klęska.

Mi to się z niczym nie kłóci. Trzeba tylko rozumieć, że 8 znakowe
hasło przeliczone przez SHA512 nie jest wydłużone do 512 bitów a
zostało tylko wydłużone o 1 bit. A przeliczone milion razy jest
wydłużone o około 20 bitów.

W moim przekonaniu ono nie zostało w ogóle wydłużone, bo liczba
możliwych kombinacji się nie zmieniła. Tylko policzenie tego trwa
dłużej, ale na zbyt słabe hasła żadne takie wydłużanie nie pomoże.
Różnica między sprzętem usera i atakującego (być może w przyszłości)
definiuje jakie to są te "zbyt słabe" hasła.
--
Krzysztof Hałasa

W dniu 2020-06-08 o 21:12, Krzysztof Halasa pisze:

Różne rzeczy da się zrobić, ale jeśli nie wystarcza nam TLS, to zamiast
robić takie solone skróty, lepiej użyć zwykłego podpisu asymetrycznego.
Wymagamy wtedy mniej-więcej tyle samo wiedzy od klienta (no niestety),
ale uzyskujemy dużo więcej - np. niezaprzeczalność złożenia zlecenia.

Osobiście uważam, że kiedyś się okaże że z tą niezaprzeczalnością to może nie tak do końca. Skoro zdarzają się kradzieże danych z na prawdę dobrze chronionych miejsc w sieci (nie mam na myśli sklepów w pl, tylko jakieś projekty militarne) to skąd pewność, że użytkownik faktycznie dobrze zabezpieczył swój klucz prywatny służący mu do podpisu.

A więc chodzi o coś w stylu PBKDF2. Stosuje się to głównie tam, gdzie
w ogóle nie ma żadnych serwerów, a musimy mieć klucz o znacznej
długości. Standardowy przykład to szyfrowanie dysków. To jest kompromis.
Każde "prawdziwe" rozwiązanie kryptograficzne będzie lepsze.

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.

W przypadku serwerów wcale nie zależy nam na tym, by policzenie takiej
funkcji trwało długo. Przeciwnie, serwer ma obsłużyć jak najwięcej zadań
(w tym także jak najwięcej sprawdzań hasła). Owszem, możemy sztucznie
zwiększyć czas wykonania procedury, by trudniej było nas atakować - ale
to nie ma pochłaniać czasu CPU. Jeśli włamywacz uzyskał dostęp do haseł
(nawet zaszyfrowanych) - to jest to klęska.

Między innymi dlatego wydłużanie hasła powinno być robione na komputerze użytkownika - nie zabiera czasu CPU serwera.

Mi to się z niczym nie kłóci. Trzeba tylko rozumieć, że 8 znakowe
hasło przeliczone przez SHA512 nie jest wydłużone do 512 bitów a
zostało tylko wydłużone o 1 bit. A przeliczone milion razy jest
wydłużone o około 20 bitów.

W moim przekonaniu ono nie zostało w ogóle wydłużone, bo liczba
możliwych kombinacji się nie zmieniła. Tylko policzenie tego trwa
dłużej, ale na zbyt słabe hasła żadne takie wydłużanie nie pomoże.

Kluczem jest definicja długości hasła. Ich definicją długości hasła (i ja to po prostu przyjąłem bo tylko to jedno źródło znam i myślałem, że to jest powszechnie stosowana definicja) jest liczba operacji kryptograficznych które musi wykonać atakujący aby sprawdzić całą przestrzeń haseł (z uwzględnieniem wiedzy słownikowej o hasłach).
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.
Hasło 8 znakowe, mimo, że znaki są kodowane na 8 bitach nie ma długości 64 bitów. Ma ono długość około 40 bitów (5 bitów na znak).
Wydaje się mało, bo przecież same duże, małe litery i cyfry to więcej jak 32 znaki, ale w hasłach występują korelacje między kolejnymi znakami (zależne też od tego jakim językiem posługuje się autor hasła). Na przykład - jak hasło składa się z dużych liter i cyfr to znacznie bardziej prawdopodobne jest, że cyfry wystąpią w zwartej grupie a nie rozstrzelone losowo między literami (przy takim założeniu kilka kolejnych bajtów ma tylko jedną z 10 wartości).
Dlatego hasło 8 znakowe wymaga około 2^40 sprawdzeń - czyli ma 40 bitów długości. Oczywiście to jest tylko szacunek.
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.

Różnica między sprzętem usera i atakującego (być może w przyszłości)
definiuje jakie to są te "zbyt słabe" hasła.

Jakakolwiek by nie była przewaga sprzętu atakującego, jeśli poświęcimy 1s czasu usera przy każdym logowaniu to zwiększymy ilość pracy atakującego milion razy. Czy to wystarczy aby odechciało mu się ataku. Zapewne zależy, ale na pewno zwiększy koszt ataku.

Solenie ma na celu uniemożliwienie jednoczesnego ataku na wiele systemów. Bez soli atakujący musiałby wykonać ten milion przeliczeń tylko raz dla danego hasła (lub + user) i potem mógłby sprawdzać wynik w wielu systemach, a z solą (jawną) musi to przeliczenie wykonać dla każdego systemu osobno.

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.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Osobiście uważam, że kiedyś się okaże że z tą niezaprzeczalnością to
może nie tak do końca. Skoro zdarzają się kradzieże danych z na prawdę
dobrze chronionych miejsc w sieci (nie mam na myśli sklepów w pl,
tylko jakieś projekty militarne) to skąd pewność, że użytkownik
faktycznie dobrze zabezpieczył swój klucz prywatny służący mu do
podpisu.

To bez znaczenia - chodzi o to, że piłeczka jest wtedy po stronie
klienta. Równie dobrze mógłby podpisać dokument po pijaku.

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ć.
Albo tylko tak teoretycznie, co by było gdyby user koniecznie chciał
stosować to samo hasło wszędzie i jak to zrobić? 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.

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.

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.

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?

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"?

No i tak, jak napisałem - może lepiej po prostu zastosować podpis
elektroniczny (niekoniecznie dokładnie w obecnej "kwalifikowanej"
postaci)? To załatwia dużo więcej, można też naprawdę mieć to samo hasło
(albo w ogóle żadne, zależnie od warunków). Czymś pośrednim są wszelkie
"notatniki haseł".
--
Krzysztof Hałasa

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.

Piotr Gałka <piotr.galka@cutthismicromade.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

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.

Piotr Gałka <piotr.galka@cutthismicromade.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

W dniu 2020-06-13 o 15:06, Krzysztof Halasa pisze:

Piotr Gałka <piotr.galka@cutthismicromade.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.

Piotr Gałka <piotr.galka@cutthismicromade.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

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.

Piotr Gałka <piotr.galka@cutthismicromade.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

W dniu 2020-06-15 o 17:03, Krzysztof Halasa pisze:

Piotr Gałka <piotr.galka@cutthismicromade.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.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Tysiące zamówień z jednego konta - na pewno nie wyślą tylko nabiorą
podejrzeń.

Myślałem o rozumnych próbach - może nie o jakichś bardzo inteligentnych,
ale w ogóle rozumnych :-)

Tysiące nowych kont (do każdego inny mail) i zamówienie z każdego
konta - też podejrzane.

Co w tym podejrzanego? Przecież dokładnie tak się normalnie robi.
Ale po co się tak męczyć - wiele (większość?) sklepów umożliwia zakupy
bez żadnych kont. Potrzebny jest tylko email.
Zastanów się - łatwiej założyć 1000 adresów email czy uzyskać dostęp
do 1000 zacryptowanych (choćby) haseł, złamać je itd.? I wszystko po to,
by zamówić jakąś lewiznę, która nam osobiście nic nie da, poza
ew. zaszkodzeniu konkurencji (czego jednak nie da się odkryć)?

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ć.

Nikt sobie też w domu nie robi szyfrowania dysków, nie ustawia lokalnego
hasła dostępu do komputera? "Polimeryzowałbym".

Ja nie mam takiej wiedzy, abym mógł cokolwiek w ciemno zakładać więc
staram się nic nie zakładać.

Ale jednak cały czas zakładasz jakiś model (akurat) dostępu do serwisów
sieciowych, model teoretyczny, i nie rozumiesz, że to tak nigdy nie
działało, ani dlaczego nie działało. Ale powinno.
Musisz się zdecydować.

Ja akurat przypadkowo wiem jakie dane są przez co i jak przechowywane,
wiem jak mogą najprościej wycieknąć, i wiem które z nich są istotne
(a nawet to napisałem). I co? I nic. Bo w książce 20 lat temu Schneier
z jakimś drugim facetem, o którym chyba nie słyszałem (skąd wiemy kto
akurat był autorem tego fragmentu?), być może napisał to, co w sposób
ewidentny się jednak nie sprawdziło (od tamtego czasu upłynęło już sporo
czasu, więc naprawdę łatwo ocenić).

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).

IOW, należy stosować różne hasła. No chyba że chcesz dostawać
niezamawiane przesyłki ze sklepów czy coś tam, to ja już nie wiem.

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

Ale to, że komputer stoi w bezpiecznym miejscu nie oznacza, że sam jest
bezpiecznym miejscem dla np. plików. Choć oczywiście może być też tak.

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.

Nigdy nie ma 100% bezpieczeństwa, to oczywiste. W kontekście logowania
do banków i sklepów takie urządzenia są jednak IMHO wystarczająco
bezpieczne, zwłaszcza jeśli się ich nie nosi przy sobie bez sensu.

co nie jest do końca prawdą bo
odczyt analogowy pozwala podobno stwierdzić ślad poprzedniego zapisu).

Chciałbym zobaczyć kogoś, kto to odczyta.
Takie rzeczy to dało się robić w czasach dysków MFM, owszem. Ale nie
teraz.

Owszem, da się np. rozpuścić obudowę scalaka i podsłuchać dane na jego
wewnętrznych szynach (nawet w scalakach, o których producent pisze, że
są przed tym zabezpieczone). Tak. Ale resztkowe ładunki we flashu -
nawet nie tylko takim przechowywanym w bezpiecznym miejscu - przesada.

Czy ekranu nie widzimy, czy widzimy okienko logowania na którym w
miejscu hasła pojawiają się gwiazdki to wychodzi na to samo.

Nie wychodzi w żaden sposób. Jeśli nie masz dostępu do okienka, to jak
wyciągniesz dane z używanej właśnie karty?
No chyba że jakoś zmusisz komputer, by zrobił coś innego niż powinien.

Istotne
jest czy dane są na jakimś etapie jawne i czy można się w to miejsce
wciąć.

Co to są "dane jawne"? Jawne dla kogo?
--
Krzysztof Hałasa

W dniu 2020-06-16 o 16:37, Krzysztof Halasa pisze:

I wszystko po to,
by zamówić jakąś lewiznę, która nam osobiście nic nie da, poza
ew. zaszkodzeniu konkurencji (czego jednak nie da się odkryć)?

Wiem, że cała ta koncepcja to szukanie problemów na siłę, ale to było jedyne skojarzenie jakie mi przyszło do głowy na temat co złego w tym jakby ktoś się mógł do sklepu zalogować na nie swoje konto. Dalej ten wątek to tylko konsekwencja tego skojarzenia.

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ć.

Nikt sobie też w domu nie robi szyfrowania dysków, nie ustawia lokalnego
hasła dostępu do komputera? "Polimeryzowałbym".

Nieporozumienie polega na tym, że ja pisałem o stosowaniu wydłużania w każdym 'systemie haseł'. Przez użycie słowa 'system' rozumiałem z definicji dużą liczbę użytkowników i ich haseł. Dlatego nie rozumiałem jak się do tego ma pojęcie system domowy. Teraz rozumiem, że piszesz, że w przypadku pojedynczego hasła stosowanego do czegoś w domu wydłużanie mogło by mieć (ewentualnie) sens.
Jak ktoś sobie w domu coś takiego robi to jest to raczej świadomy użytkownik i dobierze odpowiednio dobre hasło więc akurat w tym przypadku ja nie dostrzegałem istotnej potrzeby wydłużania.
Obowiązkowość stosowania wydłużania rozumiałem jako pewien sposób zapobiegania problemom powodowanym przez użytkowników nad których zachowaniem nie do końca panujemy.

Ja nie mam takiej wiedzy, abym mógł cokolwiek w ciemno zakładać więc
staram się nic nie zakładać.

Ale jednak cały czas zakładasz jakiś model (akurat) dostępu do serwisów
sieciowych, model teoretyczny, i nie rozumiesz, że to tak nigdy nie
działało, ani dlaczego nie działało. Ale powinno.
Musisz się zdecydować.

Nie rozumiem jaki model według Ciebie zakładam i że tak nigdy nie działało. Mi się wydawało, że o dostępie do systemów (przez użytkowników) zakładam jedynie, że ktoś kto się loguje wpisuje id. usera i hasło i nic innego chyba nie zakładam.
Ale darujmy sobie - nie musisz mnie edukować jak to jest i gdzie się mylę.

Ja akurat przypadkowo wiem jakie dane są przez co i jak przechowywane,
wiem jak mogą najprościej wycieknąć, i wiem które z nich są istotne
(a nawet to napisałem). I co? I nic.

Nie całkiem nic. Trochę do mnie dotarło :)

Bo w książce 20 lat temu Schneier z jakimś drugim facetem, o którym chyba nie słyszałem (skąd wiemy kto
akurat był autorem tego fragmentu?), być może napisał to, co w sposób
ewidentny się jednak nie sprawdziło (od tamtego czasu upłynęło już sporo
czasu, więc naprawdę łatwo ocenić).

Na temat tego drugiego faceta - oni startowali razem w konkursie na AES-a i byli ze swoim algorytmem wśród finałowej chyba czwórki. O ile pamiętam omawiają w książce wszystkie te cztery algorytmy, ale bez wnikania w szczegóły na poziomie bitów tylko tak bardziej odgórnie w sensie filozofii.
Swój algorytm (nie pamiętam nazwy) uważają, za lepszy (w sensie bezpieczeństwa) od ostatecznie wybranego. Przegrali wydajnością - ich liczył się chyba 3 razy wolniej.
Do AESa mają zastrzeżenie, że bazuje na jakiejś algebrze o której nie można być całkiem pewnym, czy kiedyś nie znajdzie się jakiś genialny matematyk, który rozwiąże problem ataku na algorytm od strony matematycznej.

IOW, należy stosować różne hasła. No chyba że chcesz dostawać
niezamawiane przesyłki ze sklepów czy coś tam, to ja już nie wiem.

Nie kwestionuję co należy, jedynie podejrzewam (na podstawie mojego zachowania i informacji prasowych po wyciekach), że praktyka jest inna.
Człowiek podświadomie zakłada, że inni korzystają ze wszystkiego tak jak on. Jeśli ja zamawiając towar nigdy nie wybieram droższej dostawy 'za zaliczeniem' to zakładam, że tak to działa. Więc jak ktoś będzie próbował coś dla mnie zamówić to za to zapłaci z jego konta (tak to wygląda w wyobraźni bez zastanowienia).
Nie od razu sobie zawsze kojarzę, że istnieje możliwość zamówienia bez zapłacenia. Nie wiem jak to działa. Wydaje mi się, że w takim przypadku to sklepy chyba wysyłają mail i oczekują potwierdzenia. Bez tego chyba nie wyślą. Ale być może znów coś zakładam tylko dlatego, że tak mi się wydaje.

Nigdy nie ma 100% bezpieczeństwa, to oczywiste. W kontekście logowania
do banków i sklepów takie urządzenia są jednak IMHO wystarczająco
bezpieczne, zwłaszcza jeśli się ich nie nosi przy sobie bez sensu.

Czekaj, czekaj.
Najpierw myślałem, że to jest program do przechowywania haseł. Potem, że to jest małe urządzenie, które może na swoim ekranie pokazać Ci jedno z pamiętanych haseł. Teraz pomyślałem, że to się podłącza pod USB i ono wyrzuca odpowiednie hasło tak jakby ktoś je wklepywał na klawiaturze.
Ale zaraz pojawiła się nowa koncepcja....
Czy przeglądarki mają w sobie coś, że jak system (np. banku) mówi im - otwieramy okienko logowania to one wiedząc, że jest takie urządzenie podłączone zamiast otwierać okienko logowania realizują połączenie między systemem banku a tym urządzeniem (to byłoby bezpieczne, że przeglądarka nie ma wglądu w sesję między bankiem a tym urządzeniem).
Coś takiego istnieje i wszystkie systemy bankowe i sklepowe są przygotowane na takie połączenie?

co nie jest do końca prawdą bo
odczyt analogowy pozwala podobno stwierdzić ślad poprzedniego zapisu).

Chciałbym zobaczyć kogoś, kto to odczyta.
Takie rzeczy to dało się robić w czasach dysków MFM, owszem. Ale nie
teraz.

Owszem, da się np. rozpuścić obudowę scalaka i podsłuchać dane na jego
wewnętrznych szynach (nawet w scalakach, o których producent pisze, że
są przed tym zabezpieczone). Tak. Ale resztkowe ładunki we flashu -
nawet nie tylko takim przechowywanym w bezpiecznym miejscu - przesada.

Czytałem kiedyś coś, z czego wynikało, że to jest mierzalne. Czyli w skasowanym flash podłączając się analogowo da się z dużym prawdopodobieństwem stwierdzić co było przed kasowaniem.
Od wszystkich tych urządzeń oczekuje się szybkości i jeszcze raz szybkości. Więc optymalizuje się czas kasowania/zapisu.
Takie dobicie bitu, aby czy wcześniej był zerem, czy jedynką był teraz dokładnie taki sam wymagało by być może 4 razy dłuższego czasu więc się tego nie robi.
Nie dałbym głowy, czy przypadkiem wszystkie karty flash nie mają jakiegoś ukrytego trybu dostępu analogowego do zawartości. Realizacja byłaby banalna - wystarczy pominąć jakiś przerzutnik odczytujący stan.

Czy ekranu nie widzimy, czy widzimy okienko logowania na którym w
miejscu hasła pojawiają się gwiazdki to wychodzi na to samo.

Nie wychodzi w żaden sposób. Jeśli nie masz dostępu do okienka, to jak
wyciągniesz dane z używanej właśnie karty?

Co rozumiesz przez brak dostępu do okienka?

Jeśli przeglądarka na komputerze jest w stanie dowiedzieć się od urządzenia o hasło to i jakiś inny program powinien być w stanie się dowiedzieć.
Sytuacja będzie inna jeśli przekazywanie hasła będzie polegało na utworzeniu sesji między tym urządzeniem a serwerem banku i przeglądarka staje się tylko pośrednikiem nie mającym dostępu do przesyłanych danych.

No chyba że jakoś zmusisz komputer, by zrobił coś innego niż powinien.

Istotne
jest czy dane są na jakimś etapie jawne i czy można się w to miejsce
wciąć.

Co to są "dane jawne"? Jawne dla kogo?

Może złych słów używam.
Hasło zaszyfrowane i przechowywane w karcie czy urządzeniu to dane tajne.
To samo hasło odszyfrowane (w celu wpisania w okienko logowania) to dane jawne.

Jeśli jakieś urządzenie miałoby (udając klawiaturę USB) wypełnić pole 'Hasło' w okienku logowania to znaczy, że ukryte w tym urządzeniu hasło zostało w nim odszyfrowane (z tajnego staje się jawne) i wysłane przez USB. A to połączenie USB jest tym miejscem, gdzie można się wciąć - nie koniecznie fizycznie włączając się w kabel ale np. wcinając się gdzieś w driver USB. Znów piszę o czymś, o czym mam blade pojęcie, ale jestem pewien, że są ludzie (i wirusy) które potrafią takie rzeczy zrobić.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Jak ktoś sobie w domu coś takiego robi to jest to raczej świadomy
użytkownik i dobierze odpowiednio dobre hasło więc akurat w tym
przypadku ja nie dostrzegałem istotnej potrzeby wydłużania.

To jest błędne założenie. Jak ktoś sobie w domu coś takiego robi, to
pomijając to, że pewnie wie o szyfrowaniu dysku (a może nawet ma taką
świadomą potrzebę), w większości przypadków nie ma wiedzy dotyczącej
kryptografii, haseł, możliwości ataków itd. Dlatego domyślne ustawienia
systemu muszą być sensowne, i dlatego właśnie domyślnie stosuje się tam
takie algorytmy.

To jest tak jak z tym specjalistą i sprzątaczką - ten pierwszy może
używać "zwykłego" hasła, bo wie jakie jest dobre a jakie nie (może
z pewną przesadą). Sprzątaczka ma 4-cyfrowy PIN i "odcisk palca", bo
chociaż te zabezpieczenia znacznie łatwiej złamać, to od niej nie można
wymagać niczego więcej.

Obowiązkowość stosowania wydłużania rozumiałem jako pewien sposób
zapobiegania problemom powodowanym przez użytkowników nad których
zachowaniem nie do końca panujemy.

W każdym razie takich funkcji nie stosuje się po stronie usera w WWW.
Jest też więcej powodów by stosować różne hasła w różnych miejscach.
Nawet dzieci uczą się o tym w szkole.

Do AESa mają zastrzeżenie, że bazuje na jakiejś algebrze o której nie
można być całkiem pewnym, czy kiedyś nie znajdzie się jakiś genialny
matematyk, który rozwiąże problem ataku na algorytm od strony
matematycznej.

BTW o każdym algorytmie innym niż XOR można coś takiego powiedzieć.
Jedynie XOR daje pewność (co do samego algorytmu, bo niekoniecznie
w kwestii warunków jego zastosowania).

Człowiek podświadomie zakłada, że inni korzystają ze wszystkiego tak
jak on.

O tak, to zauważyłem. W ogóle chyba większość ludzi zakłada, że wszyscy
robią wszystko tak samo jak oni.

Najpierw myślałem, że to jest program do przechowywania haseł. Potem,
że to jest małe urządzenie, które może na swoim ekranie pokazać Ci
jedno z pamiętanych haseł. Teraz pomyślałem, że to się podłącza pod
USB i ono wyrzuca odpowiednie hasło tak jakby ktoś je wklepywał na
klawiaturze.

Zwykle jest właśnie tak - trudno się przepisuje długie hasła.

Czy przeglądarki mają w sobie coś, że jak system (np. banku) mówi im - otwieramy okienko logowania to one wiedząc, że jest takie urządzenie
podłączone zamiast otwierać okienko logowania realizują połączenie
między systemem banku a tym urządzeniem (to byłoby bezpieczne, że
przeglądarka nie ma wglądu w sesję między bankiem a tym urządzeniem).
Coś takiego istnieje i wszystkie systemy bankowe i sklepowe są
przygotowane na takie połączenie?

Nie, notatnik haseł przechowuje tylko hasła. Przeglądarka może go
zapytać o hasło do konkretnego serwisu (może być potrzebny odpowiedni
plugin do przeglądarki), a ten - po uzyskaniu akceptacji usera - może
odesłać hasło, które przeglądarka następnie wyśle np. bankowi.
Gdyby notatnik zajmował się całą sesją, to byłby przeglądarką, ze
wszystkimi wadami (i zaletami) tego rozwiązania.

Czytałem kiedyś coś, z czego wynikało, że to jest mierzalne. Czyli w
skasowanym flash podłączając się analogowo da się z dużym
prawdopodobieństwem stwierdzić co było przed kasowaniem.

Pytanie tylko, czy ktoś potrafi to pokazać w sposób powtarzalny? Nie
słyszałem, ale oczywiście kto wie.

Nie dałbym głowy, czy przypadkiem wszystkie karty flash nie mają
jakiegoś ukrytego trybu dostępu analogowego do zawartości. Realizacja
byłaby banalna - wystarczy pominąć jakiś przerzutnik odczytujący stan.

Obawiam się że wątpię.
W kartach flash (podobnie jak w dyskach) trudno często odczytać aktualną
zawartość (odczytuje się wartość bardziej prawdopodobną, używa się kodów
korekcyjnych). Skasowaną zawartością chwilowo nie będę się przejmował
:-)

Jeśli przeglądarka na komputerze jest w stanie dowiedzieć się od
urządzenia o hasło to i jakiś inny program powinien być w stanie się
dowiedzieć.

Może tak, może nie, ale przecież atakujący nie może sobie wedle woli
uruchamiać wszystkiego na tym komputerze. Jeśli może, to istotnie
w takich okolicznościach jest już "pozamiatane".

Może złych słów używam.
Hasło zaszyfrowane i przechowywane w karcie czy urządzeniu to dane tajne.
To samo hasło odszyfrowane (w celu wpisania w okienko logowania) to
dane jawne.

No ale ono nie jest jawne, nie jest po prostu zaszyfrowane. Tak jak
hasło na kartce w sejfie: nie jest normalnie jawne.

Jeśli jakieś urządzenie miałoby (udając klawiaturę USB) wypełnić pole
'Hasło' w okienku logowania to znaczy, że ukryte w tym urządzeniu
hasło zostało w nim odszyfrowane (z tajnego staje się jawne) i wysłane
przez USB. A to połączenie USB jest tym miejscem, gdzie można się
wciąć - nie koniecznie fizycznie włączając się w kabel ale np.
wcinając się gdzieś w driver USB. Znów piszę o czymś, o czym mam blade
pojęcie, ale jestem pewien, że są ludzie (i wirusy) które potrafią
takie rzeczy zrobić.

No pewnie że można tak zrobić. Jest wiele miejsc w komputerze, z których
można uzyskać hasła. Podobnie, mając kontrolę nad komputerem, możemy
następnie przejąć sesję takiego usera itd. Notatniki haseł nie są
panaceum na wszystkie problemy - one służą tylko do zapamiętywania
haseł, by user nie musiał sam ich pamiętać. Hasła może będą lepszej
jakości i może nieco łatwiej będzie zrobić OTP, ale bez (jakiegoś)
bezpiecznego komputera nie można mówić o bezpieczeństwie.
--
Krzysztof Hałasa

W dniu 2020-06-20 o 15:10, Krzysztof Halasa pisze:

Do AESa mają zastrzeżenie, że bazuje na jakiejś algebrze o której nie
można być całkiem pewnym, czy kiedyś nie znajdzie się jakiś genialny
matematyk, który rozwiąże problem ataku na algorytm od strony
matematycznej.

BTW o każdym algorytmie innym niż XOR można coś takiego powiedzieć.

Może nie powinienem mówić algebra tylko jakoś inaczej. Chodziło o to, że opis reguł działania jest czysto matematyczny. Nie ma tam żadnego udziału elementów nie opisanych matematycznie (jak S-Boxy w DES-ie). Jak jakiś problem jest prosto zapisany matematycznie to łatwiej podejrzewać, że znajdzie się jakieś matematyczne rozwiązanie, niż gdy pewne fragmenty działania opierają się na losowych danych (lub przynajmniej udających losowe). Nie umiem ogarnąć tego matematycznie, ale z tego, że do S-Boxów wprowadzono jakieś poprawki, które jak się po latach okazało zapobiegły złamaniu DESa metodami, które były wtedy jeszcze nie znane kryptografii cywilnej by wynikało, że nawet takie 'losowe' wstawki dają się ogarniać matematycznie. A może to dotyczyło jakichś innych -boxów.
Po prostu zbyt prosty opis algorytmu uznali, za jego potencjalną słabość.

Teraz pomyślałem, że to się podłącza pod
USB i ono wyrzuca odpowiednie hasło tak jakby ktoś je wklepywał na
klawiaturze.

Zwykle jest właśnie tak - trudno się przepisuje długie hasła.

To co piszesz dalej, że być może jakiś plugin oznacza, że trochę inaczej rozumiemy swoje wypowiedzi. Dla mnie 'jakby ktoś wklepywał na klawiaturze' oznacza, że komputer nie potrafi (poza ustaleniem jakiegoś identyfikatora) rozróżnić źródła podrzucającego mu hasło od klawiatury marki "standardowa klawiatura USB".

Czy przeglądarki mają w sobie coś, że jak system (np. banku) mówi im -
otwieramy okienko logowania to one wiedząc, że jest takie urządzenie
podłączone zamiast otwierać okienko logowania realizują połączenie
między systemem banku a tym urządzeniem (to byłoby bezpieczne, że
przeglądarka nie ma wglądu w sesję między bankiem a tym urządzeniem).
Coś takiego istnieje i wszystkie systemy bankowe i sklepowe są
przygotowane na takie połączenie?

Nie, notatnik haseł przechowuje tylko hasła. Przeglądarka może go
zapytać o hasło do konkretnego serwisu (może być potrzebny odpowiedni
plugin do przeglądarki), a ten - po uzyskaniu akceptacji usera - może
odesłać hasło, które przeglądarka następnie wyśle np. bankowi.

Jeśli plugin to już transmisja hasła nie musi być udawaniem klawiatury i teoretycznie może być jakoś zabezpieczona. Tylko, że jeśli efektem końcowym jest wpisanie hasła w okienko edycyjne to ja to określiłem jako miejsce w którym dane (hasło) są jawne. Jakiś program śledzący powinien być w stanie to hasło wyczytać.

Gdyby notatnik zajmował się całą sesją, to byłby przeglądarką, ze
wszystkimi wadami (i zaletami) tego rozwiązania.

Nie całą sesją tylko dodatkową sesją utworzoną tylko w celu przekazania danych logowania.
Według mnie nie byłaby to przeglądarka.
Urządzenie od przeglądarki różniło by się przede wszystkim brakiem możliwości uruchamiania na nim jakiegokolwiek innego oprogramowania które w normalnym PC działając 'obok' przeglądarki ma potencjalną możliwość podglądnąć 'co się dzieje'.
Wydaje mi się, że jedyną możliwością bezpiecznego przekazania hasła przez taki notatnik do serwera jest utworzenie sesji między serwerem a notatnikiem.
Przekazywanie tego hasła jakiemukolwiek programowi działającemu na PC jest według mnie przekazaniem tego hasła do środowiska, które nie zapewnia bezpieczeństwa.

Czytałem kiedyś coś, z czego wynikało, że to jest mierzalne. Czyli w
skasowanym flash podłączając się analogowo da się z dużym
prawdopodobieństwem stwierdzić co było przed kasowaniem.

Pytanie tylko, czy ktoś potrafi to pokazać w sposób powtarzalny? Nie
słyszałem, ale oczywiście kto wie.

Przypuszczam, że potrafi. Jeśli nawet uzyskane w ten sposób dane nie mają 100% pewności, a 'jedynie' np. o każdym bicie wiemy że z prawdopodobieństwem 80% ma taką wartość jak nam się wydaje to choć nie znamy żadnego bitu 'na pewno' to jednak ta informacja na pewno ułatwi atakującemu (choć ja nie umiałbym tego wykorzystać).

Jeśli przeglądarka na komputerze jest w stanie dowiedzieć się od
urządzenia o hasło to i jakiś inny program powinien być w stanie się
dowiedzieć.

Może tak, może nie, ale przecież atakujący nie może sobie wedle woli
uruchamiać wszystkiego na tym komputerze. Jeśli może, to istotnie
w takich okolicznościach jest już "pozamiatane".

Ja uważam, że mając możliwość tworzenia sesji między notatnikiem a serwerem można by traktować komputer do którego podpięty jest notatnik jak całą resztę wrogiego środowiska. Z tym, że aby korzystać z przeglądarki na komputerze i notatniku do logowania i potwierdzania to notatnik musiałby pozwalać na zaprezentowanie użytkownikowi kluczowych informacji (to co przychodzi w sms z pinem) i ich potwierdzenie. Te kluczowe informacje nie mogłyby być przesyłane z przeglądarki tylko musiały być przesyłane z serwera w sesji.

No ale ono nie jest jawne, nie jest po prostu zaszyfrowane. Tak jak
hasło na kartce w sejfie: nie jest normalnie jawne.

Znów używamy nieco innego języka. Hasło na kartce mimo, że jest informacją tajną to na samej kartce jest zapisane w sposób jawny - jak ktoś wejdzie w jej posiadanie to już je zna.
Dlatego jak notatnik wyśle to hasło tak jakby to była klawiatura to ja przesłane tak dane nazwałem jawne bo dla każdego obserwującego ten strumień stają się one jawne.
Formalnie zapewne prawidłowo rzeczy nazywasz Ty.
Ja po prostu o krypto rozmawiam tylko z bratem i w naszym wewnętrznym 'slangu' dane zaszyfrowane są tajne, a dane nie zaszyfrowane (nawet jak to jest tajne hasło) są jawne. Osobny podział danych na tajne/jawne i zabezpieczone/nie zabezpieczone nie jest nam zazwyczaj potrzebny do tego abyśmy się rozumieli.

No pewnie że można tak zrobić. Jest wiele miejsc w komputerze, z których
można uzyskać hasła. Podobnie, mając kontrolę nad komputerem, możemy
następnie przejąć sesję takiego usera itd. Notatniki haseł nie są
panaceum na wszystkie problemy - one służą tylko do zapamiętywania
haseł, by user nie musiał sam ich pamiętać.

W tej rozmowie po raz pierwszy usłyszałem o notatnikach haseł i zakładałem, że być może to jest coś lepiej zrobione i stara się zrobić coś więcej niż tylko pomóc zapamiętać hasła.
Myślałem, że być może przeglądarki są dostosowane do tego, że bardziej wymagający użytkownicy stosują urządzenia, które mają im zapewnić znacznie wyższy poziom bezpieczeństwa.
Uważam, że uzupełniając komputer urządzeniem podłączonym pod USB, które miałoby maleńki wyświetlacz + czytnik kart (lub klawiaturę) dałoby się zrobić bankowanie niepodatnym na wirusy itp.
Jadąc dalej tym tropem to sesja mogłaby być nie między tym urządzeniem a serwerem a między kartą zbliżeniową a serwerem tylko karta powinna mieć wyświetlacz + co najmniej chyba 1 klawisz. Szczegóły trzeba by przemyśleć. Podłączany pod USB czytnik stawałby się też fragmentem wrogiej infrastruktury. Nadal uważałbym, że na komputerze jest przeglądarka a tutaj tylko 'potwierdzarka'.

Hasła może będą lepszej
jakości i może nieco łatwiej będzie zrobić OTP, ale bez (jakiegoś)
bezpiecznego komputera nie można mówić o bezpieczeństwie.

Wydaje mi się, że przeglądarka może chodzić na niebezpiecznym komputerze pod warunkiem, że mamy jakiś mały bezpieczny komputerek :)
P.G.

Użytkownik "Piotr Gałka"  napisał w wiadomości grup dyskusyjnych:rcq6ru$eav$1$PiotrGalka@news.chmurka.net...
W dniu 2020-06-20 o 15:10, Krzysztof Halasa pisze:

Do AESa mają zastrzeżenie, że bazuje na jakiejś algebrze o której nie
można być całkiem pewnym, czy kiedyś nie znajdzie się jakiś genialny
matematyk, który rozwiąże problem ataku na algorytm od strony
matematycznej.

BTW o każdym algorytmie innym niż XOR można coś takiego powiedzieć.

Może nie powinienem mówić algebra tylko jakoś inaczej. Chodziło o to, że opis reguł działania jest czysto matematyczny. Nie ma tam żadnego udziału elementów nie opisanych matematycznie (jak S-Boxy w DES-ie). Jak jakiś problem jest prosto zapisany matematycznie to łatwiej podejrzewać, że znajdzie się jakieś matematyczne rozwiązanie, niż gdy pewne fragmenty działania opierają się na losowych danych (lub przynajmniej udających losowe). Nie umiem ogarnąć tego matematycznie, ale z tego, że do S-Boxów

losowosc w kwestii S-Boxow to przesada.
Nietrywialne funkcje matematyczne.

wprowadzono jakieś poprawki, które jak się po latach okazało zapobiegły złamaniu DESa metodami, które były wtedy jeszcze nie znane kryptografii cywilnej by wynikało, że nawet takie 'losowe' wstawki dają się ogarniać matematycznie. A może to dotyczyło jakichś innych -boxów.
Po prostu zbyt prosty opis algorytmu uznali, za jego potencjalną słabość.

Taki RSA wezmy - opis prosty, na razie sie trzyma, ale jak sie znajdzie jakis genialny matematyk ... :-)

Teraz pomyślałem, że to się podłącza pod
USB i ono wyrzuca odpowiednie hasło tak jakby ktoś je wklepywał na
klawiaturze.

Zwykle jest właśnie tak - trudno się przepisuje długie hasła.

To co piszesz dalej, że być może jakiś plugin oznacza, że trochę inaczej rozumiemy swoje wypowiedzi. Dla mnie 'jakby ktoś wklepywał na klawiaturze' oznacza, że komputer nie potrafi (poza ustaleniem jakiegoś identyfikatora) rozróżnić źródła podrzucającego mu hasło od klawiatury marki "standardowa klawiatura USB".

I jak najbardziej ten kluczyk USB moze udawac klawiature i haslo wpisywac niby klawiszami.

No ale ono nie jest jawne, nie jest po prostu zaszyfrowane. Tak jak
hasło na kartce w sejfie: nie jest normalnie jawne.

Znów używamy nieco innego języka. Hasło na kartce mimo, że jest informacją tajną to na samej kartce jest zapisane w sposób jawny - jak ktoś wejdzie w jej posiadanie to już je zna.

No chyba, ze ktos sobie zapisze na kartce szyfrem - np od tylu :-)

Dlatego jak notatnik wyśle to hasło tak jakby to była klawiatura to ja przesłane tak dane nazwałem jawne bo dla każdego obserwującego ten strumień stają się one jawne.

I tu jest raczej kwestia konstrukcji systemu operacyjnego - na ile on umozliwia takie przechwycenie.
Skoro ma byc uniwersalny, to pewnie pozwala :-(

Hasła może będą lepszej
jakości i może nieco łatwiej będzie zrobić OTP, ale bez (jakiegoś)
bezpiecznego komputera nie można mówić o bezpieczeństwie.

Wydaje mi się, że przeglądarka może chodzić na niebezpiecznym komputerze pod warunkiem, że mamy jakiś mały bezpieczny komputerek :)

Moglaby, pod warunkiem, ze dopelnimy zabezpieczen.
Czyli np serwer bankowy przekaze do tego komputerka komplet informacji,
komputerek wyswietli "przelew na konto zdefiniowane nr xxxx kwota yyy".
A ty sprawdzisz przed przepisaniem/zatwierdzeniem.

Co sie laczy z transmisja danych do tego komputerka.
I tu jest kolejny problem - niezaleznym kanalem przez GSM, przez USB, moze QR-codem, albo np jakimis modemowymi dzwiekami z glosnika.
Czy miganiem ekranu. Kazde ma swoje wady.

Bo jak hacker moze zhackowac przegladarke czy komputer, to w nic co widac na ekranie wierzyc nie mozesz.

No a podlaczenie do USB czesto naraza ten maly komputerek, bo otwiera nowe mozliwosci.


J.

W dniu 2020-06-22 o 14:36, J.F. pisze:

Bo jak hacker moze zhackowac przegladarke czy komputer, to w nic co widac na ekranie wierzyc nie mozesz.

Ale możesz wierzyć na 99% po to, aby ułatwić obsługę, a przy potwierdzaniu dostajesz informacje dające Ci 100%.

No a podlaczenie do USB czesto naraza ten maly komputerek, bo otwiera nowe mozliwosci.

Z tym się nie zgadzam jeśli ten mały komputerek spełni kilka wymagań. Pierwszym będzie, że nie da się uruchomić w nim żadnego przysłanego kodu.
P.G.

Użytkownik "Piotr Gałka"  napisał w wiadomości grup dyskusyjnych:rcqeio$ion$1$PiotrGalka@news.chmurka.net...
W dniu 2020-06-22 o 14:36, J.F. pisze:

Bo jak hacker moze zhackowac przegladarke czy komputer, to w nic co widac na ekranie wierzyc nie mozesz.

Ale możesz wierzyć na 99% po to, aby ułatwić obsługę, a przy potwierdzaniu dostajesz informacje dające Ci 100%.

Tylko trzeba je jakos przeslac.

No a podlaczenie do USB czesto naraza ten maly komputerek, bo otwiera nowe mozliwosci.

Z tym się nie zgadzam jeśli ten mały komputerek spełni kilka wymagań. Pierwszym będzie, że nie da się uruchomić w nim żadnego przysłanego kodu.

Owszem, tylko rzeczywistosc skrzeczy i to zlacze USB ma czesto szeroki zakres mozliwosci.

Flash daje sie zapisac, debugger uruchomic, rejestry jakies wewnetrzne przestawic.
Oczywiscie nic nie stoi na przeszkodzie, aby zrobic bezpieczny ... tylko jaki naklad pracy bedzie do tego potrzebny ... i czy sami nie chcemy, zeby update programu dalo sie zrobic :-)

J.

W dniu 2020-06-22 o 16:43, J.F. pisze:

Oczywiscie nic nie stoi na przeszkodzie, aby zrobic bezpieczny ... tylko jaki naklad pracy bedzie do tego potrzebny ...

Banki na wodotryski na stronie wydają takie kwoty, że z tym nakładem pracy by sobie poradziły.


  i czy sami nie chcemy,

zeby update programu dalo sie zrobic :-)

Żeby było całkiem bezpieczne nie powinno się dać :)
Nieco mniej bezpieczne - update zabezpieczone podpisem z kluczem prywatnym banku.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Żeby było całkiem bezpieczne nie powinno się dać :)
Nieco mniej bezpieczne - update zabezpieczone podpisem z kluczem
prywatnym banku.

Zakładając chyba, że urządzenie byłoby własnością banku.
--
Krzysztof Hałasa

W dniu 2020-06-22 o 17:38, Krzysztof Halasa pisze:

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Żeby było całkiem bezpieczne nie powinno się dać :)
Nieco mniej bezpieczne - update zabezpieczone podpisem z kluczem
prywatnym banku.

Zakładając chyba, że urządzenie byłoby własnością banku.

No tak - wchodzę w ślepy zaułek.
Czyli żadnego upgrade.
Urządzenie działa jak fabryka dała, a nie jak dzisiaj, że w ramach przeglądu mogą Ci zupgradeować samochód i będzie spełniał normy, ale nie miał mocy :)
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Bo jak hacker moze zhackowac przegladarke czy komputer, to w nic co
widac na ekranie wierzyc nie mozesz.

Ale możesz wierzyć na 99% po to, aby ułatwić obsługę, a przy
potwierdzaniu dostajesz informacje dające Ci 100%.

I sprawdzasz np. numery kont itd.? Gdzie je sprawdzasz? Strona WWW
w przypadku ataku będzie "zainfekowana".

Nie chciałbym też, by raz na 100 razy dane o moich operacjach były
publikowane. Tak, wiem, że tu prawdopodobieństwo nieco inaczej działa.

No a podlaczenie do USB czesto naraza ten maly komputerek, bo
otwiera nowe mozliwosci.

Z tym się nie zgadzam jeśli ten mały komputerek spełni kilka wymagań.
Pierwszym będzie, że nie da się uruchomić w nim żadnego przysłanego
kodu.

To da się uzyskać z dość dobrą pewnością - dlatego te urządzenia mają
USB. Ale przenoszenie do nich dodatkowej funkcjonalności naraża nas na
nowe zagrożenia.
--
Krzysztof Hałasa

W dniu 2020-06-22 o 17:37, Krzysztof Halasa pisze:

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Bo jak hacker moze zhackowac przegladarke czy komputer, to w nic co
widac na ekranie wierzyc nie mozesz.

Ale możesz wierzyć na 99% po to, aby ułatwić obsługę, a przy
potwierdzaniu dostajesz informacje dające Ci 100%.

I sprawdzasz np. numery kont itd.? Gdzie je sprawdzasz? Strona WWW
w przypadku ataku będzie "zainfekowana".

Urządzenie zamieniało by przysłany do weryfikacji numer konta na zapamiętaną w nim nazwę konta, a jak nie zna numeru to wypisywało by numer (jakby miało wyświetlacz kolorowy to na czerwono).

Nie chciałbym też, by raz na 100 razy dane o moich operacjach były
publikowane. Tak, wiem, że tu prawdopodobieństwo nieco inaczej działa.

Nie zrozumiałem.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Nie chciałbym też, by raz na 100 razy dane o moich operacjach były
publikowane. Tak, wiem, że tu prawdopodobieństwo nieco inaczej działa.

Nie zrozumiałem.

Te dane są poufne, nie może być tak, że godzimy się z góry na ich
ujawnianie. Nawet dane o zakupach w sieci są poufne. Albo komputer jest
bezpieczny, i możemy go używać - albo nie. Trzeciej drogi nie ma.

Rozumiem, że są różne klasy bezpieczeństwa, ale nawet do pasywnego
dostępu do historii kont niezbędny jest bezpieczny komputer.
--
Krzysztof Hałasa

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

Rozumiem, że są różne klasy bezpieczeństwa, ale nawet do pasywnego
dostępu do historii kont niezbędny jest bezpieczny komputer.

To już prawie RODO :)
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Rozumiem, że są różne klasy bezpieczeństwa, ale nawet do pasywnego
dostępu do historii kont niezbędny jest bezpieczny komputer.

To już prawie RODO :)

Co ma do tego RODO?
Naprawdę uważasz, że to nie są poufne dane?
--
Krzysztof Hałasa

W dniu 2020-06-23 o 21:45, Krzysztof Halasa pisze:

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Rozumiem, że są różne klasy bezpieczeństwa, ale nawet do pasywnego
dostępu do historii kont niezbędny jest bezpieczny komputer.

To już prawie RODO :)

Co ma do tego RODO?
Naprawdę uważasz, że to nie są poufne dane?

Wiem, że to są dane poufne i wiem, że patrząc na to od strony banku jest to bardzo istotne. Również patrząc na to od strony klientów obracających większymi kwotami.

Natomiast patrząc na to z mojej perspektywy. Gro wydatków idzie na opłaty i wyżywienie. Informacji o tym ile i gdzie wydajemy na jedzenie i że co jakiś czas zepsuje nam się pralka, czy odkurzacz i wtedy kupimy nowe nie uważam za jakoś specjalnie poufne. Te informacje można z dostateczną dokładnością po prostu wydedukować.

Dlatego skojarzyło mi się to z RODO (niektóre wymagania uważam, za przerost formy nad treścią). Dodałem uśmieszek, bo wiem, że skojarzenie jest pokrętne.

Kiedyś tajemnica bankowa była święta. Ale o ile wiem to teraz już prawie wszystkie służby mogą bez problemu uzyskać dostęp więc dane te powoli stają się "tajne ale jawne".

Niektóre rzeczy z zakresu tajne/poufne po prostu mnie śmieszą.
Na przykład jak pobieram wyciąg z KK z Citi to jestem informowany, aby nie zapisywać tego na nie zabezpieczonym komputerze i w dodatku usunąć pliki tymczasowe i wyczyścić pamięć podręczną przed zamknięciem okna przeglądarki. Według mnie mam jeden zabezpieczony komputer, ale on (w ramach tego zabezpieczenia) jest nie podłączony do sieci więc zapis na nim tak pobieranego wyciągu odpada.
A jak przysyłają mi (jawnym) mailem informację o wystawieniu wyciągu to w mailu są informacje ile wydałem w miesiącu i ile mogę jeszcze wydać.

Dlaczego łączna kwota wydatków i wysokość limitu są jawne, a to ile w ubiegłym miesiącu wydałem na paliwo a ile w sklepiku osiedlowym to już tajne?
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Natomiast patrząc na to z mojej perspektywy. Gro wydatków idzie na
opłaty i wyżywienie. Informacji o tym ile i gdzie wydajemy na jedzenie
i że co jakiś czas zepsuje nam się pralka, czy odkurzacz i wtedy
kupimy nowe nie uważam za jakoś specjalnie poufne. Te informacje można
z dostateczną dokładnością po prostu wydedukować.

Niech i tak będzie, ale generalizujesz patrząc przez pryzmat własnej
osoby. Ogólnie rzecz biorąc, nie byłoby dobrze, gdyby takie dane były
jawne.

Kiedyś tajemnica bankowa była święta. Ale o ile wiem to teraz już
prawie wszystkie służby mogą bez problemu uzyskać dostęp więc dane te
powoli stają się "tajne ale jawne".

Obawiam się, że kiedyś służby także miały dostęp do takich danych.
Pewnie nawet bardziej "wszystkie", bo było ich mniej - za to miały
większe możliwości. Jedyne, co je mogło powstrzymać, to ew. ilość
papierkowej roboty (np. szukania igły w stogu).
--
Krzysztof Hałasa

Dnia Wed, 24 Jun 2020 15:16:58 +0200, Krzysztof Halasa napisał(a):

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Kiedyś tajemnica bankowa była święta. Ale o ile wiem to teraz już
prawie wszystkie służby mogą bez problemu uzyskać dostęp więc dane te
powoli stają się "tajne ale jawne".

Obawiam się, że kiedyś służby także miały dostęp do takich danych.
Pewnie nawet bardziej "wszystkie", bo było ich mniej - za to miały
większe możliwości.

Kiedys dawno pewnie tak. Potem sie chyba troche ukrocilo - tzn nadal
mialy, ale trzeba bylo papierki, nie wystarczylo legitymacji pokazac.

Jedyne, co je mogło powstrzymać, to ew. ilosc
papierkowej roboty (np. szukania igły w stogu).

No wlasnie - kiedys trzeba bylo banki odwiedzic i poszukac.
Dzis maja wszystko przy biurku.

J.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

To co piszesz dalej, że być może jakiś plugin oznacza, że trochę
inaczej rozumiemy swoje wypowiedzi. Dla mnie 'jakby ktoś wklepywał na
klawiaturze' oznacza, że komputer nie potrafi (poza ustaleniem
jakiegoś identyfikatora) rozróżnić źródła podrzucającego mu hasło od
klawiatury marki "standardowa klawiatura USB".

To jest zwykły tryb pracy takiego urządzenia. Ale przeglądarka może użyć
lepszego trybu - takiego, w którym ona pyta o konkretny np. serwer, user
to tylko zatwierdza (zamiast go mozolnie wyszukiwać na małej
klawiaturce). Nie ma wtedy też niebezpieczeństwa, że przeglądarka uzna
hasło za np. nazwę strony czy coś takiego (bo się userowi ręka omsknie
albo coś tam innego nastąpi).

Jeśli plugin to już transmisja hasła nie musi być udawaniem klawiatury
i teoretycznie może być jakoś zabezpieczona.

Tak sobie. Ale owszem, to już wtedy nie jest udawanie klawiatury.

Tylko, że jeśli efektem
końcowym jest wpisanie hasła w okienko edycyjne to ja to określiłem
jako miejsce w którym dane (hasło) są jawne. Jakiś program śledzący
powinien być w stanie to hasło wyczytać.

No pewnie że tak. Wystarczy login root. Po prostu nie należy umożliwiać
odpalania niezaufanych programów, zwłaszcza z prawami admina (lub
własnymi), na takiej maszynce.
Przecież napisałem, że to nie jest panaceum na wszystko.

Nie całą sesją tylko dodatkową sesją utworzoną tylko w celu
przekazania danych logowania.

To nie jest celowe. Hasło nie jest ważniejsze od samej sesji.

Przekazywanie tego hasła jakiemukolwiek programowi działającemu na PC
jest według mnie przekazaniem tego hasła do środowiska, które nie
zapewnia bezpieczeństwa.

W takim przypadku nie można korzystać z takiego komputera.

Przypuszczam, że potrafi. Jeśli nawet uzyskane w ten sposób dane nie
mają 100% pewności, a 'jedynie' np. o każdym bicie wiemy że z
prawdopodobieństwem 80% ma taką wartość jak nam się wydaje to choć nie
znamy żadnego bitu 'na pewno' to jednak ta informacja na pewno ułatwi
atakującemu (choć ja nie umiałbym tego wykorzystać).

Owszem. Nie chodzi jednak o to, co kto myśli, tylko o to, co da się
pokazać, udowodnić, albo przynajmniej uprawdopodobnić. Chwilowo jednak
najbardziej prawdopodobne jest to, że z pamięci flash (think 3D flash)
ani RAM takich danych - po ich nadpisaniu / skasowaniu - nie da się
uzyskać. Nie z prawdopodobieństwem 80%, ani nawet 1% (co także mogłoby
być wystarczające).
Co oczywiście nie zmienia faktu, że w niektórych zastosowaniach należy
zakładać, że jest to możliwe.
Oczywiście nie wątpię, że da się łatwo zbudować urządzenie, które może
monitorować operacje np. na flashu. W obecnych czasach to nie wymaga
nawet jakieś profesjonalnej technologii, 8-kanałowy analizator Saleae
można kupić za drobne kilkaset euro.

Ja uważam, że mając możliwość tworzenia sesji między notatnikiem a
serwerem można by traktować komputer do którego podpięty jest notatnik
jak całą resztę wrogiego środowiska. Z tym, że aby korzystać z
przeglądarki na komputerze i notatniku do logowania i potwierdzania to
notatnik musiałby pozwalać na zaprezentowanie użytkownikowi kluczowych
informacji (to co przychodzi w sms z pinem) i ich potwierdzenie. Te
kluczowe informacje nie mogłyby być przesyłane z przeglądarki tylko
musiały być przesyłane z serwera w sesji.

A co np. z poufnością tych i innych informacji?
Rozwiązaniem jest tu przeniesienie *całej* przeglądarki (zapewne
zubożonej) do tego małego urządzenia. Co - znów - ma wady i zalety.

W tej rozmowie po raz pierwszy usłyszałem o notatnikach haseł i
zakładałem, że być może to jest coś lepiej zrobione i stara się zrobić
coś więcej niż tylko pomóc zapamiętać hasła.

To jest (potencjalnie) bardzo dobrze zrobione, i nie istnieje tu żadne
"lepiej". To po prostu konkretne narzędzie, niestety do kawy w dalszym
ciągu trzeba mieć ekspres, a wiązania krawatów można się (lub
w desperacji np. żonę) nauczyć :-)

Uważam, że uzupełniając komputer urządzeniem podłączonym pod USB,
które miałoby maleńki wyświetlacz + czytnik kart (lub klawiaturę)
dałoby się zrobić bankowanie niepodatnym na wirusy itp.

Nie. Ale może być większy wyświetlacz + wygodna klawiatura i mysz. Tyle
że to jest kolejny komputer. Może być np. taki RPi za 200 zł.

"Wirusy" są mało istotne. Nie są inteligentne ani nie są przygotowane do
naszego konkretnego przypadku. Bardziej obawiałbym się żywych
przeciwników.

Jadąc dalej tym tropem to sesja mogłaby być nie między tym urządzeniem
a serwerem a między kartą zbliżeniową a serwerem tylko karta powinna
mieć wyświetlacz + co najmniej chyba 1 klawisz.

Trudno by się wypisywało przelewy.
--
Krzysztof Hałasa

W dniu 2020-06-22 o 17:32, Krzysztof Halasa pisze:

Jadąc dalej tym tropem to sesja mogłaby być nie między tym urządzeniem
a serwerem a między kartą zbliżeniową a serwerem tylko karta powinna
mieć wyświetlacz + co najmniej chyba 1 klawisz.

Trudno by się wypisywało przelewy.

W mojej koncepcji wpisuje się na przeglądarce na komputerze a to słuzy tylko do zatwierdzania danych po zaprezentowaniu najważniejszych info na wyświetlaczu.
P.G.

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.

W dniu 2020-06-07 o 17:07, Krzysztof Halasa pisze:

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

System wysyła do komputera użytkownika swoją sól. Komputer użytkownika
hashuje jego login+hasło+sól i to odsyła do systemu I tylko to system
zna (czy zna login, czy nie - nie wnikam - ważne, że hasła nigdy nie
widzi).

Czyli w gruncie rzeczy ten hash jest hasłem, które wystarcza do
zalogowania. Innymi słowy, znów przechowujesz niezaszyfrowane hasło
w bazie serwera, każdy kto je przejmie itd.

Jednak są pewne, kluczowe różnice:
- hash jest znacznie dłuższy od hasła użytkownika (nie da się zaatakować ani siłowo, ani słownikowo),
- jest inny w każdym serwisie nawet jak użytkownik używa tego samego hasła.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Jednak są pewne, kluczowe różnice:
- hash jest znacznie dłuższy od hasła użytkownika (nie da się
zaatakować ani siłowo, ani słownikowo),

Ale dlaczego nie? Przecież możemy dokleić salt i przelecieć słownikiem
tak samo. Jedynie trudniej zrobić rainbow tables (może nawet nie da
się).

- jest inny w każdym serwisie nawet jak użytkownik używa tego samego hasła.

No tak. Ale w praktyce tego nie można wykorzystać.
--
Krzysztof Hałasa

W dniu 2020-06-08 o 16:23, Krzysztof Halasa pisze:

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

Jednak są pewne, kluczowe różnice:
- hash jest znacznie dłuższy od hasła użytkownika (nie da się
zaatakować ani siłowo, ani słownikowo),

Ale dlaczego nie? Przecież możemy dokleić salt i przelecieć słownikiem
tak samo.

Jako oczywistą oczywistość przyjąłem stosowne wydłużenie hasła.
Wydłużając proces logowania o 1s można wydłużyć atak siłowy/słownikowy milion razy (atak dający się przeprowadzić w godzinę będzie wymagał 114 lat.

Jedynie trudniej zrobić rainbow tables (może nawet nie da się).

Nie znam pojęcia.
P.G.

Użytkownik Piotr Gałka piotr.galka@cutthismicromade.pl ...

Banki u nas poszły we własne apki, i chyba żeście o tym zapomnieli bo wszyscy dodali swoje komputery jako
zaufane.

Nie prawda. Nie wszyscy. Co najmniej jedna osoba (ja) nie dodała
żadnego komputera jako zaufanego.

I za kazdym razem logowanie potwierdzasz smsem? Ocipiałbym ;-DDD

--
Pozdrawia... Budzik
b_ud_zi_k_6_1 na poczta kropka onet kropka pl  (adres antyspamowy, usuń także "_")
Dlaczego chłopaki z Warszawy wolą dziewczyny z Poznania niż ze stolicy?
Bo z jednej strony Wola i Ochota a z drugiej Brudno i Włochy.

On 2020-11-11, Budzik <budzik61@poczta.o.n.e.t.pl.nie.spam.oj> wrote:

[...]

Nie prawda. Nie wszyscy. Co najmniej jedna osoba (ja) nie dodała
żadnego komputera jako zaufanego.

I za kazdym razem logowanie potwierdzasz smsem? Ocipiałbym ;-DDD

Może się nie loguje za często, albo korzysta z aplikacji mobilnej :)

--
Wojciech Bańcer
wojciech.bancer@gmail.com

Użytkownik "Piotr Gałka"  napisał w wiadomości grup dyskusyjnych:rbd72j$jke$1$PiotrGalka@news.chmurka.net...
W dniu 2020-06-04 o 22:07, Alf/red/ pisze:

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.

Nie wiem co to 2FA, ale uważam, że spełnienie mojego postulatu nie wymaga żadnego dodatkowego sprzętu.

System wysyła do komputera użytkownika swoją sól. Komputer użytkownika hashuje jego login+hasło+sól i to odsyła do systemu I tylko to system zna (czy zna login, czy nie - nie wnikam - ważne, że hasła nigdy nie widzi).

No ... dawniej to sie troche klocilo z idea www.
Jest przegladarka i tego nie potrafi. Musialbys napisac osobny program do obslugi.

Teraz i tak to nie jest przegladarka www, tylko skomplikowany program w JS, wiec mozna by wrocic do pomyslu.

W czasie definiowania hasła to też komputer użytkownika ma sprawdzić, czy wpisane dwa razy jest takie samo i czy spełnia ewentualne dodatkowe wymagania narzucone aby zapobiec stosowaniu haseł typu 1234. Po sprawdzeniu liczy hash i tylko to trafia do serwera.

A to troche klopotliwe, bo musisz te wszystkie sprawdzenia przeslac na komputer klienta.
Wiec wcale nie dziwne, ze sprawdza serwer.

W dodatku ... jedno haslo do wszystkiego, i moze nawet jeden login ... myslisz sobie, ze zrobili to poprawnie tak jak wyzej, a jeden serwer wcale nie, hackerzy go przejmuja i lezysz na calej linii.
Albo nie przejmuja, tylko zakladaja :-)

J.

W dniu 2020-06-05 o 13:13, J.F. pisze:

No ... dawniej to sie troche klocilo z idea www.

Nie znam idei www. Myślałem, że jak przeglądarka ma tryb z kłódeczką to znaczy, że takie podstawowe rzeczy też ma w sobie.

W dodatku ... jedno haslo do wszystkiego, i moze nawet jeden login ... myslisz sobie, ze zrobili to poprawnie tak jak wyzej, a jeden serwer wcale nie, hackerzy go przejmuja i lezysz na calej linii.

Dlaczego?
Przy założeniu, że przeglądarka jest tak zrobiona, że nie wypuści hasła.

Albo nie przejmuja, tylko zakladaja :-)

Co im to da, jeśli przeglądarka nie wypuści hasła.
P.G.

Użytkownik "Piotr Gałka"  napisał w wiadomości grup dyskusyjnych:rbdaul$mbd$1$PiotrGalka@news.chmurka.net...
W dniu 2020-06-05 o 13:13, J.F. pisze:

No ... dawniej to sie troche klocilo z idea www.

Nie znam idei www. Myślałem, że jak przeglądarka ma tryb z kłódeczką to znaczy, że takie podstawowe rzeczy też ma w sobie.

W dodatku ... jedno haslo do wszystkiego, i moze nawet jeden login ... myslisz sobie, ze zrobili to poprawnie tak jak wyzej, a jeden serwer wcale nie, hackerzy go przejmuja i lezysz na calej linii.

Dlaczego?
Przy założeniu, że przeglądarka jest tak zrobiona, że nie wypuści hasła.

Ale nie jest ... choc istotnie mogla by byc.

Albo nie przejmuja, tylko zakladaja :-)

Co im to da, jeśli przeglądarka nie wypuści hasła.

No, beda mogli sobie zgromadzic wiele odpowiedzi na rozne salty.
i moze podpasuje im do jakiegos innego systemu ... choc jak salt bedzie dlugi, to moze byc wystarczajaco niemozliwe.

J.

W dniu 2020-06-05 o 14:37, J.F. pisze:

Dlaczego?
Przy założeniu, że przeglądarka jest tak zrobiona, że nie wypuści hasła.

Ale nie jest ... choc istotnie mogla by byc.

Ja po prostu nie znam się na tym. Zakładałem, że takie dostępne ogółowi ludzi rzeczy są zrobione 'dobrze' i jakby były zrobione 'źle' to byłoby o tym głośno.

To, że hasło nie wychodzi poza mój komputer wydawało mi się oczywistą oczywistością i dlatego nie przyszło mi nawet do głowy poddać to w wątpliwość.

Pierwsze wątpliwości pojawiły się jak spotkałem się z hasłem maskowanym, ale wtedy to już chyba miałem konta w prawie wszystkich tych sklepach w których mam teraz (nie ma tego dużo) i jakoś nie chciało mi się zmieniać.

Albo nie przejmuja, tylko zakladaja :-)

Co im to da, jeśli przeglądarka nie wypuści hasła.

No, beda mogli sobie zgromadzic wiele odpowiedzi na rozne salty.
i moze podpasuje im do jakiegos innego systemu ... choc jak salt bedzie dlugi, to moze byc wystarczajaco niemozliwe.

Powinno być wystarczająco niemożliwe. Poza tym salt może też być dla każdego klienta inny, generowany na podstawie jakichś danych danego sklepu i jawnego loginu klienta.
P.G.

Użytkownik "Piotr Gałka"  napisał w wiadomości grup dyskusyjnych:rbdihf$qt8$1$PiotrGalka@news.chmurka.net...
W dniu 2020-06-05 o 14:37, J.F. pisze:

Dlaczego?
Przy założeniu, że przeglądarka jest tak zrobiona, że nie wypuści hasła.

Ale nie jest ... choc istotnie mogla by byc.

Ja po prostu nie znam się na tym. Zakładałem, że takie dostępne ogółowi ludzi rzeczy są zrobione 'dobrze' i jakby były zrobione 'źle' to byłoby o tym głośno.
To, że hasło nie wychodzi poza mój komputer wydawało mi się oczywistą oczywistością i dlatego nie przyszło mi nawet do głowy poddać to w wątpliwość.

A tymczasem "password" w takim podstawowym HTML oznacza jedynie, ze w czasie wpisywania znaki sie nie pokazuja
https://www.w3schools.com/tags/att_input_type_password.asp

No i przegladarka przechowuje te hasla, i wcale nie zahaszowane jednostronnie, wiec masz kolejna dziure w bezpiecenstwie.

Albo nie przejmuja, tylko zakladaja :-)

Co im to da, jeśli przeglądarka nie wypuści hasła.

No, beda mogli sobie zgromadzic wiele odpowiedzi na rozne salty.
i moze podpasuje im do jakiegos innego systemu ... choc jak salt bedzie dlugi, to moze byc wystarczajaco niemozliwe.

Powinno być wystarczająco niemożliwe. Poza tym salt może też być dla każdego klienta inny, generowany na podstawie jakichś danych danego sklepu i jawnego loginu klienta.

Tylko, zeby sie nie okazalo, ze zawsze taki sam, to mozna podsluchac i uzyc w przyszlosci.

Dodatkowe szyfrowanie przez HTTPS powinno temu zapobiec ...

J.

W dniu 2020-06-05 o 16:33, J.F. pisze:

Powinno być wystarczająco niemożliwe. Poza tym salt może też być dla każdego klienta inny, generowany na podstawie jakichś danych danego sklepu i jawnego loginu klienta.

Tylko, zeby sie nie okazalo, ze zawsze taki sam, to mozna podsluchac i uzyc w przyszlosci.

Raczej musi być taki sam bo jak wtedy weryfikować hasło.
O ile wiem to z założenia salt jest jawny. Na czym polegało by użycie w przyszłości.
P.G.

Użytkownik "Piotr Gałka"  napisał w wiadomości grup dyskusyjnych:rbdmls$thv$1$PiotrGalka@news.chmurka.net...
W dniu 2020-06-05 o 16:33, J.F. pisze:

Powinno być wystarczająco niemożliwe. Poza tym salt może też być dla każdego klienta inny, generowany na podstawie jakichś danych danego sklepu i jawnego loginu klienta.

Tylko, zeby sie nie okazalo, ze zawsze taki sam, to mozna podsluchac i uzyc w przyszlosci.

Raczej musi być taki sam bo jak wtedy weryfikować hasło.
O ile wiem to z założenia salt jest jawny. Na czym polegało by użycie w przyszłości.

Ze skoro serwer zawsze pyta tym samym saltem, to nie musisz znac hasla - wystarczy odpowiedz.

Oczywiscie jak rozumiem to w Twojej idei salt bedzie indywidualny dla serwera i usera,
wiec jak podsluchasz jedna odpowiedz, to zyskujesz tylko dostep do tego jednego usera i serwera.

Mozna by to zduplikowac - przy tworzeniu hasla serwer wysle salt1 i otrzyma hash1,
przy nastepnym logowaniu wysle salt2, otrzyma hash2, i przeliczy czy pasuje do zapamietanego hash1 i salt1
.... ale glowy nie dam, czy wlasnie nie otwarlem wielkiej dziury ...

J.

W dniu 2020-06-05 o 17:20, J.F. pisze:

Ze skoro serwer zawsze pyta tym samym saltem, to nie musisz znac hasla - wystarczy odpowiedz.

Dlatego zapewne taka komunikacja wymaga wczesniej ustalenia zabezpieczonej sesji. Czyli logowanie powinno być możliwe tylko na stronach z kłódeczką, która to kłódeczka mogła by się pojawić dopiero jak jest ustanowiona bezpieczna sesja.

Cały czas pomijam atak man-in-the-middle bo to jest chyba osobny temat i nie chcę się wdawać w kolejny temat o którym mało wiem.

Mozna by to zduplikowac - przy tworzeniu hasla serwer wysle salt1 i otrzyma hash1,
przy nastepnym logowaniu wysle salt2, otrzyma hash2, i przeliczy czy pasuje do zapamietanego hash1 i salt1
... ale glowy nie dam, czy wlasnie nie otwarlem wielkiej dziury ...

Wymagałoby policzenia hash1 do tyłu, a to ma własnie być z definicji niemożliwe.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.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

Użytkownik "Krzysztof Halasa"  napisał w wiadomości grup dyskusyjnych:m3k10mpr8m.fsf@pm.waw.pl...
Piotr Gałka <piotr.galka@cutthismicromade.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.

"J.F." <jfox_xnospamx@poczta.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

Użytkownik "Krzysztof Halasa"  napisał w wiadomości grup dyskusyjnych:m3tuzqoa4q.fsf@pm.waw.pl...
"J.F." <jfox_xnospamx@poczta.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 np "Ewa" to dobre haslo ?

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?

Nic, haslo nie zostalo zmienione, to za kolejnym logowaniem obowiazuje stare.
Ale nadal na poczatku bedzie wymagana zmiana hasla :-)
Poza tym mozna przypominac tydzien wczesniej ...


J.

"J.F." <jfox_xnospamx@poczta.onet.pl> writes:

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

Nic, haslo nie zostalo zmienione, to za kolejnym logowaniem obowiazuje
stare.
Ale nadal na poczatku bedzie wymagana zmiana hasla :-)
Poza tym mozna przypominac tydzien wczesniej ...

Userzy doskonale sobie radzą z obejściem takich systemów, bez żadnego
pożytku dla bezpieczeństwa.
Np. z automatycznymi zmianami radzą sobie tak, że doklejają cyfrę "1" na
końcu. Przy kolejnej zmianie usuwają tę cyfrę. Jeśli system pamięta X
ostatnich haseł, to doklejają kolejne cyfry. Jeśli system wymaga
przynajmniej 1 wielkiej litery, to pierwszą - lub ostatnią - literę
robią wielką. Itd. itd.

Zapisują hasła na monitorze, noszą je w portfelach itd. Można pamiętać
1 dobre hasło, ale nie takie, które się zmienia co 2 tygodnie.

A teraz user, który ma hasła w postaci np. 256-bitowych losowych liczb
z generatora (szestnastkowych, ale mogą być także np. dziesiętne, bez
znaczenia) - czyli z dużo większą entropią od "typowych" akceptowanych
haseł, ma problemy, bo użył tylko 16 (albo nawet 10) różnych znaków.
--
Krzysztof Hałasa

Dnia 04.06.2020 Piotr Gałka <piotr.galka@cutthismicromade.pl> napisał/a:

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

Nie muszą.
https://zaufanatrzeciastrona.pl/post/kryptografia-hasel-maskowanych-czyli-magia-matematyki/

Ale oczywiście mogą, dlatego zawsze warto mieć różne hasła
do różnych serwisów. A swoją maskowane hasła to wysokiej klasy
upierdliwość- omijam jak mogę.

--
Dominik Ałaszewski (via raspbianowy slrn)
"W życiu piękne są tylko chwile..." (Ryszard Riedel)
Wyrażam wyłącznie prywatne poglądy zgodnie z Art. 54 Konstytucji RP Pisząc na priv zmień domenę na gmail.

W dniu 2020-06-05 o 10:32, Dominik Ałaszewski pisze:

Dnia 04.06.2020 Piotr Gałka <piotr.galka@cutthismicromade.pl> napisał/a:

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

Nie muszą.
https://zaufanatrzeciastrona.pl/post/kryptografia-hasel-maskowanych-czyli-magia-matematyki/

Ciekawy artykuł.
Myślałem, że muszą przechowywać hashe dla wszystkich kombinacji.
P.G.

Dominik Ałaszewski <Dominik.Alaszewski@gazeta.pl.invalid> writes:

- czy po prostu przechowują całe hasło.

Nie muszą.
https://zaufanatrzeciastrona.pl/post/kryptografia-hasel-maskowanych-czyli-magia-matematyki/

Podobne zabawy niczego nie dadzą, ponieważ liczba możliwych kombinacji
takich liter jest na tyle mała, że można je złamać brutalną siłą
w mgnieniu oka.
Trzeba pamiętać, że posiadacza takiej bazy danych nie obowiązują
ograniczenia w rodzaju "max 3 próby" itp.
--
Krzysztof Hałasa

Dnia 07.06.2020 Krzysztof Halasa <khc@pm.waw.pl> napisał/a:

https://zaufanatrzeciastrona.pl/post/kryptografia-hasel-maskowanych-czyli-magia-matematyki/

Podobne zabawy niczego nie dadzą, ponieważ liczba możliwych kombinacji
takich liter jest na tyle mała, że można je złamać brutalną siłą
w mgnieniu oka.

Ale ja nie piszę, że hasła maskowane są najlepsze (ani w ogóle
dobre). Moim osobistym zdaniem są do dupy :-)

Podałem jedynie przykład, że nie trzeba w postaci jawnej takowego hasła przechowywać.

Trzeba pamiętać, że posiadacza takiej bazy danych nie obowiązują
ograniczenia w rodzaju "max 3 próby" itp.

No jak masz dane już "wycieknięte", to oczywiście żadne limity
prób nie obowiązują- to jasne. A ponieważ nigdy nie wiesz, jak przechowywane są hasła "po drugiej stronie" (w sensie podatności
na złamanie), zawsze trzeba mieć różne hasła do różnych serwisów. Oczywiście tych ważnych, bo na stronie forum naprawy pralek, do którego oczywiście _trzeba_ się zarejestrować, żeby sobie ściągnąć schemat można spokojnie użyć hasła "dupa123" :-)

--
Dominik Ałaszewski (via raspbianowy slrn)
"W życiu piękne są tylko chwile..." (Ryszard Riedel)
Wyrażam wyłącznie prywatne poglądy zgodnie z Art. 54 Konstytucji RP Pisząc na priv zmień domenę na gmail.

Próbowałem, każe dać dużą literę, znak polski i znak diakrytyczny, a do tego musi być co najmniej 8 znaków.
Oczywiście musisz się domyśleć, bo dla wstępnej weryfikacji klientów Pan Informatyk nie pisze, dlaczego dupę123 odrzuca ;-)))


-- -- -

na stronie forum naprawy pralek, do którego oczywiście _trzeba_ się zarejestrować, żeby sobie ściągnąć schemat można spokojnie użyć hasła "dupa123"

Dominik Ałaszewski <Dominik.Alaszewski@gazeta.pl.invalid> writes:

[hasła maskowane]

Podałem jedynie przykład, że nie trzeba w postaci jawnej takowego hasła przechowywać.

Formalnie nie, natomiast to jest takie hasło quasi-jawne.
Równie dobrze hasło zakodowane w hex nie jest jawne.

No jak masz dane już "wycieknięte", to oczywiście żadne limity
prób nie obowiązują- to jasne. A ponieważ nigdy nie wiesz, jak przechowywane są hasła "po drugiej stronie" (w sensie podatności
na złamanie), zawsze trzeba mieć różne hasła do różnych serwisów. Oczywiście tych ważnych, bo na stronie forum naprawy pralek, do którego oczywiście _trzeba_ się zarejestrować, żeby sobie ściągnąć schemat można spokojnie użyć hasła "dupa123" :-)

No tak, myślę że na taki kompromis mogę pójść :-)
--
Krzysztof Hałasa

On Mon, 1 Jun 2020 12:02:05 +0200, Piotr Gałka<piotr.galka@cutthismicromade.pl> wrote:

Czy gdzieś w ST da się znaleźć informację jaki był powód zablokowania?

możliwości:
- przekorczenie 50 prób błędnych logowań, nie pod rząd ale wszystkich (są liczone).

- dwukrotna pomyłka przy wpisywaniu TANu (kodu SMS). -dziwne zachowanie użytkownika - wybiera opcje z menu inna ścieżką niż naturalna

- i kilka innych o których nie mogę mówić ;)

--
Marek

W dniu 2020-06-02 o 10:07, Marek pisze:

On Mon, 1 Jun 2020 12:02:05 +0200, Piotr Gałka<piotr.galka@cutthismicromade.pl> wrote:

Czy gdzieś w ST da się znaleźć informację jaki był powód zablokowania?

możliwości:
- przekorczenie 50 prób błędnych logowań, nie pod rząd ale wszystkich (są liczone).

- dwukrotna pomyłka przy wpisywaniu TANu (kodu SMS).
-dziwne zachowanie użytkownika - wybiera opcje z menu inna ścieżką niż naturalna

- i kilka innych o których nie mogę mówić ;)

Czyli jesteś zorientowany ale tajne/poufne :)

Na początku maja założyłem konto na allegro.
Nigdy wcześniej nie miałem bo chyba kiedyś założenie wymagało czegoś więcej niż klikania.

Z powodu wirusa (nie komputerowego) dostałem ofertę promocyjnego, darmowego włączenia na miesiąc opcji Smart. Czas leci i promocja zbliża się do końca no to trzeba 'obowiązkowo' znaleźć czas i poszukać (nie jest łatwo) co by tu można kupić co byłoby przydatne :)
No i w sobotę się zmusiłem do znalezienia czasu na poszukiwania i udało mi się zrobić takie 3 zakupy. Zakupy w necie opłacamy przez m-transfer z KK żony.

Jak następnego dnia pojawiła się blokada to najpierw się zastanowiłem czy nie zrobiliśmy czegoś nietypowego. Ale nietypowe były tylko 2 rzeczy:
- aż 3 zakupy m-transferem jednego dnia,
- zakupy za względnie małe kwoty (miałem problemy z uzbieraniem tych 40zł na Smart).
Dotychczas było po jednym zakupie co jakiś czas i nigdy za tak małe kwoty.
Obie te nietypowości nie wydały mi się alarmujące dla banku.
Nie były to też pierwsze zakupy z allegro bo jeden już był wtedy gdy konto założyłem (wtedy ponad 1k).
Uznałem, że choć to jest teoretycznie nietypowe to nie wydaje mi się aby mogło być wyzwalaczem blokady. Przecież każda transakcja jest potwierdzana SMS-em.

Dlatego zamiast snuć spiskowe teorie postanowiłem zapytać o jakieś bardziej przyziemne wytłumaczenie.

W tej chwili to myślę, że albo 3 tanie zakupy bank uznał, za nietypowe zachowanie klienta, albo jest to jakiś zbieg okoliczności - że np. ktoś przekroczył ten licznik 50 konta żony akurat dzień po tych 3 zakupach.
P.G.

Witaj Marek, 02 cze 2020 w news:almarsoft.4707642339053576375
@news.neostrada.pl napisałeś/aś:

-dziwne zachowanie użytkownika - wybiera opcje z menu inna ścieżką niż naturalna

he he, to brzmi ciekawie - nie potrafię sobie tego wyobrazić, bo do większości funnkcji/opcji można dojść raczej jedną drogą

- i kilka innych o których nie mogę mówić ;)

Podejrzewam, że i tak nie dotyczą zwykłych zjadaczy chleba
 zdarzyło mi się kiedyś zablokowanie możliwości przelewów po wykonaniu chyba z czterech, chyba prawie identycznych, w krótkim czasie

On 03 Jun 2020 00:31:43 GMT, pueblo <nomail@nomail.pl> wrote:

he he, to brzmi ciekawie - nie potrafię sobie tego wyobrazić, bo do większości funnkcji/opcji można dojść raczej jedną drogą

Skryptem można na skróty.

--
Marek