HOTP - История изменений

Korabelnikov: /* Требования */

2013-08-13T14:16:14Z

‎Требования

Korabelnikov: много грамматических исправлений

2013-08-13T14:15:25Z

много грамматических исправлений

Andrey в 12:32, 15 июня 2012

2012-06-15T12:32:22Z

Andrey в 13:35, 10 мая 2012

2012-05-10T13:35:24Z

Andrey в 13:15, 10 мая 2012

2012-05-10T13:15:05Z

Andrey в 09:19, 3 мая 2012

2012-05-03T09:19:35Z

Andrey в 08:53, 3 мая 2012

2012-05-03T08:53:32Z

Andrey в 08:53, 3 мая 2012

2012-05-03T08:53:13Z

Andrey в 08:49, 3 мая 2012

2012-05-03T08:49:59Z

Andrey в 08:49, 3 мая 2012

2012-05-03T08:49:27Z

@@ Строка 106: / Строка 106: @@
 #Необходимо поддерживать двухфакторную аутентификацию. В данном случае подразумевается, что первым фактором является генератор одноразовых паролей (программный или аппаратный), вторым - некоторый дополнительный секрет, который добавляется к одноразовому паролю.
-#Сервер должен быть защищен от атак методом прямого перебора (brute-force attack), то есть учетная запись пользователя (в общем случае)  должна блокироваться после оправленного числа неуспешных попыток аутентификации
+#Сервер должен быть защищен от атак методом прямого перебора (brute-force attack), то есть учетная запись пользователя (в общем случае)  должна блокироваться после определенного числа неуспешных попыток аутентификации
 #Необходимо использовать защищенный канал

@@ Строка 1: / Строка 1: @@
 ==HOTP: общее описание==
-'''HOTP''' — [[OATH]]-алгоритм генерации [[одноразовый пароль|одноразовых паролей]]  по событию (event-base) описан как RFC 4226. Как сказано выше в качестве параметра, отвечающего за динамику, используется событие, то есть сам факт генерации [[одноразовый пароль|одноразового пароля]]: каждый раз при нажатии на кнопку генерации, счетчик событий увеличивает свое значение на единицу и именно это значение динамическое значение  используется как основной параметр при расчете одноразового пароля.
+'''HOTP''' — [[OATH]]-алгоритм генерации [[одноразовый пароль|одноразовых паролей]]  по событию (event-base) описан как RFC 4226. Как сказано выше в качестве параметра, отвечающего за динамику, используется событие, то есть сам факт генерации [[одноразовый пароль|одноразового пароля]]: каждый раз при нажатии на кнопку генерации, счетчик событий увеличивает свое значение на единицу и именно это динамическое значение  используется как основной параметр при расчете одноразового пароля.
-Вторым параметром, используемым при расчете [[одноразовый пароль|одноразовых паролей]], является симметричный ключ (symmetric key), который должен быть уникальным для каждого генератора и существует требование на его минимальную длину – 128 бит. Канонически, именно это значение определяет уникальность генератора [[одноразовый пароль|одноразовых паролей]]  . При этом стоит отметить, что дополнительный уровень энтропии вносится за счет случайного значения начального состояния счётчика событии, который вместе с симметричным ключом «прошивается в генератор и записывается в конфигурационный файл (по [[OATH]]-рекомендациям это должен быть формат PSKC, описанный в RFC 6030).
+Вторым параметром, используемым при расчете [[одноразовый пароль|одноразовых паролей]], является симметричный ключ (symmetric key), который должен быть уникальным для каждого генератора и существует требование на его минимальную длину – 128 бит. Канонически, именно это значение определяет уникальность генератора [[одноразовый пароль|одноразовых паролей]]. При этом стоит отметить, что дополнительный уровень энтропии вносится за счет случайного значения начального состояния счётчика событий, который вместе с симметричным ключом «прошивается» в генератор и записывается в конфигурационный файл (по [[OATH]]-рекомендациям это должен быть формат PSKC, описанный в RFC 6030).
 == О чем думали создатели алгоритма==
-Основной задачей стандартизации алгоритма является повышение его применимости, и здесь речь идет столько с совместимости серверов аутентификации (проверки) и генераторов одноразовых паролей разных производителей, сколько заостряется внимание на простоте использования конечным пользователем и простоте реализации (дешевизне, низкой себестоимости аутентификатора — генератора одноразовых паролей). Это выражается в минимизации пользовательского интерфейса (чем меньше пользователь принимает участие в процессе, тем лучше) и возможности реализовать алгоритм, например, в SIM-карте (при этом возможность реализации на Java-карте являлось фундаментальным требованием)
+Основной задачей стандартизации алгоритма является повышение его применимости, и здесь речь идет не столько о совместимости серверов аутентификации (проверки) и генераторов одноразовых паролей разных производителей, сколько заостряется внимание на простоте использования конечным пользователем и простоте реализации (дешевизне, низкой себестоимости аутентификатора — генератора одноразовых паролей). Это выражается в минимизации пользовательского интерфейса (чем меньше пользователь принимает участие в процессе, тем лучше) и возможности реализовать алгоритм, например, в SIM-карте (при этом возможность реализации на Java-карте являлось фундаментальным требованием)
 Детализированные требования можно прочитать в  RFC 4226, здесь же приведем их короткие трактовки:
-#Алгоритмы должен быть последовательность, то есть основываться на счетчике событий
+#В основе алгоритма должна быть последовательность, то есть он должен основываться на счетчике событий
-#Должен быть экономичным с точки зрения вычислительных мощностей, энергопотребления, интерфейса взаимодействия с пользователем (минимизация количества кнопок и пр)
+#Должен быть экономичным с точки зрения вычислительных мощностей, энергопотребления, интерфейса взаимодействия с пользователем (минимизация количества кнопок и пр.)
 #Не должен требовать ввода каких-либо значений
 #Простота восприятия пользователем: значение должно быть числовым с длиной минимум 6 цифр
@@ Строка 22: / Строка 22: @@
 === Проверка===
-Генератор (клиент, в [[OATH]]-терминологии) увеличивает значение своего счетчик на единицу каждый, когда инициируется генерация одноразового пароля  (при нажатии на копку). Это инкрементированное значение и подаётся на вход HMAC-SHA1 симметричным ключом (секретным значением, как мы помним, уникальным для каждого генератора).
+Генератор (клиент, в [[OATH]]-терминологии) увеличивает значение своего счетчика на единицу каждый раз, когда инициируется генерация одноразового пароля  (при нажатии на копку). Это инкрементированное значение и подаётся на вход HMAC-SHA1 симметричным ключом (секретным значением, как мы помним, уникальным для каждого генератора).
-Это значение передается на сервер аутентификации (сервер проверки, в [[OATH]]-терминологии) и сравнивается со значение рассчитанным сервером.  Если значения совпали, то сервер увеличивает значение счетчика данного генератора на единицу.
+Это значение передается на сервер аутентификации (сервер проверки, в [[OATH]]-терминологии) и сравнивается со значением рассчитанным сервером.  Если значения совпали, то сервер увеличивает значение счетчика данного генератора на единицу.
 Если значения, полученные и рассчитанные сервером не совпали, сервер инициирует процесс ресинхронизации (в пределах допустимого окна рассинхронизации — параметр s).
 Если процесс ресинхронизации не удался, сервер инициирует запрос другого значения одноразового пароля.
-Ситуация повторяется до тех пор, пока не будет достигнуто максимальное число попыток аутентификации (что должно влечь блокировку учётной учетной записи пользователя)
+Ситуация повторяется до тех пор, пока не будет достигнуто максимальное число попыток аутентификации (что должно влечь блокировку учётной записи пользователя)
 ===Рассинхронизация счетчика===
-[[OATH]]-HOTP — синхронный алгоритм, работающий по счетчику событий, что означает необходимости синхронности значений счетчика событий, используемый генератором (клиентом) и серверов в процессе расчета и проверки одноразового пароля.
+[[OATH]]-HOTP — синхронный алгоритм, работающий по счетчику событий, что означает необходимость синхронности значений счетчика событий, используемого генератором (клиентом) и сервером в процессе расчета и проверки одноразового пароля.
 Как сказано выше инкремент счетчика генератора выполняется каждый раз, когда выполняется генерация одноразового пароля. В то же время инкремент счетчика на сервере выполняется только в случае успешной аутентификации. Исходя из этого можно выделить несколько наиболее вероятных причин ресинхронизации:
 #Аутентификация не пройдена. Генератор инкрементировал свой счётчик, а сервер нет.
@@ Строка 44: / Строка 44: @@
 #ограничить вероятность подбора одноразового значения (см ниже расчет вероятности)
 # предотвратить бесконечный расчет в рамках одной проверки и как следствие отказ в обслуживании
@@ Строка 69: / Строка 64: @@
 С — текущее состояние счетчика
-T — количество неверных аутентификаций, прясле которых сервер заблокирует учетную запись пользователя
+T — количество неверных аутентификаций, после которых сервер заблокирует учетную запись пользователя
-s — параметр рассинхронизации, определяет максимальное расхождение между счетчиком сервера и генератора (клиента в [[OATH]]-терминологии) при котором одноразовый пароль будет принят.
+s — параметр рассинхронизации, определяет максимальное расхождение между счетчиком сервера и генератора (клиента в [[OATH]]-терминологии), при котором одноразовый пароль будет принят.
 Digit — количество цифр в значении одноразового пароля
@@ Строка 110: / Строка 105: @@
 ===Требования===
-#Необходимо поддерживать двухфакторную аутентификацию. В данном случае подразумевается, что первым фактором является генератор одноразовых паролей (программный или аппаратный), вторым некоторый дополнительный секрет, который добавляется к одноразовому паролю.
+#Необходимо поддерживать двухфакторную аутентификацию. В данном случае подразумевается, что первым фактором является генератор одноразовых паролей (программный или аппаратный), вторым - некоторый дополнительный секрет, который добавляется к одноразовому паролю.
-#сервер должен быть защищен от атак методом прямого перебора (brute-force attack), то есть учетная запись пользователя (в общем случае)  должна блокироваться после оправленного числе неуспешных попыток аутентификации
+#Сервер должен быть защищен от атак методом прямого перебора (brute-force attack), то есть учетная запись пользователя (в общем случае)  должна блокироваться после оправленного числа неуспешных попыток аутентификации
 #Необходимо использовать защищенный канал

@@ Строка 1: / Строка 1: @@
 ==HOTP: общее описание==
-'''HOTP''' — [[OATH]]-алгоритм генерации одноразовых паролей по событию (event-base) описан как RFC 4226. Как сказано выше в качестве параметра, отвечающего за динамику, используется событие, то есть сам факт генерации одноразового пароля: каждый раз при нажатии на кнопку генерации, счетчик событий увеличивает свое значение на единицу и именно это значение динамическое значение  используется как основной параметр при расчете одноразового пароля.
+'''HOTP''' — [[OATH]]-алгоритм генерации [[одноразовый пароль|одноразовых паролей]]  по событию (event-base) описан как RFC 4226. Как сказано выше в качестве параметра, отвечающего за динамику, используется событие, то есть сам факт генерации [[одноразовый пароль|одноразового пароля]]: каждый раз при нажатии на кнопку генерации, счетчик событий увеличивает свое значение на единицу и именно это значение динамическое значение  используется как основной параметр при расчете одноразового пароля.
-Вторым параметром, используемым при расчете одноразового пароля, является симметричный ключ (symmetric key), который должен быть уникальным для каждого генератора и существует требование на его минимальную длину – 128 бит. Канонически, именно это значение определяет уникальность генератора одноразовых паролей. При этом стоит отметить, что дополнительный уровень энтропии вносится за счет случайного значения начального состояния счётчика событии, который вместе с симметричным ключом «прошивается в генератор и записывается в конфигурационный файл (по [[OATH]]-рекомендациям это должен быть формат PSKC, описанный в RFC 6030).
+Вторым параметром, используемым при расчете [[одноразовый пароль|одноразовых паролей]], является симметричный ключ (symmetric key), который должен быть уникальным для каждого генератора и существует требование на его минимальную длину – 128 бит. Канонически, именно это значение определяет уникальность генератора [[одноразовый пароль|одноразовых паролей]]  . При этом стоит отметить, что дополнительный уровень энтропии вносится за счет случайного значения начального состояния счётчика событии, который вместе с симметричным ключом «прошивается в генератор и записывается в конфигурационный файл (по [[OATH]]-рекомендациям это должен быть формат PSKC, описанный в RFC 6030).
 == О чем думали создатели алгоритма==

← Предыдущая		Версия 13:35, 10 мая 2012
Строка 36:		Строка 36:

	===Ресинхронизация счетчика===		===Ресинхронизация счетчика===
		+
		+	Ресинхронизация выполняется расчетом следующего HOTP-значения и сравнением с полученным от клиента (генератора). Это повторяется в переделах заданного окна ресинхронизации s. Дополнительно в процессе ресинхронизации сервер может запросить дополнительные значения одноразовых паролей (2 или 3). Это сделано для повышения безопасности, так как сравнения в этом случае выполняется для двух или трех пар, и все они должны пройти успешно.
		+	Параметр s — определяет окно, в пределах которого сервер увеличивать счетчик в процессе ресинхронизации.
		+
		+	Это ограничение вводится по двум причинам:
		+
		+	#ограничить вероятность подбора одноразового значения (см ниже расчет вероятности)
		+	# предотвратить бесконечный расчет в рамках одной проверки и как следствие отказ в обслуживании
		+
		+
		+
		+

← Предыдущая		Версия 13:15, 10 мая 2012
Строка 17:		Строка 17:
	#Простота ре-синхронизации счетчика событий		#Простота ре-синхронизации счетчика событий
	#Должен использовать надёжный общий секрет (shared secret) длина которого должна быть не менее 128 бит, а рекомендованная длина — 160 бит		#Должен использовать надёжный общий секрет (shared secret) длина которого должна быть не менее 128 бит, а рекомендованная длина — 160 бит
		+
		+
		+	==Проверка одноразового пароля и прочие радости==
		+
		+	=== Проверка===
		+	Генератор (клиент, в [[OATH]]-терминологии) увеличивает значение своего счетчик на единицу каждый, когда инициируется генерация одноразового пароля (при нажатии на копку). Это инкрементированное значение и подаётся на вход HMAC-SHA1 симметричным ключом (секретным значением, как мы помним, уникальным для каждого генератора).
		+	Это значение передается на сервер аутентификации (сервер проверки, в [[OATH]]-терминологии) и сравнивается со значение рассчитанным сервером. Если значения совпали, то сервер увеличивает значение счетчика данного генератора на единицу.
		+	Если значения, полученные и рассчитанные сервером не совпали, сервер инициирует процесс ресинхронизации (в пределах допустимого окна рассинхронизации — параметр s).
		+	Если процесс ресинхронизации не удался, сервер инициирует запрос другого значения одноразового пароля.
		+	Ситуация повторяется до тех пор, пока не будет достигнуто максимальное число попыток аутентификации (что должно влечь блокировку учётной учетной записи пользователя)
		+
		+	===Рассинхронизация счетчика===
		+	[[OATH]]-HOTP — синхронный алгоритм, работающий по счетчику событий, что означает необходимости синхронности значений счетчика событий, используемый генератором (клиентом) и серверов в процессе расчета и проверки одноразового пароля.
		+	Как сказано выше инкремент счетчика генератора выполняется каждый раз, когда выполняется генерация одноразового пароля. В то же время инкремент счетчика на сервере выполняется только в случае успешной аутентификации. Исходя из этого можно выделить несколько наиболее вероятных причин ресинхронизации:
		+	#Аутентификация не пройдена. Генератор инкрементировал свой счётчик, а сервер нет.
		+	#Проблема связи. Генератор инкрементировал свой счётчик, а север не получил одноразовый пароль. В этом случае при невнятном сообщении об ошибке пользователь с высокой вероятностью выполнит повторную генерацию одноразового пароля.
		+	#Элементарное баловство :)
		+
		+	===Ресинхронизация счетчика===

← Предыдущая		Версия 09:19, 3 мая 2012
Строка 76:		Строка 76:

	Например, при 5 разрешенных попытках, окне допустимом окне рассинхронизации равном 30 и 6-цифровом одноразовом пароле, вероятность подобрать пароль составит и пройти аутентификацию составит: 0.015%		Например, при 5 разрешенных попытках, окне допустимом окне рассинхронизации равном 30 и 6-цифровом одноразовом пароле, вероятность подобрать пароль составит и пройти аутентификацию составит: 0.015%
		+
		+	===Требования===
		+
		+	#Необходимо поддерживать двухфакторную аутентификацию. В данном случае подразумевается, что первым фактором является генератор одноразовых паролей (программный или аппаратный), вторым некоторый дополнительный секрет, который добавляется к одноразовому паролю.
		+	#сервер должен быть защищен от атак методом прямого перебора (brute-force attack), то есть учетная запись пользователя (в общем случае) должна блокироваться после оправленного числе неуспешных попыток аутентификации
		+	#Необходимо использовать защищенный канал

@@ Строка 58: / Строка 58: @@
 ==Аспекты безопасности==
-===Надежность лагоритма===
+===Надежность алгоритма===
 Анализ используемой математической базы, в частности используемые алгоритмы HMAC-SHA-1 и  дальнейшие преобразования 160-битного результата до 6-8 цифрового значения, показал  что наиболее вероятной атакой на HOTP будет атака методом прямого перебора (brute-force attack).

← Предыдущая		Версия 08:53, 3 мая 2012
Строка 56:		Строка 56:


−	===Аспекты безопасности===	+	==Аспекты безопасности==
		+
		+	===Надежность лагоритма===

	Анализ используемой математической базы, в частности используемые алгоритмы HMAC-SHA-1 и дальнейшие преобразования 160-битного результата до 6-8 цифрового значения, показал что наиболее вероятной атакой на HOTP будет атака методом прямого перебора (brute-force attack).		Анализ используемой математической базы, в частности используемые алгоритмы HMAC-SHA-1 и дальнейшие преобразования 160-битного результата до 6-8 цифрового значения, показал что наиболее вероятной атакой на HOTP будет атака методом прямого перебора (brute-force attack).

← Предыдущая		Версия 08:49, 3 мая 2012
Строка 56:		Строка 56:


−	==Аспекты безопасности==	+	===Аспекты безопасности===

	Анализ используемой математической базы, в частности используемые алгоритмы HMAC-SHA-1 и дальнейшие преобразования 160-битного результата до 6-8 цифрового значения, показал что наиболее вероятной атакой на HOTP будет атака методом прямого перебора (brute-force attack).		Анализ используемой математической базы, в частности используемые алгоритмы HMAC-SHA-1 и дальнейшие преобразования 160-битного результата до 6-8 цифрового значения, показал что наиболее вероятной атакой на HOTP будет атака методом прямого перебора (brute-force attack).

@@ Строка 9: / Строка 9: @@
 Основной задачей стандартизации алгоритма является повышение его применимости, и здесь речь идет столько с совместимости серверов аутентификации (проверки) и генераторов одноразовых паролей разных производителей, сколько заостряется внимание на простоте использования конечным пользователем и простоте реализации (дешевизне, низкой себестоимости аутентификатора — генератора одноразовых паролей). Это выражается в минимизации пользовательского интерфейса (чем меньше пользователь принимает участие в процессе, тем лучше) и возможности реализовать алгоритм, например, в SIM-карте (при этом возможность реализации на Java-карте являлось фундаментальным требованием)
-Детализированные требования можно прочитать в  RFC, здесь же приведем их короткие трактовки:
+Детализированные требования можно прочитать в  RFC 4226, здесь же приведем их короткие трактовки:
 #Алгоритмы должен быть последовательность, то есть основываться на счетчике событий
@@ Строка 23: / Строка 23: @@
 ===Общее===
-В основе генерации одноразовых паролей лежит HMAC-функция (RFC 2104), на вход которой подается два значения: симметричный ключ и текущее состояние счетчика. Отсюда, кстати, и название алгоритма HOTP —  HMAC-Based One-Time Password.  В качестве основы HMAC взят алгоритм SHA-1 (RFC 3174), то есть речь идет о HMAC-SHA-1 с длиной результата 160 бит.
+В основе генерации одноразовых паролей лежит HMAC-функция, на вход которой подается два значения: симметричный ключ и текущее состояние счетчика. Отсюда, кстати, и название алгоритма HOTP —  HMAC-Based One-Time Password.  В качестве основы HMAC взят алгоритм SHA-1 (RFC 3174), то есть речь идет о HMAC-SHA-1 (RFC 2104) с длиной результата 160 бит.
 Так как конечный пользователь будет испытывать катастрофические затруднения при наборе одноразового пароля длиной 160 бит, алгоритм предусматривает обрезку оригинального результата (160 бит) до приемлемой длины: одноразовый пароль имеет формат цифрового значения с длиной не менее 6 символов (цифр).
@@ Строка 49: / Строка 49: @@
 ===Как работает Truncate (обрезка)===
-Результат HMAC-SHA-1 — 160 бит или строка, состоящая из 20 байт, на основе чего генерируется строка в 4 байта. Это происходит следующим образом:
+Результат HMAC-SHA-1 (RFC 2104)— 160 бит или строка, состоящая из 20 байт, на основе чего генерируется строка в 4 байта. Это происходит следующим образом:
 -байтная строка представляется как 20 блоков по 8 бит, 4 младших бита последней 20-ой 8-битной последовательности определяют смещение (понятно, что это значение находится в диапазоне от 0 до 15). Далее выполняется конкатенация (склеивание) 4 последовательностей, первая из которых является строковым предобразованием вычисленного смещения, а вторая — преобразованием от смещения увеличенного на единицу и т.д.  последние 31 бита этой склейки и будут теми 4 байтами.