безопасная страница входа: функция javascript md5 против SSL, если блок входа находится на главной странице

Я думаю о повышении безопасности при переносе логина и пароля со страницы входа. Я нашел в Интернете функцию javascript md5, поэтому первый способ отправить пароль - отправить хэш md5 вместо пароля с использованием метода POST. Насколько я понимаю, с этим еще много проблем, и этот метод следует улучшить. Пароли в БД не хранятся, хранится только md5 хеш (с некоторыми другими функциями тоже используются, чтобы немного усложнить). Но у меня вопрос: есть ли смысл или лучше предпочесть ssl-шифрование от хостинг-провайдера? Это стоит около 100 долларов в год (предположим, что это хорошая цена по моему вопросу) вместо того, чтобы изобретать велосипед. Минус ssl (если я не ошибаюсь): если часть входа находится на главной странице, то главная страница будет загружаться медленнее (хотя страница входа Yahoo! с https загружается довольно быстро) и любой пользователь увидит https в браузере строка (это неплохо, но хорошо ли?)

Как идея использовать (без SSL): 1) когда пользователь входит в систему, вместо его реального пароля отправляется md5 (пароль) 2) сервер получает md5 (пароль), делает его md5 (md5 (пароль) + 'kjhgkjhg' ) и сравнивается с хешем, хранящимся в БД. db хранит хэши md5(md5(пароль)+'kjhgkjhg') для всех пользователей. В результате, если md5(пароль) перехвачен, получить md5(md5(пароль)+'kjhgkjhg') не получится, так как 'kjhgkjhg' неизвестно. Это достаточно хороший способ сделать страницу входа защищенной?

Спасибо.


php security md5 login login-script
person Haradzieniec    schedule 26.11.2011    source источник
comment
Да, это имеет больше смысла. ИСПОЛЬЗУЙТЕ SSL как минимум. И не полагайтесь на Javascript в работе над тем, что получает сервер. Также не используйте md5, он считается слишком слабым для хеширования паролей.   -  person Jared Farrish    schedule 26.11.2011
comment
Вы рекомендуете удалить блокировку входа с главной страницы и использовать http для главной страницы и https для страницы входа (это другая страница с главной страницы)... Спасибо.   -  person Haradzieniec    schedule 26.11.2011
comment
Думать, что отправка хэша MD5 на сервер лучше, чем отправка простого текстового пароля, очень ошибочно. См.: stackoverflow.com/q/5724683/476   -  person deceze♦    schedule 26.11.2011
comment
На самом деле, зачеркните мой последний комментарий (я удалил). Вам НЕОБХОДИМО использовать HTTPS при доставке формы. См.: stackoverflow.com/questions /4663885/   -  person Jared Farrish    schedule 26.11.2011
comment
@Deceze: спасибо за ваш ответ в этой теме. Теперь мне ясно, функция javascript md5 или любая другая не поможет.   -  person Haradzieniec    schedule 26.11.2011
comment
@Джаред Фарриш: спасибо за ответ. SSL — это выбор! Как я могу выбрать лучший ответ, если вы только что прокомментировали мой вопрос? :)   -  person Haradzieniec    schedule 26.11.2011
comment
@Hara Ну, вы можете заставить хеширование на стороне клиента работать, если вы используете лучший алгоритм, который, по крайней мере, включает одноразовый номер (как упоминалось в комментариях к ветке, на которую я ссылался) . Лично я бы не стал заморачиваться с этим и просто использовал SSL. Я могу поместить это в ответ, если это поможет вам ... :o)   -  person deceze♦    schedule 26.11.2011

Ответы (2)


arrow_upward
1
arrow_downward

Вам нужно будет заставить браузер создать хэш MD5 (пароль + случайный()) и отправить его вместо MD5 (пароль), чтобы никто не мог использовать хэш в будущем. Затем вам нужно будет иметь открытый текст или двусторонний зашифрованный пароль на сервере, сделать то же самое на стороне сервера и сравнить результаты. Вам нужно будет сохранить случайную строку, отправленную в браузер, на сервере, чтобы эту же случайную строку нельзя было использовать снова. Это сработает, но.

  • Кто-то может захватить сеанс в середине. Просто захватите файлы cookie и используйте тот же IP-адрес, и сервер будет беззащитным.
  • Без SSL пользователь не может знать, что он / она связался с правильным сервером, и содержимое не изменилось.
  • Адрес веб-сайта пользователя и трафик по-прежнему могут быть прочитаны посредником или троянами на его/ее компьютере.
  • Обычно сохранение пароля браузера не удается.

Но да. SSL имеет тенденцию быть медленным, а срок действия этих чертовых сертификатов истекает и ломает все.

person Antti Rytsölä    schedule 26.11.2011
comment
Спасибо. Пока понял это только на 80%. 1 шаг: при посещении сайта создается уникальная случайная строка, которая находится в скрытом поле на компьютере пользователя и в БД. пользователь входит в систему. Идентификатор пользователя + md5 (пароль + случайный()) отправляет на сервер. Потом, скажете вы, ip и куки сравнивать нехорошо. Итак, у нас есть список случайных активных номеров в БД и полученный md5(пароль+случайный()). Как узнать, соответствует ли случайное в БД md5 (пароль + случайный())? Спасибо. - person Haradzieniec; 26.11.2011
comment
При посещении сервера сервер создает рандом и сохраняет его, например, сеанс. Это все до входа в систему. Это случайное значение отправляется в браузер и используется в MD5(). - person Antti Rytsölä; 26.11.2011
comment
Отправляет ли браузер md5 (случайный) и md5 (пароль) или md5 (пароль + случайный)? Если сервер получает md5(пароль+рандом), то он не может сравнить эту строку со списком рандомов... Даже если оставить пароль, а не его хеш в БД... Я все равно не понимаю :( - person Haradzieniec; 26.11.2011
comment
... или даже как переменная сеанса (да, это умнее, чем создавать новую строку в БД)... Но все равно не понимаю... Не могли бы вы объяснить мне, что часть md5 (пароль + случайный), как еще раз сравнить его со случайной переменной сеанса? - person Haradzieniec; 26.11.2011
comment
Теперь я понимаю.... Спасибо за информацию. Теперь я даже придумал, как использовать этот метод и хранить только хеш паролей в бд. Спасибо!!!!!!!!!!!1 - person Haradzieniec; 26.11.2011

arrow_upward
1
arrow_downward

Используйте SSL. Об этом действительно можно сказать очень мало. Если вы попытаетесь заново изобрести безопасную аутентификацию, вы ошибетесь.

Две причины, по которым вы предложили не использовать SSL, - это стоимость и скорость.

Стоимость: нет никакой разницы между безопасностью обычного SSL-сертификата и EV SSL-сертификата. EV означает (E) расширенную (V) проверку и означает, что центр сертификации тратит немного больше времени на проверку того, что вы являетесь тем, за кого себя выдаете. Если стоимость является проблемой, приобретите более дешевые SSL-сертификаты.

Скорость: замедление, вызванное согласованием SSL, в наши дни довольно незначительно. Я только что провел быстрый тест, выполняя запросы HEAD к yahoo.com, и я получил в среднем 0,2 секунды для 1000 соединений SSL и 0,1 секунды для 1000 соединений без SSL. Если запросы ваших страниц занимают 0,2 секунды, то задержка SSL может иметь значение для вас, но если они занимают целую секунду, то причина замедления заключается в чем-то другом.

Если вы ищете, как хранить и передавать пароли на http://security.stackexchange.com, вы найдете много полезных советов по как это сделать безопасно.

person Ladadadada    schedule 26.11.2011