Я тут потихоньку ваяю код для полноценного аггрегатора RSS, чтоб базировался на вебе, с мордой от Bootstrap. Мой древний самопал бежит строго на локальной машине, а это бардак и каменный век с точки зрения доступа. Про внешнее оформление в стиле Веб-1.0 вообще молчу.
Уже сейчас имеется подкачка RSS-лент с сайтов по списку и умное хранение обновлений в базе, постраничное отображение статей, отметка прочитанного, редактирование кое-каких деталей имеющихся лент, поддержка клавиатурных шорткатов, плюс адаптивный дизайн под десктоп и смартфон.
Помимо всяких заморочек с базой данных, жабаскриптом и пе-ха-пе, приходится кое-где и велосипеды изобретать.
В частности, задумал я накатать свой алгоритм для шифрования и передачи пароля (как нового, так и при логине).
Сразу предупреждаю: мой проект не будет хранить никаких супер-пупер секретных или интимных личных данных.
Просто мне надо разграничить доступ между пользователями, ну и предотвратить возможный вандализм с угоном аккаунта, порчей или замусориванием данных, вот это всё... Код хотелось бы сделать открытым (но не содержимое базы данных, естественно).
Итак, задача номер один: как секьюрно передать первоначальный пароль в систему, с учётом того, что хакеры могут прослушивать траффик. Идея состоит в том, что я вообще не собираюсь принимать от пользователя какой-то пароль при регистрации. Он оставляет на сайте свой запрос и получает от меня первоначальный пароль мейлом. При этом я не храню сам пароль в системе, а только его чексумму.
Вторая задача состоит в том чтобы передать пароль зарегистрированного пользователя (с учётом того, что на этот раз хакеры точно смогут прослушивать траффик). Решение выглядит так: сначала клиентская часть отправляет в систему запрос "пользователь такой-то хочет передать пароль". Система генерирует временный кусок "соли" и пересылает его клиенту обратно. После этого клиентский жабаскрипт считает чексумму пароля, на неё накладывает кусок "соли", и полученный результат возвращает в систему. Система убеждается, что это та самая сессия, накладывает свою "соль" на свою сохранённую чексумму пароля и сравнивает её с полученным от клиента кодом.
Если хакер перехватит сообщения в обоих направлениях, то всё равно повторить запрос на авторизацию он не сможет - та сессия уже стёрта, значит новая временная соль не даст тот же результат, что и у законного пользователя, ведь у него не будет из чего изготовить первую чексумму. Увы, менять пароль при этом не получится, потому что новый текст придётся передавать по тому же незащищённому каналу.
Фактически, я разрубил гордиев узел несекьюрного канала при помощи вспомогательного канала (мейл).
Насколько мой сценарий опасен с точки зрения реальной жизни? Есть какие идеи?
Уже сейчас имеется подкачка RSS-лент с сайтов по списку и умное хранение обновлений в базе, постраничное отображение статей, отметка прочитанного, редактирование кое-каких деталей имеющихся лент, поддержка клавиатурных шорткатов, плюс адаптивный дизайн под десктоп и смартфон.
Помимо всяких заморочек с базой данных, жабаскриптом и пе-ха-пе, приходится кое-где и велосипеды изобретать.
В частности, задумал я накатать свой алгоритм для шифрования и передачи пароля (как нового, так и при логине).
Сразу предупреждаю: мой проект не будет хранить никаких супер-пупер секретных или интимных личных данных.
Просто мне надо разграничить доступ между пользователями, ну и предотвратить возможный вандализм с угоном аккаунта, порчей или замусориванием данных, вот это всё... Код хотелось бы сделать открытым (но не содержимое базы данных, естественно).
Итак, задача номер один: как секьюрно передать первоначальный пароль в систему, с учётом того, что хакеры могут прослушивать траффик. Идея состоит в том, что я вообще не собираюсь принимать от пользователя какой-то пароль при регистрации. Он оставляет на сайте свой запрос и получает от меня первоначальный пароль мейлом. При этом я не храню сам пароль в системе, а только его чексумму.
Вторая задача состоит в том чтобы передать пароль зарегистрированного пользователя (с учётом того, что на этот раз хакеры точно смогут прослушивать траффик). Решение выглядит так: сначала клиентская часть отправляет в систему запрос "пользователь такой-то хочет передать пароль". Система генерирует временный кусок "соли" и пересылает его клиенту обратно. После этого клиентский жабаскрипт считает чексумму пароля, на неё накладывает кусок "соли", и полученный результат возвращает в систему. Система убеждается, что это та самая сессия, накладывает свою "соль" на свою сохранённую чексумму пароля и сравнивает её с полученным от клиента кодом.
Если хакер перехватит сообщения в обоих направлениях, то всё равно повторить запрос на авторизацию он не сможет - та сессия уже стёрта, значит новая временная соль не даст тот же результат, что и у законного пользователя, ведь у него не будет из чего изготовить первую чексумму. Увы, менять пароль при этом не получится, потому что новый текст придётся передавать по тому же незащищённому каналу.
Фактически, я разрубил гордиев узел несекьюрного канала при помощи вспомогательного канала (мейл).
Насколько мой сценарий опасен с точки зрения реальной жизни? Есть какие идеи?
Tags:
(no subject)
Date: 2022-02-13 07:58 am (UTC)Если я правильно тебя понял, сначала ты (клиент) шлешь на сервер challenge, он тебе в ответ шлет nonce, а ты ему (checksum xor nonce)? Если хацкер сидит как mitm, то он перехватывает и то и другое, значит просто checksum = (checksum xor nonce) xor nonce, и чексумма у него в кармане. Дальше он может воспроизвести в следующий раз твой протокол, а если ему скучно и делать нефига, то может и при помощи радужных таблиц восстановить по чексумме твой пароль. Если я правильно тебя понял, ты пытался упростить CHAP, избавившись от промежуточного шифрования и заменив его на xor? Не, лучше уж оставить идею алгоритма в полном объеме.
(no subject)
Date: 2022-02-13 08:51 am (UTC)1. Получаю юзернейм и пароль на стороне браузера
2. Посылаю юзернейм на сервер и в ответ получаю одноразовый ключик
3. Браузер считает MD5 пароля, конкатенирует к нему ключик и строит из этого новый MD5
4. Браузер послылает полученный MD5 на сервер
5. Сервер конкатенирует тот же ключик к своему сохранённому MD5 от оригинального пароля, строит из этой комбинации MD5 и сравнивает с полученным из браузера
Хакер не может ничего восстановить - чексум невозможно реверсить напрямую
(no subject)
Date: 2022-02-13 10:40 am (UTC)(no subject)
Date: 2022-02-13 11:29 am (UTC)Спасибо. Я как в том анекдоте "нутром чую, что литр, но доказать не могу".
А тем временем нарисовалась новая промблема: бесплатный хостер принципиально не разрешает слать мейлы из PHP (и я его прекрасно понимаю). Буду выкручиваться.
Первый вариант, это сохранять заявку в базе, чтобы админ вручную сканировал новые поступления и отправлял мейл лично. Но это как-то некомильфо. Вообще, там есть возможность запустить свой crontab, так что сканировать может и он, но это не решает проблему какого-никакого оповещения.
В крайнем случае всё-таки залезу в документацию от хостера и прикручу SMTP-плагин для отправки через gmail. Но там чёрт ногу сломит, да и плагин тот вроде бы к какому-то вордпрессу.
(no subject)
Date: 2022-02-13 03:14 pm (UTC)(no subject)
Date: 2022-02-13 04:06 pm (UTC)https://mailchimp.com/developer/transactional/docs/fundamentals
Даже описание сервиса совпадает с моими целями. Вечерком попробую пройти этот квест. Судя по тексту, надо зарегиться, получить API key, и с ним отправлять мейлы через их сайт обычными HTTP запросами. Единственное, что меня смущает, так это необходимость регить домейн для почты.
(no subject)
Date: 2022-02-24 06:38 pm (UTC)А провайдер у меня - не о чем говорить, сплошь виртуальный.
Буду смотреть в другую сторону.
(no subject)
Date: 2022-02-24 07:56 pm (UTC)Послал сам себе из PHP мейл - дошло!!!
Всё, буду прикручивать к своему сервису.
https://rapidapi.com/sendgrid/api/sendgrid/