«Если хотите, я могу зашифровать пароли»
Некоторые разработчики, которым дали прямое указание применить криптографию, использовали шифрование парольной базы с помощью Base64
Когда в СМИ появляется информация об очередной утечке данных, всегда вызывает недоумение, почему компания хранила пароли пользователей открытым текстом, не защитила API или сделала какую-то другую элементарную ошибку. Неужели в наше время возможно такое нарушение правил безопасности?
Новое исследование из Университета Бонна (Германия) показывает, что разработчики-фрилансеры по умолчанию придерживаются исключительно небезопасных практик, если только заказчик не требует большего.
Исследователи предложили 260 Java-разработчикам на Freelancer.com разработать систему регистрации для воображаемой социальной сети, которую заказчики якобы начинали делать. Из них только 43 согласились на заказ, который предусматривал использование технологий Java, JSF, Hibernate и PostgreSQL
Половина разработчиков получила за работу 100 евро, а половина — 200 евро. Половине каждой из двух групп дали указания использовать защищённое хранилище паролей, другим — нет.
Хотя выборка явно мала, но разница настолько значительная, что она позволяет предположить некие общие тенденции. Вот некоторые результаты исследования:
- Среди тех, кому не были предоставлены инструкции, 15 из 18 хранили пароли открытым текстом
- Три человека из тех, кому поручили использовать защищённое хранилище, также хранили свои пароли в виде открытого текста.
- Программисты, которые зашифровали пароли, использовали небезопасные методы: 31 программист использовал для шифрования такие методы, как Base64, MD5, SHA-1 и т. д.
- Только 12 фрилансеров применили безопасные методы, такие как bcrypt и PBKDF2.
8 человек использовали для шифрования Base64
10 – MD5
1 – SHA-1
3 – 3DES
3 – AES
5 – SHA-256
1 – HMAC/SHA1
5 – PBKDF2
7 – Bcrypt
В таблице внизу (увеличивается по клику) приведены полные результаты по каждому участнику: сколько дней ему потребовалось на выполнение задания, сколько из этого времени он потратил на реализацию безопасности и какой алгоритм шифрования применил. В верхней половине таблицы те, кому дали прямое указание зашифровать информацию. Жирным выделены участники, которые сначала прислали небезопасное решение, но потом получили дополнительное указание реализовать защищённое хранилище паролей.
В подавляющем большинстве программисты не смогли реализовать основные методы безопасности, а 17 из 43 скопировали код со случайных веб-сайтов.
Только 15 разработчиков применили соль — строку данных, которая передаётся хеш-функции вместе с паролем, что существенно усложняет брутфорс.
В таблице (можно увеличить по клику) показаны демографические данные участников исследования. Как видим, в основном это мужчины, средний возраст 30 лет, из 11 стран (в двух случаях страна не указана)
Низкооплачиваемые и высокооплачиваемые группы сработали примерно на одном уровне качества.
В целом исследование довольно удручает. Можно предположить, что базовая осведомлённость о безопасности среди фрилансеров невероятно низка. Из 18 участников, которые получили специальные указания использовать криптографию, трое решили использовать Base64 и утверждали, например: «[Я] всё зашифровал, так что пароль не виден» и «Его очень сложно расшифровать».
Возможно, такое поведение специфично только для фрилансеров, а штатные сотрудники без посторонних указаний сразу стараются сделать безопасное решение? Исследование не даёт ответа на этот вопрос.
Комментарии (85)
Aquahawk
25.04.2019 11:51+5С одной стороны да, а с другой, сервис авторизации за $100 и $200? Это примерно как выбрать строителя для отделки фасада небоскрёба за $100 и $200. Такие предложения найдутся, и оба неизбежно накосячат, и хорошо если никто не погибнет. Тут больше подходит фраза «Хочешь найти волшебника? Найдёшь сказочника» Скорее это показывает что фриланс биржи не подходят для таких заказов, особенно когда заказчик не обладает нужными знаниями.
dom1n1k
25.04.2019 13:06Проблемка в том, что нанимая компанию за прайс ?N, вы не застрахованы от того, что внутри неё сидит абсолютно тот же самый контингент. Более того, скорее всего именно так и будет.
radtie
25.04.2019 13:25+1Со строительной аналогией так же: нанимаешь подрядную организацию (офис, костюмы, проекты), а она нанимает шабашников с авито.
Aquahawk
25.04.2019 15:14Более того, с большой вероятностью и сидит. И это большая печаль любой внешней заказной разработки. Я немного в начале карьеры так поработал, да я сделал впечатляющие проекты и мой уровень тогда вырос многократно, но я увидел как это заказывается, как потом эксплуатируется, как работает обратная связь. Нельзя сделать vkontakte, facebook да и любую соц сеть на заказ. А если на самом деле заказывать качество, то получаются монстры типа IBM и прочих интеграторов, которые тоже не гарантируя результата гарантированно сожгут вагон бабла. Поэтому я верю только в собственную инхаус разработку, причём с как минимум одним настоящим технарём в кофаундерах. В ней и работаю.
vilgeforce
25.04.2019 11:51+2«использовал для шифрования такие методы, как Base64, MD5, SHA-1» — это вообще не шифрование :-)
mikechips
25.04.2019 19:17Ну, MD5 и SHA-1 какое-никакое, а всё же с намёком на шифрование. Просто одностороннее.
А с base64 смешно, да)
vilgeforce
25.04.2019 19:18Не вся криптография — шифрование: алгоритмы хэширования — не шифрование
mikechips
25.04.2019 19:43Вы правы, потому и сказал, что "с намёком на шифрование". Для неокрепших умов начинающих фрилансеров это одно и то же.
pae174
26.04.2019 08:05> MD5 и SHA-1 какое-никакое, а всё же с намёком на шифрование. Просто одностороннее.
Одностороннее шифрование и хэширование это разные вещи.
Хэширование выдает на выходе хэш, размер которого всегда фиксирован независимо от размера исходных данных. При хэшировании могут быть коллизии — для двух разных паролей на входе будет получен одинаковый хэш на выходе (и соль здесь не поможет). Это очень здорово когда ваш рандомный 22-символьный пароль от банк-клиента имеет тот же хэш, что и пароль 123.
Одностороннее шифрование это просто симметричное шифрование в котором в качестве ключа используется в том или ином виде сам исходный текст (пароль). Размер шифротекста при этом будет пропорционален размеру исходного текста. Никаких коллизий нет.pumbo
26.04.2019 12:34> При хэшировании могут быть коллизии
Под словами «могут быть» стоит упомянуть, что для современных алгоритмов хеширования (к примеру, SHA-256) такие коллизии никогда найдены небыли. Математически, вероятность коллизии настолько мала, что ей можно пренебречь.
screwer
27.04.2019 21:44>> Математически, вероятность коллизии настолько мала, что ей можно пренебречь.
как раз математически вероятность ОЧЕНЬ велика. Если входные данные для SHA-256 составят 257 бит — даже при идеально-сферическом хеше будет гарантированная коллизия.
А теперь посчитаем в байтах. 256 бит это 64 байта. Если добавить всего 1 байт — то на сообщениях получим 256 коллизий. Добавив 8 байт получим 18 446 744 073 709 551 616 коллизий. От буфера в 72 байта, да.
Число коллизий для килобайта или сотни килобайт — можете попробовать посчитать самостоятельно.Akela_wolf
28.04.2019 07:45К сожалению, это так не работает. Если у нас есть N возможных хэшей (2^256 для SHA256), то каков шанс получить хотя бы одну коллизию имея M случайных хэшей? Или аналогичный вопрос: сколько нужно сгенерировать случайных хэшей, чтобы коллизия произошла с вероятностью P?
Это Generalized birthday probled. Чтобы получить вероятность ~40% коллизии требуется сгенерировать 2^128 хэшей. И это будет коллизия между двумя случайными хэшами. Чтобы найти коллизию с заданным хэшем вам потребуется перебрать еще больше хэшей, что делает перебор практически невозможным.
trolley813
25.04.2019 11:53-6Ну вообще, Base64 сложно назвать шифрованием как таковым. А вот MD5, если солить пароли (со случайной солью), в принципе вполне подойдет.
DSolodukhin
25.04.2019 11:59+4MD5 — это тоже не шифрование, вот вообще ни разу.
trolley813
25.04.2019 12:34Так я и не говорил, что это шифрование. «Шифрование» и «подходят для хранения паролей» — это как бы разные вещи.
DSolodukhin
25.04.2019 12:56В таком случае, я вас неправильно понял (и похоже что я не один такой), но по построению вашей фразы сложилось впечатление, что вы считаете MD5 вполне подходящим на роль шифрования.
w0den
26.04.2019 09:25-2Base64 сложно назвать шифрованием как таковым
Почему сложно? Base64 — алгоритм шифрования, который не использует ключ для шифрования и дешифрования информации. Основными преимуществами алгоритма являются скорость, компактность и универсальность :)Akela_wolf
26.04.2019 09:52Не путайте шифрование (encryption) и кодирование (encoding). Base64 — это алгоритм кодирования (превращения бинарных данных в обычный текст), но никак не шифрования.
igormich88
26.04.2019 12:45Ну пляшущие человечки тоже когда то считались надёжным шифрованием. Кстати является ли сжатие данных шифрованием с вашей точки зрения?
w0den
26.04.2019 13:51Нет, «пляшущие человечки», как и Base64 никогда не являлись шифрованием. Например, шифрование обязательно требует ключ и обеспечивает целостность данных, когда ни «пляшущие человечки», ни Base64 не умеют это (разве что ASCII armor может защитить целостность Base64 от случайного повреждения).
Я подумал, что цитата, смайлик и описанные мною «преимущества», должны намекать, что я явно не считаю Base64 алгоритмом шифрования. Но оказалось, что в конце недели люди воспринимают вещи «слишком буквально».
flx0
25.04.2019 12:52+1Свалить в одну кучу base64 и SHA-1 — это надо постараться.
Равно как и причислять SHA-256 к небезопасным методам хранения паролей. По словарю их, конечно, подобрать проще чем bcrypt, но на практике соленый SHA-256 вполне хорошо работает.
ne_kotin
25.04.2019 15:40… и хорошо параллелится. поэтому — bcrypt, scrypt, PBKDF2 на овермного итераций.
qw1
25.04.2019 17:15SHA-256 на видеокарте GTX1080TI считается со скоростью 4.4 гигахешей в секунду. Если пароль не полностью случайное число, а хоть как-то удобен для запоминания, его возможно подобрать комбинацией словарей и мутаций.
gto
25.04.2019 21:04Мой пароль "cheburek s katyshkami". И не случайное число и запоминается. Найдёте по словарю с мутацией на GTX1080TI?
qw1
25.04.2019 21:51+1Скрытый текстСисадмин желал подобрать себе стойкий пароль для централизованной авторизации через radius-сервер. Он обратился за советом к Инь Фу Во.
– Как вы думаете, Учитель, пароль "???????" стойкий?
– Нет, – ответил мастер Инь, – это словарный пароль.
– Но такого слова нет в словарях…
– «Словарный» означает, что это сочетание символов есть в wordlists, то есть «словарях» для перебора, которые подключаются к программам криптоанализа. Эти словари составляются из всех сочетаний символов, которые когда-либо встречались в Сети.
– А пароль «Pft,bcm» подойдёт?
– Вряд ли. Он тоже словарный.
– Но как же? Это же…
– Введи это сочетание в Гугле – и сам увидишь.
Сисадмин защёлкал клавишами.
– О, да. Вы правы, Учитель.
Через некоторое время Сисадмин воскликнул:
– Учитель, я подобрал хороший пароль, которого не может быть в словарях.
Инь Фу Во кивнул.
– Я ввёл его в Гугле, – продолжал Сисадмин, – и убедился, что в Сети такого сочетания нет.
– Теперь есть.pumbo
26.04.2019 12:53Easy. Всего за 8,24859088481e+12 лет, при допущении, что длинна пароля 21 символ и состоит из алфавита из 27 символов.
А если серьезно, то этот пароль относительно легко подобрать, если использовать сочетание перебора по словарю, вариативность и склеивание раных вариантов.
Почитайте про «brain wallet» биткойн кошельки, как у людей уводили кошельки, к которым использовались пароли посложнее вашего.gto
26.04.2019 17:05Это если заранее знать, из чего состоит пароль. Вы же не хотите потратить 8,24859088481e+12 лет чтобы убедиться, что кавычки, например, тоже в пароль входили. С биткоин ключами проще, там словари.
Polaris99
25.04.2019 14:08То есть, 200 баксов за такую работу — это высокая оплата? Тогда нечего удивляться результатам. Ну и вывод чудесный напрашивается и имеет право на жизнь в условиях этого замечательного эксперимента — если нет разницы, то зачем платить больше? Нужно все делать в Бангладеше!
tessob
25.04.2019 16:40+1В Германии ставка синиор фрилансера ~600 в день. При указанной в статье оплате, любой работающий результат — это уже какое-то чудо. Учитывая то, что за отведенное время нужно еще: получить догступ ко всей среде, разобраться в предыдущим кришнакоде, написать свой кришнакод, как-то все это протестировать, согласовать и задеплоить.
G_Drey_V
25.04.2019 19:53+1разработчики-фрилансеры по умолчанию придерживаются исключительно небезопасных практик
Не очень понятно, при чем здесь фрилансеры? А разработчики, сидящие в офисе, от таких ошибок застрахованы по умолчанию?mikechips
25.04.2019 21:08Разработчики в офисе обычно имеют тимлида и хоть какие-нибудь код-ревью. А фрилансеру в код не будут тыкать, если работает (и заказчик сам не программист).
gto
25.04.2019 21:22А что вы удивляетесь, на каком сайте ни регаешься, везде: ваш пароль не может привышать 20 символов. Тут либо блочные шифры, либо пишут как есть. Кстати, base64 вполне себе подходит кодировать непечатные символы после шифровки.
mjr27
25.04.2019 22:54+2Старый советский анекдот.
— Что должен делать молодой специалист за зарплату в 80 рублей?
— Ничего, и даже немножечко вредить
mrsantak
25.04.2019 23:29Вообще статья странная. Все смешали в кучу — кодирование, симметричное шифрование, хеширование и при этом еще что-то пытаются вменять фрилансерам.
Вообще, я бы сказал, что не только у фрилансеров проблема с криптографией. По моему опыту большая часть разработчиков не особо разбирается в криптографии. И не потомучто они плохие специалисты, а просто потомучто они никогда не сталкивались с ней и скорее всего никогда не столкнутся. А даже те кто знают что-то, то знают «по-верхам». Банально могут знать, что надо хранить не пароль, а его хеш. Но очень мало знают, например, по каким критериям SHA-1 считается небезопасным, PBKDF2 уже считается более-менее приемлемым, а bcrypt/scrypt — хорошим. Я уж вообще молчу про понимание того для чего действительно нужна соль. Так что заявление, что вот именно фрилансеры и именно веб-разработчики такие плохие и ничего не понимают в криптографии звучит как минимум странно. Я уж вообще молчу, что (судя по ставке) выборка там была далеко не из топовых разработчиков.G_Drey_V
25.04.2019 23:48Кстати интересно, если все знают, что это такая распространенная проблема, почему в бд нет специального поля типа «password», которое в себя сразу бы включало и salt, и правильный алгоритм хэширования.
mrsantak
26.04.2019 00:05При каждой аутентификации нам нужно вычислять хеш от пароля, который нам прислал пользователь. Вычисление хеша — это достаточно ресурсоемкая здача (вполне реальная ситуация когда вычисление хеша пароля требует 20мб оперативки и пол секунды времени одного ядра). Как мне кажется, нагружать такими вычислениями сервер бд как-то не комильфо.
Плюс случайная ошибка в запросе (забудем по userId отфильтровать например) может привести к фулскану таблички с перевычислением хеша для каждой строчки, что на сколь-нибудь приличной базе пользователей отправит сервер в закат на несколько часов.G_Drey_V
26.04.2019 00:15но с другой стороны практически все бд предоставляют различные функции хэширования, вопрос лишь в том, чтобы встроить эту функцию напрямую в поле и добавить соль.
mrsantak
26.04.2019 00:23А как вы будете защищаться от того, что ваш запрос с паролем plain text'ом попадет в журнал базы?
Ну и сама эта функция не особа осмысленна из-за нагрузки на сервер бд. Вычисления хешей паролей при более-менее нормальном потоке пользователей просто положат вам сервер.
Ну а то что вычисление хешей есть в бд, так хеши не только для паролей используются, и в других задачах к функциям хеширования могут применяться диаметрально противоположные требования. Плюс возможно сделать запрос «ручками».
dom1n1k
26.04.2019 00:03Знать что такое хэш, соль и для чего они в общих чертах нужны — это и есть «по верхам». Уж если этого не знать — это значит не знать вообще ничего.
mrsantak
26.04.2019 00:11Ну вот те кто знают зачем соль и хеши «в общих чертах нужны» и используют SHA-1 и общую соль на всю бд. Ну и до кучи соль примешивают конкатенацией пароля к концу соли.
Ну и строго говоря, что считать за «вообще ничего», а что за «в общих чертах» — это вопрос терминологии. Реальность в том, что большая часть знакомых мне разработчиков сходу не увидят проблем в вышеописанном способе хеширования паролей, а как уж это назвать — дело десятое.
FRiMN
26.04.2019 09:54+1А зачем это вообще делать вручную? Есть же специальные библиотеки для этого.
Кроме того кругом читаю, мол "не пытайтесь самостоятельно реализовывать криптографию, и даже вместе собирать готовые части то же не пытайтесь".Akela_wolf
26.04.2019 10:08Именно. В 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);mrsantak
26.04.2019 10:40Ну а теперь вопросы: Почему bcrypt, а не какой-то другой алгоритм? Какой cost будет использоваться для вычисления хеша и почему именно такой, а не другой (а это важно, ибо определяет криптостойкость)? Каков размер соли и почему именно такой? Какие ограничения на размер пароля?
Я это все к чему — использование криптобиблиотек — это хорошо и правильно, но это не отменяет того, что неплохо бы понимать что именно этот код делает и как это соотносится с тем, что требуется сделать (разумеется не нужно знать реализацию самого шифрования, но вот контракты знать стоит). А то ведь можно использовать стойкий алгоритм, но использовать его с такими параметры, что окажется не сильно безопаснее SHA-1.Akela_wolf
26.04.2019 11:00Я это все к чему — использование криптобиблиотек — это хорошо и правильно, но это не отменяет того, что неплохо бы понимать что именно этот код делает и как это соотносится с тем, что требуется сделать
Вот с этим полностью согласен. Хотя, замечу, дефолтные параметры в том же PHP вполне пригодны для обычных сайтов и приложений. Если же у приложения какие-то специфические требования к хэшированию паролей — то разработчик обязан их учесть.mrsantak
26.04.2019 11:41Тут ещё дело может быть во времени. Те параметры, которые считаются оптимальными сейчас могут быть недостаточно безопасными пару лет спустя. А делать перехеширование — это просто адская боль. Но в целом тоже соглашусь, что дефолтовые настройки в подобного рода библиотеках актуальных версий более-менее адекватные.
mrsantak
26.04.2019 10:28Ну реализовывать самому какой-нибудь scrypt конечно не надо. Но вот выбрать размер соли и способ ее генерации, а так же алгоритм хеширования и его параметры придётся все-таки самому.
ssmac
26.04.2019 01:26если выдавали бы изначально правильное чётко ограниченное тз, то и получили бы всё что желается, но тогда и цены изначально поднять пришлось бы, вслед за заявленым уровнем качества; а в таком варианте этот эксперимент выглядит как «проверка на вшивость», только инициатор такой проверки — обычно «вшивый» сам;
шифрование — это очень такое широкое и растяжимое понятие, для кого-то и запись символов в обратном порядке — тоже шифрование; надо внятно и точно объяснять, чего надо и хочется, а не пытаться найти дурака, который гривенник разменяет по рублю;
«сделайте хорошо» — это не тз, это либо свойская частная просьба, либо откровенная подйопка;gban
26.04.2019 05:37Это значит, что у заказчика в штате должен быть человек, который понимает, до какого уровня подробности прописывать ТЗ… но тогда зачем ему куда-то еще обращаться за реализацией? ставим его тимлидом и вперед!
Akela_wolf
26.04.2019 09:54Вообще, хороший разработчик должен ответить что реализация по такому недетализированному ТЗ должна начинаться с согласования спецификации и стоить этот первый этап будет столько-то. Вполне возможно что часть отказов (согласились только 43 из 260) и содержали подобные формулировки.
w0den
26.04.2019 11:59Получается, в ТЗ заказчик должен написать всё подробно, в том числе, что пароль пользователя необходимо:
— Хранить как CHAR, а не как INT.
— Передать методом POST, а не GET.
— Хешировать, а не шифровать.
Скорее всего ещё придётся указать, что если пользователь будет ввести неверный пароль, то не нужно его авторизовать. И конечно, что необходимо обезопасить приложение от SQL-инъекций и CSRF-атак.wladyspb
26.04.2019 14:45Желательно да. У данного исследования много проблем, на мой взгляд. Оно крайне низко оплачивается для европейского рынка, и содержит плохопроработанное тз. Хороший разработчик, несомненно, использует защиту от инъекций, CSRF, правильное шифрование с солью, проверку на уникальность логина\почты используемых для авторизации, защиту от массовых регистраций ботов, капчу, подтверждение регистрации через email\смс, кнопку быстрой регистрации через гугл\стим\etc… Но после того, как обсудит с заказчиком что из всего этого действительно надо, и после пересмотра суммы вознаграждения в 2-5 раз. Поскольку работа по «запилить формочку авторизации» и «сделать полноценный, защищённый инструмент авторизации с защитой и удобствами» — сильно отличаются по требуемому уровню разработчика и затраченному на задачу времени. А, да, мы ещё забыли обсудить, какую нагрузку должен держать сервис авторизации! Будем ориентироваться на горизонтальное масштабирование сразу? А как насчёт GDPR, удобный механизм удаления данных о себе для пользователя предусматривать?
ЗЫ: Что-то мне подсказывает, что те, кто отказался от выполнения работы, как раз и были нормальными специалистами, с которыми не захотели обсуждать требования и повышенное вознаграждение, а говно на скорую руку они сделать не пожелали.w0den
26.04.2019 15:42+1Лично я всегда думал, что есть вещи, которые не нуждаются в ТЗ. Например, затяжка колёсных болтов, хеширование паролей, использование метода POST для передачи конфиденциальных данных, и так далее.
Например, заменитьbase64_encode()наpassword_hash()ничего не стоит (наоборот, даже сократит время разработки). И поверьте, стоимость работы никак не влияет на профессионализм разработчика. Если человек говорит, что «очень сложно расшифровать Base64», можете заплатить ему хоть миллион, от этого он не перестанет «шифровать пароли с помощью Base64» или хранить их как обычный текст. Достаточно взглянуть на крупные корпорации, которые забывают, как правильно хранить пароли и сразу становиться ясно, что проблема скорее всего не в деньгах.mrsantak
26.04.2019 15:55Формально, хешированием паролей евляется substring вырезающий первую половину пароля. Только качество такого хеширования ниже плинтуса. Понятно, что специалист, который дорожит своей репутацией такую хрень не напишет. Но в статье-то рассмотрены низкооплачиваемые ноунеймы.
Чем менее професионален исполнитель, тем более подробное ТЗ ему нужно, чтобы выдавать приличный результат.w0den
26.04.2019 16:49Проблема в том, что «низкооплачиваемые ноунеймы» охотно откликаются и на проекты с большим бюджетом. Если исследователи заплатили бы больше, это привело бы к увеличению числа исполнителей, но минимум 8 из них всё ещё использовали бы Base64. Думаю, стоимость работы не играет самой важной роли, иначе из 43 фрилансеров все бы использовали Base64, а не только 8 из них.
Поэтому, Вы должны задаваться следующим вопросом: почему большинство фрилансеров за те же условия (деньги и ТЗ) использовали правильные алгоритмы, а некоторые нет.
SantaCluster
27.04.2019 06:00есть опытные программисты с большим опытом фриланса. за такие деньги вряд ли откликнувшиеся.
есть опытные программисты, но как фрилансеры только начинают. вполне могут откликнуться и сделать либо хорошо либо "срого по ТЗ"
а есть начинающие программисты и "люди с улицы" ;) с ними либо никак либо с подсказки кто-то из них сможет что-то сделатьw0den
27.04.2019 08:19Почему Вы думаете, что опытные программисты не хотят получить, скажем, €200 за пару часов работы и хороший проект для своего портфолио?
Дело в том, что опытному программисту не нужны несколько дней, чтобы имплементировать процесс регистрации в готовом проекте. Например, первый фрилансер сдал работу через 21 часов, но он хранил пароли как обычный текст. Когда его попросили защитить пароли, ему потребовалось 38 часов, чтобы сделать это (для сравнения, один из фрилансеров перешёл на BCrypt всего за 4 минуты). Разве это не говорит о том, что задача была довольно проста для опытного разработчика?Akela_wolf
27.04.2019 08:49+138 часов?! Что можно делать 38 часов (практически рабочую неделю) для добавления хэширования? Собственную хэш-функцию реализовывать?
w0den
27.04.2019 09:23Было бы забавно, если бы он реализовал новый алгоритм, а исследовали, пытаясь высмеять его, обнаруживали бы, что алгоритм очень крут.
mrsantak
27.04.2019 12:58-1Например решил разобраться в вопросе хеширования паролей: почитать несколько статей на эту тему, поисследовать best/bad practice, посмотреть какие есть алгоритмы и в чем между ними разница. Поискать готовые библиотеки и подобрать подходящую.
Если человек никогда не сталкивался с хранением паролей, то примерно рабочая неделя и уходит на вникание в тему. Можно, конечно, и просто скопировать код из первой попавшейся ссылки на stack overflow, но тогда и результат может получиться соответствующий.
mrsantak
26.04.2019 15:49ТЗ — это продукт договренности заказчика и исполнителя. И на его составление может уйти немало времени, в зависимости от его детальности. Вполне нормальная ситуация, когда заказчик сначала заказывает у исполнителя ТЗ, а потом уже по этому ТЗ происходит работа. Но в реалиях проектов за 200 баксов так обычно никто не делает, а потом заказчики удивляются, что получилось вовсе не то чего они хотели.
pyrk2142
26.04.2019 04:41Я бы не сказал, что штатные сотрудники — это однозначное решение проблем. В последнее время кажется, что довольно много проектов реализуются людьми, которые вообще не понимают, что и зачем они делают.
Ленивый поиск уязвимостей в системах, которые показались относительно интересными за последние пару месяцев, дал пугающие результаты:
А) Люди массово считают четырехзначный СМС-код надежным способом авторизации.
Б) Чуть меньшее количество людей просто не проверяет число попыток. 10000 попыток ввода четырехзначного кода — пожалуйста. Хотя одна компания выставила ограничение в 500 попыток, которое потом убрала.
Это встречается как у тех сервисов, где вообще не ожидаешь безопасной разработки хоть какого-то уровня (кодер что-то выдал, это не падает с ошибками — премию ему), так и у довольно серьезных организаций: начиная от различных элитных и не очень доставок еды, чатиков, систем управления службами такси, заканчивая сервисами телемедицины, банками, авиакомпаниями и мобильными операторами.
Пугает то, что в такой ситуации никто из псевдо-инженеров: кодеры, тимлиды, тестировщики, безопасники (да, у некоторых из этих компаний есть безопасники), не задавался вопросом, зачем вообще они делают авторизацию. Немного боюсь того, что они выдадут в следующий раз.wladyspb
26.04.2019 14:34Если на каждую попытку ввода отправляется новое смс, и присутствует минута-две с обратным отсчётом до повторной попытки — то уровень защиты удовлетворительный. Особенно если код в смс — это 2FA после ввода логина и пароля. Но, конечно, случаи бывают разные…
pyrk2142
26.04.2019 16:17Вы описали авторизацию очень высокого качества. Я был бы рад (или нет) чаще встречать такое. Пара популярных проблем, которая встречается у более качественных реализаций:
* Перед новой попыткой ввода (хотя обычно перед набором попыток, от 3 до 75 (!)) отправляется новое СМС, правда можно спокойно запрашивать по 200 СМС в минуту.
* Обратный отсчёт есть, но он только на фронтенде. Перехватил трафик — радуешься жизни.
* Продвинутый баг: новое СМС не отправляется из-за ограничения на число СМС в минуту, но счётчик проверок обнуляется: слепой брутфорс, плюс он менее заметный для жертвы.
SantaCluster
27.04.2019 06:30главное не испортить всё передачей и хранением пароля в текстовом виде :)
mafia8
26.04.2019 10:15Что почитать по шифрованию (симметричное, асимметричное, хэширование)?
Есть инструкция, пошаговый аглоритм для вредрения шифрования?
botyaslonim
26.04.2019 11:49>> npm i --save-dev jsencrypt
>> import JSEncrypt from «jsencrypt»;
>> export default function RSAEncrypt(publicKey, data) {… }
411
26.04.2019 20:20Не удивлюсь, что у 90% при этом отсутствует https и пароль передаётся как есть с клиента
saipr
26.04.2019 21:28Программисты, которые зашифровали пароли, использовали небезопасные методы: 31 программист использовал для шифрования такие методы, как Base64, MD5, SHA-1 и т. д.
Вообще-то MD-5, SHA-1, как и SHA-256 и другие и иже с ними российские stribog-и это хэш функции и ничего зашифровать они не могут. Можно конечно говорить, что из пароля получим хэш и именно он будет паролем. Но это… Вопрос-то остается открытым как зашифровать? А дальше, зашифруем на каком-то ключе. А как ключ спрятать? Опять шифровать будем. Авторизоваться, на мой взгляд, оптимально на сертификата, хранимом на токене PKCS#11. Да и просто пароль можно хранить на флэшке, хранимой в кармане.
Да, и Base64 тоже ничего не шифрует, просто переводит в текстовый вид. Примените обратную операцию и получите исходный пароль.
EvilBeaver
27.04.2019 07:59Наличие соли хеша существенно усложняет брутфорс? С чего вдруг? Подбор по словарю — усложняет, да
w0den
27.04.2019 08:36Возможно, имеется в виду, что для того чтобы взломать соленый хеш, сначала нужно найти соль.
Akela_wolf
27.04.2019 08:50Усложняет т.к. вычисление хэша соленого пароля требует значительно больших вычислительных ресурсов, чем несоленого.
Плюс соль делает невозможным массовый брутфорс (когда мы имеем 100500 хэшей, перебираем пароли и смотрим с каким из имеющихся хэшей он совпал)
Daddy_Cool
Ну а чего… проблема безопасности — это проблема пользователя, гром не грянет — мужик не перекрестится. Анализ безопасности — это отдельная важная задача, но — которая не имеет отношения к непосредственному функционалу продукта. Очень хорошо, что эта статья появилась.