Max Home IndustryНедавняя статья arXiv дает представление о том, является ли спецификация программы полезным инструментом для задач, связанных с безопасностью. Это также показывает, что разработчики часто не могут надежно хранить пароли, несмотря на то, что утверждают, что делают это правильно.
Обеспокоенные безопасным хранением паролей, исследователи из Бристольского университета приступили к расследованию:
Приводит ли написание спецификации к измеримому улучшению метода хранения паролей?
Какие подходы используют разработчики при внедрении хранилища паролей
Как разработчики обосновывают свой подход к реализации
Чтобы разобраться в этих трех вопросах, они попросили 138 разработчиков написать код для хранения пароля на любом языке, который им наиболее удобен, или в псевдокоде. Половине разработчиков было предложено записать спецификацию того, как они будут реализовывать решение, прежде чем приступить к его написанию, и это может быть любая спецификация от простого описания до формального определения. Остальным было разрешено немедленно написать свою реализацию, а затем их спросили, составили ли они какую-либо спецификацию или план до начала их реализации (без запроса), и в этом случае их результаты были распределены по группе спецификаций.
Обеим группам было предложено представить обоснование своего подхода к кодированию в свободном текстовом поле. Их спросили, рассматривают ли они, какие угрозы могут атаковать сохраненный пароль, и ссылаются ли они на какие-либо стандарты хранения паролей при реализации кода.
Безопасность всех реализаций оценивалась с использованием показателя безопасности хранения паролей, основанного на стандарте NIST SP 800-63-3 и приписываемого Найскшиной и др.:
Что касается основного вопроса, рассматриваемого в этом исследовании, а именно эффекта написания спецификации, результаты исследования заключались в том, что разработчики, предложившие спецификацию (n = 61), набрали больше баллов (µ = 1,03), чем те, которые не были заданы (n = 77, µ = 0,47). Однако вы заметите, что средний балл чуть более одного балла вряд ли впечатляет. На самом деле только 53 разработчика (38%) произвели результаты, которые соответствовали, по крайней мере, одной части критериев Найакшины.
Изучая результаты, чтобы увидеть, какой из подходов, включенных в Naiskshina citeria, разработчики использовали для защиты паролем, наиболее распространенным был подход хеширования данных (продемонстрированный 38% участников, набравших балл, 14% от общей выборки). Чуть менее 20% разработчиков, набравших балл, использовали случайную соль или соответствующую длину хэша (в целом 7%), а остальные баллы по критериям Наякшины присуждались редко.
На самом деле разработчики в исследовании, казалось, не знали о критериях Найскшины или стандарте, лежащем в его основе. По мнению исследователей:
Идеальная спецификация могла бы полностью перечислить критерии в качестве функциональных требований, но она также могла бы быть такой простой, как: “надежно храните пароль, следуя NIST SP 800-63-3”; однако ни один из разработчиков в нашем исследовании не ссылался на какой-либо стандарт в своих спецификациях. Разработчики, казалось, знали, что есть лучшая практика, которой они должны следовать, но, похоже, не искали, что это на самом деле.
Переходя к их третьему вопросу о том, как разработчики обосновали свои реализации, в документе отмечается:
Наш анализ причин, по которым разработчики реализовали хранение паролей таким образом, выявил две интересные подгруппы. Несколько ответов, по-видимому, указывают на то, что разработчики считали, что они сохранили пароли должным образом ([ссылаясь на] опыт, репликацию предыдущих усилий, воспринимаемую передовую практику и принятые во внимание коды); в то время как другие, казалось, знали, что их реализация была ограничена и что они не знали, как это сделать.
Вывод, который я выношу из этого исследования, заключается в том, что, независимо от того, запрашивается или нет, 62% разработчиков не смогли хэшировать, солить или добавить какой-либо механизм безопасности при реализации хранения паролей. Комментируя это, в документе говорится::
Явное побуждение разработчиков написать спецификацию действительно помогает улучшить качество хранения паролей; но разработчики по-прежнему в основном терпят неудачу в хранении паролей, все еще веря, что они делают это правильно. Предоставление разработчикам времени на размышление помогает им осознать ограничения их подхода: но до тех пор, пока у нас нет ориентированных на разработчиков методов хранения паролей, проблема плохо хранимых паролей не исчезнет.