2012-03-05 3 views
1

Я создаю json webservice (C#, WCF), и мне нужно идентифицировать пользователя. Нет управления сеансом, поэтому пользователю нужно будет отправить идентификационную строку для каждой команды. Решение, которое я придумал, - это AES. Шифровать учетные данные пользователя и время, когда строка «истекает» (в настоящее время 1000 мс), а затем использовать Base64 для ее кодирования (HttpServerUtility.UrlTokenEncode) перед отправкой (через URL-адрес или иначе).Как ввести энтропию в кодированную строку Base64?

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

Зв Как я могу ввести дополнительную (обратимую) энтропию к AES закодированы Base64 строку?

+0

Почему это необходимо для обратимости? Не можете ли вы просто сгенерировать GUID, сохранить его в базе данных и другую необходимую информацию (пользователь, временную метку) и отправить ее пользователю? – svick

ответ

3

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

Это позволит пользователю пройти аутентификацию со случайной строкой без необходимости постоянно передавать свое имя пользователя и пароль. С таблицами Rainbow очень легко отменить хэшированные пароли и другие вещи.

Добавление SALT в зашифрованную строку перед шифрованием также поможет. Я бы рекомендовал добавить к концу по крайней мере 15 дополнительных случайных символов. Это приведет к тому, что грубой форсинг будет намного сложнее, если вы решите пойти по этому маршруту.

+0

Я считаю, что не очень легко отменить хэшированные пароли, даже с радужными столами, если вы правильно используете соль. – svick

+0

@svick, который зависит от силы паролей, сила пароля в оффлайновых сценариях является серьезной проблемой безопасности в целом, компьютеры слишком быстрые –

1

Способ добавления энтропии к зашифрованным данным AES/CBC заключается в использовании случайного IV и добавление к IV шифрованию IV (ровно 16 байтов, размер блока AES), а затем кодирование базы 64. Надеюсь, вы используете CBC над ЕЦБ, поскольку это может быть небезопасно.