Powiedziałbym, że to trochę za duży problem, biorąc pod uwagę, co z tego masz. Myślę, że kiedy atakujący ma dostęp do bazy danych, masz znacznie większe problemy. Ukrywanie statusu administratora użytkownika będzie kosztować atakującego dodatkowy czas, ale APT (Advanced Persistent Threat) prawdopodobnie nie zostałby tym odstraszony.

Bezpieczeństwo dzięki zaciemnianiu ma w najlepszym przypadku ograniczoną skuteczność - aby określić, czy jest odpowiednie, musisz zrozumieć, jakie zagrożenia chcesz przeciwdziałać. Jeśli osoba będąca zagrożeniem może bezpośrednio odczytać Twoją bazę danych, jakie korzyści daje ukrycie określonego przechowywanego szczegółu?

Jeśli istnieje korzyść z zaciemnienia (upewnij się, że możesz to naprawdę udowodnić), zastosuj rodzaj zaciemniania, który odnosi się do tego zagrożenia (zaszyfrowane wartości, źródła danych off-line, haszowanie itp.).

Zgadzam się z Black Magic, że prawdopodobnie nie warto tego robić, ale jeśli chcesz, możesz użyć funkcji wyprowadzania klucza, aby utworzyć klucz szyfrowania na podstawie hasła i użyć go do zaszyfrowania treści w kolumnie Status.

Potencjalnie stan musiałby być przechowywany w pamięci dla wszystkich otwartych sesji użytkownika, więc mogą one nadal być narażone na atak.

Oznaczałoby to, że mają te same ograniczenia co osoba atakująca, zakładając, że nie znasz haseł użytkowników. Nie byłbyś w stanie odczytać statusu z bazy danych, a gdybyś chciał zmienić status użytkownika, musiałbyś jednocześnie zmienić jego hasło.

Wiele nowoczesnych systemów faktycznie oddziela login użytkownika (sposób uwierzytelniania) od jego „profili” (posiadanych uprawnień), zaimplementowanych jako dwa lub więcej odrębnych systemów. Twój serwer logowania może mieć tylko identyfikator GUID, zaszyfrowaną nazwę użytkownika i zaszyfrowane hasło; po pomyślnym zalogowaniu przenieś sesję na serwer aplikacji. Dopóki serwer aplikacji nie jest zagrożony, baza danych logowania jest bezużyteczna, nawet jeśli zostanie zrzucona.

Jako dodatkowy krok możesz również zaszyfrować dane użytkownika za pomocą klucza z serwera logowania (przechowywanego jako część sesji), dzięki czemu serwer aplikacji jest również bezpieczniejszy. Dwa systemy są zazwyczaj trudniejsze do pokonania niż jeden. Jeśli jednak nie chcesz konfigurować dwóch serwerów (lub klastrów), a wszystko to wydaje się zbyt dużym nakładem pracy, prawdopodobnie i tak będzie lepiej, jeśli masz obecny projekt. Sama wiedza, na które konta kierować reklamy, nie ułatwia pracy; jeśli atakujący może złamać jeden, może złamać je wszystkie przy użyciu obliczeń równoległych.

Sugestią ze strony PlasmaHH było: „dołączenie litery przed hasłem po zaszyfrowaniu (w rzeczywistości wiele liter, był to„ identyfikator grupy ”) i wypróbowanie wszystkich kombinacji przez mechanizm uwierzytelniania.”

Chociaż jest to w pewnym stopniu zabezpieczenie przez zaciemnienie i wymaga połączenia z dobrymi praktykami, takimi jak:

• silny czynnik pracy na bcrypt
• administratorzy mający silne hasło
• sposoby zapobiegania posiadaniu przez napastnika kopii bazy danych w pierwszej kolejności

Jest to dobry sposób na spowolnienie atakującego na tyle, aby hasło jest zmieniane, zanim zostanie znalezione.

Złamanie jednego nietrywialnego hasła (zakładając, że użyłeś silnego czynnika pracy) może zająć od kilku dni do kilku miesięcy, więc jest to wykonalne, ale jeśli tego nie zrobią aby wiedzieć, które konto jest warte włamania, to sprawia, że ​​muszą zhakować każde konto.

Więc jeśli nie mają szczęścia lub nie nazwaliście konta administratora „admin”, będą musieli wypróbować wiele kont, co będzie spraw, aby ich koszt wynosił co najmniej jedno zamówienie mag większa, sprawiając, że atakujący albo czeka dłużej, kupuje więcej mocy, albo poddaje się.

