Witam.
Mam do Was wielką prośbę.
Poszukuje informacji na temat sposobów logowania się do rożnych banków. Oczywiście chodzi o serwis www.
Pisze pracę na temat bezpieczeństwa transakcji i chciałbym zrobić takie zestawienie jak wygląda logowanie się do różnych banków.
Mam kilka kont bankowych, ale nie we wszystkich bankach i nie wiem do końca jak to wygląda.
Jeżeli możecie pomóc to będe bardzo wdzięczny.
Mam np takie info:
mBank - Login : 8 cyfr + dowolne hasło otwarte
dbNet - Login 10 cyfr + hasło 6 cyfr otwarte
Alior - Login : 8 cyfr + hasło dowolne maskowane + obrazek
Openonline - Login 8 cyfr + hasło dowolne maskowane wirtualna klawiatura
Polbank - Login 9 cyfr + hasło otwarte , wymuszona zmiana hasła co 3 miesiące hasło musi się składać z min 8 znaków

Jeżeli możecie to proszę o info jak to wygląda w innych bankach.
Nie kaĹźde demo pokazuje faktyczny sposĂłb logowania
pozdrawiam i jeszcze raz dziękuje
Artur

W artykule <i68ujj$fmm$1@news.task.gda.pl>, AW napisał(a):

Mam np takie info:
mBank - Login : 8 cyfr + dowolne hasło otwarte
dbNet - Login 10 cyfr + hasło 6 cyfr otwarte
Alior - Login : 8 cyfr + hasło dowolne maskowane + obrazek
Openonline - Login 8 cyfr + hasło dowolne maskowane wirtualna klawiatura
Polbank - Login 9 cyfr + hasło otwarte , wymuszona zmiana hasła co 3 miesiące hasło musi się składać z min 8 znaków

Millennium dla indywidualnych - millekod (login - 8 cyfr) + hasło +
wefyfikacja 2 (czy 3?) znaków z numeru DO/PESEL.
Millennium dla firm - millekod (8 cyfr) + login (ustalony własnoręcznie)
+ hasło + certyfikat (z certyfikatu wycofano się około 1.5 tygodnia temu).
ING - login (6 liter + 4 cyfry) + wybrane znaki z hasła (dł. hasła
od 10 do 32 znaków).

Openonline - nie zgodzę się - 8 cyfr login + hasło pełne

Jacek

W dniu 2010-09-08 23:36, Jacek Kalinski pisze:

Openonline - nie zgodzę się - 8 cyfr login + hasło pełne

Dzięki za info.
Jak to jest że ja mam maskowane w Openie?

W dniu 2010-09-08 23:40, AW pisze:

W dniu 2010-09-08 23:36, Jacek Kalinski pisze:

Openonline - nie zgodzę się - 8 cyfr login + hasło pełne

Dzięki za info.
Jak to jest że ja mam maskowane w Openie?

Chyba zależy z jakich produktów korzystasz i od kiedy.
Mnie wymusili długie i maskowane odkąd dali mi KISa.
Zbiegło się to jakoś z ich przeflancowywaniem na serwis openonline. Przy tej okazji też coś pozmieniali.

--
Dziękuję.
    Pozdrawiam.
       SQLwiel.

Jacek Kalinski <jacek_kal@go2._NOSPAMPLEASE_.pl> writes:

W artykule <i68ujj$fmm$1@news.task.gda.pl>, AW napisał(a):

Mam np takie info:
mBank - Login : 8 cyfr + dowolne hasło otwarte
dbNet - Login 10 cyfr + hasło 6 cyfr otwarte
Alior - Login : 8 cyfr + hasło dowolne maskowane + obrazek
Openonline - Login 8 cyfr + hasło dowolne maskowane wirtualna klawiatura
Polbank - Login 9 cyfr + hasło otwarte , wymuszona zmiana hasła co 3 miesiące hasło musi się składać z min 8 znaków

Millennium dla indywidualnych - millekod (login - 8 cyfr) + hasło +

millekod + hasło (8 cyfr!, to samo hasło do logowania przez telefon) + 2 znaki z DO/PESEL/Paszport

Openonline - nie zgodzę się - 8 cyfr login + hasło pełne

To zależy, jeśli nie zmieniałeś hasła do lokat lub kis to masz pełne,
wpp. masz chyba maskowane.

Nordea - login (10 cyfr) +  ( hasło ze zdrapki (4 cyfry)  lub token) Citi -  login (własnoręczny) + hasło - (Mam wrażenie, że login jest
trzymany w ciasteczku w przeglądarce)
Toyota - login (8 cyfr) + (hasło + wskazanie tokena  w jednym polu)
Eurobank - login (9 cyfr) + hasło + (opcjonalnie) wskazanie tokena gsm lub sprzętowego
Inteligo - login 8 cyfr + hasło


Należy nadmienić, że w aliorze, bzbwk, na 1. ekranie podaje się login, a
dopiero na następnym hasło.

KJ


--
http://blogdebart.pl/2010/03/17/dalsze-przygody-swinki-w-new-jersey/
"#define QUESTION ((bb) || !(bb))" - Shakespeare.

Kamil "Jońca" <kjonca@poczta.onet.pl> dared to write:

Jacek Kalinski <jacek_kal@go2._NOSPAMPLEASE_.pl> writes:

W artykule <i68ujj$fmm$1@news.task.gda.pl>, AW napisał(a):

Mam np takie info:
mBank - Login : 8 cyfr + dowolne hasło otwarte
dbNet - Login 10 cyfr + hasło 6 cyfr otwarte
Alior - Login : 8 cyfr + hasło dowolne maskowane + obrazek
Openonline - Login 8 cyfr + hasło dowolne maskowane wirtualna klawiatura
Polbank - Login 9 cyfr + hasło otwarte , wymuszona zmiana hasła co 3 miesiące hasło musi się składać z min 8 znaków

Millennium dla indywidualnych - millekod (login - 8 cyfr) + hasło +

millekod + hasło (8 cyfr!, to samo hasło do logowania przez telefon) + 2
znaki z DO/PESEL/Paszport

Openonline - nie zgodzę się - 8 cyfr login + hasło pełne

To zależy, jeśli nie zmieniałeś hasła do lokat lub kis to masz pełne,
wpp. masz chyba maskowane.

Nordea - login (10 cyfr) +  ( hasło ze zdrapki (4 cyfry)  lub token) Citi -  login (własnoręczny) + hasło - (Mam wrażenie, że login jest
trzymany w ciasteczku w przeglądarce)
Toyota - login (8 cyfr) + (hasło + wskazanie tokena  w jednym polu)
Eurobank - login (9 cyfr) + hasło + (opcjonalnie) wskazanie tokena gsm
lub sprzętowego Inteligo - login 8 cyfr + hasło


Należy nadmienić, że w aliorze, bzbwk, na 1. ekranie podaje się login, a
dopiero na następnym hasło.

BPH, dawniejszy GE Bank - login (własny, ale niezmienialny) + hasło otwarte

Uzupełnienie do Citi: login można dowolnie zmieniać; sam login nie jest dosłownie przechowywany w cookie - cookie tylko identyfikuje użytkownika dla banku, który to wtedy zwraca przeglądarce odpowiedni login do wyświetlenia.

mBank - Login : 8 cyfr + dowolne hasło otwarte
dbNet - Login 10 cyfr + hasło 6 cyfr otwarte
Alior - Login : 8 cyfr + hasło dowolne maskowane + obrazek
Openonline - Login 8 cyfr + hasło dowolne maskowane wirtualna klawiatura
Polbank - Login 9 cyfr + hasło otwarte , wymuszona zmiana hasła co 3 miesiące hasło musi się składać z min 8 znaków

Jeżeli możecie to proszę o info jak to wygląda w innych bankach.
Nie kaĹźde demo pokazuje faktyczny sposĂłb logowania
pozdrawiam i jeszcze raz dziękuje
Artur

VWbank - login: 7 cyfr; hasło: hasło & wskazanie tokena
PKOBP - jak mBank

--
Grzexs

Użytkownik "Grzexs" <grzexs@gaXzeta.pXl> napisał w wiadomości news:i690f3$q5$1inews.gazeta.pl...

mBank - Login : 8 cyfr + dowolne hasło otwarte
dbNet - Login 10 cyfr + hasło 6 cyfr otwarte
Alior - Login : 8 cyfr + hasło dowolne maskowane + obrazek
Openonline - Login 8 cyfr + hasło dowolne maskowane wirtualna klawiatura
Polbank - Login 9 cyfr + hasło otwarte , wymuszona zmiana hasła co 3 miesiące hasło musi się składać z min 8 znaków
Jeżeli możecie to proszę o info jak to wygląda w innych bankach.
Nie kaĹźde demo pokazuje faktyczny sposĂłb logowania
pozdrawiam i jeszcze raz dziękuje
Artur

VWbank - login: 7 cyfr; hasło: hasło & wskazanie tokena
PKOBP - jak mBank

Toyota bank - login 8 cyfr; hasło & wskazanie tokena


--
Pozdrawiam,
MacGregor

Dnia Wed, 08 Sep 2010 23:18:46 +0200, AW napisał(a):

Eurobank:
*Login* 9 cyfr

*Hasło*
"Hasło powinno mieć 8 do 30 znaków i składać się z liter i cyfr (bez polskich liter). System rozróżnia wielkość liter!"
Jeżeli masz token (sprzętowy albo GSM) to też podajesz z niego kod.


BZWBK:

*Login* 8 cyfr

