Как сделать безопасную авторизацию юзера в мобильном приложении?

Question

[Mybiz]

Есть некое мобильное приложение, которое стучится к API на сервере.
Если делать авторизацию юзера через веб токен, то нужно:
Генерировать токен при авторизации, отдавать его мобильному приложению, и мобильное приложение при запросе к сервису каждый раз будет передавать этот токен.

Допустим, у юзера есть некий ключ hash($key.$username), но вопрос как расшифровывать такое на сервере?
Я так понимаю, что этот токен нужно шифровать, но как тогда расшифровывать данный токен

Не могу понять как работает этот алгоритм. Пишут что надежно что ни username ни key нипазу не передается но что мешает злоумишленику украсть hash(usernam.key) и успешно им пользоватся?

Answer 1

[xmoonlight]

расшифровывать не нужно ))
нужно просто сравнить с такой же парой на сервере через код...
1. вы передаете username и hash (key - НЕ ПЕРЕДАЕТЕ!)
2. затем берете на сервере вычисляете (по пришедшему username) hash и сравниваете его с тем, что пришел.
3. равны - AUTH OK.

Comments

[Mybiz]

напишите пожалуйста подробнее, что куда передается - сторона сервера и сторона клиента (как передается и как проверяется). Заранее благодарен

[xmoonlight]

сервер хранит изначально:
1. server-username
2. key
и знает формулу создания hash = (username.key)

Клиент передает на сервер:
1. client-username
2. client-hash
и знает формулу как создать client-hash (перед его отправкой на сервер):
client-hash = (client-username.key)
(та же что и на сервере!)

Сервер получает:
1. client-username
2. client-hash

Сервер обрабатывает:
1. Создает временно свой server-hash = (server-username.key)
2. Проверяет на основе принятых данных:
if (server-username==client-username && server-hash==client-hash) {
// AUTH OK.
} else {
// AUTH FAIL!
}
-----------------
PS: можно добавить в формулу текущую дату (timestamp) и IP-адрес клиента для сложности... НО! не забудьте включить в API функцию перезапроса авторизации в ПРОЗРАЧНОМ! режиме. (смена соты и т.п.)

[Mybiz]

Огромное спасибо! Будем пробовать

[Mybiz]

Как я понимаю на сервер всегда передается одинаковый юзер хеш, в чем тогда безопасность?

[Mybiz]

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

[xmoonlight]

@Mybiz про отсутствующий пароль в формуле, думал что Вы догадаетесь...

[xmoonlight]

key+user+pass+IP - минимальная связка
key+user+pass+long_random_num - рекомендуемая
key+user+pass+long_random_num+timer+IP и одноразовый hash - стойкая

[Mybiz]

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

[Mybiz]

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

[xmoonlight]

одноразовый hash: клиент прислал hash и random - заносите в БД в таблицу hash. Приходит тот же (проверяете уже по базе) повторно - сразу же игнорируете с ошибкой.

Answer 2

[Дмитрий Энтелис]

Пользователь вам отправляет свой логин/пароль.
Вы по нему генерируете случайный токен, кладете его в базу, отправляете пользователю.
Для полного счастья хорошо всю работу с api вести через https, в этом случае без серьезной подготовки никто этот токен не украдет.
Мне кажется что в 99% случаев этого вполне достаточно.

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

$hash = md5($password . "method=users&rand=23084723984623947&limit=10");
$url = 'http://api.site.ru/users?rand=23084723984623947&limit=10&'.$hash;

Даже если запрос будет скропрометирован - максимум что получится сделать это его повторить.
С учетом того что при определенных методиках генерации rand можно сказать что rand должен быть уникальным для пользователя к примеру за месяц - получаем достаточно надежную историю.
И да, это велосипед, как это называется правильно к сожалению не знаю, думаю другие подскажут :)

Answer 3

[FanKiLL]

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