Новый bitfloor API: глупая безопасность?

Bitfloor вернулся, и они изменили свой API. Теперь вы должны выбрать дополнительный "ключевая фраза" (Это не ваш пароль или ключ API или ваш секретный ключ, но что-то другое) и отправить его в качестве SSL-защищенного, но в противном случае, в открытом виде заголовка с каждым вызовом API (т.е. даже их внешний интерфейс HTTP-сервера могут увидеть ваш пароль) ,

Как, собственно, делает это повысить безопасность? "ключевая фраза" это просто еще один секрет, как секретный ключ. Почему два пароля более безопасный, чем один пароль? Особенно, когда существующий пароль уже случайная строка 64 байта.

Единственное различие, которое я вижу в том, что ключевая фраза выбирается пользователем, а не случайным образом генерируется bitfloor. Но если что-нибудь, что снижает безопасность: вместо того, чтобы быть уверенным bitfloor пароль подходящим случайным образом, пользователи могут выбирать слабые пароли.

Ничего из этого не имеет смысла.

Если хакер компрометирует серверы bitfloor - даже в интернет-серверы с выходом фронтэнда, которые всегда самое слабое место - они могут смотреть "ключевые фразы" поток через провод. Без дополнительной безопасности там.

Может быть, они надеются, что если они взломаны, хакер только выиграет в парольной фразе пользователей, которые происходят делать вызовы API во время хакерского периода. Но они могли бы добиться, что со старым API: просто хранить только хэш SHA из "Секретный ключ" на диске и забыть фактический секретный ключ сразу же после его создания. Точно такой же уровень безопасности, без изменения API.

Это меня беспокоит. Если я не что-то пропустили главный, это указывает на то, что кто-то на Bitfloor не понимает безопасность. Я надеюсь, что я неправильно об этом.

Цитата: eldentyrell 22 сентября 2012, 05:14:24 PM

Это странно, где вы видели, что?

Цитата: Isis 22 сентября 2012 года, 6:00:35 PM

Это странно, где вы видели, что?

Вот: https://bitfloor.com/docs/api/order-entry/rest.

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

Цитата: eldentyrell 22 сентября 2012, 05:14:24 PM

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

Это именно разница. Имея ключевую фразу, которая выбирается пользователем, имея доступ к ключу апи и секретному ключу (дамп базы данных или иным образом), не позволит злоумышленнику создать фиктивные запросы API. API-прежнему создает сильный секретный ключ для подписи, который не выбран пользователем.

Ранее (и многие нынешние обмена APIs), если злоумышленник сможет получить список ключей API и секретов, и обмен не обнаруживает или реагировать достаточно быстро, то злоумышленник может просто использовать клавиши для выполнения вызовов API, как если бы они вас (не перехватывая или другие сложные действия, необходимые на сервере злоумышленника) были. Использование ключевой фразы, которая хранится с использованием один из способов посола хэш гарантирует, что даже с ключом доступа злоумышленник не сможет сделать запросы, не зная вашего выбранного пользователем пароля. Использование ключевой фразы устанавливает общую ответственность за обеспечение тайны между клиентом и сервером без всех необходимых данных, которые хранятся на нашем сервере, чтобы сделать запрос API.

Цитата: shtylman 22 сентября 2012 года, 8:23:53 PM

Цитата: eldentyrell 22 сентября 2012, 05:14:24 PM

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

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

Я хотел бы использовать ключ системы государственного / частного подписания. Подобно тому, как Bitcoin себя функции. Если кто-то получил их секретный ключ скомпрометирован, что это их личная проблема. Однако вы только хранить открытый ключ так, компромисс абсолютно никакого отношения.

Цитата: shtylman 22 сентября 2012 года, 8:23:53 PM

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

Цитата: qxzn 22 сентября 2012, 10:22:30 PM

Цитата: shtylman 22 сентября 2012 года, 8:23:53 PM

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

Цитата: shtylman 22 сентября 2012, 10:25:49 PM

Круто. Я предполагаю, что в теории я мог бы сделать это прежде, чем путем шифрования моего ключа API с ключевой фразой, но это намного проще.

Цитата: shtylman 22 сентября 2012 года, 8:23:53 PM

