в общем, на моей страничке есть форма для авторизации пользователей. Данные о пользователях хранятся в таблице MySQL (логин, пароль и т.д.). Короче все стандартно... 
Проблема в том, что задание стоит следующим образом: ни в программном коде, не в базе данных, пароль не должен храниться в открытом виде (для обеспечения безопасности).

Подскажите, плз, в каком направлении двигаться...

пароль, которых хранится в базе, можно хэшировать функцией sha1()

Добавлено через 1 минуту и 44 секунды
И давайте разделять понятия.
Если речь идет о безопасности, то давайте говорить о безопасности.
Если речь идет о некоем "задании", то давайте забудем о безопасности, и будем говорить об этом задании.

manson, вариантов два:
1. использовать стандартные ф-ции шифрования\хеширования
2. написать свою 

ммм... я так понял речь идет о пхп-функциях шифрования?   

храни в базе хэш пароля

не шифрования, а хэширования.
пример доступен в документации, по имени функции.

Манул рулит, в нем есть примеры использование функции шифрования:
Взято из мануала MD5


SHA1



Ну а если так то :



То есть перед тем как пароль в БД запихнуть переменная с паролем скажем она методом пост передается $_POST['passwd'] должна пройти через функцию шифрования, можно записать так sha1($_POST['passwd']); и отпровляем ее в БД, только лучше отправить переменную $cr так как в ней функция шифрует полученный пароль от формы.

OutlawZ, не ьщифрование, а хэширование

хэш sha1,md5,etc еще можно "закриптографировать" md5crypt http://www.usenix.org/events/usenix99/prov...tml/node10.html

так как через "Радужные таблицы" можно перебрать хэш и взломать пароль http://ru.wikipedia.org/wiki/Радужная_таблица

я вот ковырял PostfixAdmin



Это сообщение отредактировал(а) gcc - 16.9.2009, 14:54

Большое спасибо, OutlawZ! 
Только когда я обратно буду из базы доставать, как мне расшифровать?

Да тебе не нужно расшифровывать, хэшь не имеет дешифратора (кроме грубой силы, о_О и не только)!!!
Тебе всеголишь нужно будет сравнивать хэш пришедшего пароля с хэшем в базе

Это сообщение отредактировал(а) NewDima - 16.9.2009, 14:46

to NewDima! 
Логично. Спс

Что бы сравнить хеши можно сделать что то вроде такого, из базы берем хеш по имени который было введено т.е придется составлять запрос такого вида:



Ну думаю как то так )))

Забыл сказать что переменную $_POST['passwd'] надо перед тем как помещать в запрос проверить на опастные символы , с помощью рег выражения что бы не было ошибки запрос или какие нить хулиганы не получили доступ к бд.

Это сообщение отредактировал(а) MoLeX - 16.9.2009, 16:11

OutlawZ, вы забыли кое-что в своем замечательном коде.
Мне кажется, вы очень торопитесь все время.

OutlawZ, зачем все эти лишние телодвижения?

только 

иначе ошибки будут.

ну, и перед этим не забыть

а то многие забывают.

в новой Опере подсветка не работает



это само собой

 Может не надо показывать новичкам такой пример ###кода? Они могут подумать, что это нормально.

nerezus,покажи свой пример не 

MoLeX, не, ну хотя бы следование элементарным правилам безопасности (mysql_real_escape_string)

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

Просто я не совсем сторонник использования mysql_real_escape_string и уж тем более "WHERE `name` = '".$_POST[name]." ". Любые "пришлые" переменные нужно пропускать через фильтр, а не вставлять их прямо в запрос

зы
и всё же $_POST['name'] а не $_POST[name]

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

я думаю, что nerezus, как раз имел в виду подстановки. 
поскольку при их использовании просто не возникает странных идей типа "я не сторонник корректного составления SQL запросов". мнения программиста никто не спрашивает, система молча занимается всем этим сама. В этом смысле подстановки гораздо безопаснее для начинающих программистов.

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

вот именно, начинающий программист должен заботится о безопасности "приходящих" данных, а не полагаться только на простое экранирование. Всё что приходит из $_REQUEST как минимум должно иметь вид

что касается самого вопроса, то однозначно в базе хранится не пароль а хотя бы md5(пароль).. в принципе этого достаточно. А как только пришли данные $_POST['password'], то их сразу переделываем в $password = md5($_POST['password']). Меня иногда поражают сайты где при восстановлении пароля они мне присылают мой пароль в открытом виде 

мне всегда странно 
читать такие советы
на форуме
ведь если бы форум им следовал
то такой совет 
невозможно было бы написать

Ипатьев, форум и средне статистический сайт - это не одно и тоже. Так что сравнивать их не следует

