Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
Самоучитель PHP 5 / 6 (3 издание). Авторы: Кузнецов М.В., Симдянов И.В. MySQL на примерах. Авторы: Кузнецов М.В., Симдянов И.В. Объектно-ориентированное программирование на PHP. Авторы: Кузнецов М.В., Симдянов И.В. PHP 5. На примерах. Авторы: Кузнецов М.В., Симдянов И.В., Голышев С.В. Социальная инженерия и социальные хакеры. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум PHP

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: защита пароля
 
 автор: Dazzl   (19.04.2014 в 13:40)   письмо автору
 
 

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


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


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

  Ответить  
 
 автор: confirm   (19.04.2014 в 13:51)   письмо автору
 
   для: Dazzl   (19.04.2014 в 13:40)
 

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

  Ответить  
 
 автор: Dazzl   (19.04.2014 в 14:16)   письмо автору
 
   для: confirm   (19.04.2014 в 13:51)
 

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

  Ответить  
 
 автор: confirm   (19.04.2014 в 15:55)   письмо автору
 
   для: Dazzl   (19.04.2014 в 14:16)
 

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

  Ответить  
 
 автор: Valick   (19.04.2014 в 18:47)   письмо автору
 
   для: confirm   (19.04.2014 в 15:55)
 

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

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

  Ответить  
 
 автор: confirm   (19.04.2014 в 19:01)   письмо автору
 
   для: Valick   (19.04.2014 в 18:47)
 

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

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

  Ответить  
 
 автор: Valick   (19.04.2014 в 19:12)   письмо автору
 
   для: confirm   (19.04.2014 в 19:01)
 

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

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

  Ответить  
 
 автор: confirm   (19.04.2014 в 19:32)   письмо автору
 
   для: Valick   (19.04.2014 в 19:12)
 

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

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

  Ответить  
 
 автор: Valick   (19.04.2014 в 19:44)   письмо автору
 
   для: confirm   (19.04.2014 в 19:32)
 

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

  Ответить  
 
 автор: confirm   (19.04.2014 в 19:54)   письмо автору
 
   для: Valick   (19.04.2014 в 19:44)
 

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

  Ответить  
 
 автор: Dazzl   (19.04.2014 в 22:17)   письмо автору
 
   для: confirm   (19.04.2014 в 19:54)
 

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

  Ответить  
 
 автор: Valick   (19.04.2014 в 22:45)   письмо автору
 
   для: Dazzl   (19.04.2014 в 22:17)
 

куда?

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

  Ответить  
 
 автор: confirm   (20.04.2014 в 08:58)   письмо автору
 
   для: Dazzl   (19.04.2014 в 22:17)
 

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

  Ответить  
 
 автор: tvv123456   (27.04.2014 в 21:46)   письмо автору
 
   для: confirm   (20.04.2014 в 08:58)
 

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

  Ответить  
 
 автор: sasha12342   (29.04.2014 в 10:57)   письмо автору
 
   для: tvv123456   (27.04.2014 в 21:46)
 

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

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

  Ответить  
 
 автор: Valick   (29.04.2014 в 11:11)   письмо автору
 
   для: sasha12342   (29.04.2014 в 10:57)
 

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

  Ответить  
 
 автор: sasha12342   (29.04.2014 в 11:44)   письмо автору
 
   для: Valick   (29.04.2014 в 11:11)
 

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

  Ответить  
 
 автор: moonfox   (21.04.2014 в 01:54)   письмо автору
 
   для: Valick   (19.04.2014 в 19:44)
 

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

  Ответить  
 
 автор: Valick   (21.04.2014 в 09:16)   письмо автору
 
   для: moonfox   (21.04.2014 в 01:54)
 

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

  Ответить  
 
 автор: sasha12342   (29.04.2014 в 11:32)   письмо автору
 
   для: confirm   (19.04.2014 в 19:32)
 

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

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

  Ответить  
 
 автор: confirm   (29.04.2014 в 17:51)   письмо автору
 
   для: sasha12342   (29.04.2014 в 11:32)
 

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

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

  Ответить  
 
 автор: moonfox   (21.04.2014 в 01:53)   письмо автору
 
   для: confirm   (19.04.2014 в 15:55)
 

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

  Ответить  
 
 автор: Valick   (21.04.2014 в 09:08)   письмо автору
 
   для: moonfox   (21.04.2014 в 01:53)
 

в голове :)

  Ответить  
 
 автор: moonfox   (21.04.2014 в 15:09)   письмо автору
 
   для: Valick   (21.04.2014 в 09:08)
 

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

  Ответить  
 
 автор: Саня   (29.04.2014 в 18:44)   письмо автору
 
   для: Dazzl   (19.04.2014 в 13:40)
 

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

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

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

<?
define
("ADMIN_USERNAME""AdminName");
                         
// должно быть без пробелов - форумный движок сам так порезал
define("ADMIN_PASSWORD""cf1aaeefbebc761a2583e0a985553b9f104 5f6f5b6c7bf1a1ee8abdb2ed9ce3ce4a844 bc010f6ab0338dd24457fc6f6fd573aafcb f894ddfabbaa0af9f1924f2");

// ... в процедуре проверки пароля
if ( hash('sha512'$_POST['password']) != ADMIN_PASSWORD ) {
  die(
'not4u');
}

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

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

  Ответить  
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования