Comments 97
Ну а чего… проблема безопасности — это проблема пользователя, гром не грянет — мужик не перекрестится. Анализ безопасности — это отдельная важная задача, но — которая не имеет отношения к непосредственному функционалу продукта. Очень хорошо, что эта статья появилась.
С одной стороны да, а с другой, сервис авторизации за $100 и $200? Это примерно как выбрать строителя для отделки фасада небоскрёба за $100 и $200. Такие предложения найдутся, и оба неизбежно накосячат, и хорошо если никто не погибнет. Тут больше подходит фраза «Хочешь найти волшебника? Найдёшь сказочника» Скорее это показывает что фриланс биржи не подходят для таких заказов, особенно когда заказчик не обладает нужными знаниями.
Проблемка в том, что нанимая компанию за прайс ×N, вы не застрахованы от того, что внутри неё сидит абсолютно тот же самый контингент. Более того, скорее всего именно так и будет.
Со строительной аналогией так же: нанимаешь подрядную организацию (офис, костюмы, проекты), а она нанимает шабашников с авито.
Более того, с большой вероятностью и сидит. И это большая печаль любой внешней заказной разработки. Я немного в начале карьеры так поработал, да я сделал впечатляющие проекты и мой уровень тогда вырос многократно, но я увидел как это заказывается, как потом эксплуатируется, как работает обратная связь. Нельзя сделать vkontakte, facebook да и любую соц сеть на заказ. А если на самом деле заказывать качество, то получаются монстры типа IBM и прочих интеграторов, которые тоже не гарантируя результата гарантированно сожгут вагон бабла. Поэтому я верю только в собственную инхаус разработку, причём с как минимум одним настоящим технарём в кофаундерах. В ней и работаю.
Нельзя сделать vkontakte, facebook да и любую соц сеть на заказ.
можно, но получатся одноглазнеги
Я немного в начале карьеры так поработал, да я сделал впечатляющие проекты и мой уровень тогда вырос многократно, но я увидел как это заказывается, как потом эксплуатируется, как работает обратная связь.
а я, прежде чем зарегистрировать ООО, устраивался в две местные студии погромистом. В обеих принесли задания с oDesk, плохо переведённые чьей-то родственницей
«использовал для шифрования такие методы, как Base64, MD5, SHA-1» — это вообще не шифрование :-)
UFO just landed and posted this here
Не вся криптография — шифрование: алгоритмы хэширования — не шифрование
> MD5 и SHA-1 какое-никакое, а всё же с намёком на шифрование. Просто одностороннее.
Одностороннее шифрование и хэширование это разные вещи.
Хэширование выдает на выходе хэш, размер которого всегда фиксирован независимо от размера исходных данных. При хэшировании могут быть коллизии — для двух разных паролей на входе будет получен одинаковый хэш на выходе (и соль здесь не поможет). Это очень здорово когда ваш рандомный 22-символьный пароль от банк-клиента имеет тот же хэш, что и пароль 123.
Одностороннее шифрование это просто симметричное шифрование в котором в качестве ключа используется в том или ином виде сам исходный текст (пароль). Размер шифротекста при этом будет пропорционален размеру исходного текста. Никаких коллизий нет.
Одностороннее шифрование и хэширование это разные вещи.
Хэширование выдает на выходе хэш, размер которого всегда фиксирован независимо от размера исходных данных. При хэшировании могут быть коллизии — для двух разных паролей на входе будет получен одинаковый хэш на выходе (и соль здесь не поможет). Это очень здорово когда ваш рандомный 22-символьный пароль от банк-клиента имеет тот же хэш, что и пароль 123.
Одностороннее шифрование это просто симметричное шифрование в котором в качестве ключа используется в том или ином виде сам исходный текст (пароль). Размер шифротекста при этом будет пропорционален размеру исходного текста. Никаких коллизий нет.
UFO just landed and posted this here
> При хэшировании могут быть коллизии
Под словами «могут быть» стоит упомянуть, что для современных алгоритмов хеширования (к примеру, SHA-256) такие коллизии никогда найдены небыли. Математически, вероятность коллизии настолько мала, что ей можно пренебречь.
Под словами «могут быть» стоит упомянуть, что для современных алгоритмов хеширования (к примеру, SHA-256) такие коллизии никогда найдены небыли. Математически, вероятность коллизии настолько мала, что ей можно пренебречь.
>> Математически, вероятность коллизии настолько мала, что ей можно пренебречь.
как раз математически вероятность ОЧЕНЬ велика. Если входные данные для SHA-256 составят 257 бит — даже при идеально-сферическом хеше будет гарантированная коллизия.
А теперь посчитаем в байтах. 256 бит это 64 байта. Если добавить всего 1 байт — то на сообщениях получим 256 коллизий. Добавив 8 байт получим 18 446 744 073 709 551 616 коллизий. От буфера в 72 байта, да.
Число коллизий для килобайта или сотни килобайт — можете попробовать посчитать самостоятельно.
как раз математически вероятность ОЧЕНЬ велика. Если входные данные для SHA-256 составят 257 бит — даже при идеально-сферическом хеше будет гарантированная коллизия.
А теперь посчитаем в байтах. 256 бит это 64 байта. Если добавить всего 1 байт — то на сообщениях получим 256 коллизий. Добавив 8 байт получим 18 446 744 073 709 551 616 коллизий. От буфера в 72 байта, да.
Число коллизий для килобайта или сотни килобайт — можете попробовать посчитать самостоятельно.
К сожалению, это так не работает. Если у нас есть N возможных хэшей (2^256 для SHA256), то каков шанс получить хотя бы одну коллизию имея M случайных хэшей? Или аналогичный вопрос: сколько нужно сгенерировать случайных хэшей, чтобы коллизия произошла с вероятностью P?
Это Generalized birthday probled. Чтобы получить вероятность ~40% коллизии требуется сгенерировать 2^128 хэшей. И это будет коллизия между двумя случайными хэшами. Чтобы найти коллизию с заданным хэшем вам потребуется перебрать еще больше хэшей, что делает перебор практически невозможным.
Это Generalized birthday probled. Чтобы получить вероятность ~40% коллизии требуется сгенерировать 2^128 хэшей. И это будет коллизия между двумя случайными хэшами. Чтобы найти коллизию с заданным хэшем вам потребуется перебрать еще больше хэшей, что делает перебор практически невозможным.
Ну вообще, Base64 сложно назвать шифрованием как таковым. А вот MD5, если солить пароли (со случайной солью), в принципе вполне подойдет.
MD5 — это тоже не шифрование, вот вообще ни разу.
Так я и не говорил, что это шифрование. «Шифрование» и «подходят для хранения паролей» — это как бы разные вещи.
Base64 сложно назвать шифрованием как таковымПочему сложно? Base64 — алгоритм шифрования, который не использует ключ для шифрования и дешифрования информации. Основными преимуществами алгоритма являются скорость, компактность и универсальность :)
Не путайте шифрование (encryption) и кодирование (encoding). Base64 — это алгоритм кодирования (превращения бинарных данных в обычный текст), но никак не шифрования.
Ну пляшущие человечки тоже когда то считались надёжным шифрованием. Кстати является ли сжатие данных шифрованием с вашей точки зрения?
Нет, «пляшущие человечки», как и Base64 никогда не являлись шифрованием. Например, шифрование обязательно требует ключ и обеспечивает целостность данных, когда ни «пляшущие человечки», ни Base64 не умеют это (разве что ASCII armor может защитить целостность Base64 от случайного повреждения).
Я подумал, что цитата, смайлик и описанные мною «преимущества», должны намекать, что я явно не считаю Base64 алгоритмом шифрования. Но оказалось, что в конце недели люди воспринимают вещи «слишком буквально».
Я подумал, что цитата, смайлик и описанные мною «преимущества», должны намекать, что я явно не считаю Base64 алгоритмом шифрования. Но оказалось, что в конце недели люди воспринимают вещи «слишком буквально».
Нет, «пляшущие человечки», как и Base64 никогда не являлись шифрованием.С каких пор наступило это «никогда» для «пляшущих человечков»? (Они ещё были в какой-то мере применением стеганографии.)
Например, шифрование обязательно требует ключ и обеспечивает целостность данных,Ключ у «человечков» есть (это «таблица соответствия» букв и рисунков), а требование целостности откуда взялось? Тогда и «Шифр Цезаря» уже не шифр?
(В русской википедии ссылаются на книгу «Э. Мэйволд. Безопасность сетей.», где это может (?) иметь какой-то смысл. А в английской от шифрования этого не требуют:
Encryption, by itself, can protect the confidentiality of messages, but other techniques are still needed to protect the integrity and authenticity of a message)
С каких пор наступило это «никогда» для «пляшущих человечков»?Base64, как и «пляшущие человечки» это алгоритмы кодирования/подмены символов.
Ключ у «человечков» есть (это «таблица соответствия» букв и рисунков)Это не ключ, а алфавит. У Base64 тоже есть свой алфавит.
а требование целостности откуда взялось?Вы правы, я ляпнул необдуманное. Благодарю за поправку!
Ваши комментарии наводят на мысль, что вы толкуете термин «шифрование» исключительно в его современном понимании. Но исторически «пляшущие человечки» были именно шифром. Собственно, в то время таких понятий, как «кодирование», «целостность» и т.д., еще не существовало, и требование к шифрованию было одно — соблюсти конфиденциальность с высокой степенью надежности.
они могут не являться надежным шифрованием, но в остальном это неважно
XOR - это тоже вполне себе шифрование
Свалить в одну кучу base64 и SHA-1 — это надо постараться.
Равно как и причислять SHA-256 к небезопасным методам хранения паролей. По словарю их, конечно, подобрать проще чем bcrypt, но на практике соленый SHA-256 вполне хорошо работает.
Равно как и причислять SHA-256 к небезопасным методам хранения паролей. По словарю их, конечно, подобрать проще чем bcrypt, но на практике соленый SHA-256 вполне хорошо работает.
… и хорошо параллелится. поэтому — bcrypt, scrypt, PBKDF2 на овермного итераций.
SHA-256 на видеокарте GTX1080TI считается со скоростью 4.4 гигахешей в секунду. Если пароль не полностью случайное число, а хоть как-то удобен для запоминания, его возможно подобрать комбинацией словарей и мутаций.
Мой пароль "cheburek s katyshkami". И не случайное число и запоминается. Найдёте по словарю с мутацией на GTX1080TI?
Скрытый текст
Сисадмин желал подобрать себе стойкий пароль для централизованной авторизации через radius-сервер. Он обратился за советом к Инь Фу Во.
– Как вы думаете, Учитель, пароль "史達林格勒戰役" стойкий?
– Нет, – ответил мастер Инь, – это словарный пароль.
– Но такого слова нет в словарях…
– «Словарный» означает, что это сочетание символов есть в wordlists, то есть «словарях» для перебора, которые подключаются к программам криптоанализа. Эти словари составляются из всех сочетаний символов, которые когда-либо встречались в Сети.
– А пароль «Pft,bcm» подойдёт?
– Вряд ли. Он тоже словарный.
– Но как же? Это же…
– Введи это сочетание в Гугле – и сам увидишь.
Сисадмин защёлкал клавишами.
– О, да. Вы правы, Учитель.
Через некоторое время Сисадмин воскликнул:
– Учитель, я подобрал хороший пароль, которого не может быть в словарях.
Инь Фу Во кивнул.
– Я ввёл его в Гугле, – продолжал Сисадмин, – и убедился, что в Сети такого сочетания нет.
– Теперь есть.
– Как вы думаете, Учитель, пароль "史達林格勒戰役" стойкий?
– Нет, – ответил мастер Инь, – это словарный пароль.
– Но такого слова нет в словарях…
– «Словарный» означает, что это сочетание символов есть в wordlists, то есть «словарях» для перебора, которые подключаются к программам криптоанализа. Эти словари составляются из всех сочетаний символов, которые когда-либо встречались в Сети.
– А пароль «Pft,bcm» подойдёт?
– Вряд ли. Он тоже словарный.
– Но как же? Это же…
– Введи это сочетание в Гугле – и сам увидишь.
Сисадмин защёлкал клавишами.
– О, да. Вы правы, Учитель.
Через некоторое время Сисадмин воскликнул:
– Учитель, я подобрал хороший пароль, которого не может быть в словарях.
Инь Фу Во кивнул.
– Я ввёл его в Гугле, – продолжал Сисадмин, – и убедился, что в Сети такого сочетания нет.
– Теперь есть.
Easy. Всего за 8,24859088481e+12 лет, при допущении, что длинна пароля 21 символ и состоит из алфавита из 27 символов.
А если серьезно, то этот пароль относительно легко подобрать, если использовать сочетание перебора по словарю, вариативность и склеивание раных вариантов.
Почитайте про «brain wallet» биткойн кошельки, как у людей уводили кошельки, к которым использовались пароли посложнее вашего.
А если серьезно, то этот пароль относительно легко подобрать, если использовать сочетание перебора по словарю, вариативность и склеивание раных вариантов.
Почитайте про «brain wallet» биткойн кошельки, как у людей уводили кошельки, к которым использовались пароли посложнее вашего.
UFO just landed and posted this here
В Германии ставка синиор фрилансера ~600 в день. При указанной в статье оплате, любой работающий результат — это уже какое-то чудо. Учитывая то, что за отведенное время нужно еще: получить догступ ко всей среде, разобраться в предыдущим кришнакоде, написать свой кришнакод, как-то все это протестировать, согласовать и задеплоить.
разработчики-фрилансеры по умолчанию придерживаются исключительно небезопасных практик
Не очень понятно, при чем здесь фрилансеры? А разработчики, сидящие в офисе, от таких ошибок застрахованы по умолчанию?
А что вы удивляетесь, на каком сайте ни регаешься, везде: ваш пароль не может привышать 20 символов. Тут либо блочные шифры, либо пишут как есть. Кстати, base64 вполне себе подходит кодировать непечатные символы после шифровки.
Старый советский анекдот.
— Что должен делать молодой специалист за зарплату в 80 рублей?
— Ничего, и даже немножечко вредить
Летела ракета, упала в болото. Какая зарплата — такая работа!
Вообще статья странная. Все смешали в кучу — кодирование, симметричное шифрование, хеширование и при этом еще что-то пытаются вменять фрилансерам.
Вообще, я бы сказал, что не только у фрилансеров проблема с криптографией. По моему опыту большая часть разработчиков не особо разбирается в криптографии. И не потомучто они плохие специалисты, а просто потомучто они никогда не сталкивались с ней и скорее всего никогда не столкнутся. А даже те кто знают что-то, то знают «по-верхам». Банально могут знать, что надо хранить не пароль, а его хеш. Но очень мало знают, например, по каким критериям SHA-1 считается небезопасным, PBKDF2 уже считается более-менее приемлемым, а bcrypt/scrypt — хорошим. Я уж вообще молчу про понимание того для чего действительно нужна соль. Так что заявление, что вот именно фрилансеры и именно веб-разработчики такие плохие и ничего не понимают в криптографии звучит как минимум странно. Я уж вообще молчу, что (судя по ставке) выборка там была далеко не из топовых разработчиков.
Вообще, я бы сказал, что не только у фрилансеров проблема с криптографией. По моему опыту большая часть разработчиков не особо разбирается в криптографии. И не потомучто они плохие специалисты, а просто потомучто они никогда не сталкивались с ней и скорее всего никогда не столкнутся. А даже те кто знают что-то, то знают «по-верхам». Банально могут знать, что надо хранить не пароль, а его хеш. Но очень мало знают, например, по каким критериям SHA-1 считается небезопасным, PBKDF2 уже считается более-менее приемлемым, а bcrypt/scrypt — хорошим. Я уж вообще молчу про понимание того для чего действительно нужна соль. Так что заявление, что вот именно фрилансеры и именно веб-разработчики такие плохие и ничего не понимают в криптографии звучит как минимум странно. Я уж вообще молчу, что (судя по ставке) выборка там была далеко не из топовых разработчиков.
Кстати интересно, если все знают, что это такая распространенная проблема, почему в бд нет специального поля типа «password», которое в себя сразу бы включало и salt, и правильный алгоритм хэширования.
При каждой аутентификации нам нужно вычислять хеш от пароля, который нам прислал пользователь. Вычисление хеша — это достаточно ресурсоемкая здача (вполне реальная ситуация когда вычисление хеша пароля требует 20мб оперативки и пол секунды времени одного ядра). Как мне кажется, нагружать такими вычислениями сервер бд как-то не комильфо.
Плюс случайная ошибка в запросе (забудем по userId отфильтровать например) может привести к фулскану таблички с перевычислением хеша для каждой строчки, что на сколь-нибудь приличной базе пользователей отправит сервер в закат на несколько часов.
Плюс случайная ошибка в запросе (забудем по userId отфильтровать например) может привести к фулскану таблички с перевычислением хеша для каждой строчки, что на сколь-нибудь приличной базе пользователей отправит сервер в закат на несколько часов.
но с другой стороны практически все бд предоставляют различные функции хэширования, вопрос лишь в том, чтобы встроить эту функцию напрямую в поле и добавить соль.
А как вы будете защищаться от того, что ваш запрос с паролем plain text'ом попадет в журнал базы?
Ну и сама эта функция не особа осмысленна из-за нагрузки на сервер бд. Вычисления хешей паролей при более-менее нормальном потоке пользователей просто положат вам сервер.
Ну а то что вычисление хешей есть в бд, так хеши не только для паролей используются, и в других задачах к функциям хеширования могут применяться диаметрально противоположные требования. Плюс возможно сделать запрос «ручками».
Ну и сама эта функция не особа осмысленна из-за нагрузки на сервер бд. Вычисления хешей паролей при более-менее нормальном потоке пользователей просто положат вам сервер.
Ну а то что вычисление хешей есть в бд, так хеши не только для паролей используются, и в других задачах к функциям хеширования могут применяться диаметрально противоположные требования. Плюс возможно сделать запрос «ручками».
Знать что такое хэш, соль и для чего они в общих чертах нужны — это и есть «по верхам». Уж если этого не знать — это значит не знать вообще ничего.
Ну вот те кто знают зачем соль и хеши «в общих чертах нужны» и используют SHA-1 и общую соль на всю бд. Ну и до кучи соль примешивают конкатенацией пароля к концу соли.
Ну и строго говоря, что считать за «вообще ничего», а что за «в общих чертах» — это вопрос терминологии. Реальность в том, что большая часть знакомых мне разработчиков сходу не увидят проблем в вышеописанном способе хеширования паролей, а как уж это назвать — дело десятое.
Ну и строго говоря, что считать за «вообще ничего», а что за «в общих чертах» — это вопрос терминологии. Реальность в том, что большая часть знакомых мне разработчиков сходу не увидят проблем в вышеописанном способе хеширования паролей, а как уж это назвать — дело десятое.
А зачем это вообще делать вручную? Есть же специальные библиотеки для этого.
Кроме того кругом читаю, мол "не пытайтесь самостоятельно реализовывать криптографию, и даже вместе собирать готовые части то же не пытайтесь".
Именно. В Java так хэширование делается вообще в одну строчку (в примере использую Spring, есть другие библиотеки в которых примерно то же самое):
import org.springframework.security.crypto.bcrypt.BCrypt;
....
final String hash = BCrypt.hashpw(password, BCrypt.gensalt(10));
...
final boolean isCorrect = BCrypt.checkpw(password, hash);
Ну а теперь вопросы: Почему bcrypt, а не какой-то другой алгоритм? Какой cost будет использоваться для вычисления хеша и почему именно такой, а не другой (а это важно, ибо определяет криптостойкость)? Каков размер соли и почему именно такой? Какие ограничения на размер пароля?
Я это все к чему — использование криптобиблиотек — это хорошо и правильно, но это не отменяет того, что неплохо бы понимать что именно этот код делает и как это соотносится с тем, что требуется сделать (разумеется не нужно знать реализацию самого шифрования, но вот контракты знать стоит). А то ведь можно использовать стойкий алгоритм, но использовать его с такими параметры, что окажется не сильно безопаснее SHA-1.
Я это все к чему — использование криптобиблиотек — это хорошо и правильно, но это не отменяет того, что неплохо бы понимать что именно этот код делает и как это соотносится с тем, что требуется сделать (разумеется не нужно знать реализацию самого шифрования, но вот контракты знать стоит). А то ведь можно использовать стойкий алгоритм, но использовать его с такими параметры, что окажется не сильно безопаснее SHA-1.
Я это все к чему — использование криптобиблиотек — это хорошо и правильно, но это не отменяет того, что неплохо бы понимать что именно этот код делает и как это соотносится с тем, что требуется сделать
Вот с этим полностью согласен. Хотя, замечу, дефолтные параметры в том же PHP вполне пригодны для обычных сайтов и приложений. Если же у приложения какие-то специфические требования к хэшированию паролей — то разработчик обязан их учесть.
Тут ещё дело может быть во времени. Те параметры, которые считаются оптимальными сейчас могут быть недостаточно безопасными пару лет спустя. А делать перехеширование — это просто адская боль. Но в целом тоже соглашусь, что дефолтовые настройки в подобного рода библиотеках актуальных версий более-менее адекватные.
Ну реализовывать самому какой-нибудь scrypt конечно не надо. Но вот выбрать размер соли и способ ее генерации, а так же алгоритм хеширования и его параметры придётся все-таки самому.
если выдавали бы изначально правильное чётко ограниченное тз, то и получили бы всё что желается, но тогда и цены изначально поднять пришлось бы, вслед за заявленым уровнем качества; а в таком варианте этот эксперимент выглядит как «проверка на вшивость», только инициатор такой проверки — обычно «вшивый» сам;
шифрование — это очень такое широкое и растяжимое понятие, для кого-то и запись символов в обратном порядке — тоже шифрование; надо внятно и точно объяснять, чего надо и хочется, а не пытаться найти дурака, который гривенник разменяет по рублю;
«сделайте хорошо» — это не тз, это либо свойская частная просьба, либо откровенная подйопка;
шифрование — это очень такое широкое и растяжимое понятие, для кого-то и запись символов в обратном порядке — тоже шифрование; надо внятно и точно объяснять, чего надо и хочется, а не пытаться найти дурака, который гривенник разменяет по рублю;
«сделайте хорошо» — это не тз, это либо свойская частная просьба, либо откровенная подйопка;
UFO just landed and posted this here
Вообще, хороший разработчик должен ответить что реализация по такому недетализированному ТЗ должна начинаться с согласования спецификации и стоить этот первый этап будет столько-то. Вполне возможно что часть отказов (согласились только 43 из 260) и содержали подобные формулировки.
Так там же "разработать систему регистрации для… социальной сети".
Получается, в ТЗ заказчик должен написать всё подробно, в том числе, что пароль пользователя необходимо:
— Хранить как CHAR, а не как INT.
— Передать методом POST, а не GET.
— Хешировать, а не шифровать.
Скорее всего ещё придётся указать, что если пользователь будет ввести неверный пароль, то не нужно его авторизовать. И конечно, что необходимо обезопасить приложение от SQL-инъекций и CSRF-атак.
— Хранить как CHAR, а не как INT.
— Передать методом POST, а не GET.
— Хешировать, а не шифровать.
Скорее всего ещё придётся указать, что если пользователь будет ввести неверный пароль, то не нужно его авторизовать. И конечно, что необходимо обезопасить приложение от SQL-инъекций и CSRF-атак.
Желательно да. У данного исследования много проблем, на мой взгляд. Оно крайне низко оплачивается для европейского рынка, и содержит плохопроработанное тз. Хороший разработчик, несомненно, использует защиту от инъекций, CSRF, правильное шифрование с солью, проверку на уникальность логина\почты используемых для авторизации, защиту от массовых регистраций ботов, капчу, подтверждение регистрации через email\смс, кнопку быстрой регистрации через гугл\стим\etc… Но после того, как обсудит с заказчиком что из всего этого действительно надо, и после пересмотра суммы вознаграждения в 2-5 раз. Поскольку работа по «запилить формочку авторизации» и «сделать полноценный, защищённый инструмент авторизации с защитой и удобствами» — сильно отличаются по требуемому уровню разработчика и затраченному на задачу времени. А, да, мы ещё забыли обсудить, какую нагрузку должен держать сервис авторизации! Будем ориентироваться на горизонтальное масштабирование сразу? А как насчёт GDPR, удобный механизм удаления данных о себе для пользователя предусматривать?
ЗЫ: Что-то мне подсказывает, что те, кто отказался от выполнения работы, как раз и были нормальными специалистами, с которыми не захотели обсуждать требования и повышенное вознаграждение, а говно на скорую руку они сделать не пожелали.
ЗЫ: Что-то мне подсказывает, что те, кто отказался от выполнения работы, как раз и были нормальными специалистами, с которыми не захотели обсуждать требования и повышенное вознаграждение, а говно на скорую руку они сделать не пожелали.
Лично я всегда думал, что есть вещи, которые не нуждаются в ТЗ. Например, затяжка колёсных болтов, хеширование паролей, использование метода POST для передачи конфиденциальных данных, и так далее.
Например, заменить
Например, заменить
base64_encode() на password_hash() ничего не стоит (наоборот, даже сократит время разработки). И поверьте, стоимость работы никак не влияет на профессионализм разработчика. Если человек говорит, что «очень сложно расшифровать Base64», можете заплатить ему хоть миллион, от этого он не перестанет «шифровать пароли с помощью Base64» или хранить их как обычный текст. Достаточно взглянуть на крупные корпорации, которые забывают, как правильно хранить пароли и сразу становиться ясно, что проблема скорее всего не в деньгах.Формально, хешированием паролей евляется substring вырезающий первую половину пароля. Только качество такого хеширования ниже плинтуса. Понятно, что специалист, который дорожит своей репутацией такую хрень не напишет. Но в статье-то рассмотрены низкооплачиваемые ноунеймы.
Чем менее професионален исполнитель, тем более подробное ТЗ ему нужно, чтобы выдавать приличный результат.
Чем менее професионален исполнитель, тем более подробное ТЗ ему нужно, чтобы выдавать приличный результат.
Проблема в том, что «низкооплачиваемые ноунеймы» охотно откликаются и на проекты с большим бюджетом. Если исследователи заплатили бы больше, это привело бы к увеличению числа исполнителей, но минимум 8 из них всё ещё использовали бы Base64. Думаю, стоимость работы не играет самой важной роли, иначе из 43 фрилансеров все бы использовали Base64, а не только 8 из них.
Поэтому, Вы должны задаваться следующим вопросом: почему большинство фрилансеров за те же условия (деньги и ТЗ) использовали правильные алгоритмы, а некоторые нет.
Поэтому, Вы должны задаваться следующим вопросом: почему большинство фрилансеров за те же условия (деньги и ТЗ) использовали правильные алгоритмы, а некоторые нет.
есть опытные программисты с большим опытом фриланса. за такие деньги вряд ли откликнувшиеся.
есть опытные программисты, но как фрилансеры только начинают. вполне могут откликнуться и сделать либо хорошо либо "срого по ТЗ"
а есть начинающие программисты и "люди с улицы" ;) с ними либо никак либо с подсказки кто-то из них сможет что-то сделать
Почему Вы думаете, что опытные программисты не хотят получить, скажем, €200 за пару часов работы и хороший проект для своего портфолио?
Дело в том, что опытному программисту не нужны несколько дней, чтобы имплементировать процесс регистрации в готовом проекте. Например, первый фрилансер сдал работу через 21 часов, но он хранил пароли как обычный текст. Когда его попросили защитить пароли, ему потребовалось 38 часов, чтобы сделать это (для сравнения, один из фрилансеров перешёл на BCrypt всего за 4 минуты). Разве это не говорит о том, что задача была довольно проста для опытного разработчика?
Дело в том, что опытному программисту не нужны несколько дней, чтобы имплементировать процесс регистрации в готовом проекте. Например, первый фрилансер сдал работу через 21 часов, но он хранил пароли как обычный текст. Когда его попросили защитить пароли, ему потребовалось 38 часов, чтобы сделать это (для сравнения, один из фрилансеров перешёл на BCrypt всего за 4 минуты). Разве это не говорит о том, что задача была довольно проста для опытного разработчика?
38 часов?! Что можно делать 38 часов (практически рабочую неделю) для добавления хэширования? Собственную хэш-функцию реализовывать?
Было бы забавно, если бы он реализовал новый алгоритм, а исследовали, пытаясь высмеять его, обнаруживали бы, что алгоритм очень крут.
Например решил разобраться в вопросе хеширования паролей: почитать несколько статей на эту тему, поисследовать best/bad practice, посмотреть какие есть алгоритмы и в чем между ними разница. Поискать готовые библиотеки и подобрать подходящую.
Если человек никогда не сталкивался с хранением паролей, то примерно рабочая неделя и уходит на вникание в тему. Можно, конечно, и просто скопировать код из первой попавшейся ссылки на stack overflow, но тогда и результат может получиться соответствующий.
Если человек никогда не сталкивался с хранением паролей, то примерно рабочая неделя и уходит на вникание в тему. Можно, конечно, и просто скопировать код из первой попавшейся ссылки на stack overflow, но тогда и результат может получиться соответствующий.
опытные программисты-фрилансеры чаще всего заняты «на год вперёд» :) и я не отрицал того, что не откликнутся, а написал «вряд ли», имея в виду в том числе и их загруженность.
Второй случай, про 4 минуты, как раз подтверждает тезис «строго по ТЗ» :)
Ну и 38 часов тоже не особо показатель :) может, 37 с половиной часов он занимался другим проектом (за 2000 евро), а эту задачку оставил напоследок…
а вообще: «правильное ТЗ — половина дела»
Второй случай, про 4 минуты, как раз подтверждает тезис «строго по ТЗ» :)
Ну и 38 часов тоже не особо показатель :) может, 37 с половиной часов он занимался другим проектом (за 2000 евро), а эту задачку оставил напоследок…
а вообще: «правильное ТЗ — половина дела»
А я всегда думал, что по-настоящему «опытные программисты-фрилансеры» никогда не заняты ;)
Насчёт ТЗ, я уже сказал своё мнение — профессионал должен сделать всё правильно, даже если заказчик ничего в этом не понимает или указал в ТЗ «ЧТО» делать, но не указал «КАК» это делать. Например, если у Вас есть заказ на вёрстку сайта, Вы ведь не будете использовать иконки в формате BMP по 99МБ каждая, даже если заказчик ничего не указал об этом в ТЗ. Также, я уверен, что Вы не будете тестировать результат только в одном браузере.
При необходимости профессионал должен описывать несколько сценариев и позволить заказчику выбрать то, что ему подходит. Более того, если заказчик указал в ТЗ, что необходимо применить плохое решение, профессионал должен донести это до заказчика.
И это касается не только программистов, но и всех специалистов, включая механиков, врачей, сантехников, строителей и других.
Насчёт ТЗ, я уже сказал своё мнение — профессионал должен сделать всё правильно, даже если заказчик ничего в этом не понимает или указал в ТЗ «ЧТО» делать, но не указал «КАК» это делать. Например, если у Вас есть заказ на вёрстку сайта, Вы ведь не будете использовать иконки в формате BMP по 99МБ каждая, даже если заказчик ничего не указал об этом в ТЗ. Также, я уверен, что Вы не будете тестировать результат только в одном браузере.
При необходимости профессионал должен описывать несколько сценариев и позволить заказчику выбрать то, что ему подходит. Более того, если заказчик указал в ТЗ, что необходимо применить плохое решение, профессионал должен донести это до заказчика.
И это касается не только программистов, но и всех специалистов, включая механиков, врачей, сантехников, строителей и других.
ТЗ — это продукт договренности заказчика и исполнителя. И на его составление может уйти немало времени, в зависимости от его детальности. Вполне нормальная ситуация, когда заказчик сначала заказывает у исполнителя ТЗ, а потом уже по этому ТЗ происходит работа. Но в реалиях проектов за 200 баксов так обычно никто не делает, а потом заказчики удивляются, что получилось вовсе не то чего они хотели.
Я бы не сказал, что штатные сотрудники — это однозначное решение проблем. В последнее время кажется, что довольно много проектов реализуются людьми, которые вообще не понимают, что и зачем они делают.
Ленивый поиск уязвимостей в системах, которые показались относительно интересными за последние пару месяцев, дал пугающие результаты:
А) Люди массово считают четырехзначный СМС-код надежным способом авторизации.
Б) Чуть меньшее количество людей просто не проверяет число попыток. 10000 попыток ввода четырехзначного кода — пожалуйста. Хотя одна компания выставила ограничение в 500 попыток, которое потом убрала.
Это встречается как у тех сервисов, где вообще не ожидаешь безопасной разработки хоть какого-то уровня (кодер что-то выдал, это не падает с ошибками — премию ему), так и у довольно серьезных организаций: начиная от различных элитных и не очень доставок еды, чатиков, систем управления службами такси, заканчивая сервисами телемедицины, банками, авиакомпаниями и мобильными операторами.
Пугает то, что в такой ситуации никто из псевдо-инженеров: кодеры, тимлиды, тестировщики, безопасники (да, у некоторых из этих компаний есть безопасники), не задавался вопросом, зачем вообще они делают авторизацию. Немного боюсь того, что они выдадут в следующий раз.
Ленивый поиск уязвимостей в системах, которые показались относительно интересными за последние пару месяцев, дал пугающие результаты:
А) Люди массово считают четырехзначный СМС-код надежным способом авторизации.
Б) Чуть меньшее количество людей просто не проверяет число попыток. 10000 попыток ввода четырехзначного кода — пожалуйста. Хотя одна компания выставила ограничение в 500 попыток, которое потом убрала.
Это встречается как у тех сервисов, где вообще не ожидаешь безопасной разработки хоть какого-то уровня (кодер что-то выдал, это не падает с ошибками — премию ему), так и у довольно серьезных организаций: начиная от различных элитных и не очень доставок еды, чатиков, систем управления службами такси, заканчивая сервисами телемедицины, банками, авиакомпаниями и мобильными операторами.
Пугает то, что в такой ситуации никто из псевдо-инженеров: кодеры, тимлиды, тестировщики, безопасники (да, у некоторых из этих компаний есть безопасники), не задавался вопросом, зачем вообще они делают авторизацию. Немного боюсь того, что они выдадут в следующий раз.
Если на каждую попытку ввода отправляется новое смс, и присутствует минута-две с обратным отсчётом до повторной попытки — то уровень защиты удовлетворительный. Особенно если код в смс — это 2FA после ввода логина и пароля. Но, конечно, случаи бывают разные…
Вы описали авторизацию очень высокого качества. Я был бы рад (или нет) чаще встречать такое. Пара популярных проблем, которая встречается у более качественных реализаций:
* Перед новой попыткой ввода (хотя обычно перед набором попыток, от 3 до 75 (!)) отправляется новое СМС, правда можно спокойно запрашивать по 200 СМС в минуту.
* Обратный отсчёт есть, но он только на фронтенде. Перехватил трафик — радуешься жизни.
* Продвинутый баг: новое СМС не отправляется из-за ограничения на число СМС в минуту, но счётчик проверок обнуляется: слепой брутфорс, плюс он менее заметный для жертвы.
* Перед новой попыткой ввода (хотя обычно перед набором попыток, от 3 до 75 (!)) отправляется новое СМС, правда можно спокойно запрашивать по 200 СМС в минуту.
* Обратный отсчёт есть, но он только на фронтенде. Перехватил трафик — радуешься жизни.
* Продвинутый баг: новое СМС не отправляется из-за ограничения на число СМС в минуту, но счётчик проверок обнуляется: слепой брутфорс, плюс он менее заметный для жертвы.
главное не испортить всё передачей и хранением пароля в текстовом виде :)
В последнее время кажется, что довольно много проектов реализуются людьми, которые вообще не понимают, что и зачем они делают.
«Из-за конфиденциальности моей работы я понятия не имею, что делаю» ©
Что почитать по шифрованию (симметричное, асимметричное, хэширование)?
Есть инструкция, пошаговый аглоритм для вредрения шифрования?
Есть инструкция, пошаговый аглоритм для вредрения шифрования?
Хорошо бы еще написать статью по поводу как того нужно делать и почему.
Не удивлюсь, что у 90% при этом отсутствует https и пароль передаётся как есть с клиента
Программисты, которые зашифровали пароли, использовали небезопасные методы: 31 программист использовал для шифрования такие методы, как Base64, MD5, SHA-1 и т. д.
Вообще-то MD-5, SHA-1, как и SHA-256 и другие и иже с ними российские stribog-и это хэш функции и ничего зашифровать они не могут. Можно конечно говорить, что из пароля получим хэш и именно он будет паролем. Но это… Вопрос-то остается открытым как зашифровать? А дальше, зашифруем на каком-то ключе. А как ключ спрятать? Опять шифровать будем. Авторизоваться, на мой взгляд, оптимально на сертификата, хранимом на токене PKCS#11. Да и просто пароль можно хранить на флэшке, хранимой в кармане.
Да, и Base64 тоже ничего не шифрует, просто переводит в текстовый вид. Примените обратную операцию и получите исходный пароль.
Наличие соли хеша существенно усложняет брутфорс? С чего вдруг? Подбор по словарю — усложняет, да
Возможно, имеется в виду, что для того чтобы взломать соленый хеш, сначала нужно найти соль.
Усложняет т.к. вычисление хэша соленого пароля требует значительно больших вычислительных ресурсов, чем несоленого.
Плюс соль делает невозможным массовый брутфорс (когда мы имеем 100500 хэшей, перебираем пароли и смотрим с каким из имеющихся хэшей он совпал)
Плюс соль делает невозможным массовый брутфорс (когда мы имеем 100500 хэшей, перебираем пароли и смотрим с каким из имеющихся хэшей он совпал)
Что-то непонятно, а что хотели от разработчиков с прайсом 100-200$ за 1-8 дней?
Sign up to leave a comment.
Веб-разработчики пишут небезопасный код по умолчанию