Коментарі для запису: Google для взлому паролів http://websecurity.com.ua/2249/ Mon, 20 Apr 2026 01:00:28 +0000 http://wordpress.org/?v=MustLive Edition від: MustLive http://websecurity.com.ua/2249/#comment-236714 Fri, 28 Nov 2008 21:58:02 +0000 http://websecurity.com.ua/2249/#comment-236714 <blockquote>Гм. Я зазвичай зберігаю їх в конфігах сайту.</blockquote> Теж варіант. Але це зручно лише для однокористувацьких систем. Сам в конфігах зберігаю аутентифікаційні дані, якщо система лише з одним акаунтом (адмінським). А коли система багатокористувацька, то зручно використовувати БД. Де і зберігаються логіни і паролі (або їх хеші, разом з salt, якщо вона використовується). В такому випадку всі дані беруться з БД через SQL Injection. А у випадку паролю або хешу (разом з salt) в конфігах, то використовуються інші дірки :-), зокрема Directory Traversal.

Гм. Я зазвичай зберігаю їх в конфігах сайту.

Теж варіант. Але це зручно лише для однокористувацьких систем. Сам в конфігах зберігаю аутентифікаційні дані, якщо система лише з одним акаунтом (адмінським).

А коли система багатокористувацька, то зручно використовувати БД. Де і зберігаються логіни і паролі (або їх хеші, разом з salt, якщо вона використовується). В такому випадку всі дані беруться з БД через SQL Injection. А у випадку паролю або хешу (разом з salt) в конфігах, то використовуються інші дірки :-) , зокрема Directory Traversal.

]]> від: trovich http://websecurity.com.ua/2249/#comment-158513 Thu, 17 Jul 2008 06:49:41 +0000 http://websecurity.com.ua/2249/#comment-158513 > Тому, при брутфорсі хеша потрібен буде також і salt. Який теж береться з БД разом з хешем (через дірки) ;-) . Гм. Я зазвичай зберігаю їх в конфігах сайту. > Тому, при брутфорсі хеша потрібен буде також і salt. Який теж береться з БД разом з хешем (через дірки) ;-) .
Гм. Я зазвичай зберігаю їх в конфігах сайту.

]]> від: MustLive http://websecurity.com.ua/2249/#comment-158327 Wed, 16 Jul 2008 21:17:21 +0000 http://websecurity.com.ua/2249/#comment-158327 Стівену реально повезло - попалися в Інтернеті сайти, де використовувався цей хеш. Таке трапляється рідко, але звісно з часом різних хешів на сайтах в Мережі (зокрема у якості адрес сторінок) буде більше. Та й пароль був слабкий, що збільшило шанс знайти його в пошуковці. Це лише такий цікавий приклад використання Гугла (поки що не дуже практичний). Для пошуку md5 хешів варто використовувати спеціальні пошуковці. Стівену реально повезло - попалися в Інтернеті сайти, де використовувався цей хеш. Таке трапляється рідко, але звісно з часом різних хешів на сайтах в Мережі (зокрема у якості адрес сторінок) буде більше. Та й пароль був слабкий, що збільшило шанс знайти його в пошуковці.

Це лише такий цікавий приклад використання Гугла (поки що не дуже практичний). Для пошуку md5 хешів варто використовувати спеціальні пошуковці.

]]> від: MustLive http://websecurity.com.ua/2249/#comment-158318 Wed, 16 Jul 2008 20:59:10 +0000 http://websecurity.com.ua/2249/#comment-158318 Так і є - додавання salt робить хешування більш надійним. Тому що для отримання хешу (при авторизації) буде використовуватися як пароль, так і salt, що зробить результуючий хеш менш "стандартним" (і тому його важче буде брутфорснути). За допомогою Гугла і різних md5 пошуковців вже такий "засолений" хеш не знайдеш :-). Тому, при брутфорсі хеша потрібен буде також і salt. Який теж береться з БД разом з хешем (через дірки) ;-). Тому в плані брутфорса там особливих проблем немає (використай отриманий salt і підбери вірний пароль під цей хеш) - часові вимоги ті ж самі, що й при звичайному хешуванні (використання salt майже не зменшує швидкодії). Головне не забути про salt - тобто при отриманні хешу (через дірки на сайті), потрібно вияснити, чи немає там ще salt (як у відомому тобі движку, так і у невідомому), бо інакше не вийде взломати хеш. Тому, як кажуть сіль за смаком 8-). Так і є - додавання salt робить хешування більш надійним. Тому що для отримання хешу (при авторизації) буде використовуватися як пароль, так і salt, що зробить результуючий хеш менш “стандартним” (і тому його важче буде брутфорснути). За допомогою Гугла і різних md5 пошуковців вже такий “засолений” хеш не знайдеш :-) .

Тому, при брутфорсі хеша потрібен буде також і salt. Який теж береться з БД разом з хешем (через дірки) ;-) . Тому в плані брутфорса там особливих проблем немає (використай отриманий salt і підбери вірний пароль під цей хеш) - часові вимоги ті ж самі, що й при звичайному хешуванні (використання salt майже не зменшує швидкодії). Головне не забути про salt - тобто при отриманні хешу (через дірки на сайті), потрібно вияснити, чи немає там ще salt (як у відомому тобі движку, так і у невідомому), бо інакше не вийде взломати хеш. Тому, як кажуть сіль за смаком 8-) .

]]> від: trovich http://websecurity.com.ua/2249/#comment-155794 Fri, 11 Jul 2008 15:24:34 +0000 http://websecurity.com.ua/2249/#comment-155794 По-моєму, все ж цьому Стівену пощастило з паролем. "Нормальні" слова у будь-якому випадку погані паролі, тут ще й таке співпадіння. По-моєму, все ж цьому Стівену пощастило з паролем. “Нормальні” слова у будь-якому випадку погані паролі, тут ще й таке співпадіння.

]]> від: trovich http://websecurity.com.ua/2249/#comment-155787 Fri, 11 Jul 2008 15:22:09 +0000 http://websecurity.com.ua/2249/#comment-155787 Як я розумію, достатньо надійним в цьому випадку було би додавання sault перед процедурою кодування паролю? Як я розумію, достатньо надійним в цьому випадку було би додавання sault перед процедурою кодування паролю?

]]>