Хранение паролей [добавлено в #966]

идея изменить алгоритм на SHA

Macik	#1 2012-06-12 03:43
Team Thanked: 181 times	Обратил внимание, как пароли пользователей храняться в БД и задумался... Это видимо еще с Seditio тянется. Суть в том, что сейчас пароли пользователей хешируются напрямую (в неизменном виде) алгоритмом md5, который давно морально устарел и более того, считается уязвимым. В качестве примера взял базу паролей одного из своих сайтов - 3900 пользователей в базе. За сутки удалось расшифровать 2600 паролей (буквы/цифры длиной до 8 знаков). Это говорит о том, что в случае несанкционированного доступа к БД может быть получен и расшифрован пароль пользователя (а учитывая, что у многих он одинаковый для разных сайтов / сервисов - то последствия могут быть далеко идущими). И даже если исключить стороннее проникновение в БД, то остается шанс «утечки» паролей, например если админ сайта не чист на руку. Предложение заменить MD5 на SHA1 и обязательно добавить «соли». типа $passw_hash = sha1($user_id . sha1($user_password)); Как реализовать прозрачный апгрейд текущих систем пока идей нет. Надо помозговать. https://github.com/macik правильный хостинг — https://goo.gl/fjCa1F
This post was edited by Macik (2012-10-31 14:46, 11 years ago)

Macik

#1 2012-06-12 03:43

Обратил внимание, как пароли пользователей храняться в БД и задумался...

Это видимо еще с Seditio тянется.

Суть в том, что сейчас пароли пользователей хешируются напрямую (в неизменном виде) алгоритмом md5, который давно морально устарел и более того, считается уязвимым.

В качестве примера взял базу паролей одного из своих сайтов - 3900 пользователей в базе. За сутки удалось расшифровать 2600 паролей (буквы/цифры длиной до 8 знаков).

Это говорит о том, что в случае несанкционированного доступа к БД может быть получен и расшифрован пароль пользователя (а учитывая, что у многих он одинаковый для разных сайтов / сервисов - то последствия могут быть далеко идущими). И даже если исключить стороннее проникновение в БД, то остается шанс «утечки» паролей, например если админ сайта не чист на руку.

Предложение заменить MD5 на SHA1 и обязательно добавить «соли».
типа $passw_hash = sha1($user_id . sha1($user_password));

Как реализовать прозрачный апгрейд текущих систем пока идей нет. Надо помозговать.

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F

This post was edited by Macik (2012-10-31 14:46, 11 years ago)

esclkm	#2 2012-06-12 05:42
Team Thanked: 76 times	скорее надо реализовать кастом шифрование. В конфиг файле задаваемое... littledev.ru - мой маленький зарождающийся блог о котонти. снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты

esclkm

#2 2012-06-12 05:42

Team
Thanked: 76 times

скорее надо реализовать кастом шифрование. В конфиг файле задаваемое...

littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты

Dayver	#3 2012-06-12 06:24
Team Thanked: 180 times	Сразу видно кто хабр читает))) Pavlo Tkachenko aka Dayver

esclkm	#4 2012-06-12 07:13
Team Thanked: 76 times	Паш наверное все) littledev.ru - мой маленький зарождающийся блог о котонти. снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты

esclkm

#4 2012-06-12 07:13

Team
Thanked: 76 times

Паш наверное все)

Wadik	#5 2012-06-12 09:55
Members Thanked: 4 times	Думаю esclkm прав. Нужно в конфигурации это предусмотреть.

Moool13	#6 2012-06-13 08:11
Members Thanked: 16 times	Особого смысла не вижу, ибо тому, кто получит доступ к БД, достаточно заменить пароль на свой (напр. 0000 - 4a7d1ed414474e4033ac29ccb8653d9b). Да и ломат юзеров не нужно, вся инфа в БД есть. Настраивает только это Это говорит о том, что в случае несанкционированного доступа к БД может быть получен и расшифрован пароль пользователя (а учитывая, что у многих он одинаковый для разных сайтов / сервисов - то последствия могут быть далеко идущими). Т.ч. думаю достаточно добавить пару солей, и тогда замена не поможет. А подбор в тем более безполезен.

Moool13

#6 2012-06-13 08:11

Members
Thanked: 16 times

Особого смысла не вижу, ибо тому, кто получит доступ к БД, достаточно заменить пароль на свой (напр. 0000 - 4a7d1ed414474e4033ac29ccb8653d9b). Да и ломат юзеров не нужно, вся инфа в БД есть.

Настраивает только это

Это говорит о том, что в случае несанкционированного доступа к БД может быть получен и расшифрован пароль пользователя (а учитывая, что у многих он одинаковый для разных сайтов / сервисов - то последствия могут быть далеко идущими).

Т.ч. думаю достаточно добавить пару солей, и тогда замена не поможет. А подбор в тем более безполезен.

Macik	#7 2012-06-15 13:17
Team Thanked: 181 times	Т.к. возражений нет - повесил тикет: № 966 https://github.com/macik правильный хостинг — https://goo.gl/fjCa1F