Dziś otrzymałem powiadomienie e-mail. Oracle odpowiedział na niedawny artykuł o bezpieczeństwie pt. Ocena algorytmu haszenia haseł Oracle. Autorami tego artykułu, który sprawił kłopoty Oracle, są Joshua Wright z SANS oraz Carlos Cid. SANS z Royal Holloway College w Londynie ma duży wpływ w dziedzinie bezpieczeństwa. Oracle musiała też mieć ból głowy. W artykule wspomniano o trzech głównych kwestiach bezpieczeństwa:
Słabe hasło "salt" Jeśli jeden użytkownik nazywa się Crack, hasło to hasło, a drugi to Crac, a hasło to kpassword, możesz sprawdzić słownik danych, że hasło jest w rzeczywistości takie samo! Ponieważ Oracle przetwarza cały ciąg nazw użytkownika plus hasła przed hashowaniem (w naszym przypadku nazwa użytkownika i hasło to ten sam ciąg), co powoduje niestabilność haseł.
Hasła nie są rozróżniane na podstawie wielkości liter, co nie jest odkryciem. Hasła Oracle zawsze były nierozróżniające wielkość liter. Tym razem jednak jest to poruszane razem z innymi pytaniami Oracle, które mają pewną wagę. Hasła do bezpieczeństwa użytkownika korporacyjnego z zastosowaniem Oracle 10g są rozróżniane na podstawie wielkich liter.
Słaby algorytm skrótu. Ta część informacji może odnosić się do metody szyfrowania haseł Oracle, którą wcześniej omówiłem. Ze względu na kruchość algorytmu znacznie zwiększa się możliwość złamania przez słowniki offline.
Oboje autorzy wspomnieli również o istotnych metodach profilaktyki w artykule. Połącz zalecenia z Oracle Metalink. Proste podsumowanie brzmi następująco:
Kontroluj uprawnienia użytkownika dla aplikacji webowych.
Ogranicz dostęp do informacji o hasłach haseł. Uprawnienia SELECT ANY DICTIONARY powinny być starannie kontrolowane
Wybierz akcję do audytu w DBA_USERS widoku
Szyfrowanie treści transmisji TNS
Zwiększ długość hasła (co najmniej 12 cyfr). Zastosuj politykę wygaśnięcia haseł. Hasła powinny być alfanumeryczne i mieszane, aby zwiększyć złożoność itd. |
Opublikowano 24.01.2015 13:44:38
|
|
|
