Jak przechowywać hasła

Odpowiedz Nowy wątek
2019-08-06 23:22
0

Takie pytanie. Mam aplikację webową na serwerze hostingowym. Na tym samym serwere jest baza danych. Aplikacja łączy się za pomocą webApi z różnymi zewnętrznymi serwisami. Klienci logują się do systemu stosując indywidualne hasła. Obsługę haseł klientów mam załatwioną. Pytanie: w jaki sposób i gdzie przechowywać hasła i inne access tokeny do wszystkich WebApi z którymi łączy się aplikacja? Przecież nie każę przy każdym logowaniu podawać klientowi 10 haseł. Wpisać na sztywno do kodu głupio i niepraktycznie. Jedyne co mi przychodzi do głowy to jakoś je kodować i dekodować w programie i w zakodowanej postaci zapisywać w bazie. Co myślicie?

edytowany 1x, ostatnio: akerman, 2019-08-06 23:25

Pozostało 580 znaków

2019-08-06 23:24
0

przecież hasła zwykle przechowuje się w bazie jako hash md5
Dekodować hasła nie musisz, baza danych nie powinna o nim wiedzieć jakie ono jest dokładnie, wystarczy ten hash, i w przy logowaniu porównujesz mdEncode(haselkoString) z tym z bazy

edytowany 1x, ostatnio: au7h, 2019-08-06 23:31
Pokaż pozostałe 6 komentarzy
no to jeżeli to nie hasła indywidualne dla kont w sensie login: admin pass: admin1 to zwyczajnie jako varchar w bazie, co za problem, lulz - au7h 2019-08-06 23:37
@au7h: czy ty ogarniasz, że jemu nie chodzi o hasło do konta w jego serwisie tylko zewnętrznym? - mr_jaro 2019-08-06 23:38
to nie zmienia faktu że trzeba takie rzeczy "ukrywać" - au7h 2019-08-06 23:40
pamiętam że kiedyś w którejś tam wersji komunikatora GaduGadu hasła były trzymane w pliku na kompie klienta ;p - au7h 2019-08-06 23:42
kolizje do MD5 da się wygenerować w czasie poniżej 1s. SHA1 da się złamać jak zapłacisz odpowiedniej osobie kilkaset tysięcy $. W mojej firmie nie możno używać MD5/SHA1 do czegokolwiek co ma być bezpieczne z tego właśnie powodu. Do haseł w bazie służy PBKDF2 - krwq 2019-08-07 18:11

Pozostało 580 znaków

2019-08-06 23:38

Takie rzeczy musisz szyfrować i w formie zaszyfrowanej trzymać w bazie. Nie znam innego sposobu. Klucze przechowywać w configu lub jako certy. I tutaj pojawia się najgorsza kwestia, bo jak będzie włamanie do bazy do jeszcze ok, ale jak się dostanie do plików to macie totalny kataklizm. Wasz devops musi być dobry no i sam kod powinien mieć porządne review i mieć cykliczne audyty bezpieczeństwa.

/trololol wyświetl userowi 10 password boxow przy logowaniu do aplikacji, a przeglądarka mu je wprowadzi przy użyciu "zapamiętaj hasło" :D - WeiXiao 2019-08-06 23:40

Pozostało 580 znaków

2019-08-06 23:39
1

Do 3rd party API powinieneś mieć tylko jedno konto/klucz (ewentualnie jedno per środowisko) per integracja. Twoja aplikacja powinna być swego rodzaju proxy do tych serwisów.

Pozostało 580 znaków

2019-08-06 23:41
1
iksde napisał(a):

Do 3rd party API powinieneś mieć tylko jedno konto/klucz (ewentualnie jedno per środowisko) per integracja. Twoja aplikacja powinna być swego rodzaju proxy do tych serwisów.

Podam ci przykład, kiedy to co gadasz to brednie :) Serwis korzysta z google driva, każdy user może sobie podpiąć taki dysk indywidualnie, bo coś tam ma ta jego apka zapisywać, a to oznacza że KAŻDY user ma INDYWIDUALNY TOKEN LUB ZAPISANE HASŁO I LOGIN do swojego dysku.

