Мобильное приложение: как знать, что юзер тот самый?

Question

[John Smith]

Всем привет,
Заранее сорри за сумбур :)

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

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

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

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

Сегодня смотрю в сторону Оаут 1.0 и чето мне не по себе, мне кажется я вязну в этом, есть другие вещи которые нужно закончить, может я слишком заморачиваюсь?

Еще раз не имею опыта во всем этом, гугл мой опыт.
Но имею представление. Так в общих чертах.
Приложение на ионик 2.

Как правильно сделать эту чертову проверку?
Из-за цейтнота бросаюсь на вещи нахрапом, все с рук валится.

Answer 1

[Вячеслав Золотов]

Обычная практика после аутентификации на сервере передавать клиенту токен, который отправляется на сервер с каждым запросом клиента. По этому токену и проходит проверка. Для своих приложений oauth можно не использовать, это все таки больше для сторонних.
P.S. Смотрите в сторону апи вконтакта и фейсбука

Comments

[John Smith]

т.е. настоящий пароль передавать только при первом логине, а потом на сервере генерировать этот токен и отсылать приложению?
токен не меняется?
т.е. кто-то может его перехватить? раз каждый раз отправляется - окно атаки большое( так кажетcя называется)
как сервер будет знать, что запрос пришел от приложения а не сэмулирован злоумышленником? то есть по сути, пароль мы прячем, но этот токен все равно может позволить кому то со стороны прикинуться приложением и писать в базу данных.
я вот это хочу предотвратить. сорри за вал вопросов .

[Вячеслав Золотов]

John Smith: Да, при первом логине. Лучше HTTPS пока что ничего не придумано. И погуглите про JWT токены. Там шифруются данные о пользователе, которые проверяются при запросе на сервер.

[John Smith]

ок. спасибо, посмотрю.

Answer 2

[Александр Пожарский]

Я, конечно, криптограф диванный, но, возможно :
1. устанавливать соединение по HTTPS
2. передавать пароль в POST
3. сравнивать хеш пароля и сохранённый в БД хеш
Не?

Comments

[John Smith]

почему бы сразу не отправлять хеш в таком случае? получая его в приложении?

[Александр Пожарский]

John Smith: А зачем? В любом случае - хеширование уже есть в WP, нет смысла его дублировать. Да и (в перспективе) если вдруг в WP сменят алгоритм хеширования (вроде даже уже меняли с год назад, но могу ошибаться) - не потребуется адаптация приложения.

[John Smith]

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

[John Smith]

правда в расчетах отсутствовал

[Александр Пожарский]

John Smith: А в нашем случае - нет разницы. Если мы как-то получили тело POST-запроса (читай - вскрыли сеанс обмена по https) - то хоть мы передаём хеш, хоть пароль - мы можем подделать такой же запрос и wp на принимающей стороне его схавает. Если не прав - поправь. А если прав - зачем выбирать более сложное решение?

[Александр Пожарский]

John Smith: а пойнт с хешами же - в хранении. Грубо говоря, если утекла БД с хешами, но наше приложение для авторизации получает с клиентской стороны именно пароль (а не хеш) и уже на своей стороне его преобразует и сравнит с хешем - то авторизоваться это не сильно поможет.

[Александр Пожарский]

John Smith: ну и да, безопасность в моём варианте основана на https. ЕМНИП, POST при нём будет зашифрован. Но лучше - погугли, могу ошибаться.

[John Smith]

не знаю, помню откуда все пошло - просто на стаковерфло видел, что местные гуру не советовали даже под https отправлять голый пароль, вроде безопасно, но...не совсем. и на этом моменте мой внутренний параноик вышел из запоя и начал требовать чтоб я запилил чето безопасное. параноя + отсутствие должного опыта в сфере = головная боль & оверинжиниринг.

[John Smith]

да весь сыр бор, что я почему то хотел все замутить без https

[Александр Пожарский]

John Smith: может речь шла о чём-то более продвинутом, чем простое хеширование? Всё же отправлять хеш и принимать его на серверной стороне без дополнительных преобразований - по идее ещё опаснее, чем передавать пароль и сравнивать его