Это именно разница. Имея ключевую фразу, которая выбирается пользователем,

Кто выбирает это совершенно не имеет значения, так как пользователь должен ввести его в свой веб-сайт, когда они создают его. Это не более безопасным, чем если вы случайно сгенерирован "ключевая фраза" и сказал пользователю "вот ключевая фраза я выбрал для вас",

Цитата: shtylman 22 сентября 2012 года, 8:23:53 PM

имея доступ к ключу апи и секретному ключу (дамп базы данных или иным образом), не позволит злоумышленнику создать фиктивные запросы API.

...

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

Так что точка секретного ключа тогда?

Как я уже писал ранее (и вы не ответили на):

Цитата: eldentyrell 22 сентября 2012, 05:14:24 PM

Но они могли бы добиться, что со старым API: просто хранить только хэш SHA из "Секретный ключ" на диске и забыть фактический секретный ключ сразу же после его создания. Точно такой же уровень безопасности, без изменения API.

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

Это не внушает доверие.

Цитата: eldentyrell 22 сентября 2012, 10:27:56 PM

Так что точка секретного ключа тогда?

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

Это не внушает доверие.

Секретный ключ используется, чтобы проверить подпись сообщения и, как таковой, мы должны использовать его, чтобы вычислить подпись и проверить его на достоверность. Подпись гарантирует, что ваше сообщение не подделано на MITM.

Если вы хотите какие-либо разъяснения относительно уместности полей, пожалуйста, свяжитесь с support@bitfloor.com и я буду рад вдаваться в подробности. Это поможет мне в понимании того, как документация может быть выяснена.

Цитата: shtylman 22 сентября 2012, 10:42:04 PM

Ни секретный ключ, ни ключевая фраза, ни подписи фактически не требуется для обеспечения безопасности и подлинности запросов API клиентов. нет Ключ API уже достаточно большой (128 бит), чтобы избежать грубой атаки силы, и он никогда не передается только через шифрованное подключение (SSL), и клиент не будет посылать его, если сертификат сервера не проверяет, так что ни MITM, ни подслушать возможны. Кроме того, SSL это уже включают в себя одноразовые номера, так что переигровка атака не представляется возможным, и поэтому одноразовое значение поля ненужный, тоже.

Конечно, есть еще возможность дампа базы данных, которая бы раскрыть все ключи API для злоумышленника. На самом деле, вы должны требовать проверки подлинности клиента сертификата на SSL соединения с сервером API, и база данных должна содержать сертификаты для всех пользователей API. Тогда это не имело бы значения, если злоумышленник получил дамп базы данных; они до сих пор не может претендовать на какой-либо из ваших пользователей, потому что они не будут иметь закрытые ключи, связанные с этими сертификатами.

В принципе, все эти дополнительные поля заголовка HTTP являются неуклюжие попытки решить проблему, которая уже решена в SSL. И, кстати, вы должны префикс нестандартные имена полей заголовка с "ИКС-" так что они не вступают в противоречие с будущими стандартами.

Используя ключ API и общий секрет (известный как клиент и сервер) с проверкой подлинности HMAC основе является довольно распространенной моделью для REST услуг. Это та же модель, используемая MtGox, Укусил меня, а также Amazon S3 вместе с Bitfloor.

Дополнительное поле Фраза-пароль еще один слой безопасности, так что не бесполезно. Она защищает от очень плохих сценариев, таких как пользователь получившего списка ключей API и общих секретов. Если предположить, что ключевую фразу хранится Bitfloor как соленый хэш, полезность списка быстро деградирует.

Цитата: freewil 23 сентября 2012 года, 7:39:37 AM

Общие не означает хорошо. Кейнсианская модель экономики является обычным явлением, но это не делает его хорошим.

Цитата: freewil 23 сентября 2012 года, 7:39:37 AM

Дополнительное поле Фраза-пароль еще один слой безопасности, так что не бесполезно. Она защищает от очень плохих сценариев, таких как пользователь получившего списка ключей API и общих секретов. Если предположить, что ключевую фразу хранится Bitfloor как соленый хэш, полезность списка быстро деградирует.

весь этот "модель безопасности" выглядит как-то разработан кем-то без образования в криптографических протоколах.

