Обеспечение безопасности REST Service с HMAC

Question

Я прочитал это: http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

Это была действительно большая статья. Одна из проблем, я имею в моем мышлении с этим шагом (во второй части статьи):

4. (OPTIONAL) The only way to protect against “replay attacks” on your API is to include a timestamp of time kind along with the request so the server can decide if this is an “old” request, and deny it. The timestamp must be included into the HMAC generation (effectively stamping a created-on time on the hash) in addition to being checked “within acceptable bounds” on the server. 
5. [SERVER] Receive all the data from the client. 
6. [SERVER] (see OPTIONAL) Compare the current server’s timestamp to the timestamp the client sent. Make sure the difference between the two timestamps it within an acceptable time limit (5-15mins maybe) to hinder replay attacks. 

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

Является ли моя оценка правильной или есть способ включить безопасную дату? Или он должен быть зашифрован в этом сценарии?

Спасибо.

Answer 1

HMAC - это код аутентификации сообщения. Это означает, что если у вас есть сообщение M, вы можете генерировать V = HMAC (M, K) с сообщением и вашим секретным ключом K. Имейте в виду, что до тех пор, пока вы сохраняете секрет K, никто другой не сможет создать тот же V за исключением попыток угадать К. Это невозможно, если K достаточно велико.

Это также означает, что все, что вы включаете в M, не может быть изменено без изменения V, так как M и K используются в HMAC. Поэтому, если вы включили временную метку, вы должны убедиться, что она включена в расчет HMAC. Если злоумышленник попытается изменить временную метку, V, сгенерированный HMAC, будет другим -> вы можете обнаружить попытку и отказаться от запроса.

HMAC дает вам «Подлинность», что означает, что вы можете узнать, принадлежит ли это кому-то, кто знает секретный ключ. Шифрование - это нечто иное: оно дает вам «Конфиденциальность», что означает, что никто не может прочитать сообщение, не зная секретного ключа. Важно помнить, что шифрование НЕ дает вам подлинность, поскольку злоумышленник может просто изменить случайный бит в зашифрованном сообщении. Чтобы иметь как конфиденциальность, так и подлинность, вы должны использовать HMAC, а также шифрование.

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