makzimko 23 янв 2012 в 10:56

Безопасная авторизация

3 мин

14K

Веб-разработка *

Из песочницы

-2

Комментарии 43

CAJAX 23 янв 2012 в 11:01

А просто HTTPS не хватит?

bfDeveloper 23 янв 2012 в 11:12

Пожалуй, приведённый в статье способ немного безопаснее. HTTPS легко подламывается через monkey in the middle с подменой сертификата. Браузер конечно выкидывает предупреждение о странном сертификате, но это не гарантия. Здесь такое не прокатит.

atd 23 янв 2012 в 12:07

monkey in the middle это хорошо, да )))
но при mitm таким же образом можно подсунуть вместо шифрующего js тот, который просто сольёт пароль куда надо в открытом виде. и даже браузер не предупредит никого.

skvot 23 янв 2012 в 11:04

Ну и перехватят ваше время вместе с хешем… Та же соль по сути.

bfDeveloper 23 янв 2012 в 11:13

Соль, зависящая от времени. То что перехватят, можно использовать ближайшие 60 секунд.

datacompboy 23 янв 2012 в 11:49

в данноё схеме всё сильно плохо:
1) пароль, введенный пользователем вообще не используется. авторизация производится по md5(пароль). проще говоря, имея дамп базы с сервера можно просто «в лоб» использовать скачанный оттуда хеш, не заморачиваясь разворачиванием
2) никак не рассматривается вопрос «расхождения» часов
3) никак не рассматривается вопрос разных часовых поясов
в общем и целом — +1 hidden поле для защиты от «спам ботов» и передача модифицированного пароля — по сути передача того же пароля.

homm 23 янв 2012 в 13:18

> 2) никак не рассматривается вопрос «расхождения» часов
> 3) никак не рассматривается вопрос разных часовых поясов

«в логин форму придется вставить поле типа hidden в которое будет вставляться UNIX-время».

Только по описанию мне кажется, автор не додумал, что это время должно браться с сервера.

datacompboy 23 янв 2012 в 17:17

Ну и толку-то? Если сервер не проверяет это значение — то достаточно один раз перехватить передающуюся пару unixtime + pass.
Если проверяет — см выше пункты 2 и 3.

homm 23 янв 2012 в 18:59

Расхождения чего с чем должно проверяться?
— Сервер пишет в поле формы свой timestamp.
— На клиенте пользователь вводит пароль.
— От пароля находится контрольная сумма, таймстампом солится.
— Таймстамп и контрольная сумма передаются на сервер.
— Сервер солит свой пароль таймстампом.
— Если хэши совпадают, а таймстамп, который гарантированно верный, потому что посоленный, и который ни с чем расходиться не может, потому что с сервера получен, не протух на 5 минут, то перед нами пользователь.

А про часовые пояса и их влияние на таймстампы — это что-то новенькое.

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

datacompboy 23 янв 2012 в 19:17

Зачем нужен таймстамп вообще? Чем он лучше рандомного?
Если сервер дал клиенту таймстамп — зачем его отдавать обратно? Пусть сервер помнит что он передал — иначе клиент вернёт любую фигню.

Да, можно синхронизовать время клиента и сервера и солить в момент отправки — но… в чем безопасность этой схемы?

homm 23 янв 2012 в 19:45

> Зачем нужен таймстамп вообще?
Чтобы проверить, что пользователь залогинился сейчас, а не когда-то и теперь по перехваченным данным логинится злоумышленник.

> Чем он лучше рандомного?
Рандомный ключ придется где-то хранить, чтобы не позволить злоумышленнику использовать его повторно. Через год у вас будет миллионы использованных ключей.

> Если сервер дал клиенту таймстамп — зачем его отдавать обратно?
Потому что иначе его придется где-то хранить, например в сессии. А это означает:
— На каждого анонима придется стартовать сессию.
— Нельзя открыть вторую страницу сайта и залогиниться на первой.

> Пусть сервер помнит что он передал — иначе клиент вернёт любую фигню.
Любая фигня не пройдет проверку на тухлость.

> в чем безопасность этой схемы?
goto 10;

datacompboy 23 янв 2012 в 19:55

На практике, я видел как люди не могли войти из-за сбоя таймзоны — сессия жила 15 минут, а сдвиг на час делал куку невалидной сразу после входа. Пользователь видел это так: вводит логин, вводит пароль, видит результат успешного логина. Но на любое дальнейшее движение опять форму логина.

кстати — почему а вторую страницу нельзя залогиниться на первой? рандомная фигня не обязана меняться на каждый рефреш.

homm 23 янв 2012 в 20:02

Казалось бы, при чем тут авторизация, и протухание куки.

datacompboy 24 янв 2012 в 04:48

Расхождение времени на сервере и на клиенте.

homm 24 янв 2012 в 07:24

Ну и? Как расхождение времени связано с предлагаемым способом авторизации?

makzimko 23 янв 2012 в 19:04

часовой пояс не влияет на таймстамп

datacompboy 23 янв 2012 в 19:18

gmtime — всегда по гринвичу, а localtime содержит локальный.

makzimko 23 янв 2012 в 19:24

var a = new Date();

a.getTime();

таймстамп в милисекундах по гринвичу

datacompboy 23 янв 2012 в 19:49

А теперь повторю вопрос — у всех на XP обновились таймзоны, или там всё еще в россии отставание на час? ;)

makzimko 23 янв 2012 в 20:04

я же написал, это всего лишь идея, которую нужно развивать, а не готовое решение

gigimon 23 янв 2012 в 11:08

Что-то я не совсем понимаю ваш алгоритм.
На сервере предполагается хранить в базе хэш от пароля с солью, где соль это время.
Также эту соль вы будете совать в hidden поле, как будете узнавать, кому какое время отдавать?

Да и +- 60 секунд брать это как? проверять на +-60 паролей?

dreamjke 23 янв 2012 в 11:21

Плюсую, 60 хэшей на одну авторизацию, не жирно ли?

makzimko 23 янв 2012 в 11:26

зачем 60 хэшей? Хэш будет только один, так как в поле типа hidden будет передаваться время на компьютере пользователя

homm 23 янв 2012 в 13:20

Зачем вам знать время на компьютере пользователя? Посылайте сразу в поле время на сервере, им и солите.

bfDeveloper 23 янв 2012 в 11:28

Я не автор, но отвечу.
На сервере хранится несолёный пароль. Потом к нему приклеивается время и считается md5.
+-60 секунд только перебором +-60 паролей. По-моему не так жирно.
Главный минус, который я сейчас вижу, — несолёные пароли на сервере. Слишком легко ломается, если утащат базу.

skvot 23 янв 2012 в 11:32

Вроде автор в БД хранит md5($password), а потом вычисляет хешmd5(md5($password).$time)

makzimko 23 янв 2012 в 11:50

именно да

Funcraft 23 янв 2012 в 14:30

Ниже VolCh вскользь уже упомянул, но я отдельно акцентирую ваше внимание на том, что вариантов md5(пароль) конечное множество, а вот «пароль» — бесконечное (достаточно большое, чтобы считать его бесконечным).
Т.е. беря md5(md5()) вы снижаете криптостойкость хеша. То, что вы к хешу добавляете вычисляемый, т.е. по сути известный, параметр в виде времени, не делает ваш хеш более стойким.

dasm32 24 янв 2012 в 09:34

Помоему это меркнет перед тем, что хеши паролей в базе несоленые, и для успешной аутентификации достаточно знать только лишь md5($password), который столь услужливо лежит в БД :)

Автору рекомендую посмотреть в сторону Http-Digest Auth, раз уж хочется без SSL/TLS, лучше — SRP.

Funcraft 25 янв 2012 в 07:00

Согласен.
Все эти факты указывают, что автор, видимо, не до конца понимает всю схему и имеет слабое представление о шифровании и имеющихся на текущий момент средств защиты.

Pshon 23 янв 2012 в 11:10

Да и в этом случае Вы не спасетесь от кражи сессии.
Кука передается в открытом виде, в заголовке, и ничего не мешает ее «стащить»

Squier 23 янв 2012 в 11:12

Не все понятно. Из полученно кеша нужно будет выдирать md5 пароля? Что делать людям с отключенным JS (есть и такие)? Если у пользователя очень медленный интернет, он вообще не сможет авторизоваться?

datacompboy 23 янв 2012 в 11:38

А вот тут я описывал как это сделать правильно: habrahabr.ru/blogs/web_security/121021/

ohifck 23 янв 2012 в 12:15

Жаль мне тех программистов, которые будут заниматься отладкой Вашего кода.

noonesshadow 23 янв 2012 в 12:48

https, level 3 сертификат (заметнее разница при подмене), проактивная политика паролей (менять, заставлять ставить сложные), авторизация через одноразовые пароли-карты, через токены — работает
описанное — не работает
защиты от mitm нет, от кейлоггеров нет, от перехвата трафика — минимальная

demark 23 янв 2012 в 13:24

Вообще, имхо, для дипломной работы — вполне сойдёт.

В реальной жизни для скрытия пароля есть HTTPS + OpenID etc.

VolCh 23 янв 2012 в 13:56

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

Если я канал могу только слушать, то запишу хэш и таймстамп, «побрутфорсю» по таблицам 16 цифр+таймстамп (вроде как задача получения пароля из md5 хэша пароля с солью при известной соли уже решаема с большой вероятностью), потом побрутфорсю пароль. Или по словарю-алгоритм мне известен, соль в виде таймстампа тоже, неизвестен только пароль

И кстати, зачем привязываться к времени? Просто при запросе формы логина сервер отправляет рандомную соль в хидден/куке, а клиент считает хэш с ней. Хуже чем с таймстампом точно не будет. Время уж точно не секрет. А всякие +- 60 секунд заботится не надо