|
|
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
Здравствуйте, Имеется сервер с базой логинов и паролей, имеется сервер приложений, который авторизует пользователей. Пользователь вводит логин и пароль, они отправляются на сервер приложений и если совпадают с тем, что есть, то доступ предоставляется, иначе отказ. Начитался про hash-функции и их применение в хранении паролей. Допустим, пользователь при входе в систему сохраняет хэш его пароля в ини-файле. Далее этот хэш отправляется на проверку серверу, где этот хэш и привязан к логину. Не понимаю только как это помогает НЕ предоставить доступ, если например пароль или его хэш перехватили на пути к серверу приложений? В чем смысл вообще одностороннего преобразования в данном случае? Зачем нужно хэширование паролей? Заранее благодарен за любые комментарии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 15:58 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
Гость_20121129В чем смысл вообще одностороннего преобразования в данном случае? Зачем нужно хэширование паролей?как минимум для операции смены пароля, где требуется ввести старый пароль. Злоумышленник, имея на руках только хэш, не сможет этого сделать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 16:12 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
Яростный Меч, спасибо. Обоснуйте, пожалуйста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 16:15 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
Гость_20121129, Хеш у клиента не должен сохраняется, по крайней в Вашей схеме. Пользователь вводит имя и пароль, далее это всё хешируется и передаётся серверу, который сравнивает полученный хеш с хешем у себя сохранённым. 1) Пароль на сервере не хранится и не передаётся по сети 2) Если с сервера утянут БД с учётками, то пароль не светится у взломщика. плюсом ещё будет хранить "соль" для усиления хеширования. Почитайте, гуглите об этом всё расписано во многих статьях ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 16:17 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
Гость_20121129Не понимаю только как это помогает НЕ предоставить доступ, если например пароль или его хэш перехватили на пути к серверу приложений? Если существует "человек посередине" (это вид атаки) то хеш в данном случае не спасёт. Другое дело если человек выполняет некие команды и подписывает это всё хешем. То злоумышленнику тяжелее будет подделать команду, так как заново вычислить хеш надо ( а алгоритм он не знает, по крайней мере не должен знать) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 16:19 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#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:21 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
VSVLAD, прошу прощения, ошибся про противоречие, все верно Вы написали. Остальное все равно остается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 16:22 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
рубист, спасибо. Верно, конечно же используется защищенное соединение. В моем случае реализовано на базе AES. Однако вопрос остается. Зачем же это хэширование нужно? Многие хранят этот хэш в файле, как настройки, а потом входят в систему без пароля, но ведь это одно и то же, что и просто хранить пароль в файле. Разницы по сути нет. И то и другое - очень плохо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 16:25 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
VSVLAD1) Пароль на сервере не хранится и не передаётся по сетину это где как. на веб-страницах, например, при авторизации зачастую просто сабмиттится форма, и пароль уходит "как есть" Гость_20121129Яростный Меч, спасибо. Обоснуйте, пожалуйста.я думал, это очевидно. для замены пароля нужно ввести старый пароль, но его невозможно получить из хеша. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 16:26 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
Яростный Меч, то есть старый пароль отправляется в открытом виде? Если да, то это дыра, а если нет, то опять же имеем дело с ненужностью хэша. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 16:30 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
Гость_20121129рубист, спасибо. ....... Однако вопрос остается. Зачем же это хэширование нужно? Многие хранят этот хэш в файле, как настройки, а потом входят в систему без пароля, но ведь это одно и то же, что и просто хранить пароль в файле. Разницы по сути нет. И то и другое - очень плохо. Я же написал авторХеширование паролей необходимо, чтобы пароли не хранились в базе в открытом виде. В случае компрометации БД реальное значение паролей уплывет на сторону. Если уплывут хеши, то для получения реальных паролей эти хеши нужно еще взломать. Наличие у злоумышленника хеша не даст ему в руки реальный пароль. А ввод хеша как пароля ему не поможет, так как сервер тогда будет проверять хеш от хеша и войти он не сможет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 16:49 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
рубист, таким образом, получается, что использование хэш ограничивается тем, что в базе данных не хранится пароль, но при этом сам пароль должен быть отправлен в открытом виде и при этом хранится где-то в настройках пользователя он не может. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 16:54 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
Гость_20121129Яростный Меч, то есть старый пароль отправляется в открытом виде? Если да, то это дыра, а если нет, то опять же имеем дело с ненужностью хэша.проблемы передачи данных решаются в SSL(HTTPS). Тут в любом случае можно что-то перехватить, это отдельная тема. а ведь есть ещё и хранение авторизации на компе юзера, например, в куках. Вот тут однозначно лучше хэш. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 16:56 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
Яростный Меч, ок, в целом, понятно, что и зачем. Спасибо большое всем откликнувшимся! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 16:59 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
Гость_20121129рубист, таким образом, получается, что использование хэш ограничивается тем, что в базе данных не хранится пароль, но при этом сам пароль должен быть отправлен в открытом виде и при этом хранится где-то в настройках пользователя он не может. Если говорить о Web и отправки из броузера формы логина с паролем по HTTP то да, пароль будет отправлен в открытом виде. Именно по этому порядочные сайты для работы в место HTTP используют HTTPS т.е. SSL шифрованный HTTP протокол. В настройках пользователя можно тоже хронить хеш (так же как и в БД), просто проверять пароль тагда надо по данным конфиг файла. В Unix операционке хеши паролей системных пользователей так и хранятся - в текстовом файле, который естественно доступен для чтения только администратору. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 17:06 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
рубистГость_20121129, Хеширование паролей необходимо, чтобы пароли не хранились в базе в открытом виде. В случае компрометации БД реальное значение паролей уплывет на сторону. Если уплывут хеши, то для получения реальных паролей эти хеши нужно еще взломать. для укрепления защиты хеша нужно выбирать более стойкий к взлому алгоритм (SHA2 в место SHA1 или MD5) и дабовлять к паролю так называемую соль "salt" http://en.wikipedia.org/wiki/Salt_(cryptography) Если хеш пароля передается по сети (как в вашем случае), то хеш нужно передавать по защищонному каналу SSL(HTTPS) или отдельно шифровать саму отправку. Уход хеша в чужие руки, хоть он и не дает прямой возможности узнать реальный пароль, тоже плохо.Не передавайте по сети "хэш пароля" - передавайте по сети хэш от "хэш пароля" плюс "соль", полученную с сервера перед авторизацией. Даже перехваченый взломщиками такой "одноразовый хэш" никакой практической пользы не принесет и вполне безопасен при применении на открытых каналах общего пользования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 17:12 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
sphinx_mv, Соль тоже сначало надо передать, безопасно клиенту. Самый безопасный способ это с ассиметричными ключами. В контексте веба - HTTPS (SSL). В настольных приложениях - есть куча имплементов RSA под различные платформы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 17:23 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
VSVLADsphinx_mv, Соль тоже сначало надо передать, безопасно клиенту. Вас же не смущает, что при "рукопожатии" SSL использует совершенно незащищенные каналы: это ни много, ни мало, но процесс согласования сеансового ключа шифрования - и проблем с безопасностью не особо наблюдается. VSVLADСамый безопасный способ это с ассиметричными ключами. В контексте веба - HTTPS (SSL).Не для всяких систем целесообразно (и даже возможно) использовать SSL... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 18:37 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
Немного оффтоп, но довольно увлекательная статья про криптографию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 19:08 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
Гость_20121129в базе данных не хранится пароль, но при этом сам пароль должен быть отправлен в открытом виде и при этом хранится где-то в настройках пользователя он не может. В БД пароль хранится, но видоизменённый и не подлежит расшифровке. Пароль не обязательно должен быть отправлен в открытом виде. рубистЕсли говорить о Web и отправки из броузера формы логина с паролем по HTTP то да, пароль будет отправлен в открытом виде. Именно по этому порядочные сайты для работы в место HTTP используют HTTPS т.е. SSL шифрованный HTTP протокол. Данные можно хешировать до отправки запроса! А HTTPS - прожорливое. sphinx_mvДаже перехваченый взломщиками такой "одноразовый хэш" никакой практической пользы не принесет и вполне безопасен при применении на открытых каналах общего пользования. А про сессию забыли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 20:21 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
sphinx_mvVSVLADsphinx_mv, Соль тоже сначало надо передать, безопасно клиенту. Вас же не смущает, что при "рукопожатии" SSL использует совершенно незащищенные каналы: это ни много, ни мало, но процесс согласования сеансового ключа шифрования - и проблем с безопасностью не особо наблюдается. Да, но SSL использует алгоритмы с открытым ключем и по незащещенной сети передается открытый ключь, а секретный никогда и некуда не передается. Здесь возникает вопрос, а как проверить достоверность открытого ключа на принимающей стороне? А очень просто. Ключь передается не сам по себе, а в документе называемом "сертификатом", где кроме самого ключа есть данные о том как его проверить. Почитайте на эту тему о PKI (Public Key Infrostracture), цифровых сертификатах и шифрование с открытым ключем. Так что в SSL передача ключа по открытой сети безопасна, если конечно руки от куда надо :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 21:32 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
Гость_20121129Яростный Меч, то есть старый пароль отправляется в открытом виде? Если да, то это дыра, а если нет, то опять же имеем дело с ненужностью хэша. Если "да", то это -- дыра, но это не проблема БД, в которой пароли хранятся в виде хэшей, т.е. как положено, а проблема кого-то ещё. Начитался про hash-функции и их применение в хранении паролей. Допустим, пользователь при входе в систему сохраняет хэш его пароля в ини-файле. Далее этот хэш отправляется на проверку серверу, где этот хэш и привязан к логину. Не понимаю только как это помогает НЕ предоставить доступ, если например пароль или его хэш перехватили на пути к серверу приложений? Нет, не так. Пароль отправляется серверу в виде пароля. Возможно, зашифрованного например открытым ключём (это когда зашифровать ключём можно, а расшифровать-- нет). Пароль на серверной стороне шифруется и получается хэш. По хэшу нельзя получить исходный пароль (ну или достаточно сложно), но можно проверить, применив ещё раз алгоритм ширфования, что исходный пароль соответствует данному хэшу. В итоге если БД взломана и пользователь получает хэш, он не знает пароль исходный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 21:34 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
рубистsphinx_mvпропущено... Вас же не смущает, что при "рукопожатии" SSL использует совершенно незащищенные каналы: это ни много, ни мало, но процесс согласования сеансового ключа шифрования - и проблем с безопасностью не особо наблюдается. Да, но SSL использует алгоритмы с открытым ключем и по незащещенной сети передается открытый ключь, а секретный никогда и некуда не передается. Здесь возникает вопрос, а как проверить достоверность открытого ключа на принимающей стороне? А очень просто. Ключь передается не сам по себе, а в документе называемом "сертификатом", где кроме самого ключа есть данные о том как его проверить. Почитайте на эту тему о PKI (Public Key Infrostracture), цифровых сертификатах и шифрование с открытым ключем. Так что в SSL передача ключа по открытой сети безопасна, если конечно руки от куда надо :-) Извините, но не так давно - всего лишь год назад был весьма неслабый скандал, касающийся проблем с безопасностью непосредственно в протоколах SSL и иже с ним... 30 минут на взлом любого из нескольких миллионов сайтов, использующих SSL с длиной ключа до 2К символов - это, ну, ОЧЕНЬ безопасно... ага... Тут еще: меньше 2-х минут на взлом PayPal - тоже не слабО... А если еще вспомнить о шухере ( тут или тут ), связаном со взломом сертифицирующего центра, приведшем к компрометации сертификатов безопасности - жить становится еще "интереснее"... Не настолько ЭТО безопасно, как представляется: ошибки в ПО, ошибки в организационных процедурах третьих лиц (и тем более - CA) - и ни о какой безопасной передаче данных разговор можно даже не поднимать... То есть - вообще... Ну, разве что сугубо для собственного успокоения или успокоения непосредственного начальника... Отрубаем все кабеля, сбрасываем сервер в предварительно вырытый экскаватором котлован, заливаем все бетоном... Но даже это не гарантирует защиту от взлома... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2012, 00:03 |
|
||
|
Зачем нужно хэширование паролей?
|
|||
|---|---|---|---|
|
#18+
sphinx_mv Извините, но не так давно - всего лишь год назад был весьма неслабый скандал, касающийся проблем с безопасностью непосредственно в протоколах SSL и иже с ним... 30 минут на взлом любого из нескольких миллионов сайтов, использующих SSL с длиной ключа до 2К символов - это, ну, ОЧЕНЬ безопасно... ага... Тут еще: меньше 2-х минут на взлом PayPal - тоже не слабО... А если еще вспомнить о шухере ( тут или тут ), связаном со взломом сертифицирующего центра, приведшем к компрометации сертификатов безопасности - жить становится еще "интереснее"... Не настолько ЭТО безопасно, как представляется: ошибки в ПО, ошибки в организационных процедурах третьих лиц (и тем более - CA) - и ни о какой безопасной передаче данных разговор можно даже не поднимать... То есть - вообще... Ну, разве что сугубо для собственного успокоения или успокоения непосредственного начальника... Отрубаем все кабеля, сбрасываем сервер в предварительно вырытый экскаватором котлован, заливаем все бетоном... Но даже это не гарантирует защиту от взлома... Ох, не наступайте на мазоль :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2012, 02:34 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=38058354&tid=1342026]: |
0ms |
get settings: |
6ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
159ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 207ms |
| total: | 443ms |

| 0 / 0 |
