Задать вопрос
@StynuBlizz
веб-разработка

Как правильно передавать пароль?

Подскажите, правильной ли будет такая схема работы при регистрации:
  • введенные пользователем данные (пароль не шифруется, передается как есть) пересылаются по HTTPS на сервер
  • по прибытию на сервер данные сохраняются в БД (пароль предварительно перед заносом в БД хешируется)


И схема работы при входе в аккаунт:
  • так же не зашифрованные данные передаются по HTTPS
  • по прибытию на сервер они проверяются на валидность с теми которые, в БД
  • если они не валидны то пользователю отсылается сигнал о том что данные введены неверно
  • если они валидны то здесь у меня возникает второй вопрос: что делать дальше?</li>


P.S. клиентом является Android приложение
P.P.S. Не забудьте про первый вопрос "правильным ли будет такая схема?"
  • Вопрос задан
  • 1692 просмотра
7 комментариев
Подписаться 9 Оценить 7 комментариев
Решения вопроса 2
panarama360
@panarama360
В общем правильно все, если приложению необходима супер защита, то с шифрованием при отправке нету смысла заниматься.

Насчет того что делать дальше:
Мое единственное предложение это со стороны сервера генерировать какой нибудь token (ключ), при удачной авторизации, потом этот ключ передавать пользователю на устройство, этот ключ сохранять и все последующие запросы делать с использованием этого ключа. При невалидности этого токена пользователя просо выкидывать.
Ответ написан
3 комментария
3 комментария
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Очень много ошибок!

1. При регистрации - никогда не отправляется пароль в чистом виде на сервер! Он вначале хэшируется, затем шифруются все регистрационные данные с использованием открытого ключа сервера внутри приложения, подписывается этим ключом и только после этого всё отправляется на сервер. Сервер - никогда не должен знать пароля. Он должен иметь возможность лишь проверять сам факт совпадения подписанных данных авторизации! Т.е. два поля: логин и hash на основе различных данных, включая публичный ключ: логин+пасс+...+...

2. Авторизация - CRAM-MD5 (Challenge-Response), используем ту же механику что и в CRAM-MD5, только хешируем более стойким алгоритмом и.. ВНИМАНИЕ! подписываем открытым ключом. И только после этого - отсылаем серверу на проверку. В случае успеха - получаем TOKEN сессии от сервера.

3. Общение/обмен данными - формируем json, шифруем эти данные с помощью открытого ключа, подписываем (формируем hash для передаваемого серверу сообщения) на основе следующих данных: выданный сервером TOKEN, TIMESTAMP и RANDOM. Добавляем в "хвост" шифрованные TIMESTAMP (время) и RANDOM(случайная строка). Это нужно для предотвращения повторных запросов задним числом.

подробнее
Ответ написан
2 комментария
2 комментария
Пригласить эксперта
Ответы на вопрос 1
box4
@box4
может это оставить гуглу и фейсбук с вк ? этим самым повысите аудиторию, ведь многим лень создавать сотый логин и пароль.
Ответ написан
1 комментарий
1 комментарий
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы
Вакансии с Хабр Карьеры
Frontend разработчик
Idea Platform • Москва
от 60 000 до 160 000 ₽
FullStack GameDev Developer (remote)
Wind4Tune
от 60 000 ₽
Менеджер проектов (разработка / интеграция ПО)
КБМК • Москва
от 200 000 ₽
Ещё вакансии
Заказы с Хабр Фриланса
Спинтакс шаблон
26 дек. 2024, в 14:40
15000 руб./за проект
С ++ парсер тхт логов
26 дек. 2024, в 14:27
100000 руб./за проект
Создание промо-роликов с использованием ИИ и моушн-дизайна
26 дек. 2024, в 13:56
90000 руб./за проект
Ещё заказы