Форум PHP

У меня наверное не лучший способ.
Я просто в началие файла с расширением РНР пишу die()
Наверняка есть способ получше?

Э... ну вообще лучшим вариантом является хранение в базе с md5-шифрованием... Ну можно ещё в локальных базах DBM... ну и крайний случай - в тестовых файлах, но для этого надо париться над защитой этих файлов со стороны сервера.

Во-во я слышал про md5-шифрование, можно по-подробнее, буду благодарен!
А то учебник на английском не разобрать!

Подробнее можно почитать в теме по ссылке http://www.softtime.ru/forum/read.php?id_forum=1&id_theme=138

Если пароли нужно хранить именно в файлах, то способ подходящий... ещё можно файлы с паролями хранить в отдельной директории, доступ к которой из браузера запрещён при помощи файла .htaccess - скрипты на сервере к таким файлам обращаться смогут.

Почитаем!
Да братва, вы быстро отвечайте! :)
Рэспект вам!

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

у себя я делал следующим способом:

все храниться в mySQL в зашифрованом виде с помощью mySQL функции AES_ENCRYPT, ключем для каждого пароля являеться свое имя пользоваетеля. Получаеться ключ везде разный, и при этом нигде в скриптах не сетиться..

Мне нравится!
AES_ENCRYPT-в указателе нет такой функции, есть пример?

Эти функции добавлены начиная с MySQL 4.0.2. Вот пример использования функции шифрования и дешифрования:

INSERT INTO t VALUES (1,AES_ENCRYPT('text','password')); SELECT @password:='my password'; INSERT INTO t VALUES (1,AES_ENCRYPT('text',@password));

а коментарии забыл поставить?
1строка заносит в базу зашифрованный пароль
???? что-то выбирается
и снова заносится что-то связанное со второй строкой :)

Ну на самом деле всё просто

INSERT INTO t VALUES (1,AES_ENCRYPT('text','password'));  SELECT AES_DECRYPT(name,'password') FROM t;

спасибо очень помогло :)

Не советую всётаки заморачиваться этим способом, а лучше приглядеться к md5-шифрованию. Больше доверия (md5-хэш до сих пор никто не смог расшифровать), меньше проблем.

пробую всё!

ИМХО md5 тоже не на 100% надежно.... расшифровать можно все... вопрос времени... но ведь можно использовать все в совокупности.. да, геморно.. но если вы хотите получить более менее хорошую сиепент защиты то это не такая уж ибольшая цена.
Я щас хочу немного переделать скрипт авторизации свой (в нем использую сппсоб который описал выше), хочу добавить следующее: когда в БД шифруеться пароль и имя, имя шифровать чистым, а пароль шифровать уже преобразованным в md5 hash.. это ИМХО усилит защиту... тут самое главное не перемудрить)))

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

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

Мущыны, вы предлагайте хранить пароли в базе данных,
а чтобы соединиться с базой нужен пароль, а не соединившись с базой его не возьмёшь=>
приходится пароль для доступа к базе хранить в файле.

тут уже собственно другой вопрос....тут дело стоит за дырами в скриптах и броней на сервере.. к mySQL данные для соединения придеться храниться открытыми.. тут уж ничего не поделаешь.... шифрование паролей - тут речь я вел о системах авторизации пользователей...
можно впринципе защитить и mySQL пароли.. была у меня промежуточная версия моей, так сказать cms, в которой при авторизации вводился 3 параметр - ключ который использовался для расшифровки конфиг файла, зашифрованного mcrypt функциями.. но впоследствии я отказался от этого.. слишком грамоздко, неудобно, непрактично (ИМХО). поэтому если хотите скрыть mySQL пароли - посторайтесь защитиь директорию с файлами серверными возможностями....

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

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

Может ли пользователь просмотреть содержимое файла РНР?

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

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

И как раз по этому случаю у меня случилось вот что:
зашёл я на страна.кз
а меня он приветствет под именем Evg ! Ну я их немного наказал :)
смотрю я в куку а там
LOGIN
evg-skorp
strana.kz/
1536
924895232
30050908
3201850272
29739168
*
как это могло случиться?
И при записи в куку заносить туда только имя пользователя или ещё что?
Зарегестрировался я у них сравнил свою куку всё одинаковое только разный логин

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

а в куках что лучше хранить пароль или какой нибудь идендификатор

Думаю, логин и хэш пароля - достаточно безопасно.

Не ну меня всё равно мучеит вопрос, как создалась кука если с рабочего комп-ра никто туда сроду не ходил.
Ну а тем более пользователь была из Владивостока(не имеет значения от куда)!

Я бы предположил кражу сесии - это распространенная проблема.