Podsumowując, nie jest to bezwartościowe, ponieważ jest tanim środkiem odstraszającym, który nie przeszkadza użytkownikowi.

Pamiętaj, że jeśli masz wskazówki, że ktoś jest administratorem, na przykład post od kogoś innego edytowanego przez niego (jeśli tylko administratorzy mogą to zrobić), maskowanie jego statusu w bazie danych jest bezużyteczne.

Jak wspominali inni, może to na przykład uniemożliwić utworzenie administratora użytkownika bez zmiany lub przynajmniej pytania o jego hasło.

Jeśli to możliwe, żądanie uwierzytelnienia dwuetapowego dla administratorów byłoby prawdopodobnie lepszym rozwiązaniem sposób na zabezpieczenie kont administratora.

Tak, po prostu dodaj status administratora jako część hasła.

na przykład: HereIsMe! 65371 = adminHereIsMe! 65370 = zwykłe

Następnie przy logowaniu spróbuj najpierw zwykłego następnie admin, w ten sposób:

  if (sha512 ($ password. "0") eq $ hash) {blabla user functions} else {if (sha512 ($ password. "1") eq $ hash) {funkcje administratora blabla} else {wyświetla komunikat o nieprawidłowym haśle}}  

WAŻNE: Upewnij się, że ktoś nie może edytować ostatniego znaku własnego hasła. Np. Upewnij się, że formularz rejestracyjny, formularz zapomnienia hasła i formularz zmiany hasła, zawsze dodawaj 0 lub 1 na końcu hasła w zależności od ich rzeczywistego statusu.Przechowuj status w sesji po stronie serwera, najlepiej zaszyfrowanej za pomocą klienta plik cookie sesji bocznej.

To praktycznie uniemożliwia wywnioskowanie statusu administratora bez pomyślnego złamania hasła.

Jeśli Twoja baza danych to obsługuje, skonfiguruj LDAP lub podobny serwer uwierzytelniania, a następnie poświadczenia nie będą przechowywane lokalnie.

Jest tu kilka interesujących sugestii technicznych, ale należy wspomnieć, że nawet jeśli zastosujesz je perfekcyjnie, to podejście dosłownie nic nie da w przypadku włamania z następujących powodów:

• Jeśli ktoś ma dostęp do bazy danych (chociażby wstrzyknięcie sql lub coś w tym rodzaju), jest pewne, że może robić na serwerze, co tylko zechce, z uprawnieniami dowolnego użytkownika, na którym działa Twoja usługa bazy danych, ponieważ większość systemów zarządzania bazami danych zapewniają funkcjonalność do manipulowania plikami i uruchamiania procesów na ich hoście. Oznacza to, że intruz może modyfikować strony internetowe lub przetwarzanie po stronie serwera, aby przechwytywać hasła w postaci zwykłego tekstu podczas logowania i bardzo szybko uzyskiwać niezaszyfrowane hasła dla aktywnych użytkowników. Zakładam, że Twoje konto administratora jest aktywnym użytkownikiem.
• Jeśli ktoś uzyska dostęp do skrótów Twojego hasła, prawdopodobnie nie wybierze, które z nich powinien najpierw spróbować złamać. Po prostu uruchomią narzędzie do łamania zbiorczego, aby przetworzyć je wszystkie naraz, a przy każdym przebiegu będzie sprawdzać wszystkie skróty w przetwarzanej tabeli.
• Nawet jeśli trzymasz skrót hasła administratora osobnej tabeli lub całkowicie poza bazą danych, włamanie do mniej uprzywilejowanych kont prawdopodobnie doprowadzi do eskalacji uprawnień, o ile włamanie pozostanie niewykryte, ponieważ intruz będzie mógł podszywać się pod zaufanych użytkowników, aby uzyskać dostęp do większej ilości informacji (używając moderatora, aby porozmawiać z administratorem i rozpocząć na przykład kradzież plików cookie lub inną złośliwą aktywność).
• Jeśli Twoja witryna ma jakieś funkcje społecznościowe, jest bardzo prawdopodobne, że już ujawnia inne sposoby identyfikacji użytkowników administracyjnych.

Jeśli atakujący uzyskał dostęp do bazy danych, może po prostu stworzyć własny skrót bcrypt i zastąpić ten z bazy danych. Nie ma potrzeby łamania haszu.