Как некоторые пароли не ломают сайты или базы данных?

Question

[Alexander Lamdan]

Я задавал вопрос про длину паролей и их генерируемость, теперь меня часто мучал вопрос такой.
Вот у меня есть пароль к примеру

f.zYN'w#"ec++q/j(i=cV4|WGjUe~=Mn,V^%.pPbfYhu?yPn#y

Там много скобок, и символов которые могут без проблем сломать любое хранение в базе данных, либо просто сломать сам код.
Многие переменные или код на сайтах сохраняют пароли в таком виде:
"тут пароль", `и тут пароль`
Теперь мне интересно стало, а почему такие пароли указанные выше не ломают БД и не ломают обработку в коде?
По факту многие разработчики заносят пароль в кавычки, либо как то по другому.

Comments

[Сергей Горностаев]

Там много скобок, и символов которые могут без проблем сломать любое хранение в базе данных, либо просто сломать сам код.

С чего вы это взяли?

[Дмитрий]

Обычно пароли не хранят в открытом виде

[Alexander Lamdan]

Сергей Горностаев, потому что я когда писал тестовый проект ради интереса.
При попытке сохранить пароль нужно как то его оборачивать и сохранять.
А это либо в кавычки "", '', ``, и при любом сохранении когда появляется в моем пароле один из символов кавычек, тут же ломается и вся обработка.
Тогда я не могу понять, почему у меня он ломается, а у других нет.
Ведь даже если поставить рядом """ уже сломает строку.

[Alexander Lamdan]

Дмитрий, Это верно, но даже с хешированием в MD5, Aes у меня все летело к чертям.
Хоть на PHP, хоть на Python, хоть в Bash

[Сергей Горностаев]

Alexander Lamdan, вероятно вы не знаете правил написания строковых литералов в используемых языках. Для строковых литералов есть экранирование символов, а сами строки вообще могут содержать всё, что угодно и ничего не ломать.

[Дмитрий]

Alexander Lamdan, у вас ломается код, потому что надо записывать уже результат после обработки хэш функции, и в строке, которая получается нет символов, которые ломают чего либо

[Alexander Lamdan]

Сергей Горностаев, А можно пример экранирование символов?

[Дмитрий]

Можно использовать подготовленные выражения для записи в базу, экранирование не нужно

[Сергей Горностаев]

Alexander Lamdan, python, php, bash.

[mayton2019]

Я знаю только один символ который может создавать проблемы для строк. Это символ с кодом ноль (0x00)
который в C/Unix API терминирует ASCIIZ строки.

Answer 1

[alexalexes]

Потому, что при передаче данных от пользователя и обратно нужно правильно использовать API между средами, которые обеспечивают стек технологий web.
Например, рассмотрим взаимодействие веб-сервера и сервера баз данных.
В этом месте стека, не все разработчики умеют в буквальном смысле "готовить" запросы, в которых есть входные параметры.
https://www.php.net/manual/ru/pdo.prepared-stateme...
Вместо того, чтобы использовать специальный порядок подготовки запроса SQL и данных к его выполнению, начинающие разработчики просто склеивают текст запроса с непосредственно данными, которые во входных параметрах (ну, работает же), что небезопасно, даже если экранировать данные (от кавычек и точки с запятой вы спасетесь, но не от union + произвольный запрос).
Это касается не только использования паролей в качестве данных, но и любых других данных, в особенности поступающих от пользователя.
Такие нюансы работы с интерфейсами можно найти и при использовании JSON, XML, кастомного создания пакета данных HTTP (привет попыткам отправить электронное письмо из веб-сервера с вложениями самописными скриптами), формирования HTML с пользовательскими данными.
Если взаимодействие правильно организовано, то суть данных не должно приводить систему в непредсказуемое состояние.
PS: В базу данных, вообще, можно записать blob с произвольными бинарными данными в одно поле, гигабайт размером - как здрасти. И в этом блобе будете искать кавычки?))

Answer 2

[Melkij]

Там много скобок, и символов которые могут без проблем сломать любое хранение в базе данных, либо просто сломать сам код.

Чего это? Символы как символы. Даже печатные из простого элементарного ASCII, а не смайлики разные.

При выводе данных куда-либо либо передаче куда-либо нужно элементарно соблюдать формат вот и всё. Если вам нужен JSON - будьте добры закодировать именно в JSON, а не конкатенировать входную строку как есть с кавычками похожими по виду. Нужно отправить с SQL запросом - prepared statemennts api к вашим услугам. Вывести в html? Вот вам htmlspecialchars предназначенный для корректного отображения произвольных данных в HTML. Всё просто и элементарно. Нет никаких "опасных хакерских символов". Есть разработчик проигнорировавший требования формата.

Это вообще про произвольные данные. А пароли в открытом виде и вовсе не хранятся. Из-за откровенно безалаберного обращения с паролями в PHP и вовсе существует отдельный password_hash.

Comments

[Alexander Lamdan]

Тогда смотрите, представим мы хешируем пароль просто размеров в 50 символов, с разными символами.
Чтобы захешировать такой пароль надо обработать его верно? Как будем обрабатывать? Как строку, не числом же.
Я когда читал про то как работает SALT, BCRYPT и так далее, там написано четко что они получают строку, и сами уже ее обрабатывают и выходит в виде HASH подобие.

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

Ведь они все принимают строковый формат пароля, который потом хешируется путем SALT, BCRYPT, AES и тд.

[Сергей Горностаев]

Alexander Lamdan, для любого кода строка - это поток бессмысленных байт, которые среда выполнения никак не интерпретирует. Пофиг "ядру хеширования" какие там символы в строке, для него это просто набор ноликов и единичек.

[Melkij]

алгоритм хэширования вообще binary safe. На уровне C вы передаёте указатель на участок памяти и длину этого участка памяти. Что там в этом участке памяти не волнует вообще никого. Любые бинарные данные.

[ThunderCat]

Alexander Lamdan,

Как строку, не числом же.

Плохо когда каша в голове...

там написано четко что они получают строку,

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

Answer 3

[Vitsliputsli]

Хороший вопрос.
Для того чтобы избежать этой проблемы память любой программы делят на 2 части: область кода и область данных. Программа может писать в область данных, но не в область кода. В области данных может лежать что угодно, что бы там ни было, оно не вызывает никаких действий, т.к. это не исполняемый код, поэтому ничего поломать не может.
Часто бывает, что мы вынуждены в области данных хранить код, например для работы с СУБД, там хранится код SQL. Здесь безопасность контролирует программист, если он в этот код будет подставлять произвольные данные, то это может привести к поломке на стороне СУБД. В данном случае, это решается передачей кода SQL и изменяемых данных отдельно друг от друга.

Answer 4

[GGHotDog]

Можно сделать по разному, например в php есть htmlspecialchars который превращает опасные символы в безопасные

Comments

[Alexander Lamdan]

И тогда можно распрощаться со своим паролем который ты сгенерировал, смысл этого делать?

[Дмитрий]

Не нужно хранить пароли в открытом виде, и проблем не будет

[GGHotDog]

Alexander Lamdan, А вообще в бд заносится не сам пароль, а его шифр(хэш), тот же md5, а касаемо того что должно хранится на сервере в не зашифрованном виде(допустим логин) придерживается принципа который я описал выше. Сервер не хранит твой пароль, он хранит его хеш, когда ты вводишь пароль он его так же шифрует и сопоставляет с тем что у него есть в бд

[GavriKos]

Alexander Lamdan, а почему распрощаться с паролем?
Если что цепочка такая - при регистрации с паролем фронт и бек проводят ряд манипуляций (например base64 на фронте чтобы в апи пролез нормально, потом md5 на беке и в базу)
При авторизации проводятся ТЕ ЖЕ манипуляции - и если результат совпадает - то пароль верен. По факту сравниваются не исходные пароли, а результаты манипуляций с ними.

[Alexander Lamdan]

GGHotDog, это то понятно, просто перед хешем, сам хеш получает строку.
Ну никак иначе.
Если я выведу var_dump на пароль перед хешем, я получу строку.
И сам хеш обязан это принять.
Хеш может быть и хеширует пароль, но игнорировать символы он никак не может.

[GGHotDog]

Alexander Lamdan, Переменная может содержать и кавычки и всё что угодно, основная опасность происходит когда ты допустил строку с PHP отправляешь на обработку SQL, внутри PHP она навредить не сможет

[GavriKos]

Alexander Lamdan, base64 в помощь

[Alexander Lamdan]

GavriKos, все пароли которые мы отправляем на хеширование в aes, bcrypt, salt, md5 и тд, отправляются как строка и никак иначе, даже base64, должен принять строку.

Но на уровне ядра этой функции на уровне интерпретатора Python, PHP, Bash и других скриптовых языков, там как то же переводят в строковое значение, а значит его ставят в переменную где имеются кавычки.

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

[GavriKos]

Alexander Lamdan, ничего не понял. Ну передали в base64 строку с спецсимволами. base64 сделала из нее строку без спецсимволов. Потом в хеш все это.
Откуда какая то проблема возьмется? Строка то эта не в коде написана, а лежит в памяти, как набор байт, бери и работай с ней.

Если спуститься до низкого уровня - строк нет. Есть последовательность байт. Ее преобразуют в другую последовательность байт.

Answer 5

[Станислав Бодро́в]

Кто вообще в здравом уме хранит пароли? Сколько можно твердить постоянно об одном и том же? В базе данных не должны храниться пароли. В базе должны лежать минимум sha256. А по правильному там должен лежать результат многораундового хэширования и ещё с солью.