На самом деле это не выглядит слишком хорошо.

Цитата: whitslack 23 сентября 2012 года, 1:39:50 AM

Цитата: shtylman 22 сентября 2012, 10:42:04 PM

Мяты чип используется вызов клиента сертификат для аутентификации своих тестовых серверов. Это было тривиально установить браузер серт и затем только, что браузер может получить доступ к серверу или учетной записи. Вы также должны были аутентичным сервер серта мята чипа, прежде чем вы могли бы сделать какую-либо сделку. Показалось мне очень надежным средством аутентификации для финансовой службы. И как проверка подлинности сертификата было около года, я удивлен, что она до сих пор не было более широко применяется для финансовых веб-сервисов.

Выздоровели вы в ~ 20,000BTC, поглощенные потери себя, или передали потери на ваши клиент? Прошу прощения, если я что-то пропустил ... напряженный день и далеко много нитей, чтобы следовать.

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

22 сентября 2012, 5:14:24 PM	# 1
eldentyrell Сообщения: 980 Цитировать по имени цитировать ответ	Re: bitfloor API: глупая безопасность? Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Bitfloor вернулся, и они изменили свой API. Теперь вы должны выбрать дополнительный "ключевая фраза" (Это не ваш пароль или ключ API или ваш секретный ключ, но что-то другое) и отправить его в качестве SSL-защищенного, но в противном случае, в открытом виде заголовка с каждым вызовом API (т.е. даже их внешний интерфейс HTTP-сервера могут увидеть ваш пароль) , Как, собственно, делает это повысить безопасность? "ключевая фраза" это просто еще один секрет, как секретный ключ. Почему два пароля более безопасный, чем один пароль? Особенно, когда существующий пароль уже случайная строка 64 байта. Единственное различие, которое я вижу в том, что ключевая фраза выбирается пользователем, а не случайным образом генерируется bitfloor. Но если что-нибудь, что снижает безопасность: вместо того, чтобы быть уверенным bitfloor пароль подходящим случайным образом, пользователи могут выбирать слабые пароли. Ничего из этого не имеет смысла. Если хакер компрометирует серверы bitfloor - даже в интернет-серверы с выходом фронтэнда, которые всегда самое слабое место - они могут смотреть "ключевые фразы" поток через провод. Без дополнительной безопасности там. Может быть, они надеются, что если они взломаны, хакер только выиграет в парольной фразе пользователей, которые происходят делать вызовы API во время хакерского периода. Но они могли бы добиться, что со старым API: просто хранить только хэш SHA из "Секретный ключ" на диске и забыть фактический секретный ключ сразу же после его создания. Точно такой же уровень безопасности, без изменения API. Это меня беспокоит. Если я не что-то пропустили главный, это указывает на то, что кто-то на Bitfloor не понимает безопасность. Я надеюсь, что я неправильно об этом.

22 сентября 2012, 6:00:35 PM	# 2
ISIS Сообщения: 154 Цитировать по имени цитировать ответ	Re: bitfloor API: глупая безопасность? Получил 1806 Биткоинов Реальная история. Цитата: eldentyrell 22 сентября 2012, 05:14:24 PM Bitfloor вернулся, и они изменили свой API. Теперь вы должны выбрать дополнительный "ключевая фраза" (Это не ваш пароль или ключ API или ваш секретный ключ, но что-то другое) и отправить его в качестве SSL-защищенного, но в противном случае, в открытом виде заголовка с каждым вызовом API (т.е. даже их внешний интерфейс HTTP-сервера могут увидеть ваш пароль) , Как, собственно, делает это повысить безопасность? "ключевая фраза" это просто еще один секрет, как секретный ключ. Почему два пароля более безопасный, чем один пароль? Особенно, когда существующий пароль уже случайная строка 64 байта. Единственное различие, которое я вижу в том, что ключевая фраза выбирается пользователем, а не случайным образом генерируется bitfloor. Но если что-нибудь, что снижает безопасность: вместо того, чтобы быть уверенным bitfloor пароль подходящим случайным образом, пользователи могут выбирать слабые пароли. Ничего из этого не имеет смысла. Если хакер компрометирует серверы bitfloor - даже в интернет-серверы с выходом фронтэнда, которые всегда самое слабое место - они могут смотреть "ключевые фразы" поток через провод. Без дополнительной безопасности там. Может быть, они надеются, что если они взломаны, хакер только выиграет в парольной фразе пользователей, которые происходят делать вызовы API во время хакерского периода. Но они могли бы добиться, что со старым API: просто хранить только хэш SHA из "Секретный ключ" на диске и забыть фактический секретный ключ сразу же после его создания. Точно такой же уровень безопасности, без изменения API. Это меня беспокоит. Если я не что-то пропустили главный, это указывает на то, что кто-то на Bitfloor не понимает безопасность. Я надеюсь, что я неправильно об этом. Это странно, где вы видели, что?

22 сентября 2012, 7:46:58 PM	# 3
eldentyrell Сообщения: 980 Цитировать по имени цитировать ответ	Re: bitfloor API: глупая безопасность? Цитата: Isis 22 сентября 2012 года, 6:00:35 PM Это странно, где вы видели, что? Вот: https://bitfloor.com/docs/api/order-entry/rest. Я реализовал это, и я использую его прямо сейчас - это действительно действительно функция, как описано выше.

22 сентября 2012, 8:23:53 PM	# 4
shtylman Сообщения: 243 Цитировать по имени цитировать ответ	Re: bitfloor API: глупая безопасность? Цитата: eldentyrell 22 сентября 2012, 05:14:24 PM Единственное различие, которое я вижу в том, что ключевая фраза выбирается пользователем, а не случайным образом генерируется bitfloor. Это именно разница. Имея ключевую фразу, которая выбирается пользователем, имея доступ к ключу апи и секретному ключу (дамп базы данных или иным образом), не позволит злоумышленнику создать фиктивные запросы API. API-прежнему создает сильный секретный ключ для подписи, который не выбран пользователем. Ранее (и многие нынешние обмена APIs), если злоумышленник сможет получить список ключей API и секретов, и обмен не обнаруживает или реагировать достаточно быстро, то злоумышленник может просто использовать клавиши для выполнения вызовов API, как если бы они вас (не перехватывая или другие сложные действия, необходимые на сервере злоумышленника) были. Использование ключевой фразы, которая хранится с использованием один из способов посола хэш гарантирует, что даже с ключом доступа злоумышленник не сможет сделать запросы, не зная вашего выбранного пользователем пароля. Использование ключевой фразы устанавливает общую ответственность за обеспечение тайны между клиентом и сервером без всех необходимых данных, которые хранятся на нашем сервере, чтобы сделать запрос API.

22 сентября 2012, 10:15:00 PM	# 5
ISIS Сообщения: 154 Цитировать по имени цитировать ответ	Re: bitfloor API: глупая безопасность? Цитата: shtylman 22 сентября 2012 года, 8:23:53 PM Цитата: eldentyrell 22 сентября 2012, 05:14:24 PM Единственное различие, которое я вижу в том, что ключевая фраза выбирается пользователем, а не случайным образом генерируется bitfloor. Это именно разница. Имея ключевую фразу, которая выбирается пользователем, имея доступ к ключу апи и секретному ключу (дамп базы данных или иным образом), не позволит злоумышленнику создать фиктивные запросы API. API-прежнему создает сильный секретный ключ для подписи, который не выбран пользователем. Ранее (и многие нынешние обмена APIs), если злоумышленник сможет получить список ключей API и секретов, и обмен не обнаруживает или реагировать достаточно быстро, то злоумышленник может просто использовать клавиши для выполнения вызовов API, как если бы они вас (не перехватывая или другие сложные действия, необходимые на сервере злоумышленника) были. Использование ключевой фразы, которая хранится с использованием один из способов посола хэш гарантирует, что даже с ключом доступа злоумышленник не сможет сделать запросы, не зная вашего выбранного пользователем пароля. Использование ключевой фразы устанавливает общую ответственность за обеспечение тайны между клиентом и сервером без всех необходимых данных, которые хранятся на нашем сервере, чтобы сделать запрос API. Это будет работать только если данные были сохранены не только в разных доменах, но в физически разных местах. Дамп базы данных будет полный компромисс. Соленые хэш пароля или иным способом. Если бы я проектирование API, где эта угроза была реальной возможностью, я хотел бы использовать совершенно другой подход. Я хотел бы использовать ключ системы государственного / частного подписания. Подобно тому, как Bitcoin себя функции. Если кто-то получил их секретный ключ скомпрометирован, что это их личная проблема. Однако вы только хранить открытый ключ так, компромисс абсолютно никакого отношения.

22 сентября 2012, 10:22:30 PM	# 6
qxzn Сообщения: 604 Цитировать по имени цитировать ответ	Re: bitfloor API: глупая безопасность? Цитата: shtylman 22 сентября 2012 года, 8:23:53 PM Это именно разница. Имея ключевую фразу, которая выбирается пользователем, имея доступ к ключу апи и секретному ключу (дамп базы данных или иным образом), не позволит злоумышленнику создать фиктивные запросы API. API-прежнему создает сильный секретный ключ для подписи, который не выбран пользователем. Разве это не означает также, что если мы хотим, чтобы пользователи могут требовать ввода в ключевой фразе, когда запуск наших собственных приложений? Это способ, "Ключи от царства" не просто заложить вокруг на жестком диске моего компьютера.

22 сентября 2012, 10:25:49 PM	# 7
shtylman Сообщения: 243 Цитировать по имени цитировать ответ	Re: bitfloor API: глупая безопасность? Цитата: qxzn 22 сентября 2012, 10:22:30 PM Цитата: shtylman 22 сентября 2012 года, 8:23:53 PM Это именно разница. Имея ключевую фразу, которая выбирается пользователем, имея доступ к ключу апи и секретному ключу (дамп базы данных или иным образом), не позволит злоумышленнику создать фиктивные запросы API. API-прежнему создает сильный секретный ключ для подписи, который не выбран пользователем. Разве это не означает также, что если мы хотим, чтобы пользователи могут требовать ввода в ключевой фразе, когда запуск наших собственных приложений? Это способ, "Ключи от царства" не просто заложить вокруг на жестком диске моего компьютера. Верный. Как вы выбираете для обработки ключевой фразы хранения и использования полностью зависит от вас. Если ваши программы работают таким образом, что вы можете ввести ключевую фразу только во время запуска, то вы будете в дальнейшем предотвратить фальсификацию или использование ваших торговых программ без вашего разрешения.

22 сентября 2012, 10:26:53 PM	# 8
qxzn Сообщения: 604 Цитировать по имени цитировать ответ	Re: bitfloor API: глупая безопасность? Цитата: shtylman 22 сентября 2012, 10:25:49 PM Верный. Как вы выбираете для обработки ключевой фразы хранения и использования полностью зависит от вас. Если ваши программы работают таким образом, что вы можете ввести ключевую фразу только во время запуска, то вы будете в дальнейшем предотвратить фальсификацию или использование ваших торговых программ без вашего разрешения. Круто. Я предполагаю, что в теории я мог бы сделать это прежде, чем путем шифрования моего ключа API с ключевой фразой, но это намного проще.

22 сентября 2012, 10:27:56 PM	# 9
eldentyrell Сообщения: 980 Цитировать по имени цитировать ответ	Re: bitfloor API: глупая безопасность? Цитата: shtylman 22 сентября 2012 года, 8:23:53 PM Это именно разница. Имея ключевую фразу, которая выбирается пользователем, Кто выбирает это совершенно не имеет значения, так как пользователь должен ввести его в свой веб-сайт, когда они создают его. Это не более безопасным, чем если вы случайно сгенерирован "ключевая фраза" и сказал пользователю "вот ключевая фраза я выбрал для вас", Цитата: shtylman 22 сентября 2012 года, 8:23:53 PM имея доступ к ключу апи и секретному ключу (дамп базы данных или иным образом), не позволит злоумышленнику создать фиктивные запросы API. ... Использование ключевой фразы, которая хранится с использованием один из способов посола хэш гарантирует, что даже с ключом доступа злоумышленник не сможет сделать запросы, не зная вашего выбранного пользователем пароля. Так что точка секретного ключа тогда? Как я уже писал ранее (и вы не ответили на): Цитата: eldentyrell 22 сентября 2012, 05:14:24 PM Но они могли бы добиться, что со старым API: просто хранить только хэш SHA из "Секретный ключ" на диске и забыть фактический секретный ключ сразу же после его создания. Точно такой же уровень безопасности, без изменения API. Похоже, вы, ребята, только что обнаружил, что вы должны были хранить секретный ключ в качестве подсоленной хэш вместо открытого текста. Но вместо того, чтобы просто фиксируя, что вы болтами на совершенно новый вторичный пароль системы, что делает исходный один резервный. Это не внушает доверие.

22 сентября 2012, 10:42:04 PM	# 10
shtylman Сообщения: 243 Цитировать по имени цитировать ответ	Re: bitfloor API: глупая безопасность? Цитата: eldentyrell 22 сентября 2012, 10:27:56 PM Так что точка секретного ключа тогда? Похоже, вы, ребята, только что обнаружил, что вы должны были хранить секретный ключ в качестве подсоленной хэш вместо открытого текста. Но вместо того, чтобы просто фиксируя, что вы болтами на совершенно новый вторичный пароль системы, что делает исходный один резервный. Это не внушает доверие. Секретный ключ используется, чтобы проверить подпись сообщения и, как таковой, мы должны использовать его, чтобы вычислить подпись и проверить его на достоверность. Подпись гарантирует, что ваше сообщение не подделано на MITM. Если вы хотите какие-либо разъяснения относительно уместности полей, пожалуйста, свяжитесь с support@bitfloor.com и я буду рад вдаваться в подробности. Это поможет мне в понимании того, как документация может быть выяснена.

23 сентября 2012, 1:39:50 AM	# 11
whitslack Сообщения: 120 Цитировать по имени цитировать ответ	Re: bitfloor API: глупая безопасность? Цитата: shtylman 22 сентября 2012, 10:42:04 PM Секретный ключ используется, чтобы проверить подпись сообщения и, как таковой, мы должны использовать его, чтобы вычислить подпись и проверить его на достоверность. Подпись гарантирует, что ваше сообщение не подделано на MITM. Ни секретный ключ, ни ключевая фраза, ни подписи фактически не требуется для обеспечения безопасности и подлинности запросов API клиентов. нет Ключ API уже достаточно большой (128 бит), чтобы избежать грубой атаки силы, и он никогда не передается только через шифрованное подключение (SSL), и клиент не будет посылать его, если сертификат сервера не проверяет, так что ни MITM, ни подслушать возможны. Кроме того, SSL это уже включают в себя одноразовые номера, так что переигровка атака не представляется возможным, и поэтому одноразовое значение поля ненужный, тоже. Конечно, есть еще возможность дампа базы данных, которая бы раскрыть все ключи API для злоумышленника. На самом деле, вы должны требовать проверки подлинности клиента сертификата на SSL соединения с сервером API, и база данных должна содержать сертификаты для всех пользователей API. Тогда это не имело бы значения, если злоумышленник получил дамп базы данных; они до сих пор не может претендовать на какой-либо из ваших пользователей, потому что они не будут иметь закрытые ключи, связанные с этими сертификатами. В принципе, все эти дополнительные поля заголовка HTTP являются неуклюжие попытки решить проблему, которая уже решена в SSL. И, кстати, вы должны префикс нестандартные имена полей заголовка с "ИКС-" так что они не вступают в противоречие с будущими стандартами.

23 сентября 2012, 7:39:37 AM	# 12
freewil Сообщений: 92 Цитировать по имени цитировать ответ	Re: bitfloor API: глупая безопасность? Используя ключ API и общий секрет (известный как клиент и сервер) с проверкой подлинности HMAC основе является довольно распространенной моделью для REST услуг. Это та же модель, используемая MtGox, Укусил меня, а также Amazon S3 вместе с Bitfloor. Дополнительное поле Фраза-пароль еще один слой безопасности, так что не бесполезно. Она защищает от очень плохих сценариев, таких как пользователь получившего списка ключей API и общих секретов. Если предположить, что ключевую фразу хранится Bitfloor как соленый хэш, полезность списка быстро деградирует.

23 сентября 2012, 2:51:27 PM	# 13
whitslack Сообщения: 120 Цитировать по имени цитировать ответ	Re: bitfloor API: глупая безопасность? Цитата: freewil 23 сентября 2012 года, 7:39:37 AM Используя ключ API и общий секрет (известный как клиент и сервер) с проверкой подлинности HMAC основе является довольно распространенной моделью для REST услуг. Это та же модель, используемая MtGox, Укусил меня, а также Amazon S3 вместе с Bitfloor. Общие не означает хорошо. Кейнсианская модель экономики является обычным явлением, но это не делает его хорошим. Цитата: freewil 23 сентября 2012 года, 7:39:37 AM Дополнительное поле Фраза-пароль еще один слой безопасности, так что не бесполезно. Она защищает от очень плохих сценариев, таких как пользователь получившего списка ключей API и общих секретов. Если предположить, что ключевую фразу хранится Bitfloor как соленый хэш, полезность списка быстро деградирует. весь этот "модель безопасности" выглядит как-то разработан кем-то без образования в криптографических протоколах.

24 сентября 2012, 8:58:10 PM	# 14
MPOE-PR Сообщения: 756 Цитировать по имени цитировать ответ	Re: bitfloor API: глупая безопасность? На самом деле это не выглядит слишком хорошо.

24 сентября 2012, 9:19:33 PM	# 15
BCB Сообщения: 1050 Цитировать по имени цитировать ответ	Re: bitfloor API: глупая безопасность? Цитата: whitslack 23 сентября 2012 года, 1:39:50 AM Цитата: shtylman 22 сентября 2012, 10:42:04 PM Секретный ключ используется, чтобы проверить подпись сообщения и, как таковой, мы должны использовать его, чтобы вычислить подпись и проверить его на достоверность. Подпись гарантирует, что ваше сообщение не подделано на MITM. Ни секретный ключ, ни ключевая фраза, ни подписи фактически не требуется для обеспечения безопасности и подлинности запросов API клиентов. нет Ключ API уже достаточно большой (128 бит), чтобы избежать грубой атаки силы, и он никогда не передается только через шифрованное подключение (SSL), и клиент не будет посылать его, если сертификат сервера не проверяет, так что ни MITM, ни подслушать возможны. Кроме того, SSL это уже включают в себя одноразовые номера, так что переигровка атака не представляется возможным, и поэтому одноразовое значение поля ненужный, тоже. Конечно, есть еще возможность дампа базы данных, которая бы раскрыть все ключи API для злоумышленника. На самом деле, вы должны требовать проверки подлинности клиента сертификата на SSL соединения с сервером API, и база данных должна содержать сертификаты для всех пользователей API. Тогда это не имело бы значения, если злоумышленник получил дамп базы данных; они до сих пор не может претендовать на какой-либо из ваших пользователей, потому что они не будут иметь закрытые ключи, связанные с этими сертификатами. В принципе, все эти дополнительные поля заголовка HTTP являются неуклюжие попытки решить проблему, которая уже решена в SSL. И, кстати, вы должны префикс нестандартные имена полей заголовка с "ИКС-" так что они не вступают в противоречие с будущими стандартами. Мяты чип используется вызов клиента сертификат для аутентификации своих тестовых серверов. Это было тривиально установить браузер серт и затем только, что браузер может получить доступ к серверу или учетной записи. Вы также должны были аутентичным сервер серта мята чипа, прежде чем вы могли бы сделать какую-либо сделку. Показалось мне очень надежным средством аутентификации для финансовой службы. И как проверка подлинности сертификата было около года, я удивлен, что она до сих пор не было более широко применяется для финансовых веб-сервисов.

28 сентября 2012, 3:10:32 AM	# 16
BlackHeartFund Сообщения: 126 Цитировать по имени цитировать ответ	Re: bitfloor API: глупая безопасность? Выздоровели вы в ~ 20,000BTC, поглощенные потери себя, или передали потери на ваши клиент? Прошу прощения, если я что-то пропустил ... напряженный день и далеко много нитей, чтобы следовать.

28 сентября 2012, 3:35:02 AM	# 17
weex Сообщения: 1105 Цитировать по имени цитировать ответ	Re: bitfloor API: глупая безопасность? Есть ли у этого новая ключевая фраза требование сложности? Похоже, другой пароль для грубой силы для неоткрытого злоумышленника.

Заголовок