Sposoby logowania się .
AW
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
Jacek Kalinski
> 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
AW
>
> Openonline - nie zgodzę się - 8 cyfr login + hasło pełne
Dzięki za info.
Jak to jest że ja mam maskowane w Openie?
Grzexs
> 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
SQLwiel
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.
Krzysztof Jamróz
> 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
MacGregor
news:i690f3$q5$1...@inews.gazeta.pl...
Toyota bank - login 8 cyfr; hasło & wskazanie tokena
--
Pozdrawiam,
MacGregor
Kamil Jońca
> 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.
Jarek Andrzejewski
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)
xbartx
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
WAM
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
MarekZ
dyskusyjnych:ov5h8611h3gq5qo1k...@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.
WAM
>> 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.
MarekZ
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).
Rafał
> 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
Peet
liczyć, nie są ponumerowane jak w open czy pekao.
Alf/red/
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/
MarekZ
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?
Alf/red/
>> 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/
Rafał
> 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
MarekZ
> 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.
Michal Jankowski
> 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
Kamil Jońca
> 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
Alf/red/
>> 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/
Michal Jankowski
> 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
Eneuel Leszek Ciszewski
"Michal Jankowski" kjzbp86...@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.' ene...@eneuel.comyr.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....
Eneuel Leszek Ciszewski
"Kamil "Jońca"" 877hiui...@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... ;)
Alf/red/
> 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/
Eneuel Leszek Ciszewski
"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
AW
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
Michal Jankowski
> 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
Piotr Gałka
Użytkownik "AW" <a_niepod...@wp.pl> napisał w wiadomości
news:i6f7dn$95v$1...@news.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.
witrak()
Ale skoro tak, to zmiana hasła nie ma znaczenia :-)
witrak()
--
witrak()
Krzysztof 'kw1618' z Warszawy
... 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
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
Alf/red/
> 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/
Eneuel Leszek Ciszewski
"Michal Jankowski" kjzwrqs...@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.' ene...@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... :)
Michal Jankowski
> 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
Eneuel Leszek Ciszewski
"Michal Jankowski" kjzaann...@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..,,,,..
witrak()
> Dnia Sat, 11 Sep 2010 21:38:59 +0200, witrak() napisał(a):
>
>> Piotr Gałka wrote:
>>>
>>> Użytkownik "AW" <a_niepod...@wp.pl> napisał w wiadomości
>>> news:i6f7dn$95v$1...@news.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()
>
>
...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()
Eneuel Leszek Ciszewski
"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. :)
Eneuel Leszek Ciszewski
"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..,,,,..,,..,,......
Piotr Gałka
Użytkownik "Eneuel Leszek Ciszewski" <pro...@czytac.fontem.lucida.console>
napisał w wiadomości news:i6nbhd$fsk$1...@inews.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.
Eneuel Leszek Ciszewski
"Piotr Gałka" 4c8f37e2$1...@news.home.net.pl
> Użytkownik "Eneuel Leszek Ciszewski" <pro...@czytac.fontem.lucida.console> napisał w wiadomości
> news:i6nbhd$fsk$1...@inews.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. :)
Krzysztof Halasa
> 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
witek
> Bank zawsze ma dostep do hasla usera.
no rozroznijmy bank od aplikacji chodzącej na serwerze.
to nie to samo.
Eneuel Leszek Ciszewski
"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!!!
Krzysztof Halasa
>> 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
Piotr Gałka
Użytkownik "Krzysztof Halasa" <k...@pm.waw.pl> napisał w wiadomości
news:m3r5gwq...@intrepid.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
Użytkownik "witek" <wite...@gazeta.pl.invalid> napisał w wiadomości
news:i6oota$735$3...@inews.gazeta.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 ;-) ).
P.G.
witek
o ile tak została napisana, w co bardzo wątpie.
Piotr Gałka
Użytkownik "Piotr Gałka" <piotr...@CUTTHISmicromade.pl> napisał w
wiadomości news:4c90...@news.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 ;-) ).
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
Użytkownik "witek" <wite...@gazeta.pl.invalid> napisał w wiadomości
>>>> 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.
SQLwiel
> 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.
witek
> 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?
Krzysztof Halasa
>> 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
kashmiri
> 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.
kashmiri
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.
Piotr Gałka
>> 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.
Jarek Andrzejewski
<piotr...@CUTTHISmicromade.pl> wrote:
>
>Użytkownik "Krzysztof Halasa" <k...@pm.waw.pl> napisał w wiadomości
>news:m31v8uq...@intrepid.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
Piotr Gałka
Użytkownik "Jarek Andrzejewski" <ptj...@gmail.com> napisał w wiadomości
news:04p396tlpn7sib7oj...@4ax.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.
Jarek Andrzejewski
<piotr...@CUTTHISmicromade.pl> wrote:
>
>Użytkownik "Jarek Andrzejewski" <ptj...@gmail.com> napisał w wiadomości
>news:04p396tlpn7sib7oj...@4ax.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.
Piotr Gałka
>
> 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.
Jarek Andrzejewski
<piotr...@CUTTHISmicromade.pl> wrote:
>
>Użytkownik "Jarek Andrzejewski" <ptj...@gmail.com> napisał w wiadomości
>news:9d0496djmqta15hb7...@4ax.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
Piotr Gałka
>>> 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.
Jarek Andrzejewski
<piotr...@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
Piotr Gałka
>
> 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.
Jarek Andrzejewski
<piotr...@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
Piotr Gałka
>
>>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.
Krzysztof Halasa
> 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
>> 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
Piotr Gałka
>>
>> 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.
Krzysztof Halasa
> 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
Piotr Gałka
> 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.
Krzysztof Halasa
> 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
Piotr Gałka
>> 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.
>
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..
kashmiri
>
> Użytkownik "Krzysztof Halasa" <k...@pm.waw.pl> napisał w wiadomości
> news:m3hbhk4...@intrepid.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.
kashmiri
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.
Piotr Gałka
Użytkownik "kashmiri" <nie...@nigdzie.com> napisał w wiadomości
news:i7adeq$mng$1...@news.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.
Krzysztof Halasa
> 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
Krzysztof Halasa
> 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
>
>> 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?
>
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.