Комментарии 43
А просто HTTPS не хватит?
Ну и перехватят ваше время вместе с хешем… Та же соль по сути.
Соль, зависящая от времени. То что перехватят, можно использовать ближайшие 60 секунд.
в данноё схеме всё сильно плохо:
1) пароль, введенный пользователем вообще не используется. авторизация производится по md5(пароль). проще говоря, имея дамп базы с сервера можно просто «в лоб» использовать скачанный оттуда хеш, не заморачиваясь разворачиванием
2) никак не рассматривается вопрос «расхождения» часов
3) никак не рассматривается вопрос разных часовых поясов
в общем и целом — +1 hidden поле для защиты от «спам ботов» и передача модифицированного пароля — по сути передача того же пароля.
1) пароль, введенный пользователем вообще не используется. авторизация производится по md5(пароль). проще говоря, имея дамп базы с сервера можно просто «в лоб» использовать скачанный оттуда хеш, не заморачиваясь разворачиванием
2) никак не рассматривается вопрос «расхождения» часов
3) никак не рассматривается вопрос разных часовых поясов
в общем и целом — +1 hidden поле для защиты от «спам ботов» и передача модифицированного пароля — по сути передача того же пароля.
> 2) никак не рассматривается вопрос «расхождения» часов
> 3) никак не рассматривается вопрос разных часовых поясов
«в логин форму придется вставить поле типа hidden в которое будет вставляться UNIX-время».
Только по описанию мне кажется, автор не додумал, что это время должно браться с сервера.
> 3) никак не рассматривается вопрос разных часовых поясов
«в логин форму придется вставить поле типа hidden в которое будет вставляться UNIX-время».
Только по описанию мне кажется, автор не додумал, что это время должно браться с сервера.
Ну и толку-то? Если сервер не проверяет это значение — то достаточно один раз перехватить передающуюся пару unixtime + pass.
Если проверяет — см выше пункты 2 и 3.
Если проверяет — см выше пункты 2 и 3.
Расхождения чего с чем должно проверяться?
— Сервер пишет в поле формы свой timestamp.
— На клиенте пользователь вводит пароль.
— От пароля находится контрольная сумма, таймстампом солится.
— Таймстамп и контрольная сумма передаются на сервер.
— Сервер солит свой пароль таймстампом.
— Если хэши совпадают, а таймстамп, который гарантированно верный, потому что посоленный, и который ни с чем расходиться не может, потому что с сервера получен, не протух на 5 минут, то перед нами пользователь.
А про часовые пояса и их влияние на таймстампы — это что-то новенькое.
Единственное, я бы немного усовершенствовал схему. Пусть на клиенте скрипт при загрузке страницы как можно раньше выдергивает тамстамп и начинает считать секунды. Потом, соответственно и солит и на сервер отправляет сумму. Тогда и время свежести таймстампа можно сократить секунд до 15, и пользователь может с открытой формой логина сколько угодно сидеть.
— Сервер пишет в поле формы свой timestamp.
— На клиенте пользователь вводит пароль.
— От пароля находится контрольная сумма, таймстампом солится.
— Таймстамп и контрольная сумма передаются на сервер.
— Сервер солит свой пароль таймстампом.
— Если хэши совпадают, а таймстамп, который гарантированно верный, потому что посоленный, и который ни с чем расходиться не может, потому что с сервера получен, не протух на 5 минут, то перед нами пользователь.
А про часовые пояса и их влияние на таймстампы — это что-то новенькое.
Единственное, я бы немного усовершенствовал схему. Пусть на клиенте скрипт при загрузке страницы как можно раньше выдергивает тамстамп и начинает считать секунды. Потом, соответственно и солит и на сервер отправляет сумму. Тогда и время свежести таймстампа можно сократить секунд до 15, и пользователь может с открытой формой логина сколько угодно сидеть.
Зачем нужен таймстамп вообще? Чем он лучше рандомного?
Если сервер дал клиенту таймстамп — зачем его отдавать обратно? Пусть сервер помнит что он передал — иначе клиент вернёт любую фигню.
Да, можно синхронизовать время клиента и сервера и солить в момент отправки — но… в чем безопасность этой схемы?
Если сервер дал клиенту таймстамп — зачем его отдавать обратно? Пусть сервер помнит что он передал — иначе клиент вернёт любую фигню.
Да, можно синхронизовать время клиента и сервера и солить в момент отправки — но… в чем безопасность этой схемы?
> Зачем нужен таймстамп вообще?
Чтобы проверить, что пользователь залогинился сейчас, а не когда-то и теперь по перехваченным данным логинится злоумышленник.
> Чем он лучше рандомного?
Рандомный ключ придется где-то хранить, чтобы не позволить злоумышленнику использовать его повторно. Через год у вас будет миллионы использованных ключей.
> Если сервер дал клиенту таймстамп — зачем его отдавать обратно?
Потому что иначе его придется где-то хранить, например в сессии. А это означает:
— На каждого анонима придется стартовать сессию.
— Нельзя открыть вторую страницу сайта и залогиниться на первой.
> Пусть сервер помнит что он передал — иначе клиент вернёт любую фигню.
Любая фигня не пройдет проверку на тухлость.
> в чем безопасность этой схемы?
goto 10;
Чтобы проверить, что пользователь залогинился сейчас, а не когда-то и теперь по перехваченным данным логинится злоумышленник.
> Чем он лучше рандомного?
Рандомный ключ придется где-то хранить, чтобы не позволить злоумышленнику использовать его повторно. Через год у вас будет миллионы использованных ключей.
> Если сервер дал клиенту таймстамп — зачем его отдавать обратно?
Потому что иначе его придется где-то хранить, например в сессии. А это означает:
— На каждого анонима придется стартовать сессию.
— Нельзя открыть вторую страницу сайта и залогиниться на первой.
> Пусть сервер помнит что он передал — иначе клиент вернёт любую фигню.
Любая фигня не пройдет проверку на тухлость.
> в чем безопасность этой схемы?
goto 10;
На практике, я видел как люди не могли войти из-за сбоя таймзоны — сессия жила 15 минут, а сдвиг на час делал куку невалидной сразу после входа. Пользователь видел это так: вводит логин, вводит пароль, видит результат успешного логина. Но на любое дальнейшее движение опять форму логина.
кстати — почему а вторую страницу нельзя залогиниться на первой? рандомная фигня не обязана меняться на каждый рефреш.
кстати — почему а вторую страницу нельзя залогиниться на первой? рандомная фигня не обязана меняться на каждый рефреш.
часовой пояс не влияет на таймстамп
Что-то я не совсем понимаю ваш алгоритм.
На сервере предполагается хранить в базе хэш от пароля с солью, где соль это время.
Также эту соль вы будете совать в hidden поле, как будете узнавать, кому какое время отдавать?
Да и +- 60 секунд брать это как? проверять на +-60 паролей?
На сервере предполагается хранить в базе хэш от пароля с солью, где соль это время.
Также эту соль вы будете совать в hidden поле, как будете узнавать, кому какое время отдавать?
Да и +- 60 секунд брать это как? проверять на +-60 паролей?
Плюсую, 60 хэшей на одну авторизацию, не жирно ли?
зачем 60 хэшей? Хэш будет только один, так как в поле типа hidden будет передаваться время на компьютере пользователя
Я не автор, но отвечу.
На сервере хранится несолёный пароль. Потом к нему приклеивается время и считается md5.
+-60 секунд только перебором +-60 паролей. По-моему не так жирно.
Главный минус, который я сейчас вижу, — несолёные пароли на сервере. Слишком легко ломается, если утащат базу.
На сервере хранится несолёный пароль. Потом к нему приклеивается время и считается md5.
+-60 секунд только перебором +-60 паролей. По-моему не так жирно.
Главный минус, который я сейчас вижу, — несолёные пароли на сервере. Слишком легко ломается, если утащат базу.
Вроде автор в БД хранит
md5($password), а потом вычисляет хешmd5(md5($password).$time)именно да
Ниже VolCh вскользь уже упомянул, но я отдельно акцентирую ваше внимание на том, что вариантов md5(пароль) конечное множество, а вот «пароль» — бесконечное (достаточно большое, чтобы считать его бесконечным).
Т.е. беря md5(md5()) вы снижаете криптостойкость хеша. То, что вы к хешу добавляете вычисляемый, т.е. по сути известный, параметр в виде времени, не делает ваш хеш более стойким.
Т.е. беря md5(md5()) вы снижаете криптостойкость хеша. То, что вы к хешу добавляете вычисляемый, т.е. по сути известный, параметр в виде времени, не делает ваш хеш более стойким.
Да и в этом случае Вы не спасетесь от кражи сессии.
Кука передается в открытом виде, в заголовке, и ничего не мешает ее «стащить»
Кука передается в открытом виде, в заголовке, и ничего не мешает ее «стащить»
Не все понятно. Из полученно кеша нужно будет выдирать md5 пароля? Что делать людям с отключенным JS (есть и такие)? Если у пользователя очень медленный интернет, он вообще не сможет авторизоваться?
А вот тут я описывал как это сделать правильно: habrahabr.ru/blogs/web_security/121021/
Жаль мне тех программистов, которые будут заниматься отладкой Вашего кода.
https, level 3 сертификат (заметнее разница при подмене), проактивная политика паролей (менять, заставлять ставить сложные), авторизация через одноразовые пароли-карты, через токены — работает
описанное — не работает
защиты от mitm нет, от кейлоггеров нет, от перехвата трафика — минимальная
описанное — не работает
защиты от mitm нет, от кейлоггеров нет, от перехвата трафика — минимальная
Вообще, имхо, для дипломной работы — вполне сойдёт.
В реальной жизни для скрытия пароля есть HTTPS + OpenID etc.
В реальной жизни для скрытия пароля есть HTTPS + OpenID etc.
Если я внедрился в канал, то я для начала перехвачу отправляемый хэш и таймстамп, отправлю их серверу сам, получу от сервера куку, поброжу по страницам с секретными данными, сделаю своё чёрное дело, а потом отправлю куку клиенту.
Если я канал могу только слушать, то запишу хэш и таймстамп, «побрутфорсю» по таблицам 16 цифр+таймстамп (вроде как задача получения пароля из md5 хэша пароля с солью при известной соли уже решаема с большой вероятностью), потом побрутфорсю пароль. Или по словарю-алгоритм мне известен, соль в виде таймстампа тоже, неизвестен только пароль
И кстати, зачем привязываться к времени? Просто при запросе формы логина сервер отправляет рандомную соль в хидден/куке, а клиент считает хэш с ней. Хуже чем с таймстампом точно не будет. Время уж точно не секрет. А всякие +- 60 секунд заботится не надо
Если я канал могу только слушать, то запишу хэш и таймстамп, «побрутфорсю» по таблицам 16 цифр+таймстамп (вроде как задача получения пароля из md5 хэша пароля с солью при известной соли уже решаема с большой вероятностью), потом побрутфорсю пароль. Или по словарю-алгоритм мне известен, соль в виде таймстампа тоже, неизвестен только пароль
И кстати, зачем привязываться к времени? Просто при запросе формы логина сервер отправляет рандомную соль в хидден/куке, а клиент считает хэш с ней. Хуже чем с таймстампом точно не будет. Время уж точно не секрет. А всякие +- 60 секунд заботится не надо
НЛО прилетело и опубликовало эту надпись здесь
Ваша идея похожа на протокол Kerberos. ru.wikipedia.org/wiki/Kerberos.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Безопасная авторизация