[Александр Пожарский]

John Smith: Впрочем, на твоём месте я бы таки поднял вопрос на stackoverflow или ru.stackoverflow. Ну и попросил бы раскритиковать мой метод - вдруг укажут, где конкретно я ошибаюсь.

[John Smith]

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

[John Smith]

спасибо за помощь, правда не знаю кому присудить решение :)

[Leonid Fedotov]

John Smith: Нельзя в полной мере доверять HTTPS. Да, это весьма защищенная вещь, однако при подмене самого сертификата, Вас она не спасет. Для таких ситуаций, например в вебе, самый дефолтный Apache при создании сессии отправляет клиенту куки, предположим это хэш случайного числа. Он сохраняет в своем хранилище кем Вы являетесь и какой у вас хэш, и затем быстро вас распознает, т.к. клиент присылает ему хэш, который был передам ему в свою очередь от сервера. Таким образом, если злоумышленник попытается начать прослушивать трафик между сервером и клиентом, все что он узнает - это хэш сессии. Даже не хэш пароля, а уж тем более не сам пароль. Это лучшее из возможного, ведь пользователь не будет деанонимизирован (его личные лог/пасс). + ни в коем случае нельзя хранить в открытом виде пароль клиента в БД, самое то - это хэш пароля, да побольше.

[Александр Пожарский]

Leonid Fedotov: Сертификат же можно и проверить. С прочим не спорю.

Answer 3

[Leonid Fedotov]

Сохраняйте в клиента хэш логина и пароля а-ля md5($login."_".$password), затем при каждом соединении по HTTPS с явной проверкой сертификата передавайте этот хэш на сервер. Перед исполнением любых операций проверяйте в БД пользователя по хэшу (прям в бд уже кладете сохраненное значение хэша) и все, вот и вся магия. Собственно, например, если рассматривать как работает веб-авторизация, то при вводе лог/пасса, сервер отдает клиенту куки, которые в свою очередь клиент постоянно шлет серверу. Вам оно не нада, ваша логика приложения значительно проще, так используйте это :)

Comments

[Александр Пожарский]

А смысл передавать хеш, а не считать его на серверной стороне? Для сравнения :
1. храним в БД хеш. Получаем пароль, хешируем и сравниваем на серверной стороне. Если произошла утечка - ещё нужно подобрать пароли, подходящие к этим хешам. Если как-то утёк переданный пароль - можем авторизоваться сразу.
2. храним хеш. Но получаем его от клиента и сравниваем без дополнительных преобразований. Произошла утечка - авторизоваться можно сразу. Если как-то утёк переданный хеш - можем авторизоваться сразу.
3. храним пароль. Также можно авторизоваться сразу. Если как-то утёк переданный пароль - можем авторизоваться сразу.
То есть непонятно, чем вариант 2 лучше варианта 3 и (главное) в чём его плюс перед 1? Ну и опять же - теперь это хеширование в 2 местах (на стороне клиента и WP) и любые изменения в 1 потребуют вмешательства во второе.

[Leonid Fedotov]

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

Answer 4

[xmoonlight]

SKEY(парольный хэш) - храним на клиенте и на сервере.
Он генерируется однократно при регистрации (например, присылается по электронной почте) и никогда не передаётся по сети в дальнейшем.

1. Сервер передаёт свой рандом клиенту (случайная строка): SERVER_RANDOM
2. Клиент генерирует свой рандом CLIENT_RANDOM и вычисляет CLIENT_HASH: HASH(SKEY+SERVER_RANDOM+CLIENT_RANDOM).
3. Сервер получает от клиента итоговый CLIENT_HASH и CLIENT_RANDOM.
4. Затем, сервер сверяет полученный от клиента CLIENT_HASH и HASH, посчитанный самостоятельно:

CLIENT_HASH===HASH(SKEY+SERVER_RANDOM+CLIENT_RANDOM)

,
5. Если идентичны, то юзер успешно авторизован.