*Hasło*
"Twoje hasło (PIN) musi:
1. mieć od 8 do 12 znaków,
2. zawierać wyłącznie cyfry, małe i duże litery (bez polskich znaków!), znaki specjalne `'!@#$%^&*()_+-=[]{},;:.?/

Twoje hasło (PIN) nie może:
1. zawierać ani samych liter, ani samych cyfr,
2. mieć trzech identycznych znaków obok siebie,
3. być identyczne z poprzednim,
4. zawierać numeru NIK, NIK pisanego wspak lub części NIK."

Mam wrażenie, że na większości stron polskich banków powinieneś znaleźć tego typu informacje.


--
xbartx

Dnia Wed, 08 Sep 2010 23:18:46 +0200, AW napisał(a):

Poszukuje informacji na temat sposobów logowania się do rożnych banków. Oczywiście chodzi o serwis www.
Pisze pracę na temat bezpieczeństwa transakcji i chciałbym zrobić takie zestawienie jak wygląda logowanie się do różnych banków.
Mam kilka kont bankowych, ale nie we wszystkich bankach i nie wiem do końca jak to wygląda.
Jeżeli możecie pomóc to będe bardzo wdzięczny.

Pekao SA: numer klienta (7 cyfr) + hasło maskowane (8-16 znaków), wirtualna
klawiatura na login i hasło
Getin Bank: login (8 cyfr) + hasło otwarte, 8-50 znaków, w tym mała litera
i cyfra, powiadomienie SMS po udanym i nieudanym logowaniu


--
Krzysztof Jamróz

On Wed, 08 Sep 2010 23:18:46 +0200, AW <a_niepodam_adresu@wp.pl>
wrote:

Jeżeli możecie to proszę o info jak to wygląda w innych bankach.

Lukas bez tokena: identyfikator literowo-cyfrowy, hasło 8 znaków
(literowo cyfrowe)
Lukas z tokenem: identyfikator literowo-cyfrowy, hasło 8 znaków
(literowo cyfrowe)+6 cyfr z tokena
Eurobank z tokenem: identyfikator (9 cyfr), hasło (literowo-cyfrowe),
6 cyfr z tokena
Polbank: identyfikator (9 cyfr), hasło (literowo-cyfrowe)

On Wed, 08 Sep 2010 23:18:46 +0200, AW <a_niepodam_adresu@wp.pl>
wrote:

Jeżeli możecie to proszę o info jak to wygląda w innych bankach.

BPH: login litery+cyfry, haslo maskowalne.

WAM
--
mezrom dan ysazcw -> www.nadmorze.pl <- wczasy nad morzem

Użytkownik "WAM" <nospam@nowam.nopl.pl> napisał w wiadomości grup dyskusyjnych:ov5h8611h3gq5qo1kdlsgvchd6ar7cprd4@4ax.com...

BPH: login litery+cyfry, haslo maskowalne.

A ja do BPH loguję się moim numerem CIF (9 cyfr). Na kolejnym ekranie hasło maskowane.

On Thu, 9 Sep 2010 10:23:15 +0200, "MarekZ" <brak@adresu.w.pl> wrote:

BPH: login litery+cyfry, haslo maskowalne.

A ja do BPH loguję się moim numerem CIF (9 cyfr). Na kolejnym ekranie hasło maskowane.

CIF to chyba numer klienta w sensie podmiotu? Jesli tak to w koncie
firmowym jeden CIF=wiele loginow, stad nie ma logowania CIF tylko
loginem.

Chyba ze CIF to czlowiek a nie podmiot - to nie wiem czemu ja uzywam
login a nie CIF :) jak wpisalem CIF w oknie logowania to maskownica z
pytania o haslo ma wiecej znakow niz mam istotnie w hasle - taka sama
jest reakcja jak wpisze zly login.

WAM
--
mezrom dan ysazcw -> www.nadmorze.pl <- wczasy nad morzem

Użytkownik "WAM" <nospam@nowam.nopl.pl> napisał w wiadomości grup dyskusyjnych:8e9h8698qjs7sppa1789scul0ie67fg3hj@4ax.com...

On Thu, 9 Sep 2010 10:23:15 +0200, "MarekZ" <brak@adresu.w.pl> wrote:

BPH: login litery+cyfry, haslo maskowalne.

A ja do BPH loguję się moim numerem CIF (9 cyfr). Na kolejnym ekranie hasło
maskowane.

CIF to chyba numer klienta w sensie podmiotu? Jesli tak to w koncie
firmowym jeden CIF=wiele loginow, stad nie ma logowania CIF tylko
loginem.

Chyba ze CIF to czlowiek a nie podmiot - to nie wiem czemu ja uzywam
login a nie CIF :) jak wpisalem CIF w oknie logowania to maskownica z
pytania o haslo ma wiecej znakow niz mam istotnie w hasle - taka sama
jest reakcja jak wpisze zly login.

Tak jak piszesz, CIF to podmiot. W przypadku osoby fizycznej loguje się CIF-em, bo nie ma potrzeby odrębnych profili (abstrahując od istnienia osobowości wielorakich, czego BPH nie wspiera).

W dniu 2010-09-08 23:18, AW pisze:

Jeżeli możecie to proszę o info jak to wygląda w innych bankach.

W Citi masz dowolny login i dowolne, niemaskowane hasło.

--
Raf

Meritum: login 8 cyfr + hasło maskowane, kratki trzeba sobie samemu liczyć, nie są ponumerowane jak w open czy pekao.

SKOK Stefczyka: login 10 cyfr, hasło kompletne (nie pamiętam wymogów, ale typowe), captcha czyli przepisanie tekstu z obrazka.

BOŚ z tokenem: login 8 cyfr, hasło kompletne (jw) + token.


Taa, swoją szosą dlaczego tylko jeden bank (z tego co tu napisano) wymusza co jakiś czas zmianę hasła?

--
Alf/red/

Użytkownik "Alf/red/" <alf_1009@ump.waw.pl> napisał w wiadomości grup dyskusyjnych:i6b7gu$f7e$1@node1.news.atman.pl...

Taa, swoją szosą dlaczego tylko jeden bank (z tego co tu napisano) wymusza co jakiś czas zmianę hasła?

Może dlatego, że to jest głupie?

W dniu 2010-09-09 20:16, MarekZ pisze:

wymusza co jakiś czas zmianę hasła?

Może dlatego, że to jest głupie?

Jak by to powiedzieć... robię w bezpieczeństwie łącznie z bankami, i dziwnym trafem każda firma wymusza zmienianie haseł dla wszelakich kont, niektóre nawet co 30 dni, ale zwykle co 90. Konta "non expiring password" są zatwierdzane w sposób oficjalny, po uzasadnieniu oczywiście że inaczej nie można. Bah, jeden klient uparł się, że hasło ma mieć 15 znaczków + skomplikowanie, ale to insza inszość. Czyli zabezpieczać w ten sposób własne systemy chcą, a pieniądze klientów już nie.

--
Alf/red/

W dniu 2010-09-09 20:27, Alf/red/ pisze:

Bah, jeden klient uparł się, że hasło ma mieć 15
znaczków + skomplikowanie, ale to insza inszość.

Bo są różni zboczeńcy, co się pierdoł naczytali. Praktyka wykazuje, że użytkownik używa haseł na zmianę, zapisuje je na biurku, a jak wymusić na nim wpisanie hasła różnego niż 21 ostatnich to pójdzie do szefa i tak długo będzie chodził aż ten się ugnie. Dopóki nie można robić przelewów tylko po podaniu hasła (jak w ING!) to nie ma problemu. To nie system do odpalania pocisków nuklearnych.

--
Raf

Użytkownik "Alf/red/" <alf_1009@ump.waw.pl> napisał w wiadomości grup dyskusyjnych:i6b8ud$6jl$1@node2.news.atman.pl...

Jak by to powiedzieć... robię w bezpieczeństwie łącznie z bankami, i dziwnym trafem każda firma wymusza zmienianie haseł dla wszelakich kont, niektóre nawet co 30 dni, ale zwykle co 90. Konta "non expiring password" są zatwierdzane w sposób oficjalny, po uzasadnieniu oczywiście że inaczej nie można. Bah, jeden klient uparł się, że hasło ma mieć 15 znaczków + skomplikowanie, ale to insza inszość. Czyli zabezpieczać w ten sposób własne systemy chcą, a pieniądze klientów już nie.

Takie uszczęśliwianie na siłę? Jak klient chce, to przecież nikt mu nie zabrania zmieniać haseł dowolnie często. A wymuszanie tego uważam za bzdurne. Kiedyś dawno temu Rajfi wymuszał co 30 dni i trzeba było mieć chyba różne od dziesięciu ostatnich. Więc co te 30 dni musiałem robić pełen cykl 10 zmian przez 10 haseł, żeby na końcu i tak ustawić takie samo. Ale szybko Rajfiemu to przeszło, zapewne wkurzało to zbyt wiele osób.

"MarekZ" <brak@adresu.w.pl> writes:

za bzdurne. Kiedyś dawno temu Rajfi wymuszał co 30 dni i trzeba było
mieć chyba różne od dziesięciu ostatnich. Więc co te 30 dni musiałem
robić pełen cykl 10 zmian przez 10 haseł, żeby na końcu i tak ustawić
takie samo. Ale szybko Rajfiemu to przeszło, zapewne wkurzało to zbyt
wiele osób.

O, o.

Częste wymuszanie zmiany kończy się tym, że klient:

1. jeśli tylko mu się uda, to zmienia na to samo
2. jeśli musi zmienić na nowe, to zapomina na co zmienił
3. żeby mu się nie powtórzyło więcej 2., to zapisuje hasło wraz z
identyfikatorem.

  MJ

W dniu 2010-09-09 22:46, Michal Jankowski pisze:

musiałem robić pełen cykl 10 zmian przez 10 haseł,

Jest jeszcze "zmiana nie częściej niż x dni". Rajfi na to nie wpadł?

Częste wymuszanie zmiany

Owszem, 15 znaków 30 dni 10 pamiętanych to drakońskie warunki. Biorąc pod uwagę, że i tak user wybiera hasła, yyy, słownikowe :)
http://finance.yahoo.com/family-home/article/108641/If-your-password-is-123456-just-make-it-hack-me.html?mod=family-love_money
Nadal twierdzicie, że typowy user może nie zmieniać haseł latami?

3. żeby mu się nie powtórzyło więcej 2., to zapisuje hasło wraz z
identyfikatorem.

<priv> Michał, jesteś miętkim adminem?

--
Alf/red/

Alf/red/ <alf_1009@ump.waw.pl> writes:

http://finance.yahoo.com/family-home/article/108641/If-your-password-is-123456-just-make-it-hack-me.html?mod=family-love_money
Nadal twierdzicie, że typowy user może nie zmieniać haseł latami?

Twierdzimy, ze wybieranie hasła abcd nie ma nic wspólnego z tym, czy
hasło się nadaje raz na miesiąc, czy raz na 10 lat.

Ponadto częste zmiany haseł ZACHĘCAJĄ usera do nadawania haseł
prostych.

Zamki i klucze do mieszkania też co miesiąc zmieniasz?

  MJ

"Michal Jankowski" kjzbp86t1v7.fsf@ccfs1.fuw.edu.pl

Twierdzimy, ze wybieranie hasła abcd nie ma nic wspólnego z tym,
czy hasło się nadaje raz na miesiąc, czy raz na 10 lat.

Ponadto częste zmiany haseł ZACHĘCAJĄ usera do nadawania haseł prostych.

Po co mi proste? Czy 'Aguranaga0re' jest proste? :)

 -- nie mniej niż 6 znaków
 -- i nie mniej niż jedna cyfra,
 -- i nie mniej niż jedna wielka litera
 -- nie ma znaków spoza cyfr i liter alfabetu
    ,,uniwersalnego'' (czyli liter spoza ASCII)

czyli zwykle wymagania niezwykłych (przepraszam) głupoli...

Proste, zgrabne... Łatwe do zapamiętania. ;)
Takie durne hasła się zapisuje!!! :)

Zamki i klucze do mieszkania też co miesiąc zmieniasz?

No, co Ty... Zamki w drzwiach? Te zmieniamy wtedy, gdy kluczem
(być może pogiętym, wyszczerbionym, skorodowanym) nie można
już obracać bez używania kombinerek... Klucze od mieszkania
zostawiamy sąsiadom, aby sąsiedzi podlewali kwiaty... Dzieci
zostawiają klucze w szatni, razem z ubraniami... Idąc na kajak
czy inną łódkę, zostawiamy klucze ,,na przechowanie''...

Ale hasło?! Hasła pilnujmy jak oka w głowie!!!
Zwłaszcza wtedy, gdy samo hasło na niewiele się
zda, bo potrzebne są SMSy czy tokeny... :)

Hasła... Zostawiamy je w kafejkach czy w bankach...
Ja na przykład podałem w Multi, aby bankierka mogła zalogować
się do mojej karty -- ciekawe, czy nadal pamięta to hasło, bo
jeśli oboje zapomnimy, to co wówczas?

Do FMBanku zapomniałem -- odtworzyłem z zapisków ;) przeglądarek internetowych...
I wcale nie chodzi o Operę i ,,zapamiętywanie'', ale o ślady zostawiane
nieświadomie tam, gdzie ,,klient'' się tego nie spodziewa... :)

Po prostu odpaliłem inny komputer (z którego logowałem się do FM)
i odgrzebałem stamtąd hasło... :) I poskutkowało... :)


Pojęcia nie ma, jakie są hasła do moich kont pocztowych. :)
Hasła do kont bankowych? Muszę przypomnieć sobie chwilę budowania hasła. :)
Kiedyś było prosto -- imię żeńskie, później z podwojoną końcówką, ale że
ładne imiona się skończyły, wymyślałem swoje (Annerienna) i dodawałem do
nich cyfry, gdy była taka potrzeba, czyli życiowa konieczność zwana
wymogiem banku... :)

-=-

Haseł trzeba pilnować -- nawet z tą starannością ujawniają się niepowołanym. ;)

-=-

Hasło w Multi chyba było z innej puli. ;) (nie było imieniem ani nawet
neologizmowatym imieniem) Nie pamiętam już go -- bo do logowania nie
jest mi potrzebne. ;) Przeglądarka pamięta... ;) W razie czego
kopiuję te hasła (hurtem) razem z przeglądarką w kolejne miejsca. ;)

--
   .`'.-.         ._.                           .-.
   .'O`-'     ., ; o.' eneuel@eneuel.comyr.com '.O_'
   `-:`-'.'.  '`\.'`.'    ~'~'~'~'~'~'~'~'~    o.`.,
  o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

W dniu 2010-09-10 10:54, Michal Jankowski pisze:

Ponadto częste zmiany haseł ZACHĘCAJĄ usera do nadawania haseł
prostych.

Zaraz, albo user sam z siebie wymyśla łatwe hasła, albo nie. Jak zwykle stosuje "g5D%aA1L" i mu się każe zmieniać co 3 miechy, to nagle przestawi się na "123456"?

Zamki i klucze do mieszkania też co miesiąc zmieniasz?

Jak młody zgubił klucz, to wymieniłem.
Jakbym np. po wizycie na basenie znalazł na kluczu ślady plasteliny, to też bym tak zrobił.
Jak zauważyłem, że mój kod do domofonu wyciekł (kolega syna użył), poprosiłem administrację o zmianę, i... przestawiłem się na korzystanie z cudzych. Oni nie zmieniają, nawet jeśli wiedzą że wyciekło. Wiesz co usłyszałem? "dziecku łatwo jest zapamiętać kod 9870 i nic mnie nie obchodzi". I mówił to facet, który skarżył się, że mu rower ukradziono ze wspólnego garażu.

--
Alf/red/

"Alf/red/" i6drf8$i1l$1@node2.news.atman.pl

Jak zauważyłem, że mój kod do domofonu wyciekł (kolega syna użył), poprosiłem administrację o zmianę, i... przestawiłem się na korzystanie z cudzych. Oni nie zmieniają, nawet jeśli wiedzą że wyciekło. Wiesz co usłyszałem? "dziecku łatwo jest zapamiętać kod 9870 i nic mnie nie obchodzi". I mówił to facet, który skarżył się, że mu rower ukradziono ze wspólnego garażu.

ROTFL

--
   .`'.-.         ._.                           .-.
   .'O`-'     ., ; o.' eneuel@eneuel.comyr.com '.O_'
   `-:`-'.'.  '`\.'`.'    ~'~'~'~'~'~'~'~'~    o.`.,
  o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

Alf/red/ <alf_1009@ump.waw.pl> writes:

Zaraz, albo user sam z siebie wymyśla łatwe hasła, albo nie. Jak
zwykle stosuje "g5D%aA1L" i mu się każe zmieniać co 3 miechy, to
nagle przestawi się na "123456"?

More or less. Raczej chodzi o to, że pojedyncze by miał jakieś trudne,
a zmieniać będzie na g5D%aA1L.marzec, g5D%aA1L.kwiecien, g5D%aA1L.maj.
Podpatrzysz jedno, to tak, jakbyś podpatrzył wszystkie.

Zamki i klucze do mieszkania też co miesiąc zmieniasz?

Jak młody zgubił klucz, to wymieniłem.
Jakbym np. po wizycie na basenie znalazł na kluczu ślady plasteliny,
to też bym tak zrobił.
Jak zauważyłem, że mój kod do domofonu wyciekł (kolega syna użył),
poprosiłem administrację o zmianę, i... przestawiłem się na
korzystanie z cudzych. Oni nie zmieniają, nawet jeśli wiedzą że

Jak zauważę, że ktoś loguje się do banku na moje hasło, to też to
hasło zmienię.

Tylko że wtedy:
1. Jeśli hasło wystarcza do wyprowadzenia pieniędzy z konta, to
złodziej nie będzie czekać i wyprowadzi przy pierwszym logowaniu.
2. Jeśli nie wystarcza, to i tak nic nie ukradnie poza wiedzą o moim
saldzie. Przykre, ale co tu pomoże zmienianie haseł? Nie daję swojego
hasła koledze syna. Jeśli ktoś podpatrzy moje hasło dziś, to użyje go
dziś, a nie za miesiąc, jak już się zmieni.

Zmiana haseł może odciąć od konta osobę, która hasło _już ukradła_ i
używa równolegle ze mną, a ja tego nie zauważyłem. To w przypadku
pewnych zasobów (np. jakieś miejsce, gdzie co pewien czas pojawiają
się _nowe_ tajne dane) może mieć sens. Tam, gdzie intruz z
długotrwałym dostępem narobi więcej szkód niż przy jednej wizycie. Ale
hasło do konta w banku?

Owszem, jeśli ktoś mi ukradnie dajmy na to kopertę, w której zapisałem
sobie hasło, to wtedy warto zmienić hasło, w nadziei, że zrobimy to
szybciej niż słodziej zgadnie, że to hasło i do czego. Odpiowiednik
tej plasteliny. Ale to ma się nijak do zmian okresowych.

  MJ

