Bymas.ru | PDO Запрос (безопасность)

AlertWeb (27 окт 2023, в 14:00)
Он подготовленный для базы, а вдруг пароль имеет 1 цифру, или логин существует?
Нужно максимально валидиловать, а потом только записывать значения в базу.

без разницы сколько чего имеет пароль, потому что пароль должен хешироваться, а хеш даже пустого пароля по дефолту через password_hash() имеет длину 60 символов и должен храниться в столбце постоянной длины типа char(60)

Вилы Выкидные (25 нояб 2023, в 14:37)
без разницы сколько чего имеет пароль, потому что пароль должен хешироваться, а хеш даже пустого пароля по дефолту через password_hash() имеет длину 60 символов и должен храниться в столбце постоянной длины типа char(60)

Що серйозно?

Суть не в том, что ты будешь хэшировать пароль, а в Бруте, ведь не все могу сделать капчу, ограничения и т.д, поэтому и нужна валидация на длину и доп символов к примеру

Drages (27 окт 2023, в 13:45)
Добрый, изучаю PDO в данный момент, а именно подготовленные запросы и прочее

if (isset($_POST['submit'])) {
$login = $_POST['login'];
$password= $_POST['password'];
}

$table = 'update user set login = ?, password = ?, sex= ? where id = ? limit 1';
$ssq = db::$pdo->prepare($table );
$ssq ->execute([$login, $password, $gender, ID]);

Переменную $login,$password фильтровать не обязательно в данном случае? Запрос ведь подготовленный получается.

Благодарю

Да, ты можешь их не фильтровать перед записью, подготовленные запросы сами все сделают и защитят от SQL Inj.
НО!
Это не значит что это защитит тебя в дальнейшем от XSS.
Ну и в случае с паролем, в открытом виде его хранить не очень безопасно, используй password_hash()

Drages (27 окт 2023, в 14:05)

AlertWeb , имеется в виду не нужно ли применять всякие костыли типо htmlspecialchars real_escape_string и т д к $login = $_POST['login'];

Нет, не нужно. htmlspecialchars на выводе используй для защиты от XSS, а подготовленный запрос избавит тебя от sql инъекций и смысла от real_escape_string нет
________
посл. ред. 26.11.2023 в 19:55; всего 1 раз(а); by TheAlex

AlertWeb (26 нояб 2023, в 15:21)
Суть не в том, что ты будешь хэшировать пароль, а в Бруте, ведь не все могу сделать капчу, ограничения и т.д, поэтому и нужна валидация на длину и доп символов к примеру

не нужна валидация никакая: пароль, захешированный с помощью password_hash(), проверяется с помощью password_verify()

________
посл. ред. 26.11.2023 в 21:04; всего 1 раз(а); by Вилы Выкидные

Бесполезно говорить тебе о логике, речь идёт о безопасности, никто не полезет в базу за паролем, если пароль 4 символа будет Брутом его проще подобрать.
Все понимаю что он будет зашифрован в базе, но речь не об этом.
Тебе о другом а ты о вилах.

AlertWeb (27 нояб 2023, в 0:54)
Бесполезно говорить тебе о логике, речь идёт о безопасности, никто не полезет в базу за паролем, если пароль 4 символа будет Брутом его проще подобрать.
Все понимаю что он будет зашифрован в базе, но речь не об этом.
Тебе о другом а ты о вилах.

Ты немного от темы вопроса отошел, брут это уже совсем другая тема)

AlertWeb (27 нояб 2023, в 0:54)
Бесполезно говорить тебе о логике, речь идёт о безопасности, никто не полезет в базу за паролем, если пароль 4 символа будет Брутом его проще подобрать.
Все понимаю что он будет зашифрован в базе, но речь не об этом.
Тебе о другом а ты о вилах.

не надо валидировать пароль))) как его набрал пользун так и нужно хранить, пропустив через password_hash() и скармливать password_verify() при проверке

валидировать нужно, например, логин: если для хранения выделено varchar(15), но пользун ввёл 16, то давать ему отлуп - логин не может превышать 15 символов, или проверять каким набором символов должен быть набор: латиница или кириллица

для пароля такой валидации не требуется, он всё равно залетает в БД хешем постояной длины char(60)
________
посл. ред. 29.11.2023 в 14:23; всего 1 раз(а); by Вилы Выкидные