Форум PHP

Здравствуйте, есть сайт, в файле config есть данные доступа, так и прописаны

... define("ADMIN_USERNAME", "AdminName"); define("ADMIN_PASSWORD", "AdminPassword"); ...

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

Хранят не пароль, а его хеш. Если доступна версия 5.5, то еще лучше http://www.php.net/manual/ru/book.password.php.

аа... в куках хранить этот хеш безопастно? (простите за нубские вопросы)

По хеш нельзя восстановить истинный пароль, тем более по хеш формируемый с помощью password_hash() доступной в новых версиях. Храните.

> Храните.
Это как прикажите понимать?
Куки воровали и всегда будут воровать.
Так что хранение хеша пароля в куках это уже сто лет как табу.
Обычно хранят сгенерированную метку (это может быть и хеш, но только не от самого пароля)
которая время от времени обновляется.

>По хеш нельзя восстановить истинный пароль
Но его иногда можно подобрать. Все зависит от пароля и алгоритма хеширования.

А метку значит своровать нельзя? Какая разница что своровано, если это кука-идентификатор.

Замучтитесь подбирать.

1) действие метки ограничено по времени (следовательно своровать один раз не достаточно)
и автологин у хороших программистов с ограниченным функционалом по безопасности, т.е. для радикальных действий с аккаунтом нужен пароль для подтверждения действия.
2) лично я никогда не буду "светить" хеш пароля, даже "солёного", как будут поступать остальные это их проблемы ;)

>Замучтитесь подбирать.
подбирают уже много много лет и поверьте базы там не маленькие.
подобранный однажды пароль, остается в базе навсегда.
как думаете за 8 лет (первый по ссылке 4800 миллиарда записей по данным на 2008 год) сколько можно подобрать?
http://raz0r.name/obzory/top-10-luchshix-onlajn-servisov-po-rasshifrovke-xeshej/

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

Попробуйте перебрать хеш длиною в 255, получиться расколоть, поделитесь.

какой же вы упертый
1) автологин по хешу пароля
воруем хеш получаем доступ к аккаунту (до момента пока пользователь не сменит пароль + есть шанс подобрать пароль по хешу).
2) автологин по метке
воруем метку получаем доступ к аккаунту на некоторое время (до обновления метки)
возможность подбора пролля по хешу отсутсвует
конечно по теории вероятности пароль можно угадать, но я бы на это сильно не расчитывал.

Не вижу смысла болтать попусту.

а зачем шифровать значения в куках? разве их нельзя после кражи просто подставить ?

куда?

по безопасности веб приложений написаны сотни книг не в одну сотню страниц, как думаете зачем?

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

В coockie можно хранить такой хеш, что если вы его "утащите", то вам зайти не удасться. Например,
соединить перед хешированием соль+логин+мыло+первые октеты ip(даже при динамическом ip они меняются очень редко). В таком случае если вы утащите куку и вставите в свой браузер, то толку от этого 0, если вы не находитесь на обслуживании того же самого провайдера. Если смущает ip, то можно брать и другие данные пользователя(браузер, разрешение экрана и пр.), или комбинации пользовательских данных. А при первом заходе на сайт высчитывать хеш на основе пользовательских данных и сравнивать его с хешом в печеньке, если все совпадает, то создать сессию с соответствующими авторизационными данными.

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

Привязать пользователя к одному компьютеру? А Вы жестокий человек... :)

читейте внимательнее, речь об автологине, привязка и отвязка проходит незаметно для пользователя

Извиняюсь, последнему предложению не уделил должное внимание.

кстати в вк вообще все просто
заменяешь в своей куки хеш и опля - логинишься в чужой акк

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

>Попробуйте перебрать хеш длиною в 255, получиться расколоть, поделитесь.

Легко! Я уверен что Вы прекрасно понимаете, что если в пароле можно использовать все символы utf8 с максимальной длиной в 1000 знаков, то это еще не означает что кто-то себе создаст пароль с русскими, английскими, арабскими буквами разных регистров и со всеми остальными символами, длиной в 1000 знаков.
Вы сами-то, какие пароли создаете? Думаю что они содержат 1 алфавит (скорее всего латиница), 1 регистр и пару цифр длиной не более 15 символов.
Об этом Вам и говорил "Valick", что есть некая база с типовыми паролями (типа: 77777qwert).
Но если даже не использовать базу, то перебирать мы будем не из 1048320^1000 а из 36^15. Согласитесь, что "расколоть" за один день, вполне реально.

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

Пощупайте функции hashing в РНР 5.5, отдавая функции один и тот же пароль, и смотрите результат. Не занимайтесь пустыми разговорами и домыслами.

а где, где же сам пароль хранить?

в голове :)

я совсем об этом забыл))
но идея верна

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

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

Но лучше вместо голого пароля хранить его хеш — это общепринятая практика. Ну ещё нужно хранить этот файл за пределами document root веб сервера.

<? define("ADMIN_USERNAME", "AdminName");                          // должно быть без пробелов - форумный движок сам так порезал define("ADMIN_PASSWORD", "cf1aaeefbebc761a2583e0a985553b9f104 5f6f5b6c7bf1a1ee8abdb2ed9ce3ce4a844 bc010f6ab0338dd24457fc6f6fd573aafcb f894ddfabbaa0af9f1924f2"); // ... в процедуре проверки пароля if ( hash('sha512', $_POST['password']) != ADMIN_PASSWORD ) {   die('not4u'); }

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

Если хотите ещё большей безопасности, то прикрутите OAuth аутентификацию, например, гугла. Тогда для получения доступа к аккаунту на вашем сайте, хакерам придётся взломать ваш аккаунт в гугле. А это несоизмеримо сложнее, чем сломать ваш сайт.