Войти
ПрограммированиеФорумВеб

Сеансы, Аутентификация, Авторизация, Контроль доступа... RESTFul

#0
12:42, 2 мар. 2012

хотел создать эту тему еще когда думал о разделе, но что то все руки не доходили
хочется обсудить в первую очередь теоретические основы указанных в теме проблем
интересуют в первую очередь не простые случаи
и может быть кто нибудь подскажет, что можно почитать по данной проблематике или тут обсудим
понимаю тема наверное немного не касается тематики сайта, но что ж поделать )
возможно тут особо ни кто этим и не интересуется, но что ж поделать

#1
13:18, 2 мар. 2012

Мне интересно мнение других по следующей проблеме.

Защита пароля при аутентификации, регистрации и смене пароля.
Допустим пароль мы нигде не сохраняем и атаки на хранилище паролей не рассматриваем.
Из основных вариантов атаки я вижу пока следующие:
1 - атака "человек посередине"
2 - троян-кейлоггер.

С трояном может справиться антивирус. Но это уже не зона разработчика
Есть решение с экранной клавиатурой, но она должна иметь динамическую позицию, чтобы нельзя было учитывать координаты щелчков.

"Человек посередине"
Вариант первый:
использовать SSL.
Однако наблюдая за многими интернет ресурсами, вижу, что в таких операциях SSL используется не часто.
При этом надо учитывать, что надо обязательно иметь действительный сертификат, который обязательно надо проверять. Иначе защищенный канал взламывается также легко.

Вариант второй:
Без SSL.
Аутентификация:
Сервер присылает клиенту случайно сгенерированную, так называемую, "соль". "Соль" действительна в течении одной попытки аутентификации.
Клиент получает от пользователя пароль. Хеширует: hash = md5(pass);.
Потом "солит" хеш saultHash = md5(sault+hash);.
Отправляет серверу. Сервер берет хеш из БД, "солит" его той же "солью" и сравнивает. Таким образом для аутентификация каждый раз используется уникальный хеш. Если бы мы не "солили", можно было перехватить хеш пароля и использовать его для получения сессии.

С регистрацией и сменой пароля сложнее. Никакие секретные данные серверу заранее неизвестны. Посылать в открытую хеш пароля нельзя. Его перехватят и будут "солить". Остается генерация пароля на сервере и отправка его клиенту по почте. Тут возникает проблема в том, что генерировать пароль нужно "сильный", иначе их будут легко ломать и ответственность падет на разработчика. Сильный пароль тяжел для запоминания пользователя.

#2
13:38, 2 мар. 2012

dakka
лучше SSL для хотя бы передачи пароля на вряд ли что то придумаешь
SSL сертификат можно начального уровня получить и бесплатно

альтернатива OTP но тут тоже есть ньюансы
например если по SMS то это деньги наверное (не интересовался пока)
печать одноразовых поролей... надо думать как их передавать, так что тут тоже нужен SSL

#3
15:02, 2 мар. 2012

cNoNim
> альтернатива OTP но тут тоже есть ньюансы
В ОТР, с точки зрения рассматриваемой проблемы, нужен безопасный сетевой канал для передачи гаммы, а если есть безопасный канал, то пароль можно и так послать по нему.

#4
19:52, 26 мар. 2012

dakka
OTP это и есть пароль, только одно разовый, который посылается по безопасному каналу,
но OTP решает не только проблему безопасного канала, но и позволяет не запоминать пользователю пароль или что хуже не хранить его где либо

ПрограммированиеФорумВеб

Тема в архиве.