Dlaczego to jest zły pomysł
https://niebezpiecznik.pl/post/powazna-wpadka-mbanku-klienci-mieli-wglad-w-cudze-rachunki/
1
3
mógł nastąpić jakiś błąd porównywania numerów dowodów, które bank zapewne traktuje jako tzw. unikatowe klucze w bazie lub po prostu “przekręcił” się inny identyfikator użytkownika
Numer dowodu to nie PESEL.
Sytuacja dziwna i mocno niepokojąca, zwłaszcza brak oficjalnych informacji z banku, przez co rodzą się dziwne teorie spiskowe.
3
Mimo że mamy do czynienia z unikalną sytuacją na skalę światową (jest to coś rozmiaru Czarnobyla w branży finansowej), to jakoś to jest zamiatane pod dywan.
"Wpadka"?
Trochę to zalatuje liberalnym podejściem do danych a'la JavaScript.
Czyżby mBank był oparty o Node.js?
A może ten bank wszystko wyałtsorsował do któregoś z krajów Indonezji i się nie dogadali?
Bo ofert pracy dla programistów raczej nie publikują.
4
Kluczem powinno być coś bez specjalnego znaczenia, wszelkie używanie PESEL-u, numeru dowodu, daty urodzenia, numeru ubezpieczenia itp to proszenie się o kłopoty. Prędzej czy później ktoś się pomyli przy wpisywaniu, zrobią się duplikaty, kolizje itp. Najprościej wygenerować liczbę lub GUID.
6
Ale w sumie jaki jest związek tematu z mBankiem?
Bo jedyny jaki widzę to to, że pod artykułem o mBanku pojawiła się taka dyskusja.
1
PESELa zwykle nie da się używać jako PK ponieważ może nie być unikalny.
Jest tam gdzieś info o tym w artykule?
Czy tylko domysły w komentarzach?
3
zawsze wiedziałem że zakładanie constrainów jest dla nobów, programisty nie powinno się ograniczać :D
1
WeiXiao napisał(a):
zawsze wiedziałem że zakładanie constrainów jest dla nobów, programisty nie powinno się ograniczać :D
Cytuję z głowy, więc niedokładnie:
- id? a po co to komu? dobra, Staszek, nie wygłupiaj się, dołóż timestamp do PK i będzie git.
2
Wy się nabijacie a ja naprawdę miałam takiego szefa co myślał ze kluczem może być NIP mimo że w bazie mieli też byc zagraniczni kontrahenci
4
To tylko pokazuje, na jakim poziomie mają wiedze programiści na temat baz danych. Ile razy się natłukłem do głowy młodym, że klucze obce są po to, żeby nie narobić sobie gnoju w dnaych - a oni na to ze to blokuje ich rozwiązanie, bo najpierw będą zakładać pozycje, a potem nagłówek faktury. Ostatnio mój znajomy (wiek 50+ - czyli raczej doświadczony) rozwiązał problem braku transakcji (dwaj użytkownicy aktualizowali ten sam rekord) tym ze, aktualizuje tylko wybrane kolumny, bo mu wyszło ze ci dwaj użytkownicy nie aktualizują tych samych kolumn (ciekawe co będzie jak ktoś zmieni się algorytm i zaczną jechać po tych samych kolumnach). Wszyscy uczą się haskellów, rustów, JS mało kto dba o to co w bazie. Tabelkę można wyklinać w byle narzędziu. A jeszcze lepiej Mongo użyć, bo tam można wszystko i nic nie blokuje.
1
Nie jestem specjalistą od baz danych, ale coś mi się wydaje, że JOIN wykonywany na jakimkolwiek kluczu wprowadzanym przez użytkownika, to proszenie się o kłopoty.
A teraz widzę, że @Tomek Pycia opisuje to barwniej na podstawie swojego doświadczenia.
5
Offtopując jeszcze bardziej - czy te ostatnie wpadki w bankach nie mają pośrednio związku z dyrektywą(ami) UE wymuszającymi wdrożenie Open Banking API? Czyli że każdy bank w ten czy inny sposób musi zacząć grzebać w systemach które do tej pory działały i unowocześniać je nową kadrą...
1
loza_wykletych napisał(a):
Offtopując jeszcze bardziej - czy te ostatnie wpadki w bankach nie mają pośrednio związku z dyrektywą(ami) UE wymuszającymi wdrożenie Open Banking API? Czyli że każdy bank w ten czy inny sposób musi zacząć grzebać w systemach które do tej pory działały i unowocześniać je nową kadrą...
Tak czy inaczej, nie powinny się wydarzyć. Ale zrobienie jakiegoś API nie powinno rozpieprzać całego systemu.
0
loza_wykletych napisał(a):
Czyli że każdy bank w ten czy inny sposób musi zacząć grzebać w systemach które do tej pory działały i unowocześniać je nową kadrą...
Nie dość, że muszą grzebać, to jeszcze implementują jakieś utrudnienia, żeby być "z duchem czasu" (i zgodnymi z kretyńskimi wymogami prawa). Dawniej człowiek mógł potwierdzić przelew kodem ze zdrapki, teraz jakieś smsy i aplikacje mobilne do wszystkiego. Wszystko spoko, tylko co mam zrobić, jak sms nie przychodzi, albo jestem w podróży i nie mam zasięgu, a aplikacja mobilna przestaje działać, bo jej nie włączyłem od jakiegoś czasu i po aktualizacji zgłupiała?
0
Afish napisał(a):
Nie dość, że muszą grzebać, to jeszcze implementują jakieś utrudnienia, żeby być "z duchem czasu" (i zgodnymi z kretyńskimi wymogami prawa). Dawniej człowiek mógł potwierdzić przelew kodem ze zdrapki, teraz jakieś smsy i aplikacje mobilne do wszystkiego. Wszystko spoko, tylko co mam zrobić, jak sms nie przychodzi, albo jestem w podróży i nie mam zasięgu, a aplikacja mobilna przestaje działać, bo jej nie włączyłem od jakiegoś czasu i po aktualizacji zgłupiała?
Wiesz to trochę przypomina mi historyjkę jak tworzono system bankowy w PL po transformacji. Ogólnie było tak że na początku umożliwiono istnienie prywatnych banków. I to był raj. Można było robić przelewy pomiędzy bankami gdzie potwierdzenia szły w dniach. Nie chciałbym wprowadzać w błąd ale nie wiem czy słynny oscylator nie zbudowano w oparciu o te opóźnienia. Później jak zaczęli to regulować (bo zagranica wymogła) to okazało się że niektóre główne banki (chyba chodziło o PKO) w ogóle nie mają wymaganych rezerw ani płynności :D Musiałyby upaść z dnia na dzień.
Znaleziono fundamentalne rozwiązanie: zignorowano dane, naciągnięto sprawozdania, skonsolidowano trupy. To rozwiązanie mimo całego postępu chyba działa do dziś :) Dlatego ja się nie martwię - bo wiem że nic nie posiadam.
3
Ja w ogóle nie rozumiem jak w dzisiejszych czasach przedmiotem dyskusji może być co używać jako klucze główne. Jeśli nie ma przeciw temu naprawdę ważnych i wyjątkowych z natury systemu powodów (nie urojonych), to jedynym rozsądnym kluczem głównym jest UUID. Koszta transportu sieciowego czy też samej generacji takiego identyfikatora przy dzisiejszych technologiach w praktyce nie mają znaczenia, poza jakimiś skrajnymi wyjątkami gdzie potrzeba wycisnąć ostatnie wydajnościowe soki z systemu. W każdym innym przypadku UUID jest najrozsądniejszym rozwiązaniem.
2
Mania nadużywania UUIDów to temat na oddzielną dysertację. To ma uzasadnienie tylko, gdy źródłem danych są różne systemy, w pozostałych przypadkach lepiej użyć tego, co jest rzeczywiście potrzebne - większej lub mniejszej liczby albo (w rzadkich przypadkach) unikalnej nazwy czegoś.
6
@somekind No i to jest właśnie błędny pogląd sięgający dekadę jak nie więcej wstecz. Jak już pisałem- w dzisiejszych czasach zwyczajnie nie ma sensu bawić się w używanie czegoś innego, nie tylko ze względów integracyjnych (o czym wspomniałeś) ale chociażby bezpieczeństwa czy też pisania przyszłościowych systemów (bo nie wiesz czy wybrany rodzaj klucza w przyszłości nie okaże się problematyczny). Nawet na treningu z cyberbezpiczeństwa dla developerów na którym ostatnio byłem przestrzegali przed używaniem przewidywalnych identyfikatorów, i wymieniali UUID jako znacznie lepsze rozwiązanie. Nie mówiąc już o tym że to dziś zwyczajnie działa, a koszta jak już wspomniałem praktycznie nie istnieją. Wystarczy wygenerować UUID i tyle, przestać głosić archaiczne poglądy.
1
UUIDy z tego co się orientuję są domyślnym kluczem głównym w bazach rozproszonych (partitioning, sharding, NoSQL).
int jest domyślnym rozwiązaniem dla baz jedno-instancyjnych lub z replikacją.
Ale być może jest to bardziej rozbudowana reguła.
1
@vpiotr: masz rację, ale to że int jest domyślnym kluczem bo tak było 30 lat temu i już tak zostało nie świadczy o tym że dziś jest najrozsądniejszym rozwiązaniem.
2
o, inty vs guidy, wałkowałem temat setki razy
inty mają zaletę że znacznie łatwiej się debuguje oraz analizuje dane przy ręcznym wbijaniu się w bazę
no i na tym prawie koniec xD
wady? przewidywalność, niemożność wygenerowania przed zagadaniem do bazy*, utrudnia synchronizacje danych pomiędzy bazami itd.
* Widywałem takie performance hacki, że była osobna tabela zawierająca last_id_of dla każdej większej tabeli, który był aktualizowany za pomocą triggerów, aby mieć szybki look up ;)
Nawet na treningu z cyberbezpiczeństwa dla developerów na którym ostatnio byłem przestrzegali przed używaniem przewidywalnych identyfikatorów, i wymieniali UUID jako znacznie lepsze rozwiązanie.
Mimo wszystko nie zwalnia to z weryfikowania uprawnień do zasobu.
3
Aventus napisał(a):
i to jest właśnie błędny pogląd sięgający dekadę jak nie więcej wstecz.
No tak, bo mniej więcej dekadę temu pojawiła się moda na używanie UUIDów. Nawet w tabelkach z 3 wierszami.
Jak już pisałem- w dzisiejszych czasach zwyczajnie nie ma sensu bawić się w używanie czegoś innego, nie tylko ze względów integracyjnych (o czym wspomniałeś) ale
No to taka sama zabawa, jak z używaniem różnych typów danych, a nie tylko stringa. :)
chociażby bezpieczeństwa
Security by obscurity to nie jest prawdziwe security. A PK z bezpieczeństwem nie ma wielkiego związku. Lęk przed odgadnięciem sekwencji można faktycznie załatwić UUIDami, ale to nie znaczy, że muszą one być od razu kluczami.
Abstrahując już od tego, że nie w każdym systemie trzeba się tym w ogóle przejmować.
pisania przyszłościowych systemów (bo nie wiesz czy wybrany rodzaj klucza w przyszłości nie okaże się problematyczny).
Najwięcej patologii w IT powstało w ramach "pisania przyszłościowego", wystarczy wymienić konfigurację IoC przez XML aby "móc zmienić implementację bez kompilacji" albo opakowywanie ORMów warstwami abstrakcji, w razie "potrzeby zmiany bazy".
1
No tak, bo mniej więcej dekadę temu pojawiła się moda na używanie UUIDów. Nawet w tabelkach z 3 wierszami.
Nie, bo jeszcze dekadę temu nadal myślano że tylko int powinien być PK. Zresztą z tego co widzę niewiele się zmieniło...
No to taka sama zabawa, jak z używaniem różnych typów danych, a nie tylko stringa. :)
No... tak. Ale dyskusja dotyczy czegoś innego. Nie widzę związku.
Security by obscurity to nie jest prawdziwe security. A PK z bezpieczeństwem nie ma wielkiego związku. Lęk przed odgadnięciem sekwencji można faktycznie załatwić UUIDami, ale to nie znaczy, że muszą one być od razu kluczami.
Akurat security by obscurity to dobry dodatkowy mechanizm zabezpieczający/utrudniający potencjalny atak.
Abstrahując już od tego, że nie w każdym systemie trzeba się tym w ogóle przejmować.
To prawda, ale wymieniłem to jako jeden z atutów a nie główny atut.
Najwięcej patologii w IT powstało w ramach "pisania przyszłościowego"
Tylko że jest różnica między namiętnym pisanie przyszłościowego kodu (stosowanie wzorców z których tak naprawdę nie korzystamy itp.),.a przyszłościowym projektowaniem całego systemu. W tym pierwszym przypadku jak pojawi się potrzeba to po prostu dodamy kod. W tym drugim kiedy już mamy masę danych, dodatkowo udostępnionych innym systemom to gdy nagle obudzimy się z ręką w nocniku bo źle wybraliśmy klucze (czy to PK czy też jakieś referencje) już nie będzie tak kolorowo.
No ale ja jestem dużym chłopcem i pracuję przy dużych systemach, nic nie poradzę jak są ludzie którzy piszą trochę bardziej zaawansowane CRUDy (nie to żebym uważał CRUDy za coś złego ogólnie) i nagle ich światopogląd się załamuje kiedy dowiadują się że ich przyzwyczajenia który mają sens w małej skali i starszych systemach nijak mają się do wymagań współczesnych, złożonych systemów.
3
Aventus napisał(a):
Nie, bo jeszcze dekadę temu nadal myślano że tylko int powinien być PK. Zresztą z tego co widzę niewiele się zmieniło...
Nie "powinien być", tylko w większości przypadków są są wystarczające i zwyczajnie nie ma potrzeby używania innych.
No... tak. Ale dyskusja dotyczy czegoś innego. Nie widzę związku.
Dyskusja dotyczy doboru typu danych do rozwiązania problemu. Związek jest oczywisty.
Akurat security by obscurity to dobry dodatkowy mechanizm zabezpieczający/utrudniający potencjalny atak.
To nie jest mechanizm zabezpieczający - bo nim jest autoryzacja. To nie jest też mechanizm utrudniający atak. To co najwyżej zniechęci kogoś do próby ślepego odpytywania o sekwencjęi ddosowania systemu, ale ten problem powinien rozwiązać rate limiting.
Tak naprawdę, to ukrywanie ID ma większe znaczenie dla biznesu, aby nie ujawniać wielkości sprzedaży, liczby klientów, itd.
No ale ja jestem dużym chłopcem i pracuję przy dużych systemach,
No może właśnie w tym rzecz, że czasem nie wystarczy być chłopcem, nawet dużym.
nic nie poradzę jak są ludzie którzy piszą trochę bardziej zaawansowane CRUDy (nie to żebym uważał CRUDy za coś złego ogólnie) i nagle ich światopogląd się załamuje kiedy dowiadują się że ich przyzwyczajenia który mają sens w małej skali i starszych systemach nijak mają się do wymagań współczesnych, złożonych systemów.
Skoro jednym z Twoich głównych zmartwień jest upublicznianie ID będącego liczbą, to raczej odnosi się wrażenie, że Ty żyjesz w świecie CRUDów, w których każda encja jest dostępna przez URI do jakiejś strony, a do tego autoryzacja nie działa, i faktycznie mamy problem.
W złożonych systemach 95% serwisów jest w ogóle przed światem zewnętrznym ukryta, a przy np. 2 mld transakcji rocznie nie ma potrzeby się martwić tym, że za 10 mln lat skończą się nam klucze, więc UUIDy nie rozwiązują żadnego problemu. A skoro tego nie robią, to nie ma sensu ich używać. A UUID w tabeli ze stawkami VAT czy listą państw na świecie naprawdę wygląda bardzo nieprofesjonalnie.
Częstą praktyką jest też to, że w sytuacji, gdy trzeba wystawić jakieś dane na świat zewnętrzny robi się to przez UUIDy i proxy/gateway mapujący zewnętrzny URI z UUIDem na wewnętrzny liczbowy.
1
Skoro jedno jest liczbą, drugie jest liczbą a różnica tkwi w profesjonalności to porozmawiajmy o modzie.
1
jeszcze jedna zaleta int.. jak coś się zwali w bazie trzeba znaleźć błąd w kodzie który do tego doprowadził, to kolejność ID bardzo pomaga
0
loza_wykletych napisał(a):
Skoro jedno jest liczbą, drugie jest liczbą a różnica tkwi w profesjonalności to porozmawiajmy o modzie.
Ale to strasznie nieprofesjonalne używać liczby 128 bitowej zamiast 64 bitowej i jeszcze w dodatku zapisywać ją w pokrętnej postaci szesnastkowej /s
1
Miang napisał(a):
jeszcze jedna zaleta int.. jak coś się zwali w bazie trzeba znaleźć błąd w kodzie który do tego doprowadził, to kolejność ID bardzo pomaga
Polecam UUIDy generowane na podstawie timestampa a nie losowe. Wtedy też są zawsze w kolejności rosnącej w bazie danych
3
KamilAdam napisał(a):
Polecam UUIDy generowane na podstawie timestampa a nie losowe. Wtedy też są zawsze w kolejności rosnącej w bazie danych
Pozwolę się nie zgodzić - co jeśli zegar taktujący zostanie umieszczony w obrębie silnego ośrodka masy choćby przez kilka minut? I tak rodzi się katastrofa.
2
KamilAdam napisał(a):
Ale to strasznie nieprofesjonalne używać liczby 128 bitowej zamiast 64 bitowej i jeszcze w dodatku zapisywać ją w pokrętnej postaci szesnastkowej /s
Zwłaszcza potrzebna jest ta 128 bitowa liczba gdy trzeba rozróżnić 10 wartości.
A w sumie, to czemu tylko 128 bitów, a nie 256? Albo 1024? To tylko kilka bajtów, a brzmi znacznie lepiej.