W dniu 2010-09-11 10:51, Michal Jankowski pisze:

a zmieniać będzie na g5D%aA1L.marzec, g5D%aA1L.kwiecien, g5D%aA1L.maj.

Ech, no to ja pasuję. Jak userowi nie zależy na jakimś tam dbaniu o swoje pieniądze, to co bank ma się napinać i coś wymuszać? W sumie, to dlaczego wymusza jakieś hocki klocki przy logowaniu - tokeny, captche, wybieranie znaków? Może dopuścić puste hasło i z głowy.

Jak zauważę, że ktoś loguje się do banku na moje hasło, to też to
hasło zmienię.

Ty tak. 95% gospodyń z Gdańska nie. Idą do kafejki albo mają modem z tepsy. Stosują popularne hasła i nie zmieniają. Ale patrz punkt 1.

osobę, która hasło _już ukradła_ i używa równolegle ze mną

Mi by taka świadomość przeszkadzała.

--
Alf/red/

Alf/red/ <alf_1009@ump.waw.pl> writes:

W dniu 2010-09-11 10:51, Michal Jankowski pisze:

a zmieniać będzie na g5D%aA1L.marzec, g5D%aA1L.kwiecien, g5D%aA1L.maj.

Ech, no to ja pasuję. Jak userowi nie zależy na jakimś tam dbaniu o
swoje pieniądze, to co bank ma się napinać i coś wymuszać? W sumie, to
dlaczego wymusza jakieś hocki klocki przy logowaniu - tokeny, captche,
wybieranie znaków? Może dopuścić puste hasło i z głowy.

Hasło g5D%aA1L wystarczająco zabezpiecza przed ODGADNIĘCIEM.
Zmienianie hasła co miesiąc nie zabezpiecza przed PODPATRZENIEM hasła,
bo złodziej nie będzie czekał, aż nadejdzie kolejny termin zmiany
hasła, tylko użyje hasła DZIŚ i teraz.

  MJ

"Michal Jankowski" kjzaannfj4i.fsf@ccfs1.fuw.edu.pl

Hasło g5D%aA1L wystarczająco zabezpiecza przed ODGADNIĘCIEM.
Zmienianie hasła co miesiąc nie zabezpiecza przed PODPATRZENIEM
hasła, bo złodziej nie będzie czekał, aż nadejdzie kolejny termin z
miany hasła, tylko użyje hasła DZIŚ i teraz.

O ile podpatrzy hasło w całości, zanim nastąpi zmiana.
Zwykle podpatrywanie ma charakter etapowy -- tym razem
początek, innym razem środek, a innym razem koniec. :)

No właśnie... Czy na koncie (obok środków i zewnętrzy) są także końce?

-=-

To chyba oczywiste, że okresowość hasłowa jedynie ćwiczy cierpliwość
użytkownika i sprawdza możliwości zmiany hasła -- jakże potrzebną na
wypadek użycia plasteliny. Potrzebę okresowego zmieniania hasła
wprowadzają ludzie bez wyobraźni. :)

--
      450-600 to (60-80)% .                         .                         .               749        .
      VV Ventolin                                   u               .     .                 . 739  .      26                 .
^         . .  lipiec                25 .         .01 .     .           .12 .            20   729            .   . .    02         .
  .   . .       . . .             .    26   . . .   g  03040506   .09 .      14 .      19     724      .25  27              04  06
P   .    VVVV        VV .19 . . .         .         r02VV       .          13         .    21 709    .                     .  05
E07    101112        17    20    VV .    2728    31 .            08              16VV         700                     VV
F  08         .    16          VV23          29     m sierpień       1011      15  VV         690   2324      2829   .01          07
   .-09      13        18      22  24               u                              1718       680 22              30   wrzesień
l '.O_'                      21                30   c          VV                             670                   31
/ o.`.,        1415                                 h          07                             660                         VV
m.;\|/.. ......... ........ ..... ..................y................,,,,,,....;;;;..,,;;..,,.654...,,..,,..,,..,,..,,..,,03..,,,,..

"Michal Jankowski" kjzwrqsfysm.fsf@ccfs1.fuw.edu.pl

Owszem, jeśli ktoś mi ukradnie dajmy na to kopertę, w której zapisałem
sobie hasło, to wtedy warto zmienić hasło, w nadziei, że zrobimy to
szybciej niż słodziej zgadnie, że to hasło i do czego. Odpiowiednik
tej plasteliny. Ale to ma się nijak do zmian okresowych.

Jakoś się ma. Co wówczas, jeśli przeoczysz fakt plastelinowania? :)
Jeśli Twoja okresowość trafiła akurat na plastelinowanie, uratujesz
się. :) Szansa na takie złożenie dwóch zdarzeń jest zazwyczaj żadna. :)
(zazwyczaj -- bo może akurat Twój złodziej dziś kradnie hasło/kluczyk,
ale nie używa tego przez jakiś czas, aby dać Ci czas na zmianę tego hasła)

Zmiana okresowa jest potrzebna o czegoś innego:

Ktoś patrzy Ci na ręce i odczytuje hasło powoli, na przykład
jedną literę w czasie dwóch tygodni -- lub w czasie pięciu
logowań. Zanim odczyta całe hasło, zmienisz je. Szansa na
takie podczytywanie jest już duża w zestawieniu z szansą
z poprzedniej sytuacji -- ale nadal żadna. :)

Klucz (czy raczej zamek wraz kluczem) do drzwi zmieniamy okresowo,
bo ten klucz (i zamek też) psuje się mechanicznie. Hasło nie może
się zepsuć, więc zmiana okresowa ma sens -- utrudnia życie użytkownikowi. :)

Ale można sobie wyobrazić potrzebę takiego okresowego zmieniania:
mając co miesiąc inną kochankę, warto co miesiąc zmieniać hasła
i zamki. ;)

--
   .`'.-.         ._.                           .-.
   .'O`-'     ., ; o.' eneuel@eneuel.comyr.com '.O_'
   `-:`-'.'.  '`\.'`.'    ~'~'~'~'~'~'~'~'~    o.`.,
  o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

Postscriptum... Pod wrażeniem postów tego wątku zmieniłem hasło do konta
                w Multi, które podałem bankierce przy okazji rozpoczynania
III etapu mojej współpracy z Multibankiem... BTW utraconej karty z Multi...
Dzięki tej utracie zaglądam rzadziej do Auchan a częściej do Carrefouru,
gdzie mam w piątki talony (swoiste keszbeki pięcioprocentowe) za zakupy...
Otóż w galerii Carrefoura znalazłem stoisko z tanimi ubrankami -- akurat
dobrymi na kajak... Zamiast w Auchan płacić za spodenki/Bermudy 10 złotych,
mogę tam płacić 5 złotych... :) Zawsze trzeba okazywać Bogu wdzięczność
 -- także wówczas, gdy Auchan zabiera kartę kredytową Multi... Szkoda, że
sezon na kajakowanie miną... :) Inna sprawa, że w Auchan mogę zmierzyć
jedną sztukę jakiegoś ubranka i kupić naraz wiele takich samych w tym
samym rozmiarze, podczas gdy nie wszędzie jest aż tak słodko,
a mierzenie każdej z osobna kupowanej rzeczy nie jest przyjemne... :)

Alf/red/ <alf_1009@ump.waw.pl> writes:

W dniu 2010-09-09 20:16, MarekZ pisze:

wymusza co jakiś czas zmianę hasła?

Może dlatego, że to jest głupie?

Jak by to powiedzieć... robię w bezpieczeństwie łącznie z bankami, i
dziwnym trafem każda firma wymusza zmienianie haseł dla wszelakich
kont, niektóre nawet co 30 dni, ale zwykle co 90. Konta "non expiring

Tylko że:

1. niektórych serwisów używam tylko do podglądu KK, albo jest to konto
do wypłat z bankomatów na którym trzymam < 1KPLN. Po kij mam co miesiąc
hasło zmieniać.  2. Jeśli użytkownik nie czuje, że musi zmieniać hasło to będzie zmieniał
na takie jakie miał, tyle, że dopisze "1" albo "2" na końcu. Założymy
się?  I gdzie tu większe bezpieczeństwo?
KJ

--
http://modnebzdury.wordpress.com/2009/10/01/niewiarygodny-list-prof-majewskiej-wprowadzenie/
FORTRAN is not a flower but a weed -- it is hardy, occasionally blooms,
and grows in every computer.
                -- A.J. Perlis

"Kamil "Jońca"" 877hiuipyj.fsf@alfa.kjonca

na takie jakie miał, tyle, że dopisze "1" albo "2" na końcu. Założymy
się?  I gdzie tu większe bezpieczeństwo?

No, co Ty!! Wówczas hasło urośnie w liczbę. ;)
Raz podmieni 1 na 0 innym razem 0 na 2 a kolejna zmiana przyniesie znów 1... ;)

--
   .`'.-.         ._.                           .-.
   .'O`-'     ., ; o.' eneuel@eneuel.comyr.com '.O_'
   `-:`-'.'.  '`\.'`.'    ~'~'~'~'~'~'~'~'~    o.`.,
  o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

Dziękuje za wszelkie informacje otrzymane od Was.
A nawiązując do tematu logowania i zmiany haseł w Polbanku to uważam że wymuszenie zmiany hasła ma może sens w zakładach pracy, korporacjach ponieważ tam jest większa możliwość podpatrzenia cudzego hasła niż np w bankowości internetowej z której korzystamy najczęściej w domu. Rozmawiałem ostatnio z osoba odpowiedzialną w mojej firmie za bezpieczeństwo systemów informatycznych i doszliśmy do wniosku że w banku to trochę przesada , w firmie może mieć uzasadnienie.
Poza tym Polbank chyba przesadził w drugą stronę z tym bezpieczeństwem. Mam na myśli nieszczęsne certyfikaty , ale to osobna sprawa.
Jeszcze raz dziękuje i pozdrawiam.
Artur

Użytkownik "AW" <a_niepodam_adresu@wp.pl> napisał w wiadomości news:i6f7dn$95v$1news.task.gda.pl...

A nawiązując do tematu logowania i zmiany haseł w Polbanku to uważam że wymuszenie zmiany hasła ma może sens w zakładach pracy, korporacjach ponieważ tam jest większa możliwość podpatrzenia cudzego hasła niż np w bankowości internetowej z której korzystamy najczęściej w domu.

Mnie się wydaje, że komputery domowe są statystycznie gorzej zabezpieczone niż te w pracy i że hasła są częściej podglądane nie z za pleców tylko z drugiej strony.
P.G.

Piotr Gałka wrote:

Użytkownik "AW" <a_niepodam_adresu@wp.pl> napisał w wiadomości
news:i6f7dn$95v$1news.task.gda.pl...

A nawiązując do tematu logowania i zmiany haseł w Polbanku to
uważam że wymuszenie zmiany hasła ma może sens w zakładach
pracy, korporacjach ponieważ tam jest większa możliwość
podpatrzenia cudzego hasła niż np w bankowości internetowej z
której korzystamy najczęściej w domu.

Mnie się wydaje, że komputery domowe są statystycznie gorzej
zabezpieczone niż te w pracy i że hasła są częściej podglądane nie
z za pleców tylko z drugiej strony.
P.G.

Ale skoro tak, to zmiana hasła nie ma znaczenia :-)

witrak()

--

witrak()

Dnia Sat, 11 Sep 2010 21:38:59 +0200, witrak() napisał(a):

Piotr Gałka wrote:

Użytkownik "AW" <a_niepodam_adresu@wp.pl> napisał w wiadomości
news:i6f7dn$95v$1news.task.gda.pl...

A nawiązując do tematu logowania i zmiany haseł w Polbanku to
uważam że wymuszenie zmiany hasła ma może sens w zakładach
pracy, korporacjach ponieważ tam jest większa możliwość
podpatrzenia cudzego hasła niż np w bankowości internetowej z
której korzystamy najczęściej w domu.

Mnie się wydaje, że komputery domowe są statystycznie gorzej
zabezpieczone niż te w pracy i że hasła są częściej podglądane nie
z za pleców tylko z drugiej strony.
P.G.

Ale skoro tak, to zmiana hasła nie ma znaczenia :-)

witrak()

.... bo zmiana może zostać podpatrzona hehe...


--
Zalaczam pozdrowienia i zyczenia powodzenia
Krzysztof 'kw1618' Warszawa - Ursynow
Kontakt z kw1618 przez grupy.3mam.net 'Kontakt'
http://foto.3mam.net/warsaw/slides/Tasmowa_7a_06.php

Krzysztof 'kw1618' z Warszawy wrote:

Dnia Sat, 11 Sep 2010 21:38:59 +0200, witrak() napisał(a):

Piotr Gałka wrote:

Użytkownik "AW" <a_niepodam_adresu@wp.pl> napisał w wiadomości
news:i6f7dn$95v$1news.task.gda.pl...

A nawiązując do tematu logowania i zmiany haseł w Polbanku to
uważam że wymuszenie zmiany hasła ma może sens w zakładach
pracy, korporacjach ponieważ tam jest większa możliwość
podpatrzenia cudzego hasła niż np w bankowości internetowej z
której korzystamy najczęściej w domu.

Mnie się wydaje, że komputery domowe są statystycznie gorzej
zabezpieczone niż te w pracy i że hasła są częściej podglądane nie
z za pleców tylko z drugiej strony.
P.G.

Ale skoro tak, to zmiana hasła nie ma znaczenia :-)

witrak()

.... bo zmiana może zostać podpatrzona hehe...

....z drugiej strony. Sądziłem, że przedpiścy szło o podpatrzenie
nie z zewnętrza tylko z wnętrza kompa. A wtedy zmiana też zostanie
podpatrzona... Więc czy ją się przeprowadzi czy nie  - nie ma
znaczenia... hehe...

witrak()

Tak na marginesie ale w temacie logowania:
Czy podawanie przy logowaniu zawsze pełnego loginu i pełnego hasła na pewno
jest bezpieczne ?



--
Krzysztof 'kw1618' Warszawa - Ursynow
grupy.3mam.net 'Kontakt' dla e-poczty
http://foto.3mam.net/warsaw/07/obr/index.php

