Днес получих имейл известие. Oracle отговори на скорошен доклад по сигурността, "Оценка на алгоритъма за хаширане на пароли в Oracle". Авторите на тази статия, която създаде проблеми на Oracle, са Джошуа Райт от SANS и Карлос Сид. SANS от Royal Holloway College в Лондон има голямо влияние в областта на сигурността. Оракъл също трябваше да има главоболие. В статията са споменати три основни въпроса за безопасността:
Слаба парола "сол". Ако името на единия потребител е Crack, паролата е password, а другият е Crac, а паролата е kpassword, можете да разберете, като проверите речника на данните, че паролата всъщност е същата! Защото Oracle обработва целия низ от потребителски имена плюс пароли преди хеширане (в нашия случай потребителското име и паролата са един и същ низ), което създава нестабилност в паролите.
Паролите не са чувствителни към регистри, което не е откритие. Паролите на Oracle винаги са били безчувствителни към регистри. Въпреки това, този път това се повдига заедно с други въпроси от Oracle, което има известна тежест. Паролите за корпоративна потребителска сигурност с приложен Oracle 10g са чувствителни към регистра.
Слаб хеш алгоритъм. Тази част от информацията може да се отнася до метода за криптиране на пароли в Oracle, който представих по-рано. Поради крехкостта на алгоритъма, възможността да бъдеш разбит от офлайн речници е значително увеличена.
Двамата автори също споменаха релевантни методи за превенция в статията. Комбинирайте препоръките в Oracle Metalink. Едно просто обобщение е следното:
Контролирайте потребителските права за уеб приложения.
Ограничете достъпа до информацията на хешовете на паролата. Разрешението SELECT ANY DICTIONARY трябва да се контролира внимателно
Изберете действие за одит в DBA_USERS изглед
Криптиране на TNS предавателно съдържание
Увеличете дължината на паролата (поне 12 цифри). Применете политика за изтичане на паролата. Паролите трябва да са буквено-цифрови и смесени, за да се увеличи сложността и т.н. |
Публикувано в 24.01.2015 г. 13:44:38 ч.
|
|
|
