Szyfrowanie haseł

[megi 358]

A jak w Home masz z czyms problem, to bezposrednio z panelu laczysz sie chatem online z operatorem i pytasz o co chcesz albo za podaniem kilku literek hasla masz cos-tam zrobione z miejsca.

 

Znaczy się home trzyma hasła plain tekstem? Luzacy Nadal mają tę profesjonalną metodę zmiany zapomnianego hasła do panelu administracyjnego przez wysłanie nowego faksem?

[patryk 451]

megi, sugerujesz, że mBank albo ING, który weryfikuje hasła na tej samej zasadzie takze trzyma hasła plain textem?

[Gość]

patryk dokładnie chciałem to samo napisać

 

pamiętajmy też, że to nie jest wcale plain text, tylko system, który inteligentnie pyta o poszczególny n-któryś znak hasła..

[megi 358]

megi, sugerujesz, że mBank albo ING, który weryfikuje hasła na tej samej zasadzie takze trzyma hasła plain textem?

 

W mbanku proszą o n-te cyfry telekodu tylko na mlinii, przy logowaniu podajesz również nieudostępniany nikomu identyfikator klienta. Dodatkowo niektóre operacje musisz potwierdzić jednorazowym kodem, więc jestem w stanie uwierzyć, że to jedno hasło mbank trzyma plain tekstem. Da się w ogóle coś zrobić znając hasło do mlinii a nie znając ID klienta?

 

pamiętajmy też, że to nie jest wcale plain text, tylko system, który inteligentnie pyta o poszczególny n-któryś znak hasła..

 

Co jest inteligentnego w pytaniu o 1, 3 i 6 cyferkę? Skoro możliwe jest porównanie pojedyńczych liter to znaczy, że albo hasło jest trzymane w postaci tekstowej albo szyfrowane algorytmem, który pozwala je również odszyfrować co prawie na to samo wychodzi W przypadku home w to drugie rozwiązanie szczerze wątpię biorąc pod uwagę procedurę zmiany zapomnianego hasła.

 

Oczywiście jestem otwarta na wszystkie racjonalne i zgodne z kryptografią wyjaśnienia

[Gość]

megi ..a jak wpisujesz je w formularzu, to niby co to jest jak nie szyfrowanie?

na mlinii proszą - ale to przecież maszyna robi, więc ta maszyna też jakiś dostęp musi mieć (ale nie, to nie jest plain text, to jest pewien jakiś tam system autoryzacji)

 

jak dla mnie - sama sobie zaprzeczasz... a może lepiej poczekać te parę dni i na razie na fora nie wchodzić? 3-4 dni i przestaniesz się czepiać czegoś, czego nie rozumiesz...

[blackfire 185]

<piątkowy flejm mode on>

 

megi ..a jak wpisujesz je w formularzu, to niby co to jest jak nie szyfrowanie?

na mlinii proszą - ale to przecież maszyna robi, więc ta maszyna też jakiś dostęp musi mieć (ale nie, to nie jest plain text, to jest pewien jakiś tam system autoryzacji)

 

jak dla mnie - sama sobie zaprzeczasz... a może lepiej poczekać te parę dni i na razie na fora nie wchodzić? 3-4 dni i przestaniesz się czepiać czegoś, czego nie rozumiesz...

 

To żeś chłopie pojechał.

 

Po raz, szyfrowanie haseł jest zasadniczo bez sensu (no mooooże czymś asymetrycznym). Hashowanie (funkcjami jednokierunkowymi) to i owszem.

 

Po dwa, sugerujesz, że <input type="password"> to szyfrowanie?

 

Po trzy, jeżeli system, do którego się autoryzujesz, umie Cię spytać o _wycinek_ hasła i potwierdzić jego autentyczność, to albo trzyma Twoje hasło plaintextem, albo w formie plaintext-equivalent (np. zaszyfrowane kluczem, którym dysponuje system). OK, jak się uprzesz, to zrobię Ci system oparty o hashowane hasła, który pyta o poszczególne cyferki, ale równie dobrze możesz wtedy zapisywać te hasła w ROT13, bo tak samo to będzie bezpieczne.

 

Moje hasło (zakodowane cryptem) to:

 

$1$D4Pnz...$SqjeLtHazxBsDhVHNoVXP/

 

podaję 1, 4 i 7 znak: a, f, p

 

Sprawdź proszę, czy jest poprawne, albo daruj sobie pisanie przez 3-4 dni, przynajmniej na ten temat.

 

(Po cztery, procedura przywracania hasła w home jest naprawdę do dupy.)

[megi 358]

megi ..a jak wpisujesz je w formularzu, to niby co to jest jak nie szyfrowanie?

 

W drugim poście napisałam o szyfrowaniu hasła gdy chodziło o hashowanie. Trzymane otwartym tekstem = bez hashowania.

