Как НЕ записывать пароли в базе данных

[@RDguffi]

Благодарю за столь информативный контент. Мне, как человеку впервые столкнувшемуся с вопросами безопасности хранения паролей, это видео просто заменило часы поисков. Удачи вам Владимир в начинаниях! А главное, не бросайте канал, хорошее дело делаете :)

[@VladimirMozhenkov]

Благодарю за ваши слова. Забрасывать канал я не планирую, если всё пойдёт как должно, то буду даже его развивать, чтобы он стал чем-то большим.

[@richardcobain246]

Привет из 2019

[@kl45gp]

спасибо большое, устал уже смотреть ваши видео, но все равно смотрю, безумно интересно и просто! еще раз спасибо!

[@sts5847]

Отлично разсказал,причем так хорошо что наверно поймет любой человек, ну как минимум который ознакомился с ПК

[@nmg_prm]

Спасибо что делитесь знаниями в доступном формате!

[@LeGul_in_lab]

Приветствую из 2021-го.) Благодарю за содержательный контент, информация для общего понимания вопроса все еще актуальна. Надеюсь на дальнейшее пополнение этого плейлиста.

[@nickk.9470]

Про разные соли для разных пользователей не знал. Спасибо.

[@MrAeroification]

действительно, божественно, привет 2020

[@alexb.2616]

Спасибо за видео. Привет из 2021.

[@vendetty911]

Дуже класне відео!!!

[@MasterZiv]

Чёрд, почему так мало лайков у такого правильного видоса?

[@xambey]

Все еще актуально, но думаю будет полезно сделать видео про JWT токены и асимметричное шифрование, в дополнение для актуализации

[@theDenQ]

Хорошая лекция, так и делаю всегда. Но есть один минус. Если сервис высоко нагруженный, то учитывая вес операции аутентификации, работа сервиса может "загнуться". Если конечно не позаботиться за ранее об этом. Что-то типа системы токенов, после авторизации. Хранить в key-value хранилище на сервере и в куке на клиенте(к примеру). Думаю, что есть еще более лучшие варианты.

[@ai-katrin]

Есть ещё более крутой вариант. Делаем внутренний микросервис, который хранит ключ, и генерирует хэш из пароля и соли. Таким образом, если апликуху с юзерами хакнули и стырили базу с солью и хэшем, то они не смогут получить ключ. Но обычно ключ хранится в апликухе с юзерами, так что такой ключ заполучить вполне возможно при взломе.

[@kartezist]

11:33 прочитали о соли, но не правильно поняли и стали наркоманами

[@vu4er]

Если по предложенному Вами способу генерировать разную соль для разных логинов, то эту соль же надо где то хранить? А если известен логин и соль, то даже при хэшировании разве нельзя восстановить пароль?

[@VladimirMozhenkov]

+vu4er Смотрите, если у вас 1 соль, то я начинаю генерировать хеши и сразу проверяю всех ваших пользователей. А если соль разная, то мне надо будет увеличить свои усилия в столько раз, сколько у вас пользователей. А на счёт восстановления, нет. Если хеш хороший, то это почти невозможно. P.S. Посмотрите вторую обновлённую версию этого видео: kzbin.info/www/bejne/gqGsYqltgL6WZrM

[@АсенькаАлей]

Я, как пользователь, обхожу стороной сайты, которые мне предлагают логиниться через мои соцсети, а уж тем более, через мою почту)

[@i2YouOrg]

Привет от Covid 2020 ;)

[@solowey]

Спасибо!

[@david_shiko]

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

[@АлександрБобер-у4х]

Привет из 2018 :-)

[@sergeykkk8681]

Здравствуйте! Функция PWDENCRYPT в ms sql возвращает разные хеши для одного и того же пароля. Однако, PWDCOMPARE возвращает истину при сравнении запрашиваемого пароля и соответствующего ему хеша. Как это работает?

[@pazukpazukowicz3102]

Привет из будущего. Сейчас 2020-й год. Java 15 и мир охвачен глобальной пандемией.

[@shamkhan2636]

7 лет прошло. Одна неясность. Если каждый раз новая соль, то как вообще проверяеться пароль в следующий раз? Откуда восстановить ту изначальную соль именно для этого пароля?

[@ibnkhaleed]

Привет из 2021!

[@ИльяПопов-ф4ь]

привет из 2020

[@worldofsoftware8219]

Благодарю

[@lisafox9026]

google mail тоже так делает, легко поменять пароль на нем, и многие так делают и что делать?

[@hanneldays4010]

Здравствуйте спасибо за видео. Первое видео которое смотрела с данной темой. С месяц назад писала сайт интернет магазин была курсовая по Веб разработке выполняла записывала в БД как имя и пароль и даже не подумала. Но по видео я не поняла минус Соли где одна соль на весь сайт

[@xoxot_shamana]

Минус такого подхода - одинаковые хеши у одинаковых паролей.

[@MrDeylik]

Расскажите про двухфакторную аутентификацию пожалуйста.

[@greezlock7291]

Здравствуйте, Владимир! Подскажите, пожалуйста, есть ли какой смысл от хеша повторно генерировать второй хеш и так до N повторений? Ведь взломщику не будет известно, на сколько уровней был прохеширован изначально пароль :)