тогда напишу, чтобы Ипатьев понял
$_REQUEST - это ассоциативный массив, состоящий из содержимого $_GET, $_POST, $_COOKIE и $_FILES, т.е. то что приходит (может приходить) от пользователя... Указав $_REQUEST я тем самым расширил $_POST, или чтобы совсем понятно было, то указал не "яблоко", а "фрукты"

Это сообщение отредактировал(а) Gold Dragon - 17.9.2009, 09:52

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

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

согласен, что входящие данные не обязательно так усердно проверять, но привыкать к этому нужно и необходимо.. Всё конечно зависть от целей и задач самого проекта. Хотя с другой стороны, я давно написал класс, который имеет набор часто используемых фильтров, например, таких как, мыло, сайт, телефон, имя, только цифры, только буквы. Он маленький и подцепив его в любой проект, я забываю про всякое экранирование 

Рекомендую автору топика не повторять ошибку Gold Dragon, который, даже после всех объяснений все равно не понял, что фитьтрация данных и составление SQL запросов - совершенно разные, никак не связанные между собой вещи.
И привязывать одно к другому - это в конечном итоге нанести вред безопасности сайта.
Тем более, что фраза про "забываю про всякое экранирование" - не более чем фантазия, и в реальности забыть не получится. Что я проиллюстрировал примером выше.

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

вот например это что такое вообще???
Конечно это абсолютно разные вещи, например, такие как бензин и машина, кирпич и раствор... 

Скрипт получает данные, они должны быть приведены в соответствие и составлен запрос. Каким это образом будет сделано решать разработчику. Я показал что существует ещё вариант кроме как экранирование. Если Вас не устраивает слово "фильтрация", то тогда замените его на "приведение данных в соответствие...". И экранирование к этому тоже относится(!). А вот то что Вы вставляете в SQL-запрос глобальную переменную - это не самый лучший вариант с точки зрения безопасности. Если вы пишите свои проекты исключительно для собственных нужд, то конечно это всё необязательно делать.. Но если проект в Интернете, да ещё и активно "общается" с пользователями, то безопасность должна занимать чуть-ли не половину проекта

дело в том, что данные в запрос не обязательно попадают из пользовательского ввода.
а данные, введенные пользователем, не обязательно попадают в SQL запрос.

M IZ@TOP

Не кормите Троллей!

слушаюсь!

Хотя я не думаю, что это тролль. 
Скорее - добросовестное заблуждение.

Это сообщение отредактировал(а) Ипатьев - 17.9.2009, 12:12

А где тут лишние телодвижения? по мне так вполне нормальный запрос на авторизацию..

Ипатьев, не дождешься   

зачем использовать два запроса, вместо одного?!

Добавлено через 21 секунду

Оо

Да не, там, вроде, в обоих случаях запрос был один.
Просто в первом хэш сравнивается в скрипте, а во втором подставляется прямо в запрос.
Разница только в обработке, но не принципиальная. Хотя привычнее все в запросе писать.

Gold Dragon, 
Я так же использую класс с фильтрами очень удобно 
+

Ипатьев, 

Как Вы используете библиотеку PEAR DB то же экранируете  или в фреймворке тоже экранируете .
Об этом и говорил Gold Dragon,  установил класс (фильтр) для данных, конкретной области , в том числе и экранирование данных, и забыл.



Это сообщение отредактировал(а) Sentox - 17.9.2009, 16:28

Sentox, Вы немного путаете понятия. Фильтры на данные пользовательского ввода в программе - это логика (бизнес-логика, если хотите), а экранирование данных передаваемых в SQL-запрос обязательная процедура, которая ну никак не связана с тем, фильтровали вы данные прежде или нет.

well
когда я вижу фразу

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




Это сообщение отредактировал(а) Ипатьев - 17.9.2009, 17:24

Gold Dragon и я не это аргументировали.
То что  это понятно и так, и в аргументацию я привёл  , что само собой обрабатывается своей предметной областью.

Если Вы вчитаетесь в 

увидите разницу, что человек , не берусь утверждать, реально не понимает абстракции и наверное ООП  .

Это сообщение отредактировал(а) IZ@TOP - 17.9.2009, 17:31

Вы глубоко заблуждаетесь   

Давайте не будем говорить за Gold Dragon.
Приведите пример того, о чем говорите вы лично.
Возможно, мы говорим об одном и том же, но хочется разобраться.
О какой предметной области и о каких фильтрах идет речь?

Лично я подготовку данных для SQL запроса не называю словом "фильтрация". Поскольку такие действия фильтрацией, собственно, не являются. Возможно, разночтения только в этом.

Но, тем не менее, если вы наборсаете небольшй алгоритм, вида "вот фильтрация, делает то-то, вот квотинг, вот запрос, а предметная область 0 это такие-то данные ", то я буду вам очень благодарен.