"Krzysztof 'kw1618' z Warszawy" i6gqgf$fug$1@inews.gazeta.pl

Tak na marginesie ale w temacie logowania:
Czy podawanie przy logowaniu zawsze pełnego loginu
i pełnego hasła na pewno jest bezpieczne ?

Jest wygodne. :) Nic nie jest bezpieczne. :)

--
   .`'.-.         ._.                           .-.
   .'O`-'     ., ; o.' eneuel@eneuel.comyr.com '.O_'
   `-:`-'.'.  '`\.'`.'    ~'~'~'~'~'~'~'~'~    o.`.,
  o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

"AW" i68ujj$fmm$1@news.task.gda.pl

Być może było -- nie chcę czytać całego wątku. :)

Moim zdaniem warto zezwolić na drobne błędy we wprowadzaniu
długich haseł. Jeśli ktoś wprowadzając kilkunastoznakowe
hasło jeden znak wprowadzi błędnie, system powinien to
przyjmować jako wprowadzenie bezbłędne. :)

Można też cwanie liczyć próby wprowadzenia błędnego hasła.

 -- jeśli całe hasło jest złe, 6 prób (zamiast stresujących 3)

 -- ale jeśli tylko jeden znak jest źle wprowadzony,
    próba mogłaby być ignorowana w czasie liczenia,
    o ile kolejnym razem nie dojdzie do pomyłki na
    tym samym polu

 -- podobnie mogłaby być inaczej liczona próba
    wprowadzenia hasła z wciśniętym kapslokiem

--
                    .450-600 to (60-80)%.                         .               749        .                                     .
VV Ventolin                             u               .     .                 . 739  .      26                 .           . .1213
^  lipiec                25 .         .01 .     .           .12 .            20   729            .   . .    02         . .    11
    . . .             .    26   . . .   g  03040506   .09 .      14 .      19     719      .25  27              04  06  08
P        VV .19 . . .         .         r02VV       .          13         .    21 709    .                     .  05
E        17    20    VV .    2728    31 .            08              16VV         695                     VV               .10
F .    16          VV23          29     m sierpień       1011      15  VV         690   2324      2829   .01          07  09
 13        18      22  24               u                              1718       680 22              30   wrzesień
l                21                30   c          VV                             670                   31
/  1415                                 h          07                             660                         VV
m..... ........ ..... ..................y................,,,,,,....;;;;..,,;;..,,.654...,,..,,..,,..,,..,,..,,03..,,,,..,,..,,......

Użytkownik "Eneuel Leszek Ciszewski" <prosze@czytac.fontem.lucida.console> napisał w wiadomości news:i6nbhd$fsk$1inews.gazeta.pl...

Być może było -- nie chcę czytać całego wątku. :)

Moim zdaniem warto zezwolić na drobne błędy we wprowadzaniu
długich haseł. Jeśli ktoś wprowadzając kilkunastoznakowe
hasło jeden znak wprowadzi błędnie, system powinien to
przyjmować jako wprowadzenie bezbłędne. :)

Zakładasz, że banki są w stanie stwierdzić, ile znaków jest błędnych (przechowują hasła w oryginalnej postaci).
Teraz sobie uświadomiłem, że przy logowaniu z maskowaniem bank musi przechowywać hasło w jawnej postaci (a nie wydłużone funkcją mieszającą).
Wydaje mi się to poważnym błędem, bo oznacza dostęp w banku do hasła użytkownika.
P.G.

"Piotr Gałka" 4c8f37e2$1@news.home.net.pl

Użytkownik "Eneuel Leszek Ciszewski" <prosze@czytac.fontem.lucida.console> napisał w wiadomości news:i6nbhd$fsk$1inews.gazeta.pl...

Być może było -- nie chcę czytać całego wątku. :)

Moim zdaniem warto zezwolić na drobne błędy we wprowadzaniu
długich haseł. Jeśli ktoś wprowadzając kilkunastoznakowe
hasło jeden znak wprowadzi błędnie, system powinien to
przyjmować jako wprowadzenie bezbłędne. :)

Zakładasz, że banki są w stanie stwierdzić, ile znaków jest błędnych (przechowują hasła w oryginalnej postaci).

Zakładam, że mogą mieć możliwość stwierdzenia, ile znaków jest
błędnych i jak duże są to błędy -- na przykład czy wciśnięty
kapslok lub doszło do wstukania klawisza leżącego ,,obok''
klawisza ,,dobrego''.

Jak zrealizować tę możliwość? -- na razie nie zastanawiam się nad
tym, jako że najpierw trzeba by zmian w podejściu (myśleniu o) do
zasad ,,bezpieczeństwa'' logowania. :)

Teraz sobie uświadomiłem, że przy logowaniu z maskowaniem bank musi przechowywać hasło w jawnej postaci (a nie wydłużone funkcją mieszającą).
Wydaje mi się to poważnym błędem, bo oznacza dostęp w banku do hasła użytkownika.

A zwykły Kowalski uważa, że niebezpieczne jest dopiero podawanie
całego hasła i całego loginu. :)

--
   .`'.-.         ._.                           .-.
   .'O`-'     ., ; o.' eneuel@eneuel.comyr.com '.O_'
   `-:`-'.'.  '`\.'`.'    ~'~'~'~'~'~'~'~'~    o.`.,
  o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

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

Teraz sobie uświadomiłem, że przy logowaniu z maskowaniem bank musi
przechowywać hasło w jawnej postaci (a nie wydłużone funkcją
mieszającą).
Wydaje mi się to poważnym błędem, bo oznacza dostęp w banku do hasła
uĹźytkownika.

Bank zawsze ma dostep do hasla usera. Nawet gdyby zaszyfrowanie
(zrobienie skrotu itp) bylo realne kryptograficzne (przy dluzszych
haslach), to przy najblizszym uzyciu hasla bank znow je bedzie znal.
W kazdym razie uzytkownik nigdy nie bedzie mial gwarancji, ze jego haslo
jest dobrze chronione przez bank.
--
Krzysztof Halasa

On 9/14/2010 4:09 PM, Krzysztof Halasa wrote:

Bank zawsze ma dostep do hasla usera.

no rozroznijmy bank od aplikacji chodzącej na serwerze.
to nie to samo.

"witek" i6oota$735$3@inews.gazeta.pl

no rozroznijmy bank od aplikacji chodzącej na serwerze. to nie to samo.

Rzeczywistość jest bardziej skomplikowana, ale chyba nie należy
podejrzewać Aliora o stosowanie wyrafinowanych metod. :)

Kiedyś to się nazywało ,,wiem, ale nie powiem'' -- nie
znam postępów czynionych ostatnio. :)

-=-

Wracając do hasłologii i nadzabezpieczeń...
Nawrzucałem w sklepie do wózka zakupów i jadę z tym na nieruchome
schody ruchome... Schody proponują mi podanie hasła uruchomieniowego...
Ani klawiatury nie ma rozsądnej, ani ja tego hasła nie znam, a zapewne
wiadome hasło z Seksmisji by nie przeszło... ;)

No i zepchnąłem wózek ,,przemocą''...
Raczej nie tyle schodami to coś było, co pochylnią ruchomą -- tyle,
że wówczas nieruchomą. :) Wózek blokowany był tam zmyślnym kształtem
,,okołokół'' i nie zsuwał się samoistnie pod wpływem znanej wszystkim
sile G... :) Musiałem pchać go brutalnie!!!

--
   .`'.-.         ._.                           .-.
   .'O`-'     ., ; o.' eneuel@eneuel.comyr.com '.O_'
   `-:`-'.'.  '`\.'`.'    ~'~'~'~'~'~'~'~'~    o.`.,
  o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

witek <witek7205@gazeta.pl.invalid> writes:

Bank zawsze ma dostep do hasla usera.

no rozroznijmy bank od aplikacji chodzącej na serwerze.
to nie to samo.

No ale przeciez nie chodzi o system dostepny dla "zwyklego" personelu.
Aplikacja sprawdzajaca haslo musi je znac (przynajmniej w momencie
sprawdzania), na to nie ma rady oprocz kryptografii asymetrycznej.

Z tym, ze to jest nieco trudniejsze dla "Kowalskiego" niz haslo
i formularz na WWW. Zwlaszcza jesli ma byc zrobione dobrze.
--
Krzysztof Halasa

Użytkownik "Krzysztof Halasa" <khc@pm.waw.pl> napisał w wiadomości news:m3r5gwq9bu.fsfintrepid.localdomain...

Aplikacja sprawdzajaca haslo musi je znac (przynajmniej w momencie
sprawdzania), na to nie ma rady oprocz kryptografii asymetrycznej.

Według mnie nie musi.
Hasło powinno być na komputerze użytkownika wydłużane kryptograficznie (np. milion operacji mieszania) i dopiero takie wysyłane do systemu banku i w systemie tylko takie przechowywane. Przy zmianie hasła również do systemu trafiają tylko wersje wydłużone starego i nowego.
P.G.

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

Aplikacja sprawdzajaca haslo musi je znac (przynajmniej w momencie
sprawdzania), na to nie ma rady oprocz kryptografii asymetrycznej.

Według mnie nie musi.
Hasło powinno być na komputerze użytkownika wydłużane kryptograficznie
(np. milion operacji mieszania)

Oczywiscie zwieksza to nieco moc obliczeniowa potrzebna do zlamania
(milion = 20 bitow), ale to dosc nieefektywne, jaka to ma zalete
w stosunku do kryptografii asymetrycznej? Bo ta ostatnia ma potezna
zalete, bank nie moze takiej operacji sam spreparowac.

Takie wydluzanie zwiekszy czas generowania teczowych tablic, ale ani nie
beda one wieksze, ani szukanie w nich nie bedzie wolniejsze.
--
Krzysztof Halasa

Użytkownik "Krzysztof Halasa" <khc@pm.waw.pl> napisał w wiadomości news:m31v8uq3z3.fsfintrepid.localdomain...

Według mnie nie musi.
Hasło powinno być na komputerze użytkownika wydłużane kryptograficznie
(np. milion operacji mieszania)

Oczywiscie zwieksza to nieco moc obliczeniowa potrzebna do zlamania
(milion = 20 bitow),

Nieco = milion razy. Jeśli coś teraz nie daje się (w rozsądnym czasie) złamać, ale za 10 lat dostępna moc obliczeniowa pozwoliłaby to złamać w jeden dzień to stosowanie wydłużenia powoduje, że za te 10 lat trzeba będzie milion dni. Dopiero za kolejne 10 lat wystarczy jeden dzień.

ale to dosc nieefektywne,

To jest jedna sekunda zwłoki na moim (chyba 5 letnim) PC i wydaje mi się, że to nigdy nie musi być wykonywane nigdzie indziej jak tylko na komputerze logującego się użytkownika.

jaka to ma zalete
w stosunku do kryptografii asymetrycznej? Bo ta ostatnia ma potezna
zalete, bank nie moze takiej operacji sam spreparowac.

O kryptografii asymetrycznej wiem za mało, aby się odpowiedzialnie wypowiadać.
Nie rozumiem dlaczego bank nie może sam spreparować. Jeśli jak wynika z poprzednich dyskusji przynajmniej niektóre banki przechowują hasła klientów czyli znają wszystkie informacje, którymi posługuje się klient wykonując jakąś operację (kod jednorazowy wysyłany SMS-em też bank zna).

Takie wydluzanie zwiekszy czas generowania teczowych tablic, ale ani nie
beda one wieksze, ani szukanie w nich nie bedzie wolniejsze.

Z tego co wiem o kryptografii (wiem niewiele, bo tylko z konieczności musiałem jedną książkę przeczytać (asymetryczną pominąłem)) to przy określaniu złożoności ataku czas jednego porównania z zawartością tabeli przyjmuje się za jedną operację bez względu na wielkość porównywanych obiektów. Hasła mają to do siebie, że zazwyczaj są za krótkie. Jakieś badania pokazały, że typowo na jeden znak przypada około 3..4 bitów niepewności (bo ludzie nie stosują w pełni losowego następstwa znaków). 12 znakowe hasło to byłoby około 48 bitów. Jego wydłużenie o 20 bitów to zawsze coś (wydłuża czas ataku milion razy).
Dodatkowo wydłużanie z dodaniem pewnej jawnej liczby, ale dla każdego użytkownika innej powoduje, że atakujący nie może stworzyć jednej tablicy dla wszystkich użytkowników, ale musi tworzyć osobne tablice dla każdego użytkownika.
Jeśli atakujący atakuje system haseł dla 1000 użytkowników to bez wydłużania dla każdego domniemanego hasła musi wykonać jedno porównanie czyli 1000 operacji. Z wydłużaniem dla tego jednego hasła musi wykonać 1 001 000 operacji (wydłużenie milion i 1000 porównań), dla wydłużenia z dodaniem tej jawnej liczby musi wykonać 1 000 001 000 operacji (1000 wydłużeń po milion i 1000 porównań). Z tysiąca operacji zrobił się miliard operacji dla sprawdzenia jednego domniemanego hasła u wszystkich. To jest chyba pewna różnica, a jedyny koszt to dodatkowa 1s czekania przy każdym logowaniu.
Gdyby jedna operacja zajmowała 1ns (1000 razy szybciej niż na moim PC) to sprawdzenie 2^48 haseł bez wydłużania zajmie 3.2 dnia (dla jednego użytkownika), a z wydłużaniem 3200000 dni - prawie 10 tysięcy lat. Faktyczna różnica będzie większa, bo jednak porównanie trwa znacznie krócej niż pojedyncza operacja mieszania.
P.G.

On Thu, 16 Sep 2010 11:23:39 +0200, Piotr Gałka
<piotr.galka@CUTTHISmicromade.pl> wrote:

Użytkownik "Krzysztof Halasa" <khc@pm.waw.pl> napisał w wiadomości news:m31v8uq3z3.fsfintrepid.localdomain...

Według mnie nie musi.
Hasło powinno być na komputerze użytkownika wydłużane kryptograficznie
(np. milion operacji mieszania)

Oczywiscie zwieksza to nieco moc obliczeniowa potrzebna do zlamania
(milion = 20 bitow),