[@VladimirMozhenkov]

Соблазненный разумом Смысл есть. И сейчас это делается автоматически: kzbin.info/www/bejne/gqGsYqltgL6WZrM

[@viptutorials]

Привет из 2021

[@sashasashovic91]

почему вы не сказали не чего про SHA512?

[@sdfsdfgs]

Пособия для хакеров))

[@dmytroskydanenko5106]

Ха) 2020 :)

[@ImagineState]

Если получить доступ к базе акк-хеш-соль, разве не получится восстановить исходный пароль. SHA256_Decrypt(SHA256_Encrypt(PWD XOR SALT)) == PWD XOR SALT (PWD XOR SALT) XOR SALT == PWD ???

[@VladimirMozhenkov]

Максим Шишиморов Хеш нельзя обратить обратно по определению. Если было-бы можно, то это стало-бы самым лучшим методом компрессии, так как хеш всегда генерирует определённую длинну, для *любой* длинны данных. То есть вы могли-бы взять файл 5 петабайт, прохешировать с помощью SHA256 например и получить 256 байт, а затем "разшифровать" их обратно.

[@ImagineState]

Vladimir Mozhenkov благодарю, действительно что то неподумал о не обратимости.

[@grv1621]

Если я правильно понял то даже когда я генерирую сложный пароль к примеру keepass-ом для своей почты а другие пользователи используют к примеру 1234 то они подвергают опасности всех включая меня ?

[@VladimirMozhenkov]

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

[@grv1621]

Vladimir Mozhenkov спасибо !

[@binartv13]

Класс Подписка

[@xoxot_shamana]

Почему не sha256( sha256($login).$password) ?

[@АлексейДолматов-м3я]

2021 )

[@EpisodeAST]

А где хранить соль? Не в той же таблице по соседству с паролем

[@VladimirMozhenkov]

Евгений Мокрушин Да. Соль хранится в базе, но не по соседству с паролем, так как пароль *вообще не хранится* а рядом с *хешем* пароля+соли.

[@eternal_wanderer_ru]

Сейчас для php 5.5 и новее, есть функция password_hash(). Она сама генерирует соль, для одного пароля всегда разный хеш

[@VladimirMozhenkov]

Александр Сидоров Да. Именно про это я и записал другое видео: kzbin.info/www/bejne/gqGsYqltgL6WZrM

[@eternal_wanderer_ru]

а, не заметил его. Спасибо, полезно для многих будет!

[@кириллфилиппов-п5ь]

2017 год

[@SuperKurt999]

спасибо

[@VladimirMozhenkov]

+саша курило Обязательно посмотрите продолжение: kzbin.info/www/bejne/gqGsYqltgL6WZrM

[@lisafox9026]

очень многие сайты требуют адрес эл почты, я не совсем понимаю о чем тут речь

[@aquawitty]

ку из 21

[@DYADYA_LENYA]

Привет из 22))

[@LetspalyLife]

Ктулху)

[@КимЧенОрк]

Первый из 2022

[@МихайлоАбрамов-й8щ]

2024

[@0867532]

ну а если мне насрать на сайт, на котором я зарегался? Ломанут, и хрен с ним.(и почта специальная есть)

[@VladimirMozhenkov]

G0867532 Это видео для разработчиков сайтов. Я думаю, что разработчик не хочет, чтобы у него регистрировались только люди, которым всё равно если у них всё взломают.

[@CoricComPlus]

Просмотрел видео до 8:17 - при всем уважении к Владимиру - все это правильно, но носит чисто теоретический характер. Во-первых, насчет хэшей: если и произошла утечка бэкапа, то пароль (вернее, то значение, которое дает тот же хеш) - ломается по радужным таблицам (гугл в помощь), причем весьма успешно (даже GSM трафик не устоял) Во-вторых, вопрос безопасности должен решаться инфраструктурно, а не декларативно кодом, чтобы иметь физическое ограничение, а не логическое. Например, такое решение, когда база данных - за VPN, SQL сервер имеет только приватный IP, и во внешний мир не смотрит, далее, на базе стоит шифрование критических полей (пароли, номера кредитных карт) симметричным ключом, private key которого находится на сервере - даже если и стырить бэкап, то без оригинального master key на SQL сервере, экспорт которого невозможен - будут одни NULL. Так что данный инфраструктурный пример позволяет и 123 в явном виде хранить в базе - но только он зашифрован на уровне базы. Без VPN - никак сырой запрос не послать. А стырить бэкап - смысла нет никакого. Вариант с коррумпированным DBA мы не рассматриваем - они и так получают достаточно хорошо, чтобы не ввязываться во всякие сомнительные аферы (особенно, при настроенном аудите :)

[@VladimirMozhenkov]

+Anton Lozovsky Вы не правы. kzbin.info/www/bejne/gqGsYqltgL6WZrM

[@CoricComPlus]

+Vladimir Mozhenkov Блаблабла от философствующего теоретика. Пук в лужу. В чем не прав? Потрудитесь объясниться конкретнее. Мой СУБД кластер, под MS SQL 2014 живет на 10.120.81.113. Потрудитесь взломать пароли, плиз :) На досуге, можете нагуглить о стандарте PCI DSS