Jak logujesz się na stronie z szyfrowaniem to dane idą do serwera zaszyfrowane ale aplikacja dostaje je od serwera http odszyfrowane. I jeżeli hasła do kont były hashowane jednostronnie to aplikacja wykonuje taką sama operację i porównuje skrót kryptograficzny (*nie* hasło) ze skrótem w bazie. I albo są takie same albo nie. W takiej sytuacji nie da się na podstawie skrótu odczytać hasła i tym samym porównywać pojedyńczych literek. Co w takim razie znaczy, że w home możesz podać n-tą literke a bokowiec sprawdzi czy się zgadza? Albo hasła trzymają bez hashowania w bazie, albo mają je zakodowane tak, że daje się je odkodować. Jak ktoś zdobędzie taką baze haseł to czy to odkoduje czy nie to tylko kwestia motywacji, bo nie takie rzeczy ludzie łamali. W mbanku owszem cyferki porównuje automat i pewnie nikt ze zwykłych pracowników nie ma do nich dostępu, dlatego napisałam, że jestem w stanie uwierzyć w to, że są trzymane jawnie, bo nie jest to jedyne zabezpieczenie. A kto porównuje hasła w home? Automat czy pracownik boku?

 

 

jak dla mnie - sama sobie zaprzeczasz...

 

W którym miejscu?

 

a może lepiej poczekać te parę dni i na razie na fora nie wchodzić? 3-4 dni

 

Jak ja się cieszę, że to nie Twoje forum i nie możesz banować ludzi, którzy mówią rzeczy, których nie rozumiesz

 

i przestaniesz się czepiać czegoś, czego nie rozumiesz...

 

Proszę Cie...

 

EDIT

Odnośnie mbanku to mam wrażenie, Sponsi, że nie dopuszczasz myśli, że mogą nie mieć idealnych zabezpieczeń.

Nie ufa się danym przychodzącym z zewnątrz a oni łykneli wszystko co podesłała VISA. Jak to o nich świadczy? Jeżeli x pierwszym klientom transakcje przekroczyły wszelkie limity konta to pewnie można to było wyłapać.

[merti 0]

@Blackfire:

 

Rzeczywiscie wychodzi na to, ze nie ma znaczenia czy Home trzyma haslo w tekscie czy nie, skoro i tak podaje sie POJEDYNCZE znaki.

 

Ale przeciez tak samo robia wszelkiego rodzaju banki itd.

 

Czy podawanie w celu weryfikacji CALEGO hasla ktore jest szyfowane jako calosc jest w takim razie bezpieczniejsze podawanie niz 1-3-6 literki? Moim zdaniem jednak nie w przypadku czatu z BOK...

 

@Megi:

 

Ja tez na poczatku Cie nie zrozumialem, nawet wysmarowalem lekko zlosciwy post, ale teraz juz wiem o co Ci chodzi. Napisalas na poczatku troszke niezrozumiale...

[Gość]

megi - nie pierwszy raz zaskakujesz absurdalnymi pytaniami.. ja tam się kłócić nie będę.. a dopytuj sobie nawet o budowę cepa : )

 

merti - pościki nabijamy, żeby móc publikować? : )

[bald 0]

I jeżeli hasła do kont były hashowane jednostronnie to aplikacja wykonuje taką sama operację i porównuje skrót kryptograficzny (*nie* hasło) ze skrótem w bazie. I albo są takie same albo nie. W takiej sytuacji nie da się na podstawie skrótu odczytać hasła i tym samym porównywać pojedyńczych literek. Co w takim razie znaczy, że w home możesz podać n-tą literke a bokowiec sprawdzi czy się zgadza? Albo hasła trzymają bez hashowania w bazie, albo mają je zakodowane tak, że daje się je odkodować.

 

*

jednokierunkowe funkcje skrotu dzialaja zarowno dla pojedynczych znakow jak i dla dluzszych ciagow tekstowych

 

*

wcale nie trzeba znac prawidlowego hasla wystarczy "wejsc w odpowiednie miejsce" tuz przed porownaniem skrotow i podstawic wlasne dane, haslo moze byc dowolne

[blackfire 185]

jednokierunkowe funkcje skrotu dzialaja zarowno dla pojedynczych znakow jak i dla dluzszych ciagow tekstowych

 

True. To na przykład: masz hasło "123456", hashujesz je SHA-512 (żeby bezpiecznie było, a co!) po literce. Z saltem. I w ogóle. Jak myślisz, ile zajmie złamanie tych 6x512 bitów? Bo na mój gust to krócej niż naciśnięcie Enter.

 

wcale nie trzeba znac prawidlowego hasla wystarczy "wejsc w odpowiednie miejsce" tuz przed porownaniem skrotow i podstawic wlasne dane, haslo moze byc dowolne

 

Można też ukraść serwer albo pobić bokowca. I co to ma wspólnego z bezpieczeństwem przechowywanych haseł?

[bald 0]

True. To na przykład: masz hasło "123456", hashujesz je SHA-512 (żeby bezpiecznie było, a co!) po literce. Z saltem. I w ogóle. Jak myślisz, ile zajmie złamanie tych 6x512 bitów? Bo na mój gust to krócej niż naciśnięcie Enter.

 

funkcja skrotu charatkeryzuje sie tym ze po kazdej operacji zmianie ulegaja wszystkie bity skrotu

wiec nie ma znaczenia czy "przerabiasz" pojedynczy znak czy dluzszy tekst i tak nie jestes w stanie z tego skrotu dowiedziec sie jakie byly dane wejsciowe

 

Można też ukraść serwer albo pobić bokowca. I co to ma wspólnego z bezpieczeństwem przechowywanych haseł?

 

jesli dane sa zaszyfrowane to nic z bokowca nie wycisniesz bo to uzytkownik musi podac wlasciwy znak jako punkt "zaczepienia"

 

tego typu weryfikacji NIE wykonuje sie (w powaznych firmach) na zasadzie:

bokowiec widzi cale haslo i wybiera sobie jaka literke o ktora pyta uzytkownika

[blackfire 185]

@Blackfire:Rzeczywiscie wychodzi na to, ze nie ma znaczenia czy Home trzyma haslo w tekscie czy nie, skoro i tak podaje sie POJEDYNCZE znaki.Ale przeciez tak samo robia wszelkiego rodzaju banki itd.Czy podawanie w celu weryfikacji CALEGO hasla ktore jest szyfowane jako calosc jest w takim razie bezpieczniejsze podawanie niz 1-3-6 literki? Moim zdaniem jednak nie w przypadku czatu z BOK...

 

Będziesz poszkodowany bo popełniłem wcześniej dłuugaśną epopeję na temat, ale zeżarło mi ją przy przenoszeniu wątku do kosza i z powrotem.To tak w skrócie: hasło plaintextem _gdzieś_ być musi. Albo "na drucie" (opakowane w SSL to dla aplikacji dalej plaintext), albo w bazie danych. Wybór mechanizmu przesyłania hasła (plaintext -- całe hasło czy challenge-response -- wybrane znaki) zależy od względnego bezpieczeństwa kanału transmisji i bazy danych. W przypadku, kiedy bazę danych można uznać za bezpieczną (np. bankowi musisz zaufać tak czy inaczej), może mieć sens postawienie wszystkiego na jedną kartę i strzeżenie bazy haseł jak oka w głowie (poza tym takie ryzyko pewnie łatwiej bankowi skalku

ować).

 

Żeby nie było wątpliwości -- nie chodzi mi o to, żeby bokowcowi podawać całe hasło. Chodzi mi o to, żeby w ogóle go nie musiał znać, a jednak mógł potwierdzić Twoją tożsamość. Najprościej byłoby np. udostępnić czat po zalogowaniu się do panelu administracyjnego. Wtedy system wie, że Ty to Ty i bokowcowi też to może powiedzieć, nie ujawniając hasła (bo go nigdzie nie ma, jest tylko jego skrót).

 

funkcja skrotu charatkeryzuje sie tym ze po kazdej operacji zmianie ulegaja wszystkie bity skrotu

 

No nie wszystkie, powiedzmy że koło połowy (inaczej miałbyś tylko dwa możliwe skróty). Sztuczka polega na tym, że nie wiesz które.

 

wiec nie ma znaczenia czy "przerabiasz" pojedynczy znak czy dluzszy tekst i tak nie jestes w stanie z tego skrotu dowiedziec sie jakie byly dane wejsciowe

 

A to już jest tzw. trzecia prawda góralska. W moim przykładzie z poprzedniego posta masz 3 kilobity skrótu, ale zawierają one razem niecałe 20 bitów entropii. Pierwsze 512 bitów może przyjąć jedną z 10 wartości (log2(10) = 3 bity z groszami), drugie też, itd. Zauważ, że nie zależy to od użycia salt (jest jawnie zapisany razem z hashem bo inaczej się nie da za bardzo).

 

Co więcej, jeżeli te 6 cyfr byłoby hashowane jako całość, żeby zbrute-force'ować takie hasło, musiałbyś policzyć statystycznie pół miliona skrótów (średnio w połowie trafisz). Pikuś. Natomiast jeżeli masz 6 niezależnych skrótów, to całość złamiesz po 6*(10/2) = 30 iteracjach. To to już można prawie że na kartce policzyć.

 

Żeby uniknąć niejasności -- z samego hasha nie jesteś w stanie wyczytać, że to jest skrót z jednej cyfry. Aż takich herezji nie szerzę Ale możesz to próbować zgadnąć. Gdyby było natomiast tak jak mówisz, to ataki słownikowe by nie istniały.

 

Odwracając nieco rozumowanie, nie będziesz też nigdy w stanie udowodnić, że te 512 bitów to sha512('1') a nie sha512(terabajty i terabajty śmieci o takim samym skrócie jak '1'), ale to również nie wpływa na proces brute force'owania, bo wystarczy zdobyć _jeden_ przeciwobraz.

 

jesli dane sa zaszyfrowane to nic z bokowca nie wycisniesz bo to uzytkownik musi podac wlasciwy znak jako punkt "zaczepienia"

 

Okej, ale zaszyfrowane czy hashowane (już w tym wątku się pojawiały takie nieścisłości)? Bo jak zaszyfrowane, to trzeba je jakoś odszyfrować. Otrzymując niniejszym plaintext, bez ingerencji innego człowieka niż wpisujący hasło. Czyli z punktu widzenia kogoś mającego dostęp do tej bazy, hasła są plaintextem -- skoro serwis (IVR, cokolwiek) umie je odszyfrować, to on też da sobie radę.

 

A jak hasło jest hashowane, to zostaje atak słownikowy albo jakiś inny kanał.

 

tego typu weryfikacji NIE wykonuje sie (w powaznych firmach) na zasadzie:bokowiec widzi cale haslo i wybiera sobie jaka literke o ktora pyta uzytkownika

 

No podejrzewam że aż tak źle nie jest a bokowiec w ogóle nie uwierzytelnia użytkownika (to już zrobił IVR albo inny czat). Ale gdzieś tam te hasła plaintextem są i ktoś do nich dostęp ma. A po co ma mieć jak nie musi?

 

EDIT: forum zrobiło z moimi postami co chciało

[bald 0]

Żeby uniknąć niejasności -- z samego hasha nie jesteś w stanie wyczytać, że to jest skrót z jednej cyfry. Aż takich herezji nie szerzę Ale możesz to próbować zgadnąć. Gdyby było natomiast tak jak mówisz, to ataki słownikowe by nie istniały.

 

ataki slownikowa istnieja tylko dla tego ze wiekszosc uzytkownikow jest kompletnie bezmyslna/nieodpowiedzialna

 

Okej, ale zaszyfrowane czy hashowane (już w tym wątku się pojawiały takie nieścisłości)?

 

ja w moich wypowiedziach mam na mysli tylko hashowanie jesli gdzies z "rozpedu" przemknelo sie slowo szyfrowanie to przepraszam

 

 

No podejrzewam że aż tak źle nie jest a bokowiec w ogóle nie uwierzytelnia użytkownika (to już zrobił IVR albo inny czat). Ale gdzieś tam te hasła plaintextem są i ktoś do nich dostęp ma. A po co ma mieć jak nie musi?

 

jesli serwis umozliwia odzyskanie zapomnianego hasla to nie wazne w jakiej postaci sa one przechowywane (i tak jest bardzo zle)

 

co do uwiezrzytelniania przez bok, wiekszosc firm "nie internetowych" ta sprawe zrzuca jednak na obsluge boku

[p 3]

ataki slownikowa istnieja tylko dla tego ze wiekszosc uzytkownikow jest kompletnie bezmyslna/nieodpowiedzialna

Nie. Ataki slownikowe istnieja dlatego, ze sa efektywne i ze wiekszosc zabezpieczen nadal korzysta z prostych hash'y.

 

Swoja droga nie dociera do Was mysl, ze aby zweryfikowac haslo uzytkownika przez pracownika BOK'u wystarczy zapamietac tylko niektore (np. co drugi, trzeci) znaki? Cale haslo nie musi byc nigdzie przechowywane w postaci niezaszyfrowanej.

[alien 345]

W calej rozciaglosci zgadzam sie z Megi :-). Uzupelnie tylko pojawiajace sie argumenty bankowe.

Wymieniono wyzej mBank i ING.

 

mBank juz wyjasniono - podawanie pojedynczych literek jest tylko na mLinii i tylko znajac identyfikator. Pamietajmy tez, ze z mLinii nie wykonamy automatycznie np. niezdefiniowanych przelewow. Takze by zrobic cos u operatora mLinii nalezy znac troche wiecej swoich danych (co oczywiscie nie jest nie do przeskoczenia, ale ja nigdy nie twierdzilem, ze systemy IVR w bankach sa bezpieczne ;-) Zawsze jednak mozna zablokowac i nie korzystac). Multibanku dotyczy dokladnie ta sama argumentacja - jak wiadomo to autonomiczny klon mBanku.

 

