Комментарии 20
Хм, в примере же явно написано «key», а не «password». И в документации написано «key». Почему вы решили что там должен быть пароль?
Конечно, автор гема мог бы проверить, что на вход подается корректная HEX строка.
А вы, в свою очередь, могли бы немного разобраться в криптографии. Потому что бездумное использование криптоалгоритмов не добавит безопасности вашему приложениею.
Кстати, основная проблема этого гема не в этом. А в том — что он не позволяет выбрать режим шифрования. Подозреваю, что если не предоставить ему IV, то он будет шифровать в режиме ECB, что никуда не годится.
Конечно, автор гема мог бы проверить, что на вход подается корректная HEX строка.
А вы, в свою очередь, могли бы немного разобраться в криптографии. Потому что бездумное использование криптоалгоритмов не добавит безопасности вашему приложениею.
Кстати, основная проблема этого гема не в этом. А в том — что он не позволяет выбрать режим шифрования. Подозреваю, что если не предоставить ему IV, то он будет шифровать в режиме ECB, что никуда не годится.
Это не я, это автор оригинальной строки. И он придерживался, в общем-то распространённого паттерна поведения: «скачать, попробовать использовать, если что-то не получается — читать документацию». Просто методы шифрования и дешифрования вроде-бы корректно сработали, ошибок не возникло, расшифровалось именно то, что шифровалось. Очень многие на этом месте решили бы, что всё ок.
А, это я с переводом общался. Прошу прощения. Но в любом случае автор неправ.
Прав автор или нет, но отсутствие проверки на корректность входных данных — это недостаток библиотеки. Если конечно это не закрытая библиотека которой пользуется только лично её автор.
НЛО прилетело и опубликовало эту надпись здесь
Беда в том что зачастую слово key используется как более прикольная/заумная/краткая замена password, поэтому не каждый программист вообще подозревает о разнице, и даже если подозревает, не особо надеется, что она подразумевалась другим программистом.
Конечно, автор гема мог бы проверить, что на вход подается корректная HEX строка
Библиотека кривая же, что и выявило тестирование. Именно с точки зрения API. Пользователь не хочет думать, корректная у него hex-строка или не корректная, он хочет просто задать ключ шифрования.
Вот, например, pycrypto для python. key — просто набор байтов.
https://www.dlitz.net/software/pycrypto/api/current/Crypto.Cipher.AES-module.html
key (byte string) — The secret key to use in the symmetric cipher. It must be 16 (AES-128), 24 (AES-192), or 32 (AES-256) bytes long
И никаких проблем.
Тестирование и удача — наше все.
Повезло, что тесты сделали, иначе всплыло бы в самый неподходящий момент.
А зачем гем, если симметричное шифрование есть в stdlib?
Как видно из обсуждения бага, гем и делался как обертка над OpenSSL::Cipher
А вот и исправление на подходе.
Если мне память не изменяет, то эта тема уже освещалась на хабре. Линк найти не могу, в избранное не добавил.
Человек все правильно сделал. Взял готовый инструмент с открытым исходным кодом, воспользовался им и даже протестировал. В результате вот эта статья.
Того, кто работал с криптой должно было сразу напрячь имя key которое далеко не password. Традиционно, ключ шифрования — это не пароль шифрования. И в современном мире даже не MD5 от пароля, а еще и перемешивание битов чем нибудь типа pbkdf2 на 80000 раундов. Человек мог этого не знать, но авторы криптографической библиотеки должны были сделать две вещи: четко написать о значении key в доке, не используя принцип «минимально и достаточно», как это обычно бывает когда разрабы ленятся (а вообще дока была?), и сделать защиту от дурака, а не тупо преобразовывать не-hex символы в нули.
Того, кто работал с криптой должно было сразу напрячь имя key которое далеко не password. Традиционно, ключ шифрования — это не пароль шифрования. И в современном мире даже не MD5 от пароля, а еще и перемешивание битов чем нибудь типа pbkdf2 на 80000 раундов. Человек мог этого не знать, но авторы криптографической библиотеки должны были сделать две вещи: четко написать о значении key в доке, не используя принцип «минимально и достаточно», как это обычно бывает когда разрабы ленятся (а вообще дока была?), и сделать защиту от дурака, а не тупо преобразовывать не-hex символы в нули.
Я последнее время насмотрелся творчества програмистов, в проекте порядка гигабайта исходников. Прихожу к выводу, на уровне языка надо вводить семантику типа
То есть программист должен перечислить все случаи, когда процедура работает. Во всех остальных случаях должна выводиться ошибка.
if условие then
действе
else
raise exception 'вызывается принудительно на уровне языка
end if
То есть программист должен перечислить все случаи, когда процедура работает. Во всех остальных случаях должна выводиться ошибка.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простая и ужасающая история о шифровании