![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 898 Pomógł: 48 Dołączył: 2.11.2005 Skąd: Poznań Ostrzeżenie: (0%) ![]() ![]() |
W jednej z aplikacji, w której przetwarza się dane osobowe etc. widziałem dość ciekawy "patent", a mianowicie zamiast standardowych numerycznych ID w tabeli stosowane są losowe ciągi 40 znaków (przypuszczalnie jakieś md5 z randa). Jeśli dobrze rozumiem intencję autora, to chodzi o to, aby w aplikacji współdzielonej dodać dodatkowe zabezpieczenie np. gdy ktoś w swoim profilu edytując rekord, podmieniłby id na inne i zapisał/odczytał czyjeś rekordy. Oczywiście nie jest to jedyne zabezpieczenia, a bardziej przypuszczam takie utrudnienie dla crackerów, aby już na wstępie mili problem w ustaleniu id rekordu, który chcieliby rozpracować.
I teraz pytanie - jak takie id alfanumeryczne ma się do wydajności mysql? Jest duża różnica między id numerycznym a alfanumerycznym np. w zapytaniach typu left join po id, czy np. w wyszukiwaniu rekordów o danych ID itp? Podobny patent chciałbym zastosować również u siebie, bo piszę aplikację, gdzie jest na prawdę spory mix uprawnień i czasami sam się gubię, komu co zablokować w danej akcji. Aplikacja wewnętrzna, więc użytkowników raczej nie podejrzewam o umiejętności hakerskie, ale wiadomo nawet małpa umie podmienić ID w adresie, a tak jak pisałem mix uprawnień jest spory, więc chętnie dodałbym taki dodatkowy element zabezpieczający. |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 898 Pomógł: 48 Dołączył: 2.11.2005 Skąd: Poznań Ostrzeżenie: (0%) ![]() ![]() |
Ale co za tym przemawia? - wg. informacji z podlinkowanej dyskusji wynika, że w przypadku zwykłych tabel nie ma większego problemu, chyba że mówimy o milionach rekordów. W jednej aplikacji faktycznie tak zrobiłem, że miałem id + w osobnym polu generowałem token, którym posługiwałem się w wielu przypadkach, ale było to średnio wygodne, bo trzeba było np. dla każdego obiektu dopisywać metodę wyszukującą po tokenie, niepotrzebnie duplikowane były dane (np. drugi indeks na token, żeby wyszukiwanie szło sprawnie) itp. Wtedy akurat case był z gatunku ukrywania danych, żeby np. w linku nie wyświetlić maila czy id użytkownika, ale już wtedy zaczęło mnie zastanawiać, czy nie lepiej było po prostu hash ustawić jako id, skoro i tak musiał być unikalny.
Indeksy typu hash mają kilka zalet - tak jak wspomniane trochę zwiększają bezpieczeństwo (np. przeciw sql injection, czy wstrzykiwaniu czegoś do formularzy), pozwalają ukryć wrażliwe dane w url, pozwalają no to co wspomniałeś, czyli np. ukryć dane statystyczne (np. numer zamówienia w sklepie internetowym jako losowy ciąg zamiast kolejny numer, aby konkurencja nie wiedziała ile zamówień realizujesz) itp itd. Wszystko to można uzyskać dodatkowymi polami w bazie, tylko czy jest sens. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 16.10.2025 - 21:10 |