Вот о чём и спор.. Ипатьев, понимаете, Вы пытаетесь навязать своё понимание терминологии всем., но чем хорош русский язык что в нём может родиться существительное, прилагательное или глагол лишь только по тому что человек ЭМОЦИОНАЛЬНО так решил.. вот например, "Чайник уже звенит от свиста" или более понятно "голова болит от понимания прочитанного".. Я же писал что если Вам не нравится слово "фильтрация", то замените его "приведение данных в соответствие". Вы привыкли вставлять глобальные переменные с экранированием сразу в запрос, а я приучил себя все глобальные отдавать локальным, локальные приводить в соответствие, запрос присваивать переменной, а уж потом переменную отдавать в запрос. 

Вот скажите мне зачем мне это нужно

если у меня, например, есть такое

кстати, вот это вообще считаю безобразием, использовать глобальную переменную

почему? ведь изначально для порядка рекомендуется не создавать лишних переменных, легче с ними потом обращаться

если есть, то не нужно.
А если речь идет не о целочисленном значении, а строковом, вы как поступаете?

Добавлено через 30 секунд
bars80080, согласитесь, это совершенно не принципиальный вопрос.

ну  как-то имея глобальную переменную типа $_POST лучше её оставлять в первозданном виде.. А создавая локальную переменную в функции или классе.. так она после обработке исчезнит

так я уже писал есть класс, в котором есть следующие функции
- телефон
- mail
- сайт
- только цифры
- только буквы
- буквы, цифры, знаки типа точки

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

Добавлено через 35 секунд
просто после обработки у меня по определению в запросе не будет "неожиданностей" 

Ну, на первый взгляд, такой подход не грозит немедленной опасностью. 
Он не совсем совместим с идеологией баз данных, но в небольших проектах, ориентированных только на веб, без развитого функционала - вполне можно применять.

Но другим его советовать я бы воздержался. 

Это сообщение отредактировал(а) Ипатьев - 17.9.2009, 21:32

есть такое


и такое есть


ну, это самый оптимальный, ИМХО, метод


у меня в обработке есть формат all, в нём с данными ничего не делается. данные только переприсваиваются массиву заявленных входящих переменных, а если таковой нет, то устанавливается значение по умолчанию. так что, неожиданности возможны
с другой стороны, когда я составляю запрос к БД, то делаю это примерно так:

где класс БД сам всё обработает, и тут уж точно у меня и голова не болит, и все обработки будут применены именно там, где им следует быть

странное суждение... мне кажется что наоборот в больших проектах "экранирование", фильтрацию", "приведение в соответствие" вообще нужно именно выделять в отдельный класс и расширять функционал... В настоящее время я даже сделал класс который просто обрабатывает все "приходящие переменные", т.е. получает к примеру $_POST, а возвращает массив ключ->значение

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

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

   Ох и консерватор
Предлагаю написать разрабам PHP убрать в нём ООП - такой себе огромный костыль, который в принципе никому не нужен так как есть стандартные механизмы работы с данными.
Впринципе это уже холивар на тему стоит ли применять абстракцию и ни к чему не приведёт.

bars80080



Что и требовалось доказать   

А это не зависит от размеров проекта. Просто нужно разделять три операции:
1. Валидация данных. Валидация - проверка дынных на смысловое содержания. Уже из определения оно не может быть централизовано, т.к. система в целом не должна даже представлять какого вида данные ожидает отдельная ее часть. При этом данные никоим образом не должны измениться -- если какие-то данные не подходят по смысловой нагрузке, то они должны быть отправлены на повторный ввод пользователю.
2. Подготовка данных к сохранению. Включает только преобразование данных в безопасный для сохранения вид. При этом данные никоим образом не должны измениться.
3. Подготовка данных к отображению. Опять же, данные ни коим образом не должны измениться. В большинстве случаев, пользователь должен лицезреть именно то, что он ввел в систему. Если это было нечто вроде 

то в таком виде он и должен их просмотреть. Наглядный пример в этом же сообщении строкой выше )
Исключение составляют только задачи, в которых нужно интерпретировать некоторые теги. Например, пользователю разрешено использовать html теги a, strong, em. И вот только теперь, в этом частном случае,  можно говорить о фильтрации. Тут нам нужно отобразить интерпретировать нектороые теги как теги, а некоторые, как текст, т.е. применить фильтр


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

Я вот одного не пойму, почему бы не отказаться от экранирования и не работать с prepared statement?

Добавлено через 6 минут и 4 секунды


Понимаете ли, подготовка данных для SQL это действительно не фильтрация. Причем даже в буквальном прочтении слова "фильтровать" оно не подходит.