Nieco = milion razy. Jeśli coś teraz nie daje się (w rozsądnym czasie) złamać, ale za 10 lat dostępna moc obliczeniowa pozwoliłaby to złamać w jeden dzień to stosowanie wydłużenia powoduje, że za te 10 lat trzeba będzie milion dni. Dopiero za kolejne 10 lat wystarczy jeden dzień.

ale milion mieszań wcale nie oznacza, że złamanie tego będzie
trudniejsze niż po mieszaniu 1-krotnym.

BTW: co rozumiesz przez "mieszanie"? Permutację bitów?

O kryptografii asymetrycznej wiem za mało, aby się odpowiedzialnie wypowiadać.
Nie rozumiem dlaczego bank nie może sam spreparować. Jeśli jak wynika z

Bo tak właśnie działa kryptografia asymetryczna: jeden klucz ma
użytkownik i nikomu go nie ujawnia, a mimo to można stwierdzic
zgodność jawnego klucza publicznego z tym prywatnym.
--
pozdrawiam,
Jarek Andrzejewski

Użytkownik "Jarek Andrzejewski" <ptja.pl@gmail.com> napisał w wiadomości news:04p396tlpn7sib7ojpr3067jkm0b7n8lbh4ax.com...

ale milion mieszań wcale nie oznacza, że złamanie tego będzie
trudniejsze niż po mieszaniu 1-krotnym.

BTW: co rozumiesz przez "mieszanie"? Permutację bitów?

Nie. Założenie jest zawsze takie, że algorytm jest znany atakującemu. Milion znanych!! permutacji zastąpiłby jedną wynikową.
Przez mieszanie rozumiem np. SHA-256. Miliona mieszań SHA-256 nie da się zastąpić jednym innym (przynajmniej na razie algorytm SHA-256 nie jest złamany).
A chodzi o nakład obliczeń potrzebny atakującemu do sprawdzenia jednej hipotezy.

O kryptografii asymetrycznej wiem za mało, aby się odpowiedzialnie
wypowiadać.
Nie rozumiem dlaczego bank nie może sam spreparować. Jeśli jak wynika z

Bo tak właśnie działa kryptografia asymetryczna: jeden klucz ma
użytkownik i nikomu go nie ujawnia, a mimo to można stwierdzić
zgodność jawnego klucza publicznego z tym prywatnym.

Przypuszczałem, że ustanowienie sesji między komputerem a systemem banku opiera się na kryptografii asymetrycznej i że to jest to, co ma uniemożliwić bankowi spreparowanie operacji.
Teraz rozumiem, że chodzi o sytuację, gdy każdy użytkownik posiada klucz prywatny - pewnie to jest najlepsze rozwiązanie.

Generalnie wypowiadałem się na temat: Jak powinno wyglądać logowanie, przy założeniu, że użytkownik identyfikuje się zestawem login, hasło.
P.G.

On Thu, 16 Sep 2010 13:31:22 +0200, Piotr Gałka
<piotr.galka@CUTTHISmicromade.pl> wrote:

Użytkownik "Jarek Andrzejewski" <ptja.pl@gmail.com> napisał w wiadomości news:04p396tlpn7sib7ojpr3067jkm0b7n8lbh4ax.com...

ale milion mieszań wcale nie oznacza, że złamanie tego będzie
trudniejsze niż po mieszaniu 1-krotnym.

BTW: co rozumiesz przez "mieszanie"? Permutację bitów?

Nie. Założenie jest zawsze takie, że algorytm jest znany atakującemu. Milion znanych!! permutacji zastąpiłby jedną wynikową.
Przez mieszanie rozumiem np. SHA-256. Miliona mieszań SHA-256 nie da się zastąpić jednym innym (przynajmniej na razie algorytm SHA-256 nie jest złamany).
A chodzi o nakład obliczeń potrzebny atakującemu do sprawdzenia jednej hipotezy.

A masz coś na poparcie tezy, że SHA-256 wykonany milion razy będzie
bezpieczniejszy niż wykonany 1 raz?
Tak naprawdę idea łamania funkcji skrótu sprowadza się do jednego: tak
zmodyfikować wiadomość (lub inaczej: znaleźć taką wiadomość), aby
skrót był taki sam, jak dla wiadomości oryginalnej.

Można wielokrotnie wykonywać przekształcenie, ale idea jest taka:
http://en.wikipedia.org/wiki/Hash_chain
albo taka (połączenie wyniku kilku algprytmów):
http://en.wikipedia.org/wiki/Cryptographic_hash_function#Concatenation_of_cryptographic_hash_functions


A zamiast "mieszania" chyba lepiej użyć nazwy "funkcji skrótu".

Teraz rozumiem, że chodzi o sytuację, gdy każdy użytkownik posiada klucz prywatny - pewnie to jest najlepsze rozwiązanie.

to właśnie jest istota algorytmu _asymetrycznego_. Jeśli klucz jest
znany obu stronom - to jest kryptografia symetryczna.

Użytkownik "Jarek Andrzejewski" <ptja.pl@gmail.com> napisał w wiadomości news:9d0496djmqta15hb78lectj281eds467j84ax.com...

A masz coś na poparcie tezy, że SHA-256 wykonany milion razy będzie
bezpieczniejszy niż wykonany 1 raz?

A ja stawiałem taką tezę ?
Nie mówię o łamaniu SHA-256 tylko o ataku na hasła poprzez sprawdzanie pewnej listy prawdopodobnych haseł w oparciu o domniemane zwyczaje użytkowników. Chodzi jedynie o pozorne "wydłużenie" hasła użytkownika o jakieś 20 bitów. Jeśli atakujący sprawdzałby hasła z przestrzeni 2^48 to po takim "wydłużeniu" nadal musi sprawdzić 2^48, ale pracy będzie miał przy tym jakby sprawdzał hasła z przestrzeni 2^68 (licząc liczbę niezbędnych operacji kryptograficznych do wykonania, porównanie=operacja, SHA=operacja). Gdyby chciał pominąć to "wydłużenie" i atakować poprzez sprawdzanie wszystkich możliwych wyników to musiałby sprawdzać 2^256 kombinacji, bo tu nie da się stworzyć listy prawdopodobnych wybranych przez użytkownika wartości.
Zakładam, że taki atak jest znacznie prostszy od próby łamania SHA-256 i wykonanie SHA-256 milion razy nie ma na celu jego wzmacniania.

Tak naprawdę idea łamania funkcji skrótu sprowadza się do jednego:

To (według mnie) nie jest tematem tej dyskusji.

Można wielokrotnie wykonywać przekształcenie, ale idea jest taka:
http://en.wikipedia.org/wiki/Hash_chain

Rzuciłem (niedokładnie) okiem - to jest jakaś zupełnie inna bajka - chodzi o to, aby za każdym razem inne hasło było przesyłane. Jeśli łącze jest odpowiednio zabezpieczone to nie widzę takiej potrzeby.

albo taka (połączenie wyniku kilku algprytmów):
http://en.wikipedia.org/wiki/Cryptographic_hash_function#Concatenation_of_cryptographic_hash_functions

Nie mam powodów aby wątpić, że poskładanie wielu funkcji hash nie jest bezpieczniejsze od wykonania jedynie najmocniejszej z nich.

A zamiast "mieszania" chyba lepiej użyć nazwy "funkcji skrótu".

Zgodzę się, choć dla mnie słowo "mieszanie" lepiej oddaje wykonywaną operację, a "funkcja skrótu" sugeruje, że wynik jest krótszy od oryginału, a to akurat w tym przypadku raczej nie jest prawdą (nigdy nie stosowałem jeszcze 32 znakowych haseł).
P.G.

On Thu, 16 Sep 2010 14:54:37 +0200, Piotr Gałka
<piotr.galka@CUTTHISmicromade.pl> wrote:

Użytkownik "Jarek Andrzejewski" <ptja.pl@gmail.com> napisał w wiadomości news:9d0496djmqta15hb78lectj281eds467j84ax.com...

A masz coś na poparcie tezy, że SHA-256 wykonany milion razy będzie
bezpieczniejszy niż wykonany 1 raz?

A ja stawiałem taką tezę ?

Tak.

Cytat (Message-ID: <4c908574$1@news.home.net.pl>): Hasło powinno być na komputerze użytkownika wydłużane kryptograficznie
(np. milion operacji mieszania) i dopiero takie wysyłane do systemu
banku /.../

Teraz piszesz:

Chodzi jedynie o pozorne "wydłużenie" hasła użytkownika o jakieś 20 bitów. Jeśli atakujący sprawdzałby hasła z przestrzeni 2^48 to po

a to nic nowego: jest to tak zwany "salt" (czyli dodanie jawnych
bitów) i od zarania dziejów jest stosowany np. w linuksie (tam jest
bodajże 12-bitowy).

A "salt" ma tę przewagę nad Twoją propozycją, że nawet dla
identycznych haseł da różne skróty.
--
pozdrawiam,
Jarek Andrzejewski

Użytkownik "Jarek Andrzejewski" <ptja.pl@gmail.com> napisał w wiadomości news:ru5496h1um3uck243n521d3231fb33nnge4ax.com...

A masz coś na poparcie tezy, że SHA-256 wykonany milion razy będzie
bezpieczniejszy niż wykonany 1 raz?

A ja stawiałem taką tezę ?

Tak.

Cytat (Message-ID: <4c908574$1@news.home.net.pl>):

Hasło powinno być na komputerze użytkownika wydłużane kryptograficznie
(np. milion operacji mieszania) i dopiero takie wysyłane do systemu
banku /.../

Tu nie ma nic o zwiększeniu bezpieczeństwa funkcji hash przez jej wielokrotne wykonanie, a jedynie o wydłużeniu hasła.

Teraz piszesz:

Chodzi jedynie o pozorne "wydłużenie" hasła użytkownika o
jakieś 20 bitów. Jeśli atakujący sprawdzałby hasła z przestrzeni 2^48 to po

Czyli powtarzam to samo, co wcześniej napisałem, bo wygląda, że nie zostało zrozumiane.

a to nic nowego: jest to tak zwany "salt" (czyli dodanie jawnych
bitów) i od zarania dziejów jest stosowany np. w linuksie (tam jest
bodajże 12-bitowy).

W tym fragmencie nic nie piszę o dodaniu jawnych bitów. "Wydłużenie" to nie jest dodanie soli tylko wielokrotne przeliczenie funkcji skrótu.
O soli pisałem tak: (Message-ID: <4c91e223$1@news.home.net.pl> )
-- -- -- -- --
Dodatkowo wydłużanie z dodaniem pewnej jawnej liczby, ale dla każdego
użytkownika innej powoduje, że atakujący nie może stworzyć jednej tablicy
dla wszystkich użytkowników, ale musi tworzyć osobne tablice dla każdego
użytkownika.
-- -- -- -- --

A "salt" ma tę przewagę nad Twoją propozycją, że nawet dla
identycznych haseł da różne skróty.

Sól da różne skróty dla identycznych haseł, a wydłużenie zwiększa nakład obliczeniowy atakującego.

Chodzi o obliczenie typu: X0=0; Xi=SHA(Xi-1||p||s), dla i=1,...,r, p-hasło, s-sól, || - połączenie tekstów, Xi-1 - X o indeksie i-1.
Wydłużenie o 20 bitów to r = milion, a sól to s w tym algorytmie.
Wydłużenie to co innego, a sól to co innego. Ja piszę o wydłużeniu to Ty zauważasz: "a to nic nowego to sól".
Jak napiszę o soli (już pisałem wczoraj koło 11-tej) to w odpowiedzi zobaczę: "a to nic nowego to wydłużanie".
Dla mnie chaos nie dyskusja.
P.G.

On Thu, 16 Sep 2010 16:28:09 +0200, Piotr Gałka
<piotr.galka@CUTTHISmicromade.pl> wrote:

Tu nie ma nic o zwiększeniu bezpieczeństwa funkcji hash przez jej wielokrotne wykonanie, a jedynie o wydłużeniu hasła.

do wydłużenia hasła wystarczy wygenerowanie (pseudo)losowo
parudziesięciu bitów. Nie rozumiem więc, po co proponujesz "milion
operacji mieszania".

W tym fragmencie nic nie piszę o dodaniu jawnych bitów. "Wydłużenie" to nie jest dodanie soli tylko wielokrotne przeliczenie funkcji skrótu.

możesz dać jakiś link do tej metody? Nie spotkałem się z
wykorzystaniem "miliona operacji mieszania" w celu wydłużenia hasła.

Sól da różne skróty dla identycznych haseł, a wydłużenie zwiększa nakład obliczeniowy atakującego.

ale skąd mają się te dodatkowe bity wziąć?

Chodzi o obliczenie typu: X0=0; Xi=SHA(Xi-1||p||s), dla i=1,...,r, p-hasło, s-sól, || - połączenie tekstów, Xi-1 - X o indeksie i-1.

podaj jakiś link, bo nie jestem przekonany, że milion takich
przekształceń jakoś istotnie zwiększa bezpieczeństwo - przekształcenie
jest deterministyczne, a p i s są jedynymi niewiadomymi.
--
pozdrawiam,
Jarek Andrzejewski

Użytkownik "Jarek Andrzejewski" <ptja.pl@gmail.com> napisał w wiadomości news:7fa496lekk93851qg8c6aus7fj7m3kip414ax.com...

do wydłużenia hasła wystarczy wygenerowanie (pseudo)losowo
parudziesięciu bitów. Nie rozumiem więc, po co proponujesz "milion
operacji mieszania".

Przy (podobno) obowiązkowym w kryptologii założeniu, że algorytmy są znane atakującemu wygenerowanie pseudolosowo nic nie daje, a wygenerowanie losowo nie ma tu sensu.
Używam słowa "wydłużenie" w zupełnie innym sensie.
Mam wrażenie, że nie czytasz tego co piszę. Już 2 razy tłumaczyłem jaki jest cel czyli odpowiedź na pytanie "po co".

W tym fragmencie nic nie piszę o dodaniu jawnych bitów. "Wydłużenie" to nie
jest dodanie soli tylko wielokrotne przeliczenie funkcji skrótu.

możesz dać jakiś link do tej metody? Nie spotkałem się z
wykorzystaniem "miliona operacji mieszania" w celu wydłużenia hasła.

