Компромисс безопасность/удобство, по сути ложный компромисс. Потому что, увеличить удобство, можно многими путями. И повысить безопасность тоже можно по разному.
И вот, если разработчик выберет тот способ повышения безопасности, который уменьшает удобство, то это компромисс. Но ведь, можно выбрать и способ, который не уменьшает удобство. Тогда и компромисса не будет.
Выходит, что все в руках разработчика. Если он убежден, что высокая безопасность всегда неудобна, то так и будет. А если думает головой и выбирает правильные способы повышения безопасности, то удобство никак не пострадает.
К тому же, неудобная система сама по себе менее безопасна, потому что потребитель активно сопротивляется, а он умный. Пример обсудили наверх – ограничения на пароль – пользы ноль, а удобство пострадало, потребитель недоволен. Но правда, выглядит «безопасно». Только выглядит.
Все это весело, но по сути неверно. Потому что директор ресторана просто заменит солонки на одноразовых пакетиках соли/перца. И будет, кстати, их продавать. А по охранительных камерах, «хакера» возьмут примерно на шестого, седьмого дня.
Это не так. Заводить детей можно всегда. И дети и родители счастливы совсем не из за миллионов родителей. Знаю, что трудно поверить, но это именно так.
В обсуждение на Хабре тоже самое написали сразу. И я с этим согласен. Нельзя зажать две половинки смартфона струбцинами и ожидать что шарнир не будет деформироваться на каждом сгибе. Даже странно что выдержал 27000 циклов.
С автором согласен на 100%. Даже скажу еще – некоторые разработчики идут дальше и путают неудобство с безопасностью. То есть, думают, что если сделают просто неудобно, то безопасность повыситься сама собой.
Например, многие думают что ограничения пароля (т.н. password policy) увеличивает безопасность. Но это совершенно не так! Всякое ограничение состава пароля, только уменьшает безопасность. Оно просто неудобно и поэтому выглядит безопасней.
А потребители, конечно очень быстро придумывают словарьные пароли, которые отвечают всем требованиям.
То же самое с листочкам. По сути, записать сложный пароль на бумаге не так уж и плохо. Плохо, если люди не ценят этого листочка и вешают его на мониторе. А так, люди довольно хороши в сохранении бумажных листочках в тайне. Если видят в этом смысл.
Ну-у-у, мне вообще-то нужна статья «для профессионалов», а не «для школьников». А автор, получает взамен популярность своей библиотеки. Все справедливо.
которая несёт гораздо больше пользы, чем бОльшая часть публикаций за день вместе взятых.
С этим нельзя не согласится. Поэтому я и плюсанул и статью и карму автора.
А тот факт, что Вам не разжевали и в рот не положили объясняется просто: это НЕ учебная статья, а заметка от профессионала для профессионалов.
А с этим согласится уже нельзя. Для заметки есть твитер и редит. На Хабре пишут именно статьи где объясняют. Такую статью тоже можно написать "для профессионалов". А можно написать и для школьников. Это как раз зависит от автора.
Рассматриваемые методы не новы и описаны в диссертации по ссылке и других гуглимых ресурсах.
Диссертация это содержит 183 страниц текста на академическом английском. И вы предлагаете нам прочитать ее, чтобы понять как работает 500 строк кода на C.
Нет, я понимаю, что это будет очень полезно для моего роста как программиста, но доступное и простое объяснение принципов (а не высокого академичного стиля) думаю будет очень полезно для аудитории хабра.
потому что их средний случай сильно уступает среднему случаю популярных сегодня алгоритмов (например, dlmalloc)
А насколько сильно? Хотя бы приблизительно на глаз? Делались ли некие тесты и измерения?
А какие недостатки данного подхода? Почему все менажеры динамической памяти не использует этот алгоритм?
И вообще, главный недостаток статьи, это то, что не объяснено как все это работает. Конечно, код (при этом небольшой!) это прекрасно, но объяснение как это работает и почему сделано так, а не по другому многим понравится и повысит читаемость статьи.
То что не улучшит ясно. Но и не уменьшит же! А еще уменьшит раздраженность пользователя от ненужных ограничений. И еще, это никак не вредит – пароль никуда не записывается так или иначе. И код обработки пароля будет меньше, а значит меньше вероятности багов. вин-вин.
Вам просто ещё не попадались люди которые пытаются в качестве пароля отправить строку в пару килобайт, причём иногда даже с кодами ниже пробела — отсюда и ограничения.
А в чем проблема??? Включительно с кодами ниже пробела. Нормальный софт должен обрабатывать такое нормально. И если пароль совпадает, просто предоставить доступ.
Вообще, даже для людей, необходимость ограничивать содержание пароля очень спорна.
Потому что требования выполняются (обманываются) просто, а проконтролировать сложно. Например пароль "Qwer12!@" выполняет все требования, но не безопасен.
По мне, намного лучше никаких ограничении не ставить, а людей обучить придумывать пароли такие что легко запоминаются, а трудно отгадываются.
А кто выбрасывает? Я просто считаю, что считать лекции сугубо аудио-видео и из этого делать выводы что видео/аудио учебники лучше чем текстовые абсолютно неправильно.
Лекции, дело вообще сложное и многогранное. Я бы сказал, что лекция – это по идее общение. Иногда получается, а иногда нет.
Компромисс безопасность/удобство, по сути ложный компромисс. Потому что, увеличить удобство, можно многими путями. И повысить безопасность тоже можно по разному.
И вот, если разработчик выберет тот способ повышения безопасности, который уменьшает удобство, то это компромисс. Но ведь, можно выбрать и способ, который не уменьшает удобство. Тогда и компромисса не будет.
Выходит, что все в руках разработчика. Если он убежден, что высокая безопасность всегда неудобна, то так и будет. А если думает головой и выбирает правильные способы повышения безопасности, то удобство никак не пострадает.
К тому же, неудобная система сама по себе менее безопасна, потому что потребитель активно сопротивляется, а он умный. Пример обсудили наверх – ограничения на пароль – пользы ноль, а удобство пострадало, потребитель недоволен. Но правда, выглядит «безопасно». Только выглядит.
Все это весело, но по сути неверно. Потому что директор ресторана просто заменит солонки на одноразовых пакетиках соли/перца. И будет, кстати, их продавать. А по охранительных камерах, «хакера» возьмут примерно на шестого, седьмого дня.
Это не так. Заводить детей можно всегда. И дети и родители счастливы совсем не из за миллионов родителей. Знаю, что трудно поверить, но это именно так.
Да. Потому что когда люди складывают/раскладывают Razr, они не нагружают шарнир на растяжение.
В обсуждение на Хабре тоже самое написали сразу. И я с этим согласен. Нельзя зажать две половинки смартфона струбцинами и ожидать что шарнир не будет деформироваться на каждом сгибе. Даже странно что выдержал 27000 циклов.
qw1!Qwer — чем не словарьный?
С автором согласен на 100%. Даже скажу еще – некоторые разработчики идут дальше и путают неудобство с безопасностью. То есть, думают, что если сделают просто неудобно, то безопасность повыситься сама собой.
Например, многие думают что ограничения пароля (т.н. password policy) увеличивает безопасность. Но это совершенно не так! Всякое ограничение состава пароля, только уменьшает безопасность. Оно просто неудобно и поэтому выглядит безопасней.
А потребители, конечно очень быстро придумывают словарьные пароли, которые отвечают всем требованиям.
То же самое с листочкам. По сути, записать сложный пароль на бумаге не так уж и плохо. Плохо, если люди не ценят этого листочка и вешают его на мониторе. А так, люди довольно хороши в сохранении бумажных листочках в тайне. Если видят в этом смысл.
web 3.0 — выбрасываем html/css/js, а оставляем только микроразметку. Google рендирует содержание для посетителей.
web 4.0 — выбрасываем и микроразметку – google лучше нас знает что нужно посетителю.
Ну-у-у, мне вообще-то нужна статья «для профессионалов», а не «для школьников». А автор, получает взамен популярность своей библиотеки. Все справедливо.
С этим нельзя не согласится. Поэтому я и плюсанул и статью и карму автора.
А с этим согласится уже нельзя. Для заметки есть твитер и редит. На Хабре пишут именно статьи где объясняют. Такую статью тоже можно написать "для профессионалов". А можно написать и для школьников. Это как раз зависит от автора.
Диссертация это содержит 183 страниц текста на академическом английском. И вы предлагаете нам прочитать ее, чтобы понять как работает 500 строк кода на C.
Нет, я понимаю, что это будет очень полезно для моего роста как программиста, но доступное и простое объяснение принципов (а не высокого академичного стиля) думаю будет очень полезно для аудитории хабра.
А насколько сильно? Хотя бы приблизительно на глаз? Делались ли некие тесты и измерения?
А какие недостатки данного подхода? Почему все менажеры динамической памяти не использует этот алгоритм?
И вообще, главный недостаток статьи, это то, что не объяснено как все это работает. Конечно, код (при этом небольшой!) это прекрасно, но объяснение как это работает и почему сделано так, а не по другому многим понравится и повысит читаемость статьи.
Так это работает именно потому что кому то в голове возникла идея, что позитивная дискриминация это хорошо и справедливо.
То что не улучшит ясно. Но и не уменьшит же! А еще уменьшит раздраженность пользователя от ненужных ограничений. И еще, это никак не вредит – пароль никуда не записывается так или иначе. И код обработки пароля будет меньше, а значит меньше вероятности багов. вин-вин.
А в чем проблема??? Включительно с кодами ниже пробела. Нормальный софт должен обрабатывать такое нормально. И если пароль совпадает, просто предоставить доступ.
Только дело в том, что дискриминация в головах, а не в словах.
Вообще, даже для людей, необходимость ограничивать содержание пароля очень спорна.
Потому что требования выполняются (обманываются) просто, а проконтролировать сложно. Например пароль "Qwer12!@" выполняет все требования, но не безопасен.
По мне, намного лучше никаких ограничении не ставить, а людей обучить придумывать пароли такие что легко запоминаются, а трудно отгадываются.
Пароль на который наложили ограничения, намного хуже, чем полностью рандомный пароль. Ограничения нужны только когда люди придумывают себе пароли.
Я бы хотел чтобы закладки были сделаны в форме плагина. Чтобы можно было его не устанавливать.
А кто выбрасывает? Я просто считаю, что считать лекции сугубо аудио-видео и из этого делать выводы что видео/аудио учебники лучше чем текстовые абсолютно неправильно.
Лекции, дело вообще сложное и многогранное. Я бы сказал, что лекция – это по идее общение. Иногда получается, а иногда нет.