Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
29.11.2012, 15:58
|
|||
|---|---|---|---|
|
|||
Зачем нужно хэширование паролей? |
|||
|
#18+
Здравствуйте, Имеется сервер с базой логинов и паролей, имеется сервер приложений, который авторизует пользователей. Пользователь вводит логин и пароль, они отправляются на сервер приложений и если совпадают с тем, что есть, то доступ предоставляется, иначе отказ. Начитался про hash-функции и их применение в хранении паролей. Допустим, пользователь при входе в систему сохраняет хэш его пароля в ини-файле. Далее этот хэш отправляется на проверку серверу, где этот хэш и привязан к логину. Не понимаю только как это помогает НЕ предоставить доступ, если например пароль или его хэш перехватили на пути к серверу приложений? В чем смысл вообще одностороннего преобразования в данном случае? Зачем нужно хэширование паролей? Заранее благодарен за любые комментарии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 16:12
|
|||
|---|---|---|---|
|
|||
Зачем нужно хэширование паролей? |
|||
|
#18+
Гость_20121129В чем смысл вообще одностороннего преобразования в данном случае? Зачем нужно хэширование паролей?как минимум для операции смены пароля, где требуется ввести старый пароль. Злоумышленник, имея на руках только хэш, не сможет этого сделать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 16:15
|
|||
|---|---|---|---|
|
|||
Зачем нужно хэширование паролей? |
|||
|
#18+
Яростный Меч, спасибо. Обоснуйте, пожалуйста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 16:17
|
|||
|---|---|---|---|
Зачем нужно хэширование паролей? |
|||
|
#18+
Гость_20121129, Хеш у клиента не должен сохраняется, по крайней в Вашей схеме. Пользователь вводит имя и пароль, далее это всё хешируется и передаётся серверу, который сравнивает полученный хеш с хешем у себя сохранённым. 1) Пароль на сервере не хранится и не передаётся по сети 2) Если с сервера утянут БД с учётками, то пароль не светится у взломщика. плюсом ещё будет хранить "соль" для усиления хеширования. Почитайте, гуглите об этом всё расписано во многих статьях ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 16:19
|
|||
|---|---|---|---|
Зачем нужно хэширование паролей? |
|||
|
#18+
Гость_20121129Не понимаю только как это помогает НЕ предоставить доступ, если например пароль или его хэш перехватили на пути к серверу приложений? Если существует "человек посередине" (это вид атаки) то хеш в данном случае не спасёт. Другое дело если человек выполняет некие команды и подписывает это всё хешем. То злоумышленнику тяжелее будет подделать команду, так как заново вычислить хеш надо ( а алгоритм он не знает, по крайней мере не должен знать) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 16:21
|
|||
|---|---|---|---|
Зачем нужно хэширование паролей? |
|||
|
#18+
Гость_20121129, Хеширование паролей необходимо, чтобы пароли не хранились в базе в открытом виде. В случае компрометации БД реальное значение паролей уплывет на сторону. Если уплывут хеши, то для получения реальных паролей эти хеши нужно еще взломать. для укрепления защиты хеша нужно выбирать более стойкий к взлому алгоритм (SHA2 в место SHA1 или MD5) и дабовлять к паролю так называемую соль "salt" http://en.wikipedia.org/wiki/Salt_(cryptography) Если хеш пароля передается по сети (как в вашем случае), то хеш нужно передавать по защищонному каналу SSL(HTTPS) или отдельно шифровать саму отправку. Уход хеша в чужие руки, хоть он и не дает прямой возможности узнать реальный пароль, тоже плохо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 16:21
|
|||
|---|---|---|---|
|
|||
Зачем нужно хэширование паролей? |
|||
|
#18+
VSVLAD, спасибо. Во-первых, возможно случайно вы сами себе противоречите: "который сравнивает полученный хеш с хешем у себя (!!!!) сохранённым (!!!!)" и "1) Пароль на сервере не хранится" Во-вторых, что мешает злоумышленнику, перехватить этот самый хеш, который пользователь отправляет серверу и использовать его в дальнейшем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 16:22
|
|||
|---|---|---|---|
|
|||
Зачем нужно хэширование паролей? |
|||
|
#18+
VSVLAD, прошу прощения, ошибся про противоречие, все верно Вы написали. Остальное все равно остается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 16:25
|
|||
|---|---|---|---|
|
|||
Зачем нужно хэширование паролей? |
|||
|
#18+
рубист, спасибо. Верно, конечно же используется защищенное соединение. В моем случае реализовано на базе AES. Однако вопрос остается. Зачем же это хэширование нужно? Многие хранят этот хэш в файле, как настройки, а потом входят в систему без пароля, но ведь это одно и то же, что и просто хранить пароль в файле. Разницы по сути нет. И то и другое - очень плохо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 16:26
|
|||
|---|---|---|---|
|
|||
Зачем нужно хэширование паролей? |
|||
|
#18+
VSVLAD1) Пароль на сервере не хранится и не передаётся по сетину это где как. на веб-страницах, например, при авторизации зачастую просто сабмиттится форма, и пароль уходит "как есть" Гость_20121129Яростный Меч, спасибо. Обоснуйте, пожалуйста.я думал, это очевидно. для замены пароля нужно ввести старый пароль, но его невозможно получить из хеша. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 16:30
|
|||
|---|---|---|---|
|
|||
Зачем нужно хэширование паролей? |
|||
|
#18+
Яростный Меч, то есть старый пароль отправляется в открытом виде? Если да, то это дыра, а если нет, то опять же имеем дело с ненужностью хэша. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 16:49
|
|||
|---|---|---|---|
Зачем нужно хэширование паролей? |
|||
|
#18+
Гость_20121129рубист, спасибо. ....... Однако вопрос остается. Зачем же это хэширование нужно? Многие хранят этот хэш в файле, как настройки, а потом входят в систему без пароля, но ведь это одно и то же, что и просто хранить пароль в файле. Разницы по сути нет. И то и другое - очень плохо. Я же написал авторХеширование паролей необходимо, чтобы пароли не хранились в базе в открытом виде. В случае компрометации БД реальное значение паролей уплывет на сторону. Если уплывут хеши, то для получения реальных паролей эти хеши нужно еще взломать. Наличие у злоумышленника хеша не даст ему в руки реальный пароль. А ввод хеша как пароля ему не поможет, так как сервер тогда будет проверять хеш от хеша и войти он не сможет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 16:54
|
|||
|---|---|---|---|
|
|||
Зачем нужно хэширование паролей? |
|||
|
#18+
рубист, таким образом, получается, что использование хэш ограничивается тем, что в базе данных не хранится пароль, но при этом сам пароль должен быть отправлен в открытом виде и при этом хранится где-то в настройках пользователя он не может. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 16:56
|
|||
|---|---|---|---|
|
|||
Зачем нужно хэширование паролей? |
|||
|
#18+
Гость_20121129Яростный Меч, то есть старый пароль отправляется в открытом виде? Если да, то это дыра, а если нет, то опять же имеем дело с ненужностью хэша.проблемы передачи данных решаются в SSL(HTTPS). Тут в любом случае можно что-то перехватить, это отдельная тема. а ведь есть ещё и хранение авторизации на компе юзера, например, в куках. Вот тут однозначно лучше хэш. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 16:59
|
|||
|---|---|---|---|
|
|||
Зачем нужно хэширование паролей? |
|||
|
#18+
Яростный Меч, ок, в целом, понятно, что и зачем. Спасибо большое всем откликнувшимся! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 17:06
|
|||
|---|---|---|---|
Зачем нужно хэширование паролей? |
|||
|
#18+
Гость_20121129рубист, таким образом, получается, что использование хэш ограничивается тем, что в базе данных не хранится пароль, но при этом сам пароль должен быть отправлен в открытом виде и при этом хранится где-то в настройках пользователя он не может. Если говорить о Web и отправки из броузера формы логина с паролем по HTTP то да, пароль будет отправлен в открытом виде. Именно по этому порядочные сайты для работы в место HTTP используют HTTPS т.е. SSL шифрованный HTTP протокол. В настройках пользователя можно тоже хронить хеш (так же как и в БД), просто проверять пароль тагда надо по данным конфиг файла. В Unix операционке хеши паролей системных пользователей так и хранятся - в текстовом файле, который естественно доступен для чтения только администратору. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 17:12
|
|||
|---|---|---|---|
Зачем нужно хэширование паролей? |
|||
|
#18+
рубистГость_20121129, Хеширование паролей необходимо, чтобы пароли не хранились в базе в открытом виде. В случае компрометации БД реальное значение паролей уплывет на сторону. Если уплывут хеши, то для получения реальных паролей эти хеши нужно еще взломать. для укрепления защиты хеша нужно выбирать более стойкий к взлому алгоритм (SHA2 в место SHA1 или MD5) и дабовлять к паролю так называемую соль "salt" http://en.wikipedia.org/wiki/Salt_(cryptography) Если хеш пароля передается по сети (как в вашем случае), то хеш нужно передавать по защищонному каналу SSL(HTTPS) или отдельно шифровать саму отправку. Уход хеша в чужие руки, хоть он и не дает прямой возможности узнать реальный пароль, тоже плохо.Не передавайте по сети "хэш пароля" - передавайте по сети хэш от "хэш пароля" плюс "соль", полученную с сервера перед авторизацией. Даже перехваченый взломщиками такой "одноразовый хэш" никакой практической пользы не принесет и вполне безопасен при применении на открытых каналах общего пользования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 17:23
|
|||
|---|---|---|---|
Зачем нужно хэширование паролей? |
|||
|
#18+
sphinx_mv, Соль тоже сначало надо передать, безопасно клиенту. Самый безопасный способ это с ассиметричными ключами. В контексте веба - HTTPS (SSL). В настольных приложениях - есть куча имплементов RSA под различные платформы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 18:37
|
|||
|---|---|---|---|
Зачем нужно хэширование паролей? |
|||
|
#18+
VSVLADsphinx_mv, Соль тоже сначало надо передать, безопасно клиенту. Вас же не смущает, что при "рукопожатии" SSL использует совершенно незащищенные каналы: это ни много, ни мало, но процесс согласования сеансового ключа шифрования - и проблем с безопасностью не особо наблюдается. VSVLADСамый безопасный способ это с ассиметричными ключами. В контексте веба - HTTPS (SSL).Не для всяких систем целесообразно (и даже возможно) использовать SSL... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 19:08
|
|||
|---|---|---|---|
Зачем нужно хэширование паролей? |
|||
|
#18+
Немного оффтоп, но довольно увлекательная статья про криптографию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 20:21
|
|||
|---|---|---|---|
Зачем нужно хэширование паролей? |
|||
|
#18+
Гость_20121129в базе данных не хранится пароль, но при этом сам пароль должен быть отправлен в открытом виде и при этом хранится где-то в настройках пользователя он не может. В БД пароль хранится, но видоизменённый и не подлежит расшифровке. Пароль не обязательно должен быть отправлен в открытом виде. рубистЕсли говорить о Web и отправки из броузера формы логина с паролем по HTTP то да, пароль будет отправлен в открытом виде. Именно по этому порядочные сайты для работы в место HTTP используют HTTPS т.е. SSL шифрованный HTTP протокол. Данные можно хешировать до отправки запроса! А HTTPS - прожорливое. sphinx_mvДаже перехваченый взломщиками такой "одноразовый хэш" никакой практической пользы не принесет и вполне безопасен при применении на открытых каналах общего пользования. А про сессию забыли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 21:32
|
|||
|---|---|---|---|
Зачем нужно хэширование паролей? |
|||
|
#18+
sphinx_mvVSVLADsphinx_mv, Соль тоже сначало надо передать, безопасно клиенту. Вас же не смущает, что при "рукопожатии" SSL использует совершенно незащищенные каналы: это ни много, ни мало, но процесс согласования сеансового ключа шифрования - и проблем с безопасностью не особо наблюдается. Да, но SSL использует алгоритмы с открытым ключем и по незащещенной сети передается открытый ключь, а секретный никогда и некуда не передается. Здесь возникает вопрос, а как проверить достоверность открытого ключа на принимающей стороне? А очень просто. Ключь передается не сам по себе, а в документе называемом "сертификатом", где кроме самого ключа есть данные о том как его проверить. Почитайте на эту тему о PKI (Public Key Infrostracture), цифровых сертификатах и шифрование с открытым ключем. Так что в SSL передача ключа по открытой сети безопасна, если конечно руки от куда надо :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.11.2012, 21:34
|
|||
|---|---|---|---|
Зачем нужно хэширование паролей? |
|||
|
#18+
Гость_20121129Яростный Меч, то есть старый пароль отправляется в открытом виде? Если да, то это дыра, а если нет, то опять же имеем дело с ненужностью хэша. Если "да", то это -- дыра, но это не проблема БД, в которой пароли хранятся в виде хэшей, т.е. как положено, а проблема кого-то ещё. Начитался про hash-функции и их применение в хранении паролей. Допустим, пользователь при входе в систему сохраняет хэш его пароля в ини-файле. Далее этот хэш отправляется на проверку серверу, где этот хэш и привязан к логину. Не понимаю только как это помогает НЕ предоставить доступ, если например пароль или его хэш перехватили на пути к серверу приложений? Нет, не так. Пароль отправляется серверу в виде пароля. Возможно, зашифрованного например открытым ключём (это когда зашифровать ключём можно, а расшифровать-- нет). Пароль на серверной стороне шифруется и получается хэш. По хэшу нельзя получить исходный пароль (ну или достаточно сложно), но можно проверить, применив ещё раз алгоритм ширфования, что исходный пароль соответствует данному хэшу. В итоге если БД взломана и пользователь получает хэш, он не знает пароль исходный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.11.2012, 00:03
|
|||
|---|---|---|---|
Зачем нужно хэширование паролей? |
|||
|
#18+
рубистsphinx_mvпропущено... Вас же не смущает, что при "рукопожатии" SSL использует совершенно незащищенные каналы: это ни много, ни мало, но процесс согласования сеансового ключа шифрования - и проблем с безопасностью не особо наблюдается. Да, но SSL использует алгоритмы с открытым ключем и по незащещенной сети передается открытый ключь, а секретный никогда и некуда не передается. Здесь возникает вопрос, а как проверить достоверность открытого ключа на принимающей стороне? А очень просто. Ключь передается не сам по себе, а в документе называемом "сертификатом", где кроме самого ключа есть данные о том как его проверить. Почитайте на эту тему о PKI (Public Key Infrostracture), цифровых сертификатах и шифрование с открытым ключем. Так что в SSL передача ключа по открытой сети безопасна, если конечно руки от куда надо :-) Извините, но не так давно - всего лишь год назад был весьма неслабый скандал, касающийся проблем с безопасностью непосредственно в протоколах SSL и иже с ним... 30 минут на взлом любого из нескольких миллионов сайтов, использующих SSL с длиной ключа до 2К символов - это, ну, ОЧЕНЬ безопасно... ага... Тут еще: меньше 2-х минут на взлом PayPal - тоже не слабО... А если еще вспомнить о шухере ( тут или тут ), связаном со взломом сертифицирующего центра, приведшем к компрометации сертификатов безопасности - жить становится еще "интереснее"... Не настолько ЭТО безопасно, как представляется: ошибки в ПО, ошибки в организационных процедурах третьих лиц (и тем более - CA) - и ни о какой безопасной передаче данных разговор можно даже не поднимать... То есть - вообще... Ну, разве что сугубо для собственного успокоения или успокоения непосредственного начальника... Отрубаем все кабеля, сбрасываем сервер в предварительно вырытый экскаватором котлован, заливаем все бетоном... Но даже это не гарантирует защиту от взлома... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.11.2012, 02:34
|
|||
|---|---|---|---|
Зачем нужно хэширование паролей? |
|||
|
#18+
sphinx_mv Извините, но не так давно - всего лишь год назад был весьма неслабый скандал, касающийся проблем с безопасностью непосредственно в протоколах SSL и иже с ним... 30 минут на взлом любого из нескольких миллионов сайтов, использующих SSL с длиной ключа до 2К символов - это, ну, ОЧЕНЬ безопасно... ага... Тут еще: меньше 2-х минут на взлом PayPal - тоже не слабО... А если еще вспомнить о шухере ( тут или тут ), связаном со взломом сертифицирующего центра, приведшем к компрометации сертификатов безопасности - жить становится еще "интереснее"... Не настолько ЭТО безопасно, как представляется: ошибки в ПО, ошибки в организационных процедурах третьих лиц (и тем более - CA) - и ни о какой безопасной передаче данных разговор можно даже не поднимать... То есть - вообще... Ну, разве что сугубо для собственного успокоения или успокоения непосредственного начальника... Отрубаем все кабеля, сбрасываем сервер в предварительно вырытый экскаватором котлован, заливаем все бетоном... Но даже это не гарантирует защиту от взлома... Ох, не наступайте на мазоль :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=16&mobile=1&tid=1342026]: |
0ms |
get settings: |
9ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
88ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
78ms |
get tp. blocked users: |
2ms |
| others: | 228ms |
| total: | 447ms |
| 0 / 0 |