Co do ING i w dalekim podobienstwie rozwiazan np. BPH. System istotnie prosi o podanie wybranych literek z hasla, najpewniej wiec haslo wejscia do systemu jest trzymane plaintekstem. Ale. Nalezy pamietac, ze do ING istnieja dwa rozne hasla. Pierwsze umozliwia jedynie wejscie do systemu i przejrzenie danych. Do wykonania operacji potrzebne jest haslo nr 2 i te podaje sie juz w calosci. Malo tego - w istocie nie ejst to haslo samo w sobie, a haslo do klucza prywatnego, ktorym podpisywana jest transakcja. Klucz ten mozna trzymac w repozytorium banku i wtedy jest to zabezpieczenie warte dokladnie tyle co bezpieczenstwo hasla do niego. Mozna jednak takze sobie skopiowac klucz na swoj komputer, najlepiej na wyjmowalny nosnik. Jest to wtedy juz powazne zabezpieczenie (choc wciaz mniej odporne na dzialalnosc wirusowo-trojanowa po stronie uzytkownika niz np. token czy hasla SMS). Bezpieczenstwo zastosowanego w takim przypadku hasla po stronie serwera wynosi 100%. Serwer bowiem w ogole nie zna tego hasla, a bezpieczenstwo samego mechanizmu autoryzacji transakcji jest tozsame z bezpieczenstwem podpisow cyfrowych.

[blackfire 185]

jesli serwis umozliwia odzyskanie zapomnianego hasla to nie wazne w jakiej postaci sa one przechowywane (i tak jest bardzo zle)

 

