Pull to refresh

Безопасный вход, Secure Login

Reading time3 min
Views1K
Здравствуйте, хабралюди.
— Окунемся в мир безопасности.

Не для кого не секрет, что в интернете гуляет полно троянов, вирусов и тд, у каждого своя цель, каждый делает свои действия. Одни крадут у вас аккаунты от соц. сетей, вторые собирают аккаунты Аськи, третьи просто ждут команды с сервера, четвертые собирают банковские данные, пятые делают еще что-то… Список можно продолжать очень долго.

Я хочу обратить внимание создателей сайтов на безопасность передачи пароля от клиента на сервер.

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

Понимаете в чем прикол?
Можно зайти на страницу статистики счетчика и посмотреть запросы на сайт…

И если передается по GET — видно как на ладони все.
Таким багом страдает до сих пор не один городской чат и некоторые гостевые…
Но это их проблемы.

Допустим разработчики приложили все усилия от перехвата данных 3м лицам.
Используют POST, SSL но тут снова есть уязвимое место.

я не зря в начале написал про вирусы.

Дело в том, что существующие трояны могут перехватывать отсылаемые формы и сохранять их в себе в файл…

Далее прочитать содержимое форм — пара пустяков, они выглядят обычно так:
[IP]
[DATЕ]
[URL]
username=root
password=ri2i098vnd
— Даже SSL не помогает… все перехватывается на стороне клиента без проблем.
Можете поставить снифер и посмотреть как обстоят дела на самом деле :-)

Есть одно решение, которое существенно испортит настроение злоумышленнику, ну а само решение довольно простое — хешировать пароль на стороне клиента. И после этого только передавать на сервер.

То есть алгоритм работы такой:
0. Когда пользователь заходит на сайт, сайт выдает ему COOKIE длинной, скажем, символов 50.
1. Пользователь вводит пароль (лучше всего через вирт. клавиатуру, чтобы нажатия клавиш не светилось )
2. Введенные символы хешируются с использованием куки.
3. Это все передается на сервер.

В таком случае от клиента уходит логин и хеш!
— Вы скажите, что это может передать и злоумышленник… Бесспорно, но есть одно НО! Когда от пользователя уходит запрос, так же уходит и присвоенная КУКИ. А трояны КУКИ не перехватывают!
То есть один и тот же пароль в итоге будет иметь разные ХЕШИ, и зная полученный ХЕШ, злоумышленник не авторизируется потому что троян КУКИ не перехватывает, а следовательно и не сможет войти. На стороне сервера считывается КУКИ и ХЕШ и на основании этих данных принимается решение.

Понимаете в чем дело?
Теперь злоумышленник получает куча гемороя в добавок.
Он надеялся увидеть пароли «как есть» а тут хеши, да и еще разные… и пойми это разные пароли или один…

Злоумышленнику придется придумывать новые способы получения пароля, но неопытных хакеров отпугнет, т.е отфильтруются школьники-дегенераты и тд…

ЭТО НЕ ПАНАЦЕЯ, но достаточно эффективный способ скрыть пароль от троянов и их хозяев, пусть и на время. По-этому уважаемые разработчики, если вы пишете сервис, в котором будут крутиться деньги, данные, какие-то важная информация — лишний способ защиты не помешает, да и к тому же он достаточно прост в реализации, но а клиентов с отключенным JS && Cookie достаточно мало…

Всем спасибо

UPD:Для тех, кто считает что тема бред и SSL спасает мир — вот данные со снифера локального — смотреть
Отсюда вывод: SSL хорош тем, что пароль не перехватят между клиентом и сервером, но на клиенте можно снять запросто и не важно куда идет на http или https

UPD2: Ребята, это НЕ ПАНАЦЕЯ. Не нужно тюкать, плеваться. ЭТО РАБОТАЕТ На других сайтах и успешно работает. Тот же OSMP.ru ТАК РАБОТАЛ до перехода на сертификат.

Не надо писать что это г.
Есть желание — есть возможностей
Нет желания — есть куча причин.
Tags:
Hubs:
+11
Comments79

Articles