Z
взгрустнул от каверстори в 255 хакере. То ли я уже вырос и все перестало казаться супертехничным и сложным, то ли просто качество статей стало проседать и весь какой-то интересный материал теперь можно найти только в твиттере и личных блогах
Четам
Size: a a a
2020 August 05
PC
Четам
механизмы безопасности виндоус и способы их обхода
Z
Просто журнал не может расти вместе с тобой ;)
PC
ну или около того))
Z
Всегда будут начинающие, которым это будет интересно
PC
согласен, когда то "взлом army.mil" был чем-то необычным, а спустя N лет это банальная скуля в говнодвижке
Z
Да
DP
Хаюши ,потерял сегодня мышку.есть ноутбук старенький.2013 г .вопрос:мж ли как то сделать этот тачпад более комфортным программно ?касаемо софта и переназначения
Z
Как и взлом Рамблера сто лет назад
PC
Каеф))
PC
2009, откопал)
Z
Лооол
Z
А кто автор?
Z
Вот она была свобода, похек армии
PC
SKVOZ
PC
хз кто это правда)
PC
андрей комаров
Z
Было время, толи дело сейчас багхантер нашёл раскрытие путей и сопли пузырем
Z
Один из классических вопросов на собеседование AppSec специалисту - "Как хранить пароли?". И тут будет потрясающим ответ - "пароли хранить не надо, потому что в 2020 мы не должны запускать сервисы с паролями!". За это можно получить хороший плюс. Но если все-таки вернуться к вопросу, то ожидается ответ в духе:
- Давайте использовать Argon2, PBKDF2, Bcrypt, Scrypt с оптимальным количеством раундов
- И харденинг - например использовать HSM (тут долгие холивары в каком режиме), "pepper" и т.д.
Ответы хранить соленный md5/sha1/sha256/sha512 автоматически ставят жирный минус.
Но также есть еще один вопрос, сложный, и ответ на него мало кто знает - *”А как нам хранить пароли так, что если атакующий получит RCE на бэкендах, в т.ч. root привилегии, то не сможет дампнуть табличку с хэшами?”*
Вопрос ставит в тупик, можно начинать придумывать "security through obscurity" решения, но не надо. Есть очень легкий, понятный и технически верный путь, как решить поставленную задачу. Нам нужно отозвать права "select" у бэкенд юзера на таблицу с хэшами и написать 2 хранимых SQL процедуры:
Вернет «соль» пароля на бэкенд по userId, который пытается войти. Бэкенд возьмет введенный юзером пароль и получит хэш с солью из базы
Возвращает true/false на проверке хэша пароля на предыдущем шаге у user_id
Еще нужна процедура на создание пользователя и смену пароля, но они также не позволяет select'нуть хэши паролей пользователей. Хорошая статья по теме(но там не всё): https://www.secjuice.com/secure-password-handling/
Странно, что ни в одном современном решении - типа WordPress или Django это не реализовано. Да и не надо уже, давайте лучше откажемся от паролей!
- Давайте использовать Argon2, PBKDF2, Bcrypt, Scrypt с оптимальным количеством раундов
- И харденинг - например использовать HSM (тут долгие холивары в каком режиме), "pepper" и т.д.
Ответы хранить соленный md5/sha1/sha256/sha512 автоматически ставят жирный минус.
Но также есть еще один вопрос, сложный, и ответ на него мало кто знает - *”А как нам хранить пароли так, что если атакующий получит RCE на бэкендах, в т.ч. root привилегии, то не сможет дампнуть табличку с хэшами?”*
Вопрос ставит в тупик, можно начинать придумывать "security through obscurity" решения, но не надо. Есть очень легкий, понятный и технически верный путь, как решить поставленную задачу. Нам нужно отозвать права "select" у бэкенд юзера на таблицу с хэшами и написать 2 хранимых SQL процедуры:
getSalt(user_id)
Вернет «соль» пароля на бэкенд по userId, который пытается войти. Бэкенд возьмет введенный юзером пароль и получит хэш с солью из базы
checkPassword(user_id, hashed_password)
Возвращает true/false на проверке хэша пароля на предыдущем шаге у user_id
Еще нужна процедура на создание пользователя и смену пароля, но они также не позволяет select'нуть хэши паролей пользователей. Хорошая статья по теме(но там не всё): https://www.secjuice.com/secure-password-handling/
Странно, что ни в одном современном решении - типа WordPress или Django это не реализовано. Да и не надо уже, давайте лучше откажемся от паролей!
AK
хуйня это нолик