Jeżeli rzeczywiście serwis pozwala na uzyskanie informacji "Twoje stare hasło to: 123456, sklerozo", to jest to dramat. Ale jeżeli hasła są przechowywane w postaci skrótów, to nie bardzo ma taką możliwość (nie będzie raczej ich brute force'ować), i może jedynie zaoferować ustawienie nowego hasła.

 

co do uwiezrzytelniania przez bok, wiekszosc firm "nie internetowych" ta sprawe zrzuca jednak na obsluge boku

 

Znaczy co, że bokowiec ma Twoje hasło przed oczami i mówi "Pan poda 1, 3 i 5 cyferkę"? Gdzie tak jest żebym przypadkiem im jakichś pieniędzy nie zostawił? Albo lepiej, pójdę tam do pracy na 3 mesiące i wyjdę z kompletem danych klientów.

 

Swoja droga nie dociera do Was mysl, ze aby zweryfikowac haslo uzytkownika przez pracownika BOK'u wystarczy zapamietac tylko niektore (np. co drugi, trzeci) znaki? Cale haslo nie musi byc nigdzie przechowywane w postaci niezaszyfrowanej.

 

OK. Mam hasło '123456'. Sugerujesz trzymać sha512('135') zamiast mojego hasła? Z miliona możliwości właśnie zrobiłeś tysiąc, a możesz zapytać tylko o '135' albo ściemniać że znasz pozostałe cyfry, pytać o '145' i akceptować cokolwiek na środkowej pozycji. Jeżeli chcesz trzymać skróty wszystkich kombinacji bez powtórzeń ('123', '124' itd. aż do '456'), to kompletnie położysz bezpieczeństwo na łopatki. Bo skróty te są w określonej kolejności, więc wystarczy złamać dwa ('123' i '456') i masz już całe hasło.

 

Skróty nie bardzo mogą być w kolejności losowej (tj. nie wiesz, które znaki zawiera skrót pierwszy), bo przy uwierzytelnianiu system wybiera Ci challenge ("1, 3, i 5 cyferka") przypisane do określonego skrótu. Jeżeli sam nie wie, do którego, to musi zaakceptować wszystkie -- wpisujesz 123 i jesteś w domu.

[bald 0]

Jeżeli rzeczywiście serwis pozwala na uzyskanie informacji "Twoje stare hasło to: 123456, sklerozo", to jest to dramat. Ale jeżeli hasła są przechowywane w postaci skrótów, to nie bardzo ma taką możliwość (nie będzie raczej ich brute force'ować), i może jedynie zaoferować ustawienie nowego hasła.

i o tym napisalem ze to tragedia jesli takie cos jest mozliwe

Znaczy co, że bokowiec ma Twoje hasło przed oczami i mówi "Pan poda 1, 3 i 5 cyferkę"? Gdzie tak jest żebym przypadkiem im jakichś pieniędzy nie zostawił? Albo lepiej, pójdę tam do pracy na 3 mesiące i wyjdę z kompletem danych klientów.

jak juz wczesniej wspomnialem w NORMALNYCH firmach tak sie nie postepujepoczytaj lepiej wszystkie wypowiedzi a nie opisuj "co ci sie wydaje ze wyczytales"

Nie. Ataki slownikowe istnieja dlatego, ze sa efektywne i ze wiekszosc zabezpieczen nadal korzysta z prostych hash'y.Swoja droga nie dociera do Was mysl, ze aby zweryfikowac haslo uzytkownika przez pracownika BOK'u wystarczy zapamietac tylko niektore (np. co drugi, trzeci) znaki? Cale haslo nie musi byc nigdzie przechowywane w postaci niezaszyfrowanej.

przeczytaj o czym wczesniej wspomnialem:bokowiec nie musi miec dostepu do hasla (a nawet nie powinien)moze miec tylko u siebie na ekranie komunikat przykladowo:prosze podac 4 znak hasla dla uzytkownika xxxprosi o ten znak uzytkownika, wklepuje i na tym konczy sie jego wiedza o haslach

[blackfire 185]

i o tym napisalem ze to tragedia jesli takie cos jest mozliwe

 

No. To się zgadzamy. Przechowywanie w systemie hasła plaintextem lub plaintext-equivalent jest złe.

 

przeczytaj o czym wczesniej wspomnialem:bokowiec nie musi miec dostepu do hasla (a nawet nie powinien)moze miec tylko u siebie na ekranie komunikat przykladowo:prosze podac 4 znak hasla dla uzytkownika xxxprosi o ten znak uzytkownika, wklepuje i na tym konczy sie jego wiedza o haslach

 

No dobrze. Jeżeli tak to wygląda, to bokowiec pozna hasło użytkownika najwcześniej po drugim kontakcie, najpóźniej po n-tym (wybacz, nie chce mi się tego liczyć, ale to groszowe sprawy. Na oko to coś koło piątego, pomijając złośliwe przypadki). A zawsze można klientowi coś delikatnie zepsuć, albo jakąś fakturę dziwną wystawić żeby zadzwonił. Osobą wykradającą hasła nie musi być też bokowiec -- admin (chociaż ten to zawsze da sobie radę :>), DBA, jakiś zewnętrzny konsultant albo ktokolwiek.

 

A ja cały czas stoję na stanowisku, że _nikt_ nie powinien znać żadnych Twoich h

seł. Móc zmienić owszem, ktoś na pewno, ale znać plaintext? W żadnym wypadku nie uznałbym tego za pożądane, chociaż czasem nieuniknione. Opisany przez Ciebie sch

mat na pewno jest lepszy od pokazywania bokowcowi całego hasła, ale wciąż wymaga dużego zaufania do operatora. A moje zaufanie np. do Home (przykładowo, b

 to od nich zaczął się ten wątek) kończy się na wierze, że nikt im nie zbackdoorował formularza do logowania.

 

Wyłączając bokowca z procesu autentykacji absolutnie nic nie tracisz (system wyświetlając challenge klientowi zamiast bokowcowi jest tak samo prosty/skomplikowany jak był wcześniej), a zabezpieczasz się przed bokowcem, a dokładnie jego złośliwością (wykradaniem haseł cyferka po cyferce) i ludzkimi błędami (źle coś usłyszy, klawisz mu się omsknie). Dodatkowym atutem jest fakt, że uwierzytelniania klient<->maszyna (bez bokowca w środku) nie da się ubłagać, przekupić, przekonać, zaszantażować itd.

 

EDIT: IPB mnie nie lubi.

[Gość]

Ludzie, to jest chore.. wy naprawdę dyskutujecie w temacie, czy przy autoryzacji "proszę podać trzeci znak hasła" jest pisane plain tekstem? Daliście się wciągnąć w tą dyskusję???

 

Przecież to logiczne, że to jest zabezpieczone, a gościu z BOKu nie ma hasła przed oczami i nie mówi sobie od tak "proszę podać trzeci znak hasła"... tak samo system wypluwa automatowi na mLinii "zapytać o któryś znak hasła" i przechodzi przez autoryzację tylko któryś tam znak.. naprawdę wierzycie, że to by było tak naiwne i łatwo dostępne?

 

megi sobie palnęła jakiś temat, bo nie chce jej się pogooglować ani pomyśleć logicznie, wysnuła jakieś dziwne wnioski (choć tak naprawdę, to technikaliów tego systemu raczej się nie da zdobyć, ewentualnie bardzo luźną teorię - bo przecież to są ważne rzeczy, baaardzo tajne wręcz), a wy teraz dysputy prowadzicie na ten temat?

 

Załamujecie mnie...

 

tak żeby zupełnie nie offtopować: jestem pewien (na to wskazuje ludzka logika), że BOKowiec jest tylko narzędziem pośredniczącym między systemem, a wami po drugiej stronie słuchawki.. nie widzi hasła, tylko czyta to, co mu system podaje... jaaa.. zaraz zaczniecie się dopytywać jak działa prepaid na komórkach albo autoryzacja SSL... phhhhhhh... żeby to chociaz webhelp był... ale na tym forum takie rzeczy?

 

Wiem, wychodzi moja jakaś duma i atak na niewiedzę, ale wybaczcie.. nie takie podstawy.. to są pytania informatyczne typu "mamusiu, a skąd się biorą dzieci?"... dyskusja skończyła się z 5 czy 8 postów wyżej.. co tu dodawać, co drążyć? Plain text to nie jest - BOK nie widzi hasła.. wszystko się dzieje szyfrowaniem w systemie autoryzacji.. i koniec, tyle musimy wiedzieć jako klient - ba, tyle najprawdopodobniej musi nam wystarczyć z informacji odnośnie tego systemu...

[p 3]

przeczytaj o czym wczesniej wspomnialem:bokowiec nie musi miec dostepu do hasla (a nawet nie powinien)moze miec tylko u siebie na ekranie komunikat przykladowo:prosze podac 4 znak hasla dla uzytkownika xxxprosi o ten znak uzytkownika, wklepuje i na tym konczy sie jego wiedza o haslach

Przeczytaj jeszcze raz to co napisalem i powiedz mi w jaki sposob koliduje to z tym o czym napisales?

 

OK. Mam hasło '123456'. Sugerujesz trzymać sha512('135') zamiast mojego hasła?

Nie, sugeruje, ze jezeli z jakis powodow w systemie hasla sa trzymane plaintekstem (np. do uwierzytelnienie przez pracownika BOKu), to wystarczy trzymac tylko czesc tego hasla w postaci niezaszyfrowanej (np. system/pracownik moze pytac tylko o parzyste znaki, ktore sa gdzies zapisane w plaintekscie, natomiast cale haslo jest zahashowane i nikt go nie moze odczytac). Tak, pozwala to na wielokrotne zmniejszenie liczby kombinacji podczas ataku typu brutal-force wykonywanego przez pracownika BOKu, ktory ma dostep do takich informacji, ale jednoczesnie wielokrotnie zwieksza bezpieczenswo w porownaniu do sytuacji, w ktorej pracownik widzi cale haslo (opisywanej powyzej).

Nie sugeruje, ze jest to rozwiazanie bezpieczne. Ale jest to na pewno rozwiazanie bezpieczniejsze

 

Przecież to logiczne, że to jest zabezpieczone, a gościu z BOKu nie ma hasła przed oczami i nie mówi sobie od tak "proszę podać trzeci znak hasła"... tak samo system wypluwa automatowi na mLinii "zapytać o któryś znak hasła" i przechodzi przez autoryzację tylko któryś tam znak.. naprawdę wierzycie, że to by było tak naiwne i łatwo dostępne?

Tak, to jest logiczne (co wcale nie oznacza, ze jest realizowane w praktyce). Poza tym opisywana sytuacja nie ogranicza sie tylko do mBank'u, ktory korzysta z IVR.

[alien 345]

@Sponsi Tylko, ze w tej dyskusji zupelnie nie chodzi o to co widzi pracownik obslugi BOKu i czy widzi on cale haslo czy tylko czesc. Jesli cale to tym gorzej, ale istota dyskusji, ktora zaczela Megi jest pytanie dlaczego na serwerze w ogole lezy haslo plaintext.

 

Na marginesie, nie przekonasz mnie do tego, ze system IVR mBanku jest naprawde bezpieczny. W tym systemie tylko do pewnego stopnia chodzi o bezpieczenstwo. Priorytetem jest jego uzytecznosc, dostepnosc. Sam mi przyznasze, ze mBank zyskal popularnosc wlasnie dzieki wygodzie swoich systemow. To tak jak z kartami platniczymi. Gdyby chodzilo o ich bezpieczenstwo to dawno juz zrezygnowano by z czterocyfrowych PINow. Ale dla banku priorytet to uzytecznosc kart. Jak ludzie zapomna dluzszych PINow to obroty banku spadna :-).

[bald 0]

Ludzie, to jest chore.. wy naprawdę dyskutujecie w temacie, czy przy autoryzacji "proszę podać trzeci znak hasła" jest pisane plain tekstem? Daliście się wciągnąć w tą dyskusję???

 

 

zimno dzisiaj okrutnie (+snieg :/), ps3 mi latorosl okupuje, zwyczajnie nudze sie

[blackfire 185]

Ludzie, to jest chore.. wy naprawdę dyskutujecie w temacie, czy przy autoryzacji "proszę podać trzeci znak hasła" jest pisane plain tekstem? Daliście się wciągnąć w tą dyskusję???

 

Tak. Bo widzisz, niektórzy coś wiedzą na ten temat.

 

Przecież to logiczne, że to jest zabezpieczone, a gościu z BOKu nie ma hasła przed oczami i nie mówi sobie od tak "proszę podać trzeci znak hasła"... tak samo system wypluwa automatowi na mLinii "zapytać o któryś znak hasła" i przechodzi przez autoryzację tylko któryś tam znak.. naprawdę wierzycie, że to by było tak naiwne i łatwo dostępne?

 

W mBanku (o innych pisał alien) jest to zrobione z głową o tyle, że bokowiec nie uczestniczy w żaden sposób w procesie autentykacji za pomocą telekodu (choć za pomocą nieśmiertelnego nazwiska panieńskiego matki to i owszem). Nie zmienia to faktu, że Twój telekod jest trzymany w bazie mBanku plaintextem. Tak, naprawdę. Przykro mi. Przy uwierzytelnianiu challenge-response (a "1, 3 i 5 cyferka" to jego prymitywna wersja, gdzie response może policzyć człowiek) system musi znać hasło plaintextem. Pomyśl nad tym przez chwilę. O użyciu do tego funkcji skrótu już pisałem.

 

megi sobie palnęła jakiś temat, bo nie chce jej się pogooglować ani pomyśleć logicznie, wysnuła jakieś dziwne wnioski (choć tak naprawdę, to technikaliów tego systemu raczej się nie da zdobyć, ewentualnie bardzo luźną teorię - bo przecież to są ważne rzeczy, baaardzo tajne wręcz), a wy teraz dysputy prowadzicie na ten temat?

 

No bo wiadomo, że mechanizm bezpieczeństwa musi być tajny, a w Home zaprojektował go sam janioł z niebiesiech. Weź się jeszcze bardziej nie kompromituj. Podstawowa zasada kryptografii zakłada, że tajny jest _klucz_. Algorytm może zawsze zostać ujawniony bez straty dla bezpieczeństwa systemu. Dlatego ważność rzeczy nijak nie koreluje z jej "baaardzo tajnością wręcz" (no prawie nijak).

 

Zdobyć technikalia mógłby ktoś, kto pracuje w Home i byłby skłonny się podzielić takimi informacjami, ale przy obecnym stanie naszej wiedzy na ten temat (fragment hasła podajesz bokowcowi plaintextem) nie spodziewałbym się rewelacji. BTW, czujesz różnicę między "wpisujesz część hasła w DTMF automatowi po drugiej stronie" a "wpisujesz część hasła w okienko czatu z bokowcem"?

 

Załamujecie mnie...

 

I vice versa. Poczytaj wikipedię, a potem np. "Practical cryptography" Schneiera i Fergusona (za "Applied cryptography" jeszcze się nie bierz bo to trudna książka).

 

tak żeby zupełnie nie offtopować: jestem pewien (na to wskazuje ludzka logika), że BOKowiec jest tylko narzędziem pośredniczącym między systemem, a wami po drugiej stronie słuchawki.. nie widzi hasła, tylko czyta to, co mu system podaje... jaaa.. zaraz zaczniecie się dopytywać jak działa prepaid na komórkach albo autoryzacja SSL... phhhhhhh... żeby to chociaz webhelp był... ale na tym forum takie rzeczy?

 

No żeby to webhelp był to byś wyszedł na guru a tak -- sorry Wincencie. Zdążyliśmy już ustalić, że system, w którym bokowiec widzi hasło to dramat, syf i malaria, nie sugeruję że Home tak ma. Ale z drugiej strony (o tym też już pisałem), jak podajesz _bokowcowi_ choćby fragment hasła, to w krótkim czasie jest on w stanie zdobyć całość plaintextu. Tak więc jeszcze raz: jakikolwiek udział żywego pracownika BOKu w procesie autentykacji jest raz że zbędny, a dwa że szkodliwy. I nie ma to akurat związku z metodą uwierzytelniania (plaintext/C-R).

 

Wiem, wychodzi moja jakaś duma i atak na niewiedzę, ale wybaczcie.. nie takie podstawy.. to są pytania informatyczne typu "mamusiu, a skąd się biorą dzieci?"... dyskusja skończyła się z 5 czy 8 postów wyżej.. co tu dodawać, co drążyć? Plain text to nie jest - BOK nie widzi hasła.. wszystko się dzieje szyfrowaniem w systemie autoryzacji.. i koniec, tyle musimy wiedzieć jako klient - ba, tyle najprawdopodobniej musi nam wystarczyć z informacji odnośnie tego systemu...

 

Nie, to nie duma. Poszukaj wśród cytatów przypisywanych Twainowi. Jeżeli porównujesz to pytanie do "skąd się biorą dzieci", to mogę porównać Ciebie do "mamusi", która na konferencji ginekologów (or whatever) udowadnia zawzięcie, że z kapusty. Czy Ty w ogóle masz świadomość tego, co to jest plaintext? To naprawdę nie jest karteczka nad biurkiem bokowca. Trzymanie haseł plaintextem może być bezpieczne (jeżeli wgląd do tej bazy jest odpowiednio strzeżony), ale taka decyzja musi być podjęta świadomie i z pełną znajomością konsekwencji. Z dostępnych tu informacji wynika, że Home w tym miejscu dał ciała.

[alien 345]

Ale z drugiej strony (o tym też już pisałem), jak podajesz _bokowcowi_ choćby fragment hasła, to w krótkim czasie jest on w stanie zdobyć całość plaintextu. Tak więc jeszcze raz: jakikolwiek udział żywego pracownika BOKu w procesie autentykacji jest raz że zbędny, a dwa że szkodliwy. I nie ma to akurat związku z metodą uwierzytelniania (plaintext/C-R).

 

To akurat w czatach da sie latwo rozwiazac. Wprawdzie nie wiem jak to robi home, ale mozna w czata zaimplementowac calkowicie zautomatyzowany system weryfikacji takiego hasla / czesci hasla. Pracownik BOK moze w takim przypadku otrzymywac od systemu jedynie informacje typu "Zweryfikowano jako xxx (login)".

 

Co do reszty wypowiedzi oczywiscie brak zastrzezen :-).