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

Question

[StynuBlizz]

Подскажите, правильной ли будет такая схема работы при регистрации:

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

И схема работы при входе в аккаунт:

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

P.S. клиентом является Android приложение
P.P.S. Не забудьте про первый вопрос "правильным ли будет такая схема?"

Comments

[Денис Загаевский]

Блин, хватит спамить. Если каждые 5 часов писать вопрос, лучше на него не ответят.

[15432]

Почему бы не хешировать пароль ещё на устройстве?

[StynuBlizz]

Ну во первых вопрос я задал только 2 раза,а вполне возможно что на него ответят лучше так его могут увидеть другие люди

[StynuBlizz]

а во вторых*

[StynuBlizz]

зачем?

[Денис Загаевский]

StynuBlizz: а надо только один.

[StynuBlizz]

Денис Загаевский: Ну как видишь толк от того что переспросил был

Answer 1

[Иван]

В общем правильно все, если приложению необходима супер защита, то с шифрованием при отправке нету смысла заниматься.

Насчет того что делать дальше:
Мое единственное предложение это со стороны сервера генерировать какой нибудь token (ключ), при удачной авторизации, потом этот ключ передавать пользователю на устройство, этот ключ сохранять и все последующие запросы делать с использованием этого ключа. При невалидности этого токена пользователя просо выкидывать.

Comments

[StynuBlizz]

Спасибо за ответ,теперь появилась цельная картинка как надо.А на какие-нибудь нюансы при реализации этой схемы не укажите?

[Иван]

Да нет, схема самая простая, при грамотной архитектуре все делается довольно просто.
Токен только как можно уникальнее генерировать)
А так вообще если это android приложение и есть авторизация, лучше ее делать через соц сети, так людям проще, если только это не какой то особый проект.

[riot26]

О шифровании при отправке позаботится https.

Answer 2

[xmoonlight]

Очень много ошибок!

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

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

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

подробнее

Comments

[Maksim Kochkin]

Какая лютая паранойя. В вашем рассказе не хватает одной мааааленькой детальки — процесс получения «публичного ключа», о котором говорится в первом шаге. Его, я так понимаю, нужно получать по такой же схеме, с хэшированием и шифрованием с использованием публич... Oh, wait...

[xmoonlight]

MaxxArts: процесс получения - через почту при регистрации/напоминании, ну чтобы не ловили особо)

Answer 3

[Alister O]

может это оставить гуглу и фейсбук с вк ? этим самым повысите аудиторию, ведь многим лень создавать сотый логин и пароль.

Comments

[xmoonlight]

Согласен, но только как доп. функционал. И название ему OAUTH 2.0.