Nie mam linku. Informacja pochodzi z książki którą już wspominałem wczoraj rano:
Message-ID: <4c9090b0$1@news.home.net.pl>
-- -- -- -- -- -- -- -
Cytat z książki napisanej w 2003 roku (polskie wydanie 2004) "Kryptografia w
praktyce":
"22.2.1. Solenie i rozciąganie..... Techniki te są tak proste i naturalne,
że powinny być stosowane we wszystkich systemach haseł. Ignorowanie ich nie
ma żadnego wytłumaczenia."
-- -- -- -- -- -- -- --
Dodam, że autorzy to Neils Ferguson i Bruce Schneier. Głowy nie dam, ale to chyba światowi eksperci w zakresie bezpieczeństwa systemów kryptograficznych.
Opisywali tam też karygodny błąd w implementacji wydłużania (rozciągania) w jakimś systemie którego bezpieczeństwo mieli zbadać. Programista, aby użytkownik nie musiał czekać 1s aż się ten milion operacji wykona zapamiętywał CRC hasła i szybko sprawdzał, że OK, a potem brał się za ten milion przeliczeń.
P.G.

Sól da różne skróty dla identycznych haseł, a wydłużenie zwiększa nakład
obliczeniowy atakującego.

ale skąd mają się te dodatkowe bity wziąć?

Tłumaczyłem 2 posty wyżej (cytat):
-- -- -- -- -- --
Chodzi jedynie o pozorne "wydłużenie" hasła użytkownika o
jakieś 20 bitów. Jeśli atakujący sprawdzałby hasła z przestrzeni 2^48 to po
takim "wydłużeniu" nadal musi sprawdzić 2^48, ale pracy będzie miał przy tym
jakby sprawdzał hasła z przestrzeni 2^68 (licząc liczbę niezbędnych operacji
kryptograficznych do wykonania, porównanie=operacja, SHA=operacja).
-- -- -- -- -- -- -
To nie są prawdziwe bity, tylko pozorne - że pracy jest tyle jakby one były.

Chodzi o obliczenie typu: X0=0; Xi=SHA(Xi-1||p||s), dla i=1,...,r, p-hasło,
s-sól, || - połączenie tekstów, Xi-1 - X o indeksie i-1.

podaj jakiś link, bo nie jestem przekonany, że milion takich
przekształceń jakoś istotnie zwiększa bezpieczeństwo - przekształcenie
jest deterministyczne, a p i s są jedynymi niewiadomymi.

Znów szybkość kosztem dokładności (chaos): s nie jest niewiadomą - jest jawne z założenia.
Nie zwiększa bezpieczeństwa w sensie łamania algorytmów, ale milion razy zwiększa koszt ataku "brute force" na hasła.
P.G.

On Thu, 16 Sep 2010 17:17:13 +0200, Piotr Gałka
<piotr.galka@CUTTHISmicromade.pl> wrote:

Cytat z książki napisanej w 2003 roku (polskie wydanie 2004) "Kryptografia w
praktyce":

Mam, można rzec, że to "biblia".

Dodam, że autorzy to Neils Ferguson i Bruce Schneier. Głowy nie dam, ale to chyba światowi eksperci w zakresie bezpieczeństwa systemów

zgadza się.
Fakt, że ostatnio jej nie czytałem.

Nie zwiększa bezpieczeństwa w sensie łamania algorytmów, ale milion razy zwiększa koszt ataku "brute force" na hasła.

Tak, to może mieć sens.
Sprawdzę, jak będę miał książkę pod ręką.

--
pozdrawiam,
Jarek Andrzejewski

Użytkownik "Jarek Andrzejewski" <ptja.pl@gmail.com> napisał w wiadomości news:hbd49611p8rs13ljc957krk6qds2qjb7m54ax.com...

Nie zwiększa bezpieczeństwa w sensie łamania algorytmów, ale milion razy
zwiększa koszt ataku "brute force" na hasła.

Tak, to może mieć sens.

Zachodzę w głowę dlaczego musiałem to 3 razy tłumaczyć ?
P.G.

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

Oczywiscie zwieksza to nieco moc obliczeniowa potrzebna do zlamania
(milion = 20 bitow),

Nieco = milion razy. Jeśli coś teraz nie daje się (w rozsądnym czasie)
złamać, ale za 10 lat dostępna moc obliczeniowa pozwoliłaby to złamać
w jeden dzień to stosowanie wydłużenia powoduje, że za te 10 lat
trzeba będzie milion dni. Dopiero za kolejne 10 lat wystarczy jeden
dzień.

Tylko to "jesli". Jesli juz robimy to na maszynce uzytkownika, to lepiej
zrobic to tak, zeby nie dalo sie tego skutecznie zlamac nawet za 50 lat.
No chyba ze jacys Chinczycy wymysla metode, kto wie - ale to zagrozenie
jest zawsze.

Nie rozumiem dlaczego bank nie może sam spreparować. Jeśli jak wynika
z poprzednich dyskusji przynajmniej niektóre banki przechowują hasła
klientów czyli znają wszystkie informacje, którymi posługuje się
klient wykonując jakąś operację

Ale przy kryptografii asymetrycznej nawet jesli klient posiada
(opcjonalne) haslo, to bank go nie zna. Klient moze zmienic haslo
w kazdej chwili, bez udzialu banku.
Mam na mysli oczywiscie normalne zastosowanie, a nie "przechowywanie
klucza prywatnego na serwerze banku".

Hasła mają to do siebie, że zazwyczaj są za
krótkie. Jakieś badania pokazały, że typowo na jeden znak przypada
około 3..4 bitów niepewności (bo ludzie nie stosują w pełni losowego
następstwa znaków). 12 znakowe hasło to byłoby około 48 bitów. Jego
wydłużenie o 20 bitów to zawsze coś (wydłuża czas ataku milion razy).
Dodatkowo wydłużanie z dodaniem pewnej jawnej liczby, ale dla każdego
użytkownika innej powoduje, że atakujący nie może stworzyć jednej
tablicy dla wszystkich użytkowników, ale musi tworzyć osobne tablice
dla kaĹźdego uĹźytkownika.

Wszystko pieknie, ale problem lezy zupelnie w czyms innym. Jesli klient
podaje haslo swojemu programowi, i nastepnie jest ono "wydluzane"
i wysylane do banku, to co przeszkodzi bankowi w przechwyceniu owego
"wydluzonego" hasla, i w przeprowadzeniu fraudu korzystajac z niego?
Oryginalne "krotkie" haslo nie jest do tego potrzebne.

Atak "brutalny" na 12-znakowe haslo bylby niepraktyczny z powodow
ekonomicznych, chyba ze haslo znajdowaloby sie w slowniku - ale wtedy
nie mozna mowic o 48 bitach, tyle nie bedzie nawet po "wydluzeniu".
--
Krzysztof Halasa

Użytkownik "Krzysztof Halasa" <khc@pm.waw.pl> napisał w wiadomości news:m3bp7wt294.fsfintrepid.localdomain...

Nieco = milion razy. Jeśli coś teraz nie daje się (w rozsądnym czasie)
złamać, ale za 10 lat dostępna moc obliczeniowa pozwoliłaby to złamać
w jeden dzień to stosowanie wydłużenia powoduje, że za te 10 lat
trzeba będzie milion dni. Dopiero za kolejne 10 lat wystarczy jeden
dzień.

Tylko to "jesli". Jesli juz robimy to na maszynce uzytkownika, to lepiej
zrobic to tak, zeby nie dalo sie tego skutecznie zlamac nawet za 50 lat.

Oczywiście. Tylko, że wydłużanie o 20 bitów zajmujące 1s jest do zaakceptowania przez użytkownika, a wydłużanie o 30 bitów (powiedzmy kolejne 10 lat) zajmujące 1024s już nie za bardzo. Za 10 lat powinno się zmienić hasła i wydłużenie do 30bitów, co wtedy będzie zajmowało 1s. Proszę nie czepiać się wartości liczbowych, bo chodzi o ideę, a nie szczegóły.

Nie rozumiem dlaczego bank nie może sam spreparować. Jeśli jak wynika
z poprzednich dyskusji przynajmniej niektóre banki przechowują hasła
klientów czyli znają wszystkie informacje, którymi posługuje się
klient wykonując jakąś operację

Ale przy kryptografii asymetrycznej nawet jesli klient posiada
(opcjonalne) haslo, to bank go nie zna. Klient moze zmienic haslo
w kazdej chwili, bez udzialu banku.
Mam na mysli oczywiscie normalne zastosowanie, a nie "przechowywanie
klucza prywatnego na serwerze banku".

Ja myślałem, że kryptografia asymetryczna jest stosowana do tworzenia sesji na łączu i że to jakoś uniemożliwia bankowi spreparowanie operacji. Już w innym odgałęzieniu wątku dotarło do mnie, w jakim sensie była ta wypowiedź o kryptografii asymetrycznej.

Hasła mają to do siebie, że zazwyczaj są za
krótkie. Jakieś badania pokazały, że typowo na jeden znak przypada
około 3..4 bitów niepewności (bo ludzie nie stosują w pełni losowego
następstwa znaków). 12 znakowe hasło to byłoby około 48 bitów. Jego
wydłużenie o 20 bitów to zawsze coś (wydłuża czas ataku milion razy).
Dodatkowo wydłużanie z dodaniem pewnej jawnej liczby, ale dla każdego
użytkownika innej powoduje, że atakujący nie może stworzyć jednej
tablicy dla wszystkich użytkowników, ale musi tworzyć osobne tablice
dla kaĹźdego uĹźytkownika.

Wszystko pieknie, ale problem lezy zupelnie w czyms innym.

Są różne problemy, każde zabezpieczenia ma rozwiązywać inne z nich. To o czym pisałem ma zwiększyć nakład pracy atakującego, który nie ma dostępu do wyniku wydłużania, ale ma możliwość weryfikacji kolejnych haseł.

Jesli klient
podaje haslo swojemu programowi, i nastepnie jest ono "wydluzane"
i wysylane do banku, to co przeszkodzi bankowi w przechwyceniu owego
"wydluzonego" hasla, i w przeprowadzeniu fraudu korzystajac z niego?

Koncepcja nieuczciwego banku pojawiła się w dyskusji później niż "wydłużanie".
To tak jakby po długiej dyskusji na temat jak grube i jak wysokie mury naokoło twierdzy postawić ktoś rzucił hasło: "rozważmy też kwestię konia trojańskiego" i po jakimś czasie pojawiają się pretensje to kogoś kto postulował 5m grubości muru, że gadał bez sensu, bo przecież jest koń trojański.

Atak "brutalny" na 12-znakowe haslo bylby niepraktyczny z powodow
ekonomicznych, chyba ze haslo znajdowaloby sie w slowniku - ale wtedy
nie mozna mowic o 48 bitach, tyle nie bedzie nawet po "wydluzeniu".

Kryptografia to nie jest moja dziedzina. Nie wiem, co dokładnie rozumiesz przez słownik. Jeśli np. słownik języka polskiego to oczywiście, że tych bitów będzie mało. Ja uważam, że stosowane hasła mieszczą się w większym zbiorze, ale na pewno mniejszym niż po 8 bitów na każdy znak. Na przykład przypuszczam, że w hasłach zarówno litery jak i cyfry występują najczęściej w grupach (grupa jednoznakowa to też grupa, jeśli wystąpi w haśle raz lub dwa razy), a to powoduje, że liczba kombinacji do sprawdzenia dla 12 znakowego hasła się zmniejsza. Cały czas mam na myśli atak nie na jedno hasło, tylko na hasła wielu użytkowników.

Tak, czy siak uważam, że największym zagrożeniem (przy, być może błędnym, założeniu o uczciwości banków) są key-loggery, a jedyne skuteczne zabezpieczenie jakie przed tym sobie wyobrażam (poza jak rozumiem kryptografią asymetryczną) to taka klawiaturka (opisałem wcześniej) sama realizująca wydłużenie i tworząca bezpieczny kanał z bankiem, w której żaden obcy program nie mógłby się zainstalować, bo po prostu sprzęt by tego nie umożliwiał.

A tak na marginesie ostatnio (gdy instalowały mi się kolejne uaktualnienia Windowsa) sobie uświadomiłem co by to się działo, jakby nagle wszystkie PC-ty na świecie po najnowszym uaktualnieniu, sformatowały wszystkie dyski - chaos totalny.
Ciekawe ilu pracowników MicroSoftu ma możliwość zrobienia takiego "kawału" i czy na pewno wszyscy oni biorą tylko jedną pensję.
P.G.

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

Ja myślałem, że kryptografia asymetryczna jest stosowana do tworzenia
sesji na łączu i że to jakoś uniemożliwia bankowi spreparowanie
operacji. Już w innym odgałęzieniu wątku dotarło do mnie, w jakim
sensie była ta wypowiedź o kryptografii asymetrycznej.

Po prostu samo zlecenie operacji (tresc zlecenia, a dokladniej jego
skrot) jest "podpisywane" kluczem uzytkownika. Bank (i inni) moga tylko
zweryfikowac podpis, ale nie znaja klucza prywatnego i nie moga takiego
np. polecenia przelewu spreparowac.

Są różne problemy, każde zabezpieczenia ma rozwiązywać inne z nich. To
o czym pisałem ma zwiększyć nakład pracy atakującego, który nie ma
dostępu do wyniku wydłużania, ale ma możliwość weryfikacji kolejnych
haseł.

Ale to nie jest praktyczny atak. Zabezpieczac sie nalezy raczej przed
praktycznie mozliwymi atakami. Obecnie prawdopodobne ataki to takie
a) zwiazane z trojanami na komputerze klienta, b) wynikajace z tego, ze
bank musi posiadac haslo klienta (lub cos, co jest tak samo dobre -
"password equivalent") i moze spreparowac operacje w jego imieniu.
Oczywiscie a) jest zdecydowanie bardziej prawdopodobnym zagrozeniem,
przypuszczalnie dlatego schematy asymetryczne nie sa powszechnie
stosowane, bo przed tym jakos specjalnie nie chronia (bo nic nie chroni,
no moze poza kodami SMS zawierajacymi dane o transakcji, ktore daja
czesciowa ochrone).

Koncepcja nieuczciwego banku pojawiła się w dyskusji później niż
"wydłużanie".