1. От необходимости экранирования избавляют не prepared statement, а использование placeholders
2. Когда вы вызываете, например, PDO::prepare() это не имеет никакого отношения к prepared statement
3. А какая разница? Таким образом вы просто перекладываете эту работу на одну из стандартных библиотек, но экранирование все равно происходит ). Тут же речь не о том, как именно это делать, а о том что это делать нужно в принципе и где своевремменно это делать

Это сообщение отредактировал(а) solenko - 18.9.2009, 08:08

Лично я - только "за". В смысле посоветовать другим. Лично мне способ не нравится за "ненаглядность".
Но в этом удивительном топике речь идет совсем о другом. 

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

Этих способов, включая изобретения из этого топика я насчитал уже 4:

1. строки прослешиваются и заключаются в кавычки, числа приводятся к нужному типу.
2. prepared statements, они же подготовленные выражения, они же placeholders, они же употребленное мной выше слово "подстановки": запрос отдельно - данные отдельно.
3. редко используемая hex-string
4. способ Gold Dragon: физическое удаление спецсимволов из строки.

Самым безопасным следует признать способ номер 2. Хотя не без оговорок. Ибо ничто не помешает программисту собирать запрос с плейсхолдерами точно так же динамически. 
Самым неудачным - то, что придумал Gold Dragon. База данных задумана так, чтобы хранить все символы. Любые. А сознательно ограничивая функциональность БД, мы заранее раскладываем себе грабли, на которые впоследствии обязательно наступим. 

Это сообщение отредактировал(а) Ипатьев - 18.9.2009, 09:35

С PDO как раз не работал. Но Ипатьев прав, я говорил о pg_prepare()
ibase_prepare()

Ипатьев, ну ты прям меня на пьедестал определил  философ...

А может вернёмся к "Авторизации"... Я вообще-то и не утверждаю что база не должна хранить всё что хочется... Вот только ЗАЧЕМ?  Я утверждаю что ВСЕ данные должны приводится в соответствие с задачей... Лично моё мнение, что в имени пользователя (логине) не должно быть кавычек и других спецсимволов, поэтому мне не нужно это экранировать, и я их просто убираю, ну или предлагаю пользователю самому их убрать. Пароль - думаю букв и цифр больше чем достаточно для составления пароля. Да и я не трогаю первоначальные данные вообще и оставляю их такими какими они пришли, для этого и существуют локальные переменные.

Ну уэ если на то пошло, то куда приятнее читать код когда используются функции класса (главное красиво и понятно назвать)


Да и что вы прицепились к слову ФИЛЬТРАЦИЯ?  я уже давно поправился и сказал что имел в виду и даже пару раз уже озвучил конкретно 


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



Это сообщение отредактировал(а) Gold Dragon - 18.9.2009, 12:36

Gold Dragon, вот в этом посте solenko очень подробно все расписал.
У него обработке данных посвящено три пункта. А ваше 

- это только первый из них.
И с ним никто не спорит.
Просто есть еще два.

 Да зачем?
Но в нем нне будет следующих косяков:
1) Порчи входящих данных. Ты обрабатываешь входящие данные а потом работаешь с ними. При этом по ним непонятно, обработаны они или нет, поэтому из-за человеческого фактора ты можешь допустить SQL-inj.
При правильной работе с данными SQL-inj исключен и человеческий фактор не может на него повлиять.
2) Входящие данные могут быть использованы в нескольких местах(статистика и т.д.), при этом ты рискуешь, что они уже будут испорчены на предыдущем этапе.

 Есть правило не портить входящие данные никогда. Не раз сталкивался с ним в литературе.

 Я тоже. И я с тобой согласен. Причем это мнение разделяют уважаемые члены phpclub.
Но у парней из Зенда другое мнение - попробуй сдать тест на ZCE. Я завалил разделы Security и PHP4(все остальное на Excellent). Security завалена по этой причине. Когда же стал читать их ман, то увидел, что у нас просто разница в терминологии, и обработку по непонятным причинам они называют фильтрацией.

M IZ@TOP

Модератор: Давайте вернёмся к теме обсуждения.

Предлагаю закрыть тему непонимания со всех сторон и просто перечитать этот пост столько раз, сколько необходимо, чтобы он для вас стал мантрой. Разумеется есть всякие ситуации, но описанные solenko три пункта - это заветы, которым необходимо следовать, потому, что это логично, это правильно.
Не думаю, что тут можно что-то еще добавить.

Добавлено @ 15:47

Я за понимание. Когда я приезжаю на PHPConf, где могу пообщаться с гуру интернет-промышленности, у меня с ними не возникает непонимания из-за различия в терминологии, потому, что я не считаю, что в нашем ремесле дозволены подобные вольности. Я знаю как правильно, пусть и не всегда знаю почему именно, но это неоспоримо. 
Это что касается нас.
Парни из Зенда, у них менталитет другой, язык другой, сообщество отличается. Но это уже другой вопрос.