Kilka znaków zamiast całego hasła - jak to działa? Opcje

[NetBeans]

Cześć.
Pewnie większość z Was kojarzy metody logowania na stronach banków. Jest to wykonane w ten sposób, że musimy podać tylko kilka znaków naszego hasła (reszta jest zablokowana, tak jakby już były wpisane). Zastanawiam się w jaki sposób to działa. Zakładam, że hasła są hashowane, więc w jaki sposób porónywane są ciągi, skoro są niekompletne. Nie jest chyba możliwe, że system wie jakie znaki hasła mamy pod daną cyferką (widoczne na obrazku) i uzupełnia ciąg do porównania z hashem. Do tego "szare" pola są generowane losowo. Interesuje mnie zasada działania, nie proszę o żaden gotowy kod etc.
Pozdrawiam.

Wspomniany obrazek:

[b4rt3kk]

Rzeczywiście, hasło na pewno nie jest przechowywane w formie jawnej i na pewno nie jest to jeden hash, ale nic nie stoi na przeszkodzie, by było to np. 10 hash-ów, każdy odpowiedzialny za zakodowanie 1 znaku.

[NetBeans]

Tak, ale hashe dla każdego znaku z tablicy ASCII (a nawet dla wielu prostych słów) są dostępne w Google dla każdej funkcji hashującej. Nie byłboby to bezpieczne, nieprawdaż?

[pyro]

Hasło: przykładowo X znaków

czyli X wpisów do tabeli user_password_chars_hashes (z relacją do usera), każdy znak oddzielnie hashowany jednostronie (np. SHA-256).

Nie takie trudne jak się wydaje.

Ten post edytował pyro 13.07.2013, 12:10:42

[adamantd]

Ciekawe
A może tak.
1. rejestrujesz się do systemu bankowego i wymyślasz sobie hasło
2. system rozbija je na literki, koduje każdą z nich jednostronnie
3. zapisuje do bazy w postaci zakodowanaPojedynczaLiterka|zakodowanaDrugaLiterka|zakodowanaTrzeciaLiterka|itd itd
4. chcesz się zalogować, system wyciąga z bazy twoje hasło i rozbija na tablicę i przedstawia Ci losowo np 4, 6, 9 pole do uzupełnienia a pozostałe pokazuje że są uzupełnione (w rzeczywistości nie są tylko tak wygląda, żeby łatwiej było Ci policzyć którą masz wpisać)
5. system koduje te literki i porównuje z poszczególnymi wartościami z tablicy

[b4rt3kk]

Tak, ale hashe dla każdego znaku z tablicy ASCII (a nawet dla wielu prostych słów) są dostępne w Google dla każdej funkcji hashującej. Nie byłboby to bezpieczne, nieprawdaż?

Każdy znak można odpowiednio "posolić".

[NetBeans]

Faktycznie, jedynie soląc hashe znaków byłoby to w miarę bezpieczne. Inaczej możnaby stworzyć mini tablicę tęczową z hashami dla każdego znaku ASCII, a następnie przelecieć dany hash. Wtedy takie zabezpieczenie byłoby bez sensu. No cóż, chyba doszliśmy (a właście doszliście) do rozwiązania. Jeżeli ktoś ma jeszcze inny pomysł to chętnie poczytam.

[gitbejbe]

tak jak piszecie powyżej.

Systemy bankowe mają tą przewagę, że wszystkie informacje o klientach nie są jawne. To nie forum gdzie widać kto ma jaki nick, kiedy się zarejestrował itd.... Nie ma żadnych danych o klientach co daje duże pole manewru do bezpiecznego hasowania haseł. Też uważam, że takie hasło poprostu rozbija się na pojedyncze znaki i odpowiednio soli. Solą może być wszystko, więc nie będę wymyślał jakiś przykładów ale taki rodzaj sprawdzania hasła dla zwykłych witryn jest zbędny...

[pyro]

Warto dodać, że sól powinna być wyłącznie zahardcodowana w skrypcie, a nie w bazie danych tak jak np. to się podaje w każdym wierszu userów w ich tabeli.

[drPayton]