To nie zmienia spektrum zagrozen. Walczyc nalezy przede wszystkim
z najbardziej prawdopodobnymi zagrozeniami, i zreszta to jest robione -
listy hasel jednorazowych, tokeny, SMSy z haslami sluza wlasnie do tego.
Oczywiscie nie jest to calkiem pewne zabezpieczenie, ale zmniejsza
szanse na udany atak bardzo silnie, zwlaszcza w przypadku klienta, ktory
czasem mysli przed kliknieciem "OK".

Kryptografia to nie jest moja dziedzina. Nie wiem, co dokładnie
rozumiesz przez słownik. Jeśli np. słownik języka polskiego to
oczywiście, że tych bitów będzie mało.

Slowniki zawieraja slowa z roznych jezykow, aczkolwiek mozna sobie
wybrac jakies bardziej prawdopodobne podzbiory. Uzywane sa takze rozne
typowe triki. Druga mozliwosc to wszystkie kombinacje znakow o okreslonej
dlugosci, z okreslonego zestawu. Ale zrobienie w taki sposob 12 znakow
moze byc niepraktyczne. 8 znakow z duzymi i malymi literami oraz cyframi
jest duzo bardziej praktyczne.

Tak czy owak nie ma wtedy znaczenia ilosc bitow entropii na znak, tylko
po prostu ilosc kombinacji.

Cos takiego ma sens tylko wtedy, gdy system nie blokuje itp. dostepu po
kilku probach, czyli nie w typowym przypadku "bankowym".

Tak, czy siak uważam, że największym zagrożeniem (przy, być może
błędnym, założeniu o uczciwości banków) są key-loggery, a jedyne
skuteczne zabezpieczenie jakie przed tym sobie wyobraĹźam (poza jak
rozumiem kryptografią asymetryczną) to taka klawiaturka (opisałem
wcześniej) sama realizująca wydłużenie i tworząca bezpieczny kanał z
bankiem, w której żaden obcy program nie mógłby się zainstalować, bo
po prostu sprzęt by tego nie umożliwiał.

Zalozenie o uczciwosci bankow jest tylko minimalnie bledne (ale jest).
Kryptografia asymetryczna nie chroni calkowicie przed trojanami, choc
oczywiscie chroni przed keyloggerami (ktore nic wiecej nie robia).
Klawiaturka (sprzetowa) jest niepraktyczna - koszty oraz to, ze nie
rozwiazuje podstawowego problemu - przechwycenie "przedluzonego" hasla
daje dokladnie taki sam efekt jak normalnego.
--
Krzysztof Halasa

Użytkownik "Krzysztof Halasa" <khc@pm.waw.pl> napisał w wiadomości news:m3iq22nccu.fsfintrepid.localdomain...

Klawiaturka (sprzetowa) jest niepraktyczna - koszty oraz to, ze nie
rozwiazuje podstawowego problemu - przechwycenie "przedluzonego" hasla
daje dokladnie taki sam efekt jak normalnego.

Zakładałem, że byłaby to dodatkowa funkcjonalność wprowadzona we wszystkie produkowane na świecie klawiaturki - koszt byłby znikomy.
Jeśli można by tworzyć bezpieczny kanał: klawiaturka-bank to rozwiązywałaby ten podstawowy problem.
Musiałby istanieć jeden (lub kilka, ale ustalonych) światowy standard przedłużania, i tworzenia bezpiecznego kanału, aby klawiatura nie musiała akceptować żadnych ładowanych w trakcie sesji procedurek itp, co zabezpieczało by ją przed trojanami itp.
Gdyby banki (wszystkie razem) wpłynęły na powstanie nowej specyfikacji klawiatury to być może stopniowo problem stałby się ciekawostką historyczną.
Przypuszczam, że do utworzenia bezpiecznego kanału za pomocą kryptografii asymetrycznej potrzebna jest dość duża moc obliczeniowa, ale ta moc już obecnie daje się chyba zmieścić w klawiaturce i nie koniecznie bardzo podnosząc jej cenę.

P.G.

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

Zakładałem, że byłaby to dodatkowa funkcjonalność wprowadzona we
wszystkie produkowane na świecie klawiaturki - koszt byłby znikomy.
Jeśli można by tworzyć bezpieczny kanał: klawiaturka-bank to
rozwiązywałaby ten podstawowy problem.

No, jasne. Ale bez "przedluzania" byloby dokladnie tak samo.

Musiałby istanieć jeden (lub kilka, ale ustalonych) światowy standard
przedłużania, i tworzenia bezpiecznego kanału, aby klawiatura nie
musiała akceptować żadnych ładowanych w trakcie sesji procedurek itp,
co zabezpieczało by ją przed trojanami itp.

A skad by wiedziala z kim sie laczy?

Gdyby banki (wszystkie razem) wpłynęły na powstanie nowej specyfikacji
klawiatury to być może stopniowo problem stałby się ciekawostką
historyczną.

Sama klawiatura nie wystarczy. Potrzebny jest takze wyswietlacz, ktory
zweryfikuje wszelkie potrzebne np. certyfikaty oraz wyswietli szczegoly
operacji. Po prostu potrzebny jest dedykowany komputer, na ktorym nie
bedzie zadnych trojanow ani innych np. keyloggerow. Nic nowego.

Przypuszczam, że do utworzenia bezpiecznego kanału za pomocą
kryptografii asymetrycznej potrzebna jest dość duża moc obliczeniowa,

Nie. Poza tym bezpieczny kanal nie jest potrzebny do ochrony przed
fraudami itp. - potrzebny jest tylko do zachowania tajemnicy.

ale ta moc już obecnie daje się chyba zmieścić w klawiaturce i nie
koniecznie bardzo podnosząc jej cenę.

Tyle ze to dokladnie nic nie daje.
--
Krzysztof Halasa

Użytkownik "Krzysztof Halasa" <khc@pm.waw.pl> napisał w wiadomości news:m3hbhk43gx.fsfintrepid.localdomain...

Jeśli można by tworzyć bezpieczny kanał: klawiaturka-bank to
rozwiązywałaby ten podstawowy problem.

No, jasne. Ale bez "przedluzania" byloby dokladnie tak samo.

Racja.
Przedłużanie miało być z innego powodu niż ten podstawowy.

Musiałby istanieć jeden (lub kilka, ale ustalonych) światowy standard
przedłużania, i tworzenia bezpiecznego kanału, aby klawiatura nie
musiała akceptować żadnych ładowanych w trakcie sesji procedurek itp,
co zabezpieczało by ją przed trojanami itp.

A skad by wiedziala z kim sie laczy?

Nie za bardzo rozumiem o co chodzi. A skąd teraz człowiek wie z kim się łączy.
Ja nie sugeruję, że ona ma nie mieć żadnej pamięci ma tylko nie mieć możliwości uruchamiania w niej załadowanych programów.
Gdyby można było wpisać jej klucz publiczny tego (tych) z kim ma się łączyć to powinno chyba wystarczyć do stwierdzenia z kim się łączy.
Gdybym się choć trochę znał na kryptografii asymetrycznej to może wiedziałbym o co chodzi i jak odpowiedzieć.

Sama klawiatura nie wystarczy. Potrzebny jest takze wyswietlacz, ktory
zweryfikuje wszelkie potrzebne np. certyfikaty oraz wyswietli szczegoly
operacji. Po prostu potrzebny jest dedykowany komputer, na ktorym nie
bedzie zadnych trojanow ani innych np. keyloggerow. Nic nowego.

Oczywiście, że nic nowego, ale czasem rzeczy oczywiste też warto powtórzyć, bo może nie dla wszystkich oczywiste.
Mnie się wydaje (podkreślam wydaje, bo wiem, że za mało wiem), że taka klawiaturka+zwykły PeCet wystarczy. Nie sądzę aby informacje potrzebne do ewentualnego włamywania się do konta było trzeba wyświetlać więc połączenie do monitora mogłoby zostać jak jest - narażone na podglądanie.
Tak samo komputer, gdyby bezpieczny kanał był klawiatura-bank to penetracja PC nie byłaby groźna.
Być może nadużywam słowa klawiatura, faktycznie byłby to tak jak piszesz dedykowany komputer skoro ona (ta klawiaturka) miałaby decydować co trzeba wyświetlić. Mi się po prostu wydaje, że obecnie istniejącą sytuację najłatwiej byłoby poprawić wprowadzając taki powszechnie dostępny dedykowany komputer w formie klawiatury współpracującej z każdym PC. Chyba taniej niż dedykowany komputer wyposażony we wszystko to, co typowy komputer ma.

Poza tym bezpieczny kanal nie jest potrzebny do ochrony przed
fraudami itp. - potrzebny jest tylko do zachowania tajemnicy.

Tylko, a moĹźe aĹź.
Tematem wątku jest logowanie, a nie fraudy.

ale ta moc już obecnie daje się chyba zmieścić w klawiaturce i nie
koniecznie bardzo podnosząc jej cenę.

Tyle ze to dokladnie nic nie daje.

Być może.
Mimo to moje poczucie bezpieczeństwa przy logowaniu byłoby znacznie większe gdybym wiedział, że wpisywane przez mnie hasło nie da się podejrzeć żadnym programem, a wydłużanie znacznie utrudnia atak słownikowy.
P.G..

Piotr Gałka <piotr.galka@CUTTHISmicromade.pl> dared to write:

Użytkownik "Krzysztof Halasa" <khc@pm.waw.pl> napisał w wiadomości news:m3hbhk43gx.fsfintrepid.localdomain...

Jeśli można by tworzyć bezpieczny kanał: klawiaturka-bank to
rozwiązywałaby ten podstawowy problem.

No, jasne. Ale bez "przedluzania" byloby dokladnie tak samo.

Racja.
Przedłużanie miało być z innego powodu niż ten podstawowy.

Musiałby istanieć jeden (lub kilka, ale ustalonych) światowy standard
przedłużania, i tworzenia bezpiecznego kanału, aby klawiatura nie
musiała akceptować żadnych ładowanych w trakcie sesji procedurek itp,
co zabezpieczało by ją przed trojanami itp.

A skad by wiedziala z kim sie laczy?

Nie za bardzo rozumiem o co chodzi. A skąd teraz człowiek wie z kim się łączy.
Ja nie sugeruję, że ona ma nie mieć żadnej pamięci ma tylko nie mieć możliwości uruchamiania w niej załadowanych programów.
Gdyby można było wpisać jej klucz publiczny tego (tych) z kim ma się
łączyć  to powinno chyba wystarczyć do stwierdzenia z kim się łączy.
Gdybym się choć trochę znał na kryptografii asymetrycznej to może wiedziałbym o co chodzi i jak odpowiedzieć.

Sorki że się włączam, ale nie mogę odgonić się od myśli o terminalach płatniczych i o tym, jak to bodaj 2 lata temu w Wlk Brytani wyszło na jaw, że przynajmniej do kilku tysięcy z nich już w fazie produkcji zostały dołączone układy elektroniczne, które przesyłały wszystkie dane kart, za pomocą dedykowanego łącza GPRS, na jakiś serwer w Pakistanie.

Jak wyobrażasz sobie gwarancje, że taka klawiaturka tego nie będzie robiła? Czy ktokolwiek ma to certyfikować? Nadzorować produkcję?...

/ciach/

pzdr.
k.

Użytkownik "kashmiri" <nie.ma@nigdzie.com> napisał w wiadomości news:i7adeq$mng$1news.onet.pl...

Jak wyobrażasz sobie gwarancje, że taka klawiaturka tego nie będzie robiła? Czy ktokolwiek ma to certyfikować? Nadzorować produkcję?...

Jakby przesyłała przez sieć komórkową to wielu użytkowników by to zauważyło (charakterystyczne dźwięki w głośnikach).
A jak przez połączenie sieciowe komputera to pewnie ci sami co znajdują wszystkie błędy systemów operacyjnych szybko by to nakryli i byłoby hasło klawiatur producenta XX nie kupować. Ta informacja nie musiałaby dotrzeć do końcowych użytkowników, to hurtownie by nie brały.
P.G.

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

Jakby przesyłała przez sieć komórkową to wielu użytkowników by to
zauważyło (charakterystyczne dźwięki w głośnikach).

Zalezy od modulacji, poza tym mysle ze od GPRS skuteczniejsze byloby
cos, co promieniuje lokalnie, i wymaga odbiornika w niewielkiej
odleglosci.
Wlamywacze naprawde nie musza miec danych wszystkich kart na swiecie,
wystarczy im znikoma czesc.

Oczywiscie przed tym problemem zabezpieczaja procesory w kartach.

A jak przez połączenie sieciowe komputera to pewnie ci sami co
znajdują wszystkie błędy systemów operacyjnych szybko by to nakryli i
byłoby hasło klawiatur producenta XX nie kupować. Ta informacja nie
musiałaby dotrzeć do końcowych użytkowników, to hurtownie by nie
brały.

Piekne teorie, ale nie maja nic wspolnego z rzeczywistoscia. Praktyka
pokazuje, ze ukrycie takiego czegos w zamknietym systemie jest latwe
i z duzym prawdopodobienstwem nigdy nie zostanie od wykryty, a nawet
jesli zostanie wykryty, to typowo stanie sie to po wielu latach od jego
wprowadzenia.

Bledy w systemach operacyjnych sa znajdowane tylko dlatego, ze
a) przeszkadzaja w normalnej pracy, lub b) sa w takich miejscach,
w ktorych szukanie problemu jest naturalne, lub ew. c) ktos ma naprawde
duzo szczescia. Znakomita wiekszosc bledow, ktore nie wplywaja na prace
zamknietego systemu, nigdy nie zostanie wykryta.
--
Krzysztof Halasa

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

Nie za bardzo rozumiem o co chodzi. A skąd teraz człowiek wie z kim
się łączy.

Przegladarka wie, ma certyfikat urzedu certyfikujacego i po lancuchu
certyfikatow potrafi sobie dojsc, ze dane z serwera banku pochodza
rzeczywiscie od serwera o takiej nazwie domenowej (a przynajmniej ze
certyfikaty to stwierdzaja).

