Архитектура клиент-серверного приложения для дополнительной авторизации
От: FrozenHeart  
Дата: 25.06.14 10:06
Оценка: -1
Приветствую.

Передо мной встала задача написания приложения, обеспечивающего дополнительную авторизацию для некоторой клиент-серверной системы, которая на данный момент ограничивается связкой "логин — пароль". Доступа к исходникам данной системы у меня нет. Соответственно, для серверной части должен быть написан плагин, который имеет доступ к БД пользователей самой системы, а для клиентской -- приложение с GUI, в котором пользователь сможет создавать и изменять свой security code, а также логиниться в систему. После успешного логина у клиента будет 5 минут на то, чтобы залогиниться уже через нативный клиент для данной системы с того же IP-адреса. Если не успел, то процедуру необходимо повторить заново.

Общение между моими клиентом и сервером предположительно хотелось бы сделать на сокетах в виде обмена JSON'ом. Пока придумал следующее:

action codes:

0 — login
1 — create_sec_code
2 — verify_sec_code
3 — change_sec_code


ret codes:

0 — Ok
1 — You need to create a security code
2 — You need to enter a security code
3 — Invalid login / password
4 — Invalid security code
5 — Invalid session token
6 — Invalid commands sequence


В начале работы пользователь вводит логин и пароль от своего аккаунта, в результате чего приложение отправляет следующий запрос на сервер:
{
    "action_code": 0,
    "action_desc": "login",
    "login": 1,
    "password": "qwe123"
}


, где "login" и "password" -- основные логин и пароль от аккаунта пользователя в данной системе

Если sec_code не был создан:

— От сервера приходит следующий ответ:
{
    "action_code": 0,
    "action_desc": "login",
    "ret_code": 1,
    "ret_msg": "You need to create a security code",
    "session_token": "fdhrr4tdg5yrerdfg553w4trg"
}


— В GUI появляется окно с просьбой ввода sec_code'а и, после его ввода, на сервер отправляется следующий запрос:
{
    "action_code": 1,
    "action_desc": "create_sec_code",
    "sec_code": "dgh5ythfeyrtfdgh5gf",
    "session_token": "fdhrr4tdg5yrerdfg553w4trg"
}


, где "sec_code" -- пароль для дополнительной авторизации

— От сервера приходит ответ следующего вида:
{
    "action_code": 1,
    "action_desc": "create_sec_code",
    "ret_code": 0,
    "ret_msg": "Ok"
}


Если sec_code был создан:

— От сервера приходит следующий ответ:
{
    "action_code": 0,
    "action_desc": "login",
    "ret_code": 1,
    "ret_msg": "You need to create a security code",
    "session_token": "fdhrr4tdg5yrerdfg553w4trg"
}


— В GUI появляется окно с просьбой ввода sec_code'а и, после его ввода, на сервер отправляется следующий запрос:
{
    "action_code": 2,
    "action_desc": "verify_sec_code",
    "sec_code": "dgh5ythfeyrtfdgh5gf",
    "session_token": "fdhrr4tdg5yrerdfg553w4trg"
}


— От сервера приходит ответ следующего вида:
{
    "action_code": 2,
    "action_desc": "verify_sec_code",
    "ret_code": 0,
    "ret_msg": "Ok"
}


Дальнейшее общение с сервером (например, изменение sec_code'а) происходит при помощи выданного session_token'а, время жизни которого заканчивается через 5 минут.

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

Заранее благодарю за возможные ответы.
avalon/1.0.434
Re: Архитектура клиент-серверного приложения для дополнительной авторизации
От: wildwind Россия  
Дата: 25.06.14 10:57
Оценка: +1
Здравствуйте, FrozenHeart, Вы писали:

FH>Приветствую.


FH>Передо мной встала задача написания приложения, обеспечивающего дополнительную авторизацию для некоторой клиент-серверной системы, которая на данный момент ограничивается связкой "логин — пароль". Доступа к исходникам данной системы у меня нет. Соответственно, для серверной части должен быть написан плагин, который имеет доступ к БД пользователей самой системы, а для клиентской -- приложение с GUI, в котором пользователь сможет создавать и изменять свой security code, а также логиниться в систему. После успешного логина у клиента будет 5 минут на то, чтобы залогиниться уже через нативный клиент для данной системы с того же IP-адреса. Если не успел, то процедуру необходимо повторить заново.


А какой профит ожидается от этой нашлепки? Один из двух паролей скомпрометировать еще проще, чем единственный. Тем более если его выбирает юзер, у 95% они будут одинаковыми.

Я так понимаю, необходимость в нашлепке появилась, потому что начали ломать. Так ты расскажи как именно, тогда можно ожидать толковых советов.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.