Warto dodać, że sól powinna być wyłącznie zahardcodowana w skrypcie, a nie w bazie danych tak jak np. to się podaje w każdym wierszu userów w ich tabeli.

Chyba, że każde hasło (czy ogólnie: każdy hashowany string) ma osobną sól. Wówczas nie ma innej opcji jak zapisywanie ich w bazie a potencjalny "kradziej" bazy danych, nie mając kodu i tak nie wie jak sól jest używana... (a jak kod ma to i hardcodowaną w nim sól

[pyro]

Chyba, że każde hasło (czy ogólnie: każdy hashowany string) ma osobną sól. Wówczas nie ma innej opcji jak zapisywanie ich w bazie a potencjalny "kradziej" bazy danych, nie mając kodu i tak nie wie jak sól jest używana... (a jak kod ma to i hardcodowaną w nim sól

No tak... bo komu by się chciało poświęcić setki godzin aby sprawdzić, czy litera jest hashowana tak:

'a'.'UltraSol'

Czy tak:

'UltraSol'.'a'

Proszę o przemyślenie sprawy przed napisaniem kolejnego postu tego typu.

Ten post edytował pyro 17.07.2013, 07:12:51

[Sephirus]

Włączę się bo widzę pewną potencjalną lukę. Przy takich założeniach gdzie mamy pojedyncze literki hashowane oddzielnie dość łatwo jest wyciągnąć hasła wszystkich userów.

Założenia:
1. Literki są hashowane i solone tym samym ciągiem (ciąg na sztywno w kodzie)
2. Na wstępie mamy bazę powiedzmy 1000 userów z różnymi hasłami - bierzemy wszystkie możliwości hashu literek (unikalne - maks liczba = liczbie znaków w alfabecie hasła)
3. Dla każdej możliwości bruteforcem jedziemy i szukamy literki tworząc hashe ze znaną solą,
4. Mamy tablice (hash => literka) - prosty skrypt i mamy tysiąc haseł

Czas realizacji po włamie na serwer i ściągnięciu danych wg mnie: manualnie: ~1h, automatycznie (skrypt): 5minut?

Warto zauważyć że jak raz się skapniemy jak dodawany jest do literki salt to potem już jest błyskawicznie...

Więc taka opcja odpada na bank (chyba, że o czymś zapomniałem).

Wynika mi z tego, że każda literka powinna mieć różne sole, bądź rózni userzy różne sole. Wydaje mi się jednak, że to jedynie nieco spowolni proces bo sól danego usera musi być gdzieś zapisana/generowana a z tego wynika, że dla konkretnego gościa musimy jedynie przelecieć wszystkie literki z tą solą i i tak odzyskać hasło. Można napisać skrypt który ogarnie to w dość szybkim czasie dla każdego z userów osobno.

Co wy na to? Czy o czymś zapominam czy to jednak totalna bzdura?

Dla porównania bruteforce na normalnej długości haśle, nawet posiadając sól już nie potrwa tak krótko...

[pyro]

Cześć.

Mając trochę doświadczenie w temacie raczej bzdura. No chyba, że ta sól to coś w stylu "abcd".

Jak Ty sobie wyobrażasz złamanie hashu w stylu:

'a'.'diuu5778912UIDFH3279&^@^$CFHSHNSHDFMsif375*&@(%%Y^|YHF998@*($fhhfjLL'

W ciągu ileś minut / godzin? Jak dla mnie można z takim czymś spokojnie spać nawet do końca życia. Nawet jak natrafisz na kolizję to Ci nic nie da poza odkodowaniem jednej literki.

Co do tęczowych tablic - mam wrażenie, że po prostu nie wiesz co to jest .

Ten post edytował pyro 17.07.2013, 08:09:34

[b4rt3kk]

Jakby solą był np. login użytkownika (lub kilka znaków z loginu, np. pierwszy, ostatni i 3) + unikalny hash jeszcze raz zahashowane razem i dopiero użyte jako sól to nie ma takiej opcji żebyś brute forcem odkodował literka po literce. No chyba, że znałbyś metodę kodowania, czyli musiałbyś mieć dostęp do skryptów.

[Sephirus]

@pyro

Wyobraź sobie, że wyobrażam (zauważ, że mówię tu o włamania na FTP + DB a nie samym DB - wówczas masz rację)

salt = xxx... (znany)
hash = yyy...
metoda hashowania znana (załóżmy) hash = f([literka].salt);

mam Ci napisać FORa, który to szybko zgadnie literkę? Ile będzie miał iteracji... hmm.. nie wiem ale pewnie ~100 max

Dalej... mam już "rozszyfrowana" literkę x, potem robie to samo dla y, z, ....

Mam wszystkie literki => mam wszystkie hasła - proste?

To wszystko w założeniu istnienia jednej soli.

Dla różnych soli proces wcale nie jest bardziej skomplikowany.

Nic nie pisałem o tęczowych tablicach - są tu zbędne - jesli naprawdę "masz trochę doświadczenia w temacie" to wyjechanie z nimi oznacza jedynie, że nie rozumiesz co napisałem

@up

Zgadzam się - ale to właśnie zakładam a wbrew pozorom trzeba to mieć na uwadzę, że ktoś może się włamać na serwer (co mu też daje dostęp do DB). W przypadku zwykłych haseł liczba kombinacji nawet znając SALT i układ jest ogromna. Dla jednej literki liczba kombinacji jest max 3 cyfrowa (tak na prawdę 2 cyfrowa w praktyce)

Ten post edytował Sephirus 17.07.2013, 08:18:38

[pyro]

@Sephirus, według Twojego toku myślenia jak włamywacz znajdzie nawet reflected XSS to ma kontrolę nad całym serwerem.

Jeżeli ktoś się włamie do bazy danych (SQL Injection, weak password, inne.) i ma tam też wszystkie sole, to w ogóle po jaką cholerę one miały by być? A jak się włamie do bazy danych, a sól jest długa i zahardcodowana w skrypcie, to te wszystkie hashe dla niego raczej bezwartościowe ciągi znaków i jeżeli nie znajdzie sposobu na dostanie się do plików, to jest bezsilny. Widzisz różnicę?

Ten post edytował pyro 17.07.2013, 08:22:36

[sowiq]

Koledzy, wtrącę się i ja, bo kiedyś myślałem o takim rozwiązaniu. Wybaczcie, ale trochę kupy nie trzyma się Wasze rozumowanie. Najpierw napiszę dlaczego, a później opiszę moje rozumowanie.

1. Hashowanie pojedynczych znaków

1.a. Wspólna sól trzymana w kodzie.
Przypadek trywialny, bo sami sobie robimy szyfr słownikowy. Każdemu znakowi będzie w bazie odpowiadał jeden, taki sam ciąg. Mało tego - po znalezieniu soli dla jednego znaku znamy ją globalnie. Czas złamania - kilka minut na znak w zależności od długości soli. Ewentualnie można polecieć algorytmem statystycznym, jak to robili już w czasie II wojny światowej

1.b. Każdy znak solony inną solą.
W tym przypadku nie ma innej opcji jak trzymanie każdej soli w bazie. Przypadek jeszcze łatwiejszy niż poprzedni, bo niewiadomą jest już tylko szukany znak. Ile milisekund potrzebowałby w miarę szybki komputer na wygenerowanie n hashy (n - liczba dostępnych znaków)?

1.c. Sól generowana dynamicznie w kodzie dla każdego usera.
Rozwiązanie najlepsze z tych 3. Ale domyślam się, że po złamaniu pierwszych 1000 haseł bez większego problemu można znaleźć klucz, który określa w jaki sposób generowana jest ta sól. Bo oczywiście nie może to być losowanie, bo za każdym razem dla danego usera musi być wygenerowana ta sama sól.


2. Moje rozumowanie

2.a Generowanie n kombinacji
Jak dla mnie najbezpieczniejszym rozwiązaniem byłoby wygenerowanie n kombinacji dla danego hasła. Załóżmy dla uproszczenia, że hasło składa się z 5 znaków, a user musi wpisać co najmniej 3. Daje to 26 kombinacji (poprawcie mnie jeśli się mylę). Zapisujemy każdą z nich w bazie jako posolony hash. Przy każdym rekordzie zapisujemy które znaki są w nim zawarte i zapisujemy też sól. Przed logowaniem system wybiera z bazy opcję hasła (które znaki trzeba wpisać), a później hashuje hasło i porównuje z informacją w bazie, podobnie jak przy "normalnym" logowaniu.
Wady:
- przy dłuższych hasłach hashy będzie dosyć sporo
- przy algorytmach lepszych niż md5/sha1, czas generowania kombinacji może być dosyć długi (kilka/naście sekund?)
- trochę skomplikowana implementacja generowania kombinacji
Zalety:
- kombinacje generowane tylko podczas zakładania konta i zmiany hasła
- IMO całkiem bezpieczne rozwiązanie

Ten post edytował sowiq 17.07.2013, 08:29:24

[pyro]

Koledzy, wtrącę się i ja, bo kiedyś myślałem o takim rozwiązaniu. Wybaczcie, ale trochę kupy nie trzyma się Wasze rozumowanie. Najpierw napiszę dlaczego, a później opiszę moje rozumowanie.

1. Hashowanie pojedynczych znaków

1.a. Wspólna sól trzymana w kodzie.
Przypadek trywialny, bo sami robimy szyfr słownikowy. Każdemu znakowi będzie w bazie odpowiadał jeden, taki sam ciąg. Czas złamania - kilka minut na znak w zależności od długości soli. Ewentualnie można polecieć algorytmem statystycznym, jak to robili już w czasie II wojny światowej

To jest mój hash: e152c000118ddbc4b372c6e1d8289696662de535993269e715348f02f9b4f238

Powiem Ci w jak on jest zaszyfrowany: SHA256
Ba... powiem Ci nawet z której strony jest literka: na początku.
Mega Ba!... powiem Ci nawet ile znaków ma sól: 76
Jeżeli uda Ci się to złamać kiedykolwiek, to obiecuję Ci, że uczynię nas obu bogatymi. A jeżeli tak jak to mówisz dla Ciebie kwestia kilka minut to ohohho!

Czas start!

[Sephirus]

@pyro - nie mam zamiaru się z Tobą kłócić o to czy da się włamać na serwer (i jak) czy się nie da - to jest OT. Podałem w moim rozumowaniu bardzo mocną lukę takiego kodowania "literek" jesli ktoś ma dostęp do serwera - bo ma wtedy dostęp do wszystkiego co mu jest potrzebne aby rozkodować wszystkie hasła.

Więc przeczytaj to uważnie i odpowiedz mi: Mam dostęp całkowity do serwera i DB - czy moje rozumowanie jest wówczas poprawne czy nie? (nie mam zamiaru tu wmawiać nikomu, że gdybym miał sam dostęp do bazy do tym odhashował wszystkie hasła - a Ty mi to wmawiasz.)

Nie mówię tu o żadnym XSS tylko full dostępie - musisz sobie przypomnieć, że wyciek danych to nie koniecznie potocznie zwany "hakier" ale na przykład niedopłacany programista, który ma dostęp do serwera, bądź jakiś kolega, który pochwali się jaki to wspaniały system zrobili hashowania literek itd.

Sam mam dostępy do różnych baz z masą kont użytkowników. Sam wiem jakich metod uzywamy do przechowywania haseł w bazie. Ta wiedza daje mi tyle, że nigdy bym się nie pokwapił na próbę ich rozkodowania nawet mając full dostęp (jedyne co mógłbym zrobić to przy rejesteacji wysylać mail do siebie z jawnym hasłem ). W tym jednak przypadku wydaje mi się dość prostę odszyfrowanie tego wszystkiego - a ja (może się mylę?) widze to jako duże zagrożenie... ale może polityka bezpieczeństwa wewnętrznego jest nieistotna

[sowiq]

Czas start!

Zwróć szczególną uwagę na to:

sami sobie robimy szyfr słownikowy [...] można polecieć algorytmem statystycznym, jak to robili już w czasie II wojny światowej

[edit]
Mało tego. Przypadek może trochę z dupy, ale wyobraź sobie, że "atakujący" sam ma konto w serwisie, z którego pochodzi baza. Jego konto ma 20-znakowe hasło. I co? I 20 znaków z naszego słownika leci "w pizdu"

Ten post edytował sowiq 17.07.2013, 08:38:55