Ja nie sugeruję, że ona ma nie mieć żadnej pamięci ma tylko nie mieć
możliwości uruchamiania w niej załadowanych programów.
Gdyby można było wpisać jej klucz publiczny tego (tych) z kim ma się
łączyć to powinno chyba wystarczyć do stwierdzenia z kim się łączy.

A jak chcesz ten klucz tam wpisac?

Mnie się wydaje (podkreślam wydaje, bo wiem, że za mało wiem), że taka
klawiaturka+zwykły PeCet wystarczy.

Nie, w ogole haslo nie rozwiazuje problemu, ktorego rozwiazanie samo sie
narzuca - tj. tego, ze ktos inny niz klient moze spreparowac operacje
"w imieniu" klienta. Podpis cyfrowy eliminuje taka mozliwosc, a tak
naprawde zadnych dodatkowych srodkow nie wymaga.

BTW moze nie w bankowosci detalicznej, ale w firmowej cos takiego od
dawna funkcjonuje. Na wydzielonym komputerze, odpietym od normalnej
sieci, wprowadza sie przelewy, sa podpisywane kluczem prywatnym,
i transmitowane do banku (kiedys w ogole robilo sie to osobnym modemem).
Limit kwoty przelewu = 1 Mzl nie jest problemem.

Nie sądzę aby informacje potrzebne
do ewentualnego włamywania się do konta było trzeba wyświetlać więc
połączenie do monitora mogłoby zostać jak jest - narażone na
podglądanie.
Tak samo komputer, gdyby bezpieczny kanał był klawiatura-bank to
penetracja PC nie byłaby groźna.

Nic z tych rzeczy - co z tego ze wiemy komu podajemy haslo, jesli nie
wiemy, jaka operacje wlasnie zlecamy? Trojany zmieniajace zawartosc
polecenia przelewu pojawily sie juz jakis czas temu.

Na trojany nie ma skutecznej rady, poza oczywiscie taka, zeby ich nie
miec na urzadzeniu, ktore sluzy do zlecania operacji. Mozna przenosic
funkcjonalnosc owego urzadzenia z peceta do czegos mniejszego, ale to
generalnie nie zmienia niczego fundamentalnego - wciaz musi to byc
bezpieczny komputer z wyswietlaczem i klawiatura itd.

Dodatkowo mozna rozmnozyc ta urzadzenie (kody SMS), wtedy intruz
musialby miec kontrole nad wszystkimi (byc moze) czesciami. Ale
oczywiscie to wciaz nie zmienia zadnej generalnej zasady.

Być może nadużywam słowa klawiatura, faktycznie byłby to tak jak
piszesz dedykowany komputer skoro ona (ta klawiaturka) miałaby
decydować co trzeba wyświetlić. Mi się po prostu wydaje, że obecnie
istniejącą sytuację najłatwiej byłoby poprawić wprowadzając taki
powszechnie dostępny dedykowany komputer w formie klawiatury
współpracującej z każdym PC. Chyba taniej niż dedykowany komputer
wyposaĹźony we wszystko to, co typowy komputer ma.

Potrzebna jest klawiatura (przynajmniej 1 klawisz do zatwierdzania,
przypuszczalnie trzeba wprowadzac np. PIN albo w ogole haslo -> uklad
QWERTY) oraz wyswietlacz.

Poza tym bezpieczny kanal nie jest potrzebny do ochrony przed
fraudami itp. - potrzebny jest tylko do zachowania tajemnicy.

Tylko, a moĹźe aĹź.
Tematem wątku jest logowanie, a nie fraudy.

Samo logowanie jest nieistotnym epizodem w tym kontekscie. Istotne sa
a) bezpieczenstwo zlecanych operacji, b) zachowanie ich w tajemnicy.
--
Krzysztof Halasa

Użytkownik "Krzysztof Halasa" <khc@pm.waw.pl> napisał w wiadomości news:m3tylivrom.fsfintrepid.localdomain...

Ja nie sugeruję, że ona ma nie mieć żadnej pamięci ma tylko nie mieć
możliwości uruchamiania w niej załadowanych programów.
Gdyby można było wpisać jej klucz publiczny tego (tych) z kim ma się
łączyć to powinno chyba wystarczyć do stwierdzenia z kim się łączy.

A jak chcesz ten klucz tam wpisac?

Z wpisywaniem informacji jawnej (klucz publiczny) nie powinno być jakichś specjalnych kłopotów. Gorzej z zabezpieczeniem, aby bez świadomości użytkownika nie można było go podmienić.

Tak samo komputer, gdyby bezpieczny kanał był klawiatura-bank to
penetracja PC nie byłaby groźna.

Nic z tych rzeczy - co z tego ze wiemy komu podajemy haslo, jesli nie
wiemy, jaka operacje wlasnie zlecamy? Trojany zmieniajace zawartosc
polecenia przelewu pojawily sie juz jakis czas temu.

Zakładałem bezpieczny kanał i nie sądzę, aby te trojany robiły to w bezpiecznym kanale (raczej na jego końcu). Ale jakby tak przyblokować jedno zero lecące z tej bezpiecznej klawiatury na ekran to użytkownik pomyślałby, że klawisz nie zadziałał i nacisnąłby ponownie no i poszłoby o jedno zero więcej.

Bez dostępu do bezpiecznego kanału atakujący nie mógłby (chyba) zlecić zaplanowanego przez siebie przelewu, ale namieszać mógłby za wiele, aby nadal bronić takiego rozwiązania.
Więc przyznaję, że kanał do wyświetlacza też musi być niedostępny - zostaje dedykowany komputer.

Potrzebna jest klawiatura (przynajmniej 1 klawisz do zatwierdzania,
przypuszczalnie trzeba wprowadzac np. PIN albo w ogole haslo -> uklad
QWERTY) oraz wyswietlacz.

Przekonałeś mnie.

Tematem wątku jest logowanie, a nie fraudy.

Samo logowanie jest nieistotnym epizodem w tym kontekscie. Istotne sa
a) bezpieczenstwo zlecanych operacji, b) zachowanie ich w tajemnicy.

Nie brałem dotychczas pod uwagę w ogóle b), a warunek b) od razu dyskwalifikuje bezpieczną klawiaturkę z mało bezpiecznym monitorem.
P.G.

Krzysztof Halasa <khc@pm.waw.pl> dared to write:

witek <witek7205@gazeta.pl.invalid> writes:

Bank zawsze ma dostep do hasla usera.

no rozroznijmy bank od aplikacji chodzącej na serwerze.
to nie to samo.

No ale przeciez nie chodzi o system dostepny dla "zwyklego" personelu.
Aplikacja sprawdzajaca haslo musi je znac (przynajmniej w momencie
sprawdzania), na to nie ma rady oprocz kryptografii asymetrycznej.

Z tym, ze to jest nieco trudniejsze dla "Kowalskiego" niz haslo
i formularz na WWW. Zwlaszcza jesli ma byc zrobione dobrze.

Aplikacja dostępna dla "zwykłego" personelu w brytyjskim banku HSBC pokazuje hasło w całości. Wystarczy, że personel w dowolnym oddziale wpisze numer okazanej karty debetowej, aby pokazał się login i hasło klienta. Byłem zszokowany, kiedy to zobaczyłem - również tym, że HSBC jak by nie patrzeć ma jakąś renomę.

k.

"kashmiri" <nie.ma@nigdzie.com> writes:

Aplikacja dostępna dla "zwykłego" personelu w brytyjskim banku HSBC
pokazuje hasło w całości. Wystarczy, że personel w dowolnym oddziale
wpisze numer okazanej karty debetowej, aby pokazał się login i hasło
klienta. Byłem zszokowany, kiedy to zobaczyłem - również tym, że HSBC
jak by nie patrzeć ma jakąś renomę.

Obawiam sie ze renoma nie ma z tym wielkiego zwiazku.

To haslo potrzebne tylko przy dostepie przez Internet? IOW, nie jest
przydatne w oddziale?

W przypadku hasel, ktore ma "sprawdzac" pracownik (klient podaje haslo
pracownikowi w oddziale albo przez telefon, nie komputerowi), tak sie
robi, bo pracownik czesto nie moglby wprowadzic poprawnie hasla. Ale dla
hasla "internetowego" nie mam wytlumaczenia :-(
--
Krzysztof Halasa

Krzysztof Halasa <khc@pm.waw.pl> dared to write:

"kashmiri" <nie.ma@nigdzie.com> writes:

Aplikacja dostępna dla "zwykłego" personelu w brytyjskim banku HSBC
pokazuje hasło w całości. Wystarczy, że personel w dowolnym oddziale
wpisze numer okazanej karty debetowej, aby pokazał się login i hasło
klienta. Byłem zszokowany, kiedy to zobaczyłem - również tym, że HSBC
jak by nie patrzeć ma jakąś renomę.

Obawiam sie ze renoma nie ma z tym wielkiego zwiazku.

To haslo potrzebne tylko przy dostepie przez Internet? IOW, nie jest
przydatne w oddziale?

W przypadku hasel, ktore ma "sprawdzac" pracownik (klient podaje haslo
pracownikowi w oddziale albo przez telefon, nie komputerowi), tak sie
robi, bo pracownik czesto nie moglby wprowadzic poprawnie hasla. Ale dla
hasla "internetowego" nie mam wytlumaczenia :-(

Hasło WYŁĄCZNIE do dostępu internetowego. W oddziale identyfikujesz się TYLKO okazując kartę bankomatową.

Też nie mam wytłumaczenia.

Hasło (PIN) telefoniczne jest inne, ale podobnie jest widoczne w systemie dla KAŻDEGO pracownika po wpisaniu numeru karty, numeru konta albo numeru klienta.

Ot, system w HSBC.

k.

Użytkownik "witek" <witek7205@gazeta.pl.invalid> napisał w wiadomości news:i6oota$735$3inews.gazeta.pl...

On 9/14/2010 4:09 PM, Krzysztof Halasa wrote:

Bank zawsze ma dostep do hasla usera.

no rozroznijmy bank od aplikacji chodzącej na serwerze.
to nie to samo.

Według mnie dostęp musi mieć tylko aplikacja chodząca na komputerze użytkownika, do serwera leci już skrót (a właściwie wydłużenie ;-) ).
P.G.

On 9/15/2010 3:39 AM, Piotr Gałka wrote:

Użytkownik "witek" <witek7205@gazeta.pl.invalid> napisał w wiadomości
news:i6oota$735$3inews.gazeta.pl...

On 9/14/2010 4:09 PM, Krzysztof Halasa wrote:

Bank zawsze ma dostep do hasla usera.

no rozroznijmy bank od aplikacji chodzącej na serwerze.
to nie to samo.

Według mnie dostęp musi mieć tylko aplikacja chodząca na komputerze
użytkownika, do serwera leci już skrót (a właściwie wydłużenie ;-) ).

o ile tak została napisana, w co bardzo wątpie.

Użytkownik "witek" <witek7205@gazeta.pl.invalid> napisał w wiadomości news:i6q1l6$bj3$1inews.gazeta.pl...

Bank zawsze ma dostep do hasla usera.

no rozroznijmy bank od aplikacji chodzącej na serwerze.
to nie to samo.

Według mnie dostęp musi mieć tylko aplikacja chodząca na komputerze
użytkownika, do serwera leci już skrót (a właściwie wydłużenie ;-) ).

o ile tak została napisana, w co bardzo wątpie.

Dlatego napisałem "musi mieć tylko", a nie "ma tylko".
Ale właściwie dlaczego wątpić.
Cytat z książki napisanej w 2003 roku (polskie wydanie 2004) "Kryptografia w praktyce":
"22.2.1. Solenie i rozciąganie..... Techniki te są tak proste i naturalne, że powinny być stosowane we wszystkich systemach haseł. Ignorowanie ich nie ma żadnego wytłumaczenia."
Jeśli nie jest to podstawowa wiedza ludzi piszących oprogramowanie dla banków to coś jest chyba postawione na głowie.
P.G.

On 9/15/2010 4:23 AM, Piotr Gałka wrote:

Jeśli nie jest to podstawowa wiedza ludzi piszących oprogramowanie dla
banków to coś jest chyba postawione na głowie.

a coś jest niepostawione na głowie?

Użytkownik "Piotr Gałka" <piotr.galka@CUTTHISmicromade.pl> napisał w wiadomości news:4c908643news.home.net.pl...

Według mnie dostęp musi mieć tylko aplikacja chodząca na komputerze użytkownika, do serwera leci już skrót (a właściwie wydłużenie ;-) ).

Dopiszę jeszcze jedną myśl:
Jeszcze bezpieczniej z podawaniem hasła by było jakby klawiatury PC miały taką funkcję, że się włącza specjalny tryb, wpisuje hasło i na Enter ten tryb się kończy, a hasło jest mieszane (i wydłużane) i wysyłane via USB. Jakby tak jeszcze szyfrowane było nie łącze bank-komputer, a łącze bank-klawiatura. Zakładam, przy tym, że algorytmy mogły by być ustalone raz na zawsze, co by oznaczało, że klawiatura nie musi akceptować żadnych podsyłanych programów, a więc byłaby odporna na włamania. Ta stałość algorytmów to jest to, co by tę klawiaturę wyróżniało od komputera. Wszystko, co by choć przez mikrosekundę było w PC (ogólnie mało bezpieczne miejsce) byłoby bezużyteczne dla różnych trojanów itp.
Myślę, że producenci klawiatur bez problemu by zrealizowali takie nowe dodatkowe wymaganie i nie powinno to wcale wpłynąć zbyt na cenę klawiatury. Skoro nic takiego się nie robi, to albo błądzę, albo bankom nie zależy na bezpieczeństwie logowania.
P.G.

Piotr Gałka pisze:

Myślę, że producenci klawiatur bez problemu by zrealizowali takie nowe
dodatkowe wymaganie i nie powinno to wcale wpłynąć zbyt na cenę
klawiatury. Skoro nic takiego się nie robi, to albo błądzę, albo bankom
nie zależy na bezpieczeństwie logowania.
P.G.

Bankom nie zaleĹźy.
Bank idzie po linii najmniejszego oporu, po czym formułuje regulamin,
który przerzuca na klienta odpowiedzialność za błędy (wirusy, trojany,
keyloggery, zgubiony tf itp).



--

Dziękuję.
    Pozdrawiam.
        SQL-wiel.