Comments 22
Если это стоит X0000 долларов, то с большой вероятностью оно безопасное. Вот есть N долларов, то менее безопасное. Улавливаете мысль?
Справки пока нет. А что важнее справка о том что безопасное или безопасное, если, например, исключительно для себя использовать?
Для себя, думаю, важнее, чтобы было безопасно. Вопрос, только, как об этом узнать?
Безопасность это хорошо и знать это хорошо, только вот не всем заказчикам объяснишь, что это нужно и платить за это редко кто хочет.
Вот с этим абсолютно согласен.

Но я же не говорю: «все должны делать именно так!». Я говорю: «если вам нужна безопасность, делайте так».

А то, что это стоимость повышает, что это увеличивает время разработки…

Скажу даже больше: не всем это надо Но, если надо…
Пост конечно нужный, совсем не против, только за. Просто, почему-то это не очень котируется и это печально.
Вы мне об этом рассказываете?

А вообще, я тут читал курс и рассказывал, как показываю клиентам стоимость проекта.

Я рисую прямоугольник, одна сторона которого — функциональность программы; другая сторона — ее качество. Безопасность относится к качеству. Стоимость разработки (и, конечно, ее время) будет в площади прямоугольника. А дальше, как скажет заказчик.
Это помогает договориться. А мне это помогает понять, что хочет заказчик.
Много воды — интересны только ссылки в конце. Про ценные советы вроде «тестируйте» и «используйте библиотеки» я промолчу.
Тем не менее, вопросы задают. И цитата из начала статьи: «И, надеюсь, вы убедитесь, что в безопасном программировании нет ничего такого уж необычного.»

На самом деле, для повышения безопасности надо делать очень-очень простые вещи. Надо только их делать.
Кстати, а Вы свои программы тестируете на безопасность? Если да, то как?
Не приходилось, по работе разрабатываю приложения для интранетов, своих проектов, которые бы этого требовали, тоже нет — поэтому тема мне интересна.
Из-за этого и выражаю некоторую разочарованность в статье, которая по-моему опоздала лет на 10-15, когда code review и тестирование было не очень распространено, особенно во всяких буллщит веб-проектах эпохи доткомов. Да, вокруг все еще много людей с галстуками вместо мозгов, кому такие советы не очевидны, есть конторы а-ля «РОСГОВНСОФТ» которые пишут свой php-фреймворк силами студентов за еду и бесплатный чай.
Если бы вы описали те-же методы secure design, со схемами и примерами из тех-же ссылок — была-бы интересная статья. А так похоже на курсовую, которая написана в ночь перед сдачей, уж не обессудьте.
Спасибо Вам большое за отзыв. Мне обратная связь с читателями очень полезна, вероятно, я действительно переупростил статью, и мне об этом даже мои друзья сказали.

Тем не менее, в статье написаны далеко не самые очевидные вещи.

Давайте возьмем, например, тестирование. Когда я в другом месте посоветовал делать его, мне сказали: «а Microsoft так не делает». Действительно, если вы посмотрите книгу по SDL (в моем микрообзоре она под номером 15), то там вы не найдете рекомендации тестировать безопасное поведение. Там есть fuzzing, там есть penetration testing. Но тестирования безопасного поведения — нет. И тогда пришлось разбираться, что мы получаем, внедряя эту практику, что теряем.

Так что, как минимум одна практика, которую Вы считаете очевидной, на деле оказывается спорной.

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

Не очень понятно, что именно Вам нужно. OpenSSL поддерживает формат pkcs12.
Простите за оффтоп.
Она: — А кем вы работаете?
Он: — Программистом систем безопасности данных.
Она: — Ой, это должно быть очень интересно! Все эти ваши асимметричные шифры, односторонние хэш-функции, таблицы подстановок, гаммирование, алгоритм Диффи-Хеллмана! Вы знаете, я в этом ничего не понимаю...
Чтение статьи значительного объема представляет собой дилемму: тема сложная, интересно написанных публикаций по ней немного, а времени — дефицит. Поэтому необходимо тщательно подойти к выбору публикаций для прочтения. По теме безопасности все больше статей, написанных формальным языком, для специалистов, глубоко разбирающихся в вопросе.

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

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

В противном случае, это будет обзор обо всем или ни о чем. И лучше, если примеры будут из практики. Они представляют больший интерес, чем общие соображения и здравый смысл :)
Only those users with full accounts are able to leave comments. Log in, please.