Edit, dodam tylko, że to nie jest wcale jakieś dziwne, bo pół roku temu przez kilka miesięcy pracowałem nad takim serwisem, który integrował w sobie kilka innych serwisów, tak by user z jednego miejsca zarządzał kontami z kilku zupełnie innych stron ale robiących to samo. Tam musieliśmy zapisywać klucze, które userzy generowali w tych zewnętrznych serwisach.

edytowany 2x, ostatnio: mr_jaro, 2019-08-06 23:46

Pozostało 580 znaków

2019-08-06 23:49
0
mr_jaro napisał(a):
iksde napisał(a):

Do 3rd party API powinieneś mieć tylko jedno konto/klucz (ewentualnie jedno per środowisko) per integracja. Twoja aplikacja powinna być swego rodzaju proxy do tych serwisów.

Podam ci przykład, kiedy to co gadasz to brednie :) Serwis korzysta z google driva, każdy user może sobie podpiąć taki dysk indywidualnie, bo coś tam ma ta jego apka zapisywać, a to oznacza że KAŻDY user ma INDYWIDUALNY TOKEN LUB ZAPISANE HASŁO I LOGIN do swojego dysku.

Edit, dodam tylko, że to nie jest wcale jakieś dziwne, bo pół roku temu przez kilka miesięcy pracowałem nad takim serwisem, który integrował w sobie kilka innych serwisów, tak by user z jednego miejsca zarządzał kontami z kilku zupełnie innych stron ale robiących to samo. Tam musieliśmy zapisywać klucze, które userzy generowali w tych zewnętrznych serwisach.

A czy w takim przypadku (google drive) nie powinno to się odbyć tak, że użytkownik przekazuje aplikacji uprawnienia do swojego dysku/folderu? Oczywiście nie każda apka na coś takiego pozwoli, ale jeśli można to chyba tak by było lepiej :D

Opcja nr 2 - aplikacja ma swojego google drive'a, którego udostępnia użytkownikom i przy okazji zarządza uprawnieniami. Robiłem coś podobnego, tylko zamiast gdrive był Sharepoint, nawet spoko działało.

Pewnie można wymyślić scenariusze, gdzie nie da się tego zastosować, ale może akurat OP to wystarczy ;)

edytowany 1x, ostatnio: iksde, 2019-08-06 23:51

Pozostało 580 znaków

2019-08-06 23:51
0

@iksde: przekazuje ale nadal ty w bazie musisz zapisać otrzymany klucz. A sama udzielenie uprawnień to rzadkość. Google i fb tak, ale inne nawet z sektora finansowego, nie maja czegoś takiego ;)

edit. oj uwierz, że opcja numer 2 jest możliwa w dużo mniej niż 1% przypadkach :D

edytowany 1x, ostatnio: mr_jaro, 2019-08-06 23:53
Chyba opcja 1 jest rzadko możliwa do zrealizowania :) przecież opcja 2 to zwykłe wykorzystanie API, tylko doklepanie paru checków zanim wyślemy request w imię jakiegoś użytkownika. Wtedy ty jesteś bogiem i o wszystkim decydujesz, a API traktujesz jako zasób. - iksde 2019-08-06 23:55
@iksde: spróbuj zrobić coś takiego np z grą na giełdzie bo takie coś robiłem jakiś czas temu, powodzenia :D - mr_jaro 2019-08-06 23:56

Pozostało 580 znaków

2019-08-07 10:29
0

Dziękuję za burzliwą dyskusję pod moim pytaniem, zwłaszcza @mr_jaro .Wydaje się więc, że potrzebne jest trzymanie w bazie zaszyfrowanych haseł. Pytanie gdzie trzymać klucze szyfrujące. A może zrobić coś takiego że za klucz robiłoby hasło użytkownika podawane przy logowaniu (ewentualnie po zhaszowaniu)? Wtedy unikniemy sytuacji, że klucze są przechowywane w kodzie/configu na serwerze. Tak myślę, że to by się mogło fajnie sprawdzić gdyby klient korzystający z zestawu haseł zewnętrznych był jeden. Jeśli w ramach firmy, korzystającej z tego samego zestawu haseł zewnętrznych jest wielu klientów, trzeba by robić jakąś formę dodatkowego logowania (podawania secret codu - takiego samego dla wszystkich użytkowników z jednej firmy). Ale dzięki temu nie będę miał na serwerze równocześnie zaszyfrowanych haseł i kluczy. Co myślicie?

Pozostało 580 znaków

2019-08-07 11:48
0

jak będziesz szyfrował hashem to atakujący będzie miał wszystko na tacy gdy się dostanie do bazy. Za to gdy trzymasz klucze w plikach to gdy się dostanie tylko do bazy to nadal nic nie uzyska, a gdy się dostanie do plików to i tak do bazy się dostanie.

Pozostało 580 znaków

2019-08-07 13:14
0

@mr_jaro No tak. Masz rację, ale to szczegół techniczny. Do szyfrowania/deszyfrowania można użyć innego rodzaju hashowania (czy przetwarzania hasła klienta na klucz do szyfrowania). Chodzi mi o samą ideę, dzięki której w bazie przechowywać będę hashe haseł klienta oraz zaszyfrowane hasła i loginy do serwisów zewnętrznych, a klucze do ich szyfrowania nie będą nigdzie przechowywane, bo będę je generował na podstawie hasła klienta w momencie gdy będzie się on logował. W momencie włamania, nawet gdy ktoś zdekompiluje mój kod, znajdzie jedynie metodę którą przetwarzam hasło klienta na klucz a nie sam klucz. Daj proszę znać czy widzisz jakieś haczyki, bo ja mam wrażenie że znalazłem graala.

Nie znalazłes graala, tylko próbujesz budowac taran żeby wyważyć drzwi w kiblu, które sa otwarte a w rzeczywistości chcesz wejść do kuchni. Poczytaj o OAuth. Nie trzyma się w bazie zaszyfrowanych haseł. Nigdy. Nie trzyma sie w bazie haseł w plain text. Nigdy. Uzywa sie skrótu, ale nie md5 - jest już za stary i nie zapewnia żadnego bezpieczeństwa. - ccwrc 2019-08-07 13:36
OAuth bardzo fajne. Przyda się jak się będę integrował z Googlem. Pytanie co robić gdy zewnętrzny serwis nie ma oauth. Zresztą oauth też nie do końca jest tu rozwiązaniem bo tak czy owak zmusza klienta do dodatkowego logowania się. - akerman 2019-08-07 14:57
problem, który opisujesz jest znany: https://www.google.com/search[...]sKAA&biw=1859&bih=903 natomiast twoje wypowiedzi wskazują, że szukasz dla siebie usprawiedliwienia do zrobienia sobie bazy haseł klientów do obcych serwisów. Nie zdajesz sobie sprawy, że przez to możesz nie wypłacić się do końca życia. - ccwrc 2019-08-07 15:19

Pozostało 580 znaków

2019-08-07 13:18
0

1) user zmienia hasło do konta u ciebie i nagle nie ma jak odszyfrować zapisanych haseł do zewnętrznych usług
2) atakujący włamuje się na serwer, pobiera sobie kod, pobiera sobie bazę, odpala go u siebie lub, znajduje algorytm i ma dostep do wszystkich haseł zapisanych w bazie - brawo sprawiłeś, że 15 minut dłużej walczył by mieć wszystkie dane w plain text :)

edytowany 1x, ostatnio: mr_jaro, 2019-08-07 13:18
1) Procedura zmiany hasła klienta będzie obejmować zaszyfrowanie zewnętrznych haseł nowym kluczem. 2) W kodzie znajdzie jedynie algorytm którym zamieniam hasło klienta na klucz do szyfrowania. Samego hasła nie będzie, a bez niego klucza do szyfrowania się nie wygeneruje. Czy może w euforii czegoś nie ogarniam? - akerman 2019-08-07 13:24
pomyśl logicznie, ja cały czas widzę luki, luki których nie zabezpieczysz inaczej jak porządnym audytem bezpieczeństwa i stałym silnym monitoringiem serwera - mr_jaro 2019-08-07 13:27
Tak czy owak, dzięki za inspirującą rozmowę. - akerman 2019-08-07 13:28

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0