Как стать автором
Обновить

Комментарии 31

НЛО прилетело и опубликовало эту надпись здесь
Хабр — торт!
Разве MD5 уже не считается устарелым и небезопасным? Сейчас вроде в моде SHA семейство.
Там есть несколько атак. Можно забрутфорсить хешированную строку, если она короткая. Но у нас она длинная. Можно сделать MD5 от 'foobar' не зная 'foo'. Не поможет, у нас MD5 от конкретной длинной строки. Можно сделать другую последовательность байт, которая будет иметь тот же MD5 хэш — но в случае JSON payload это приведет к невалидным данным. Как-то так.
Можно сделать другую последовательность байт, которая будет иметь тот же MD5 хэш — но в случае JSON payload это приведет к невалидным данным.

Кто сказал?

Да, я согласен с заголовком.


И где там про, что для дьявола и ангела есть коллизии, а для JSON нет? И насколько авторитетный это источник, чтобы подкреплять им свою (и клиентов) безопасность? Отдайте безопасность людям, которые в этом разбираются, как минимум в стандартах и хороших практиках. А то потом на API смотреть больно.

Вобще в теории колизия делается легко.
например валидный json.
{"action": {
  "id": "file",
  "value": "File"}}

Хотим сделать что-то другое.
{"action": {
  "id": "eval",
  "value": "some_code"},"somesting":"some_data_with_32bytes"}

И в теории мы можем перебирать some_data_with_32bytes и можно перебирать пока не совпадет хеш. И вот вам валидный json на который сервер даже не отреагирует никак.
По той атаке что по ссылке оно в конец дописывается. А в конце у JSON закрывающие скобочки и все вот это. Коллизию с произвольными данными, насколько я знаю, простым способом сделать нельзя. Или я ошибаюсь?
И в теории мы можем перебирать some_data_with_32bytes и можно перебирать пока не совпадет хеш

Долго и дорого.

НЛО прилетело и опубликовало эту надпись здесь
Почему велосипеды? Один из вполне стандартных методов, которые используют облачные платформы в качестве дополнительной страховки к HTTPS. А какое решение вы считаете не велосипедом? :)

jwt

От какого типа атаки вас это защищает? От MITM — не думаю, что это безопаснее чем TLS?
Может лучше проверку клиентского сертификата тогда сделать?

От того, что кто-то сделает HTTP запрос к backend нашего клиента «от имени» Voximplant. Как я писал в статье, есть много разных способов. Этот хороший по соотношению потраченных разработчиком усилий (минута и пара строк кода) и степени защиты (простого способа обойти нет).
1. обычно используют все же не накополенную поделку, а стандартизированный hmac.
2. md5 уже не считается безопасным

Притом велосипеды с какой-то странной терминологией. Разве ж это соль в общепринятом понимании? Это скорее private key.

Это именно соль. Чтобы нельзя было сделать фейковый коллбек, зная только его данные и данные аккаунта

Не согласен.


In cryptography, a salt is random data that is used as an additional input to a one-way function that "hashes" data, a password or passphrase.

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

Это не соль, а общий ключ (shared key)
облако Voximplant считает MD5-хэш от данных аккаунта, запроса и соли

Для таких вещей вроде как hash_hmac() существует.
Как минимум.
старый добрый hmac, только в профиль
а полученный hash(account + request body + salt) вы как передаете, в url (header)?
Нет, в самом JSON
так ведь hash зависит от тела запроса, или я не так понял?

На php код примерно такой:


$key = 'pUWTzQ3qGNgIn39nTI4ul3BfS9v5UHdioz+ao8AKjxw=';
$data = json_decode(stream_get_contents(STDIN), true);
$hmac = $data['hmac'];
unset($data['hmac']);
if ($hmac !== hash_hmac('sha256', json_encode($data), $key)) {
  throw new \RuntimeException('Bad HMAC');
}
Не от тела целиком, от одного из полей с id запроса

Если только от id, то как это защищает от подмены тела?

НЛО прилетело и опубликовало эту надпись здесь
Даже без рассмотрения полноценной инфраструктуры ЭЦП безопасней использовать полноценную подпись с закрытым и открытым ключом. В админке облака виден открытый ключ, который бэкенд может спокойно хранить в открытом виде, а в самом облаке где-то есть закрытый, который даже пользователь админки не знает. То есть даже взлом админки (компроментация пользователя) не позволит никому от имени облака слать запросы на бэкенд.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий