алгоритм:
поступили данные?
очищаем от мусора, проверяем пользователя в бд
*Если пользователь найдет сверяем поступивший пароль
если пароль совпадает – задаем куки логина и пароля
при каждом заходе на сайт – проверяем наличие кук, если они обе есть выполняем дествия под звездочкой
елси проверку прошли – записываем например в сессию состояние входа, и на каждой странице в закрытом доступе проверяем, если она положительная – открываем скрытую часть
в бд держим мд5(пароль) и соль, а в куки держим мд5(мдп(пароль).соль)), а далее – сверяем то, что у нас в куки с тем, что у нас в бд.
а вообще нюк – это не лучший пример. как говорится, нюк- это одна сплошная дыра в безопасности.
просто хэш пароля уже не катит для защиты. благодаря радужным таблицам http://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B4%D1%8... пароль можно очень быстро подобрать. поэтому нужна соль.
как пример хорошей реализации могу посоветовать vbulletin или подобные качественные вещи, но в них гораздо труднее разобраться что к чему. поэтому советую статьи читать, например, на хабрахабре.
вместо md5 щас hash("sha256") какойнеть моднее.
когда начинал програмить придумывал всякую шнягу, в том числе делать два хеша md5, например логин и пароль, соединял, и мешал внутри куски. в итоге получался 64-значный вроде хеш какойто но его никак не расшифруешь т.к. алгоритм обратной перестановки кусков известен только скрипту на моем сайте. ну это шняга. для начала. потом система анти-взлома стала намного серьезней. а потом подумав что нахрен никому мой сайт не нужен взламывать его париться это ж не вебмани, понял что все это лишняя паранойа. короче щас тупо $id.hash("sha256", $db_login.$db_pass.$какаянетьшняга) в куки. в базе пароль тоже хешированый. можно еще айпи в хеш куков добавить, это нехуйский плюс в безопасности, куки уже с другого компа из другой подсети не сработают, но будет гемор для пользователей с динамическим айпи ( дайлап / жпрс ). а в целом если пользователь хуево дружит с компом, не понимает как ставятся трояны, куда нельзя вводить пароль, его у него всеравно умудрятся увести и от того каким методом его на сайте шифровать ничего не зависит. троян с перехватом вводимых данных в форму он себе сам поставит. надо только чтото свое туда добавлять и все. соль т.н.чтоб не по шаблону.
1) Ввели данные в форме дле авторизации, очищаем данные от мусора, делаем запрос к бд. Если юзверь найден, ставим ему сессию и куки.
2) При заходе на сайт проверяем наличие сессии. Если таковая имеется, берём из неё данные, делаем запрос к бд. Если юверь найден, пропускаем, если нет – сессию стираем.
3) Если отсутствует сессия и есть соответствующие куки, делаем проверку данных, полученных из куки. Если юзверь найден в бд, ставим сессию, если нет – стираем куки.
З.Ы. Разумеется, чтобы мускул каждый раз не мучать, все запросы к бд кешируются.
З.Ы.Ы. Очень улыбнуло:
"пароль можно очень быстро подобрать. поэтому нужна соль."
md5(md5($password)); – это тоже взламывается и хацкеров этим не удивишь, соль по крайней мере может ввести в заблуждение,
Алеша PDZ [ aka PEREDOZO ] Душевнобольной правильно сказал, нужно новые алгоритмы использовать
Господа, у всех у вас одна трабла – вы не думаете о том что будет, если сделать 20 запросов в секунду (как минимум). В сессии (лучше в memcached) надо хранить целиком учетные данные юзверя, и не спрашивать БД при каждом открытии страницы о наличии учетки соответствующей. Это же +1 запрос, что есть плохо. Если мы уже аутентифицировали пользователя – нам не надо делать это каждый раз.
2) При заходе на сайт проверяем наличие сессии. Если таковая имеется, берём из неё данные, делаем запрос к бд. Если юверь найден, пропускаем, если нет – сессию стираем.
Что вы имелии ввиду под "проверяем наличие сессии"?.. если я не ошибаюсь, то сессия будет уничтожена при закритии браузера. Если это не так, то расскажите пожалуйста про механизм хранения сессий и проверки их(сессий) наличия. буду признателен
#21
налицо полное непонимание что такое сессия и где\как данные сессии хранятся. Наверное ты имел в виду возможность кражи cookie, содержащего идентификатор сессии – ну так это проблема реализации механизмов защиты сайта от xss и тому подобных атак, а не проблема механизма аутентификации и авторизации.
Илья VAMPIRE Ленин
можно проверять стартанута ли сессия для данного пользователя простой проверкой куки
if (isset($_COOKIE[session_name()])) session_start(); – только нужно пользоваться аккуратно, если остальной код позволяет. можно организовать обёртку для сессий, чтобы была ленивая инициализация – когда вызов Session::set Session::get
вторая часть опять же завязана на куке с сидом, которой можно управлять session_set_cookie_params. у меня в блоге есть более-менее подробная статья на этот счёт, но там далеко не всё.
А вот я согласен с тем, что безопасность системы определяется безопасностью самого слабого звена.
В этом плане хакеру по нынешним временам значительно проще своровать пароли путем перехвата клавиатурного ввода или подсадкой какого-нибудь другого вируса. В наше время лучшие антивирусные программы стоят довольно дорого, а чтобы пользоваться ими нужно подчас быть специалистом очень высокого уровня и в довольно специфической области. Таким образом, риск того, что вирус проберется на комп или в сеть довольно велик. На много больше того, что хакер будет использовать пресловутые радужные таблицы, требующие до 500 гигабайт высокоскоростной памяти и время, сравнимое с десятками суток.
Вряд ли.
Так что будете вы использовать соль, не будете, а хакнут ваш сайт через FTP. И что? Ни у кого никогда на сайт не сажали вируса? Да не поверю. У меня за несколько последних лет такое раза три было и всегда одинаковым способом. Вскрывали хостера.
Один раз так вскрыли, что хостер по своей инициативе поменял всем своим клиентам пароли на фтп.
Но и запускать вопрос безопасности на мой взгляд нельзя. Ни в коем случае не нужно хранить хеш пароля ни в сессии ни в куках. Единственное, что можно хранить – это первичный код, по котоорому в базе данных доступны все сведения пользователя. Сама сессия должна хранить только зашифрованные сведения. Каждый раз при открытии страницы нужно брать эти сведения, расшифровывать и если соль совпадает – брать сведения о пользователе. Сами по себе сессии не являются образцом безопасности.
И последнее. Никак нельзя ( на мой взгляд) уменьшать безопасность за счет ускорения доступа пользователей. Если у уважаемых коллег идут авторизации по 20 штук в секунду, то, во-первых, их можно с этим поздравить, а во-вторых, посоветовать переход на более мощную технику и на распределенные, например по региональному признаку, базы.
К чему это я все написал? Да к тому, что на своем сайте http://php-classes.ru я сделал, подробнейшим образом задокументировал закомментировал и в настоящий момент пишу примеры по использованию классов системы авторизации.
Обсуждать можно на сайте или в группе php-classes.ru – открытой группе новостей сайта. Буду раз мнениям и обоснованной критике, ибо сам себя идеалом не считаю.
#27 & #28
а) много слов абсолютно ни о чем
б) про "уменьшение безопасности за счет ускорения доступа" – просто бред
в) насчет "не храните в сессиях" – дважды бред и претензия на госпитализацию в желтый дом.
г) дешевый самопиар дешевенького сайтеца вызывает улыбку и не более. Всегда было интересно – а как людям не стыдно рассказывать на своих страницах о сайтостроении и другим советы давать, когда сам ресурс тянет максимум на работу абитуриента сантехнического ПТУ.
в наше время антивирусы бесплатны, из хороших – аваст и от майкрософт.
про радужные таблицы и вовсе смешно, да и нужны они уже после того, как сайт взломали и вытащили хэшь паролей. соль нужна чтобы паролями, подобранными по таблице не могли воспользоваться на другом ресурсе.
непонимания принципов работы сессий тоже на лицо, они хранятся на сервере, единственная загвоздка – на шаред гавнохостингах они хранятся в общей папке, но это легко изменяется одной строчкой php кода.
а сайтег и вовсе не доступен. это не пиар, а позорный столб.
#30 "соль нужна чтобы паролями, подобранными по таблице не могли воспользоваться на другом ресурсе".
Соль нужна чтоб изменить результат функции хеширования исделать невозможным применение любых просчитанных таблиц.
а я о чём? просто указал, что сразу имеем хэшь со взломанного сайта, а затем по нему подбирают слова, дающие такой же результат. ясное дело, соль делает это не возможным, если ей не одинаково посыпают, как любят делать некоторые мастера. тогда как раз возможно.
Мне странно такое недоброе отношение к своим коллегам.В этой группе принято хамство? Извините, я не знал.
Вы, ругатели, еще очень и очень молоды и, я думаю вас еще пот не прошибал от того, что корпоративная сеть не работает из-за вирусной атаки, а шеф орет на вас, что фирма теряет деньги. Или какая-нибудь девочка оставляет работающим комп и идет по магазинам, а в это время кто-нибудь подделывает ее сессию. Или пароли на экранах фотографируют из соседнего офисного здания. Или ддосят сервера и несколько интернет-магазинов становятся недоступны.
Аваст и другие "бесплатные" вирусы бесплатны только для домашнего использования. Читайте лицензионные соглашения! (Я же не могу подумать, что вы еще и пираты!) Поставьте себе аваст и через очень короткое время вы в полной мере ощутите себя тем самым …, который виноват в убытках своей фирмы.
Полуэкт Сидоров я сижу на авасте уже давно, с тех пор, как заразился вирусом пользуясь касперычем. весь список популярных антивирусов облажался, случайно человек пожаловался, что нашёл вирус в расшаренной папке. аваст вылечил. так что проблемы у компании будут скорее из-за твоей некомпетентности.
тебя не оскорбляли, а указали на пункты в которых ты не разбираешься.
на нас шеф не будет кричать, тем более из-за вирусной атаки или что заддосили, для этого бог создал сисадминов, а php-шники занимаются безопасностью веб приложений.
какая нафик подделка сессий. а фотографирование паролей на экранах – это вообще пёрл: "я угадаю пароль из шести звёздочем, а я из семи".
даже если я сейчас заявлю что ты – воинствующий невежда, это будет не оскорбление, а констатация факта, так как это было уже доказано выше.
какой нахрен толк от солей если для md5 легко можно коллизию сгенерировать? как минимум sha256 и это не мода как кто-то выразился.
#33 да хоть 30 раз оберни один хер можно коллизию найти (строку дающую тот же результат), надо быть дятлом чтобы md5 подбирать по словарю или алфавиту.
а вообще парольная аутентификация сама по себе полное говно. что лучше? протоколы с открытым ключем.
Сергей Сергеевич соль для того, чтобы добыв базу хэшей и подобрав слова или коллизии их нельзя было применить в другом месте
md5('соль'.'пароль') !=md5('соль2'.'пароль')
пользователи любят использовать ОДИН пароль на разных ресурсов, если сломали ваш сайт, то здесь уже ничего не поделаешь, но зато даже зная хэш и соль этими данными нельзя будет воспользовыаться
Все вместе)
а поподробнее? просто немного не понимаю способ в php-nuke (не нахожу отправную точку массива $cookie)
что вы за него зацепились?
алгоритм:
поступили данные?
очищаем от мусора, проверяем пользователя в бд
*Если пользователь найдет сверяем поступивший пароль
если пароль совпадает – задаем куки логина и пароля
при каждом заходе на сайт – проверяем наличие кук, если они обе есть выполняем дествия под звездочкой
елси проверку прошли – записываем например в сессию состояние входа, и на каждой странице в закрытом доступе проверяем, если она положительная – открываем скрытую часть
Ну как)) для сохранения данных при перехода с одной страницы на другую, используйте сессии. Для организации "запомнить меня" кукисы.
в бд держим мд5(пароль) и соль, а в куки держим мд5(мдп(пароль).соль)), а далее – сверяем то, что у нас в куки с тем, что у нас в бд.
а вообще нюк – это не лучший пример. как говорится, нюк- это одна сплошная дыра в безопасности.
думаю что для хранения в кукисах лучше использовать id и сгенерированный hesh.
ну это естественно, я тебе пример показал
Авторизация по кукам не самый лучший вариант.. в плане безопасности аккаунта.
Юзай сессии..имхо.
подробнее в привате по ним могу рассказать)
Ванек, лучше в аське))))
просто хэш пароля уже не катит для защиты. благодаря радужным таблицам http://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B4%D1%8... пароль можно очень быстро подобрать. поэтому нужна соль.
как пример хорошей реализации могу посоветовать vbulletin или подобные качественные вещи, но в них гораздо труднее разобраться что к чему. поэтому советую статьи читать, например, на хабрахабре.
не,не хеш пароля, а спец хеш, который генеритца системой
Иван ЬIхТеАнДеР Лутохин
ты не прав, сессия хранит сид тоже в _куке_, так что фиолетово, если уж куку увели
вместо md5 щас hash("sha256") какойнеть моднее.
когда начинал програмить придумывал всякую шнягу, в том числе делать два хеша md5, например логин и пароль, соединял, и мешал внутри куски. в итоге получался 64-значный вроде хеш какойто но его никак не расшифруешь т.к. алгоритм обратной перестановки кусков известен только скрипту на моем сайте. ну это шняга. для начала. потом система анти-взлома стала намного серьезней. а потом подумав что нахрен никому мой сайт не нужен взламывать его париться это ж не вебмани, понял что все это лишняя паранойа. короче щас тупо $id.hash("sha256", $db_login.$db_pass.$какаянетьшняга) в куки. в базе пароль тоже хешированый. можно еще айпи в хеш куков добавить, это нехуйский плюс в безопасности, куки уже с другого компа из другой подсети не сработают, но будет гемор для пользователей с динамическим айпи ( дайлап / жпрс ). а в целом если пользователь хуево дружит с компом, не понимает как ставятся трояны, куда нельзя вводить пароль, его у него всеравно умудрятся увести и от того каким методом его на сайте шифровать ничего не зависит. троян с перехватом вводимых данных в форму он себе сам поставит. надо только чтото свое туда добавлять и все. соль т.н.чтоб не по шаблону.
В моей CMS:
1) Ввели данные в форме дле авторизации, очищаем данные от мусора, делаем запрос к бд. Если юзверь найден, ставим ему сессию и куки.
2) При заходе на сайт проверяем наличие сессии. Если таковая имеется, берём из неё данные, делаем запрос к бд. Если юверь найден, пропускаем, если нет – сессию стираем.
3) Если отсутствует сессия и есть соответствующие куки, делаем проверку данных, полученных из куки. Если юзверь найден в бд, ставим сессию, если нет – стираем куки.
З.Ы. Разумеется, чтобы мускул каждый раз не мучать, все запросы к бд кешируются.
З.Ы.Ы. Очень улыбнуло:
"пароль можно очень быстро подобрать. поэтому нужна соль."
md5(md5($password));
Подберёте? Денег даже дам))))))))
md5(md5($password)); – это тоже взламывается и хацкеров этим не удивишь, соль по крайней мере может ввести в заблуждение,
Алеша PDZ [ aka PEREDOZO ] Душевнобольной правильно сказал, нужно новые алгоритмы использовать
Господа, у всех у вас одна трабла – вы не думаете о том что будет, если сделать 20 запросов в секунду (как минимум). В сессии (лучше в memcached) надо хранить целиком учетные данные юзверя, и не спрашивать БД при каждом открытии страницы о наличии учетки соответствующей. Это же +1 запрос, что есть плохо. Если мы уже аутентифицировали пользователя – нам не надо делать это каждый раз.
я тоже так "md5(md5($password));" делал, я думал я один такой "параноик"
или можетбыло так "md5(login+md5($password));"
return md5($password.md5(md5('denis').md5('nyaka')));
и кто еще параноик?)
Владислав felix90 Гарнатка
2) При заходе на сайт проверяем наличие сессии. Если таковая имеется, берём из неё данные, делаем запрос к бд. Если юверь найден, пропускаем, если нет – сессию стираем.
Что вы имелии ввиду под "проверяем наличие сессии"?.. если я не ошибаюсь, то сессия будет уничтожена при закритии браузера. Если это не так, то расскажите пожалуйста про механизм хранения сессий и проверки их(сессий) наличия. буду признателен
нормальному взломщику не составит труда сформировать весь http-запрос
можно хранить сессии в бд
а смысл?
#21
налицо полное непонимание что такое сессия и где\как данные сессии хранятся. Наверное ты имел в виду возможность кражи cookie, содержащего идентификатор сессии – ну так это проблема реализации механизмов защиты сайта от xss и тому подобных атак, а не проблема механизма аутентификации и авторизации.
#21
Конечно. Но только для начала этому хЭкеру придется получить доступ к серверу, где собственно и храниться информация о сессии.
Илья VAMPIRE Ленин
можно проверять стартанута ли сессия для данного пользователя простой проверкой куки
if (isset($_COOKIE[session_name()])) session_start(); – только нужно пользоваться аккуратно, если остальной код позволяет. можно организовать обёртку для сессий, чтобы была ленивая инициализация – когда вызов Session::set Session::get
вторая часть опять же завязана на куке с сидом, которой можно управлять session_set_cookie_params. у меня в блоге есть более-менее подробная статья на этот счёт, но там далеко не всё.
А вот я согласен с тем, что безопасность системы определяется безопасностью самого слабого звена.
В этом плане хакеру по нынешним временам значительно проще своровать пароли путем перехвата клавиатурного ввода или подсадкой какого-нибудь другого вируса. В наше время лучшие антивирусные программы стоят довольно дорого, а чтобы пользоваться ими нужно подчас быть специалистом очень высокого уровня и в довольно специфической области. Таким образом, риск того, что вирус проберется на комп или в сеть довольно велик. На много больше того, что хакер будет использовать пресловутые радужные таблицы, требующие до 500 гигабайт высокоскоростной памяти и время, сравнимое с десятками суток.
Вряд ли.
Так что будете вы использовать соль, не будете, а хакнут ваш сайт через FTP. И что? Ни у кого никогда на сайт не сажали вируса? Да не поверю. У меня за несколько последних лет такое раза три было и всегда одинаковым способом. Вскрывали хостера.
Один раз так вскрыли, что хостер по своей инициативе поменял всем своим клиентам пароли на фтп.
Но и запускать вопрос безопасности на мой взгляд нельзя. Ни в коем случае не нужно хранить хеш пароля ни в сессии ни в куках. Единственное, что можно хранить – это первичный код, по котоорому в базе данных доступны все сведения пользователя. Сама сессия должна хранить только зашифрованные сведения. Каждый раз при открытии страницы нужно брать эти сведения, расшифровывать и если соль совпадает – брать сведения о пользователе. Сами по себе сессии не являются образцом безопасности.
И последнее. Никак нельзя ( на мой взгляд) уменьшать безопасность за счет ускорения доступа пользователей. Если у уважаемых коллег идут авторизации по 20 штук в секунду, то, во-первых, их можно с этим поздравить, а во-вторых, посоветовать переход на более мощную технику и на распределенные, например по региональному признаку, базы.
К чему это я все написал? Да к тому, что на своем сайте http://php-classes.ru я сделал, подробнейшим образом задокументировал закомментировал и в настоящий момент пишу примеры по использованию классов системы авторизации.
Обсуждать можно на сайте или в группе php-classes.ru – открытой группе новостей сайта. Буду раз мнениям и обоснованной критике, ибо сам себя идеалом не считаю.
#27 & #28
а) много слов абсолютно ни о чем
б) про "уменьшение безопасности за счет ускорения доступа" – просто бред
в) насчет "не храните в сессиях" – дважды бред и претензия на госпитализацию в желтый дом.
г) дешевый самопиар дешевенького сайтеца вызывает улыбку и не более. Всегда было интересно – а как людям не стыдно рассказывать на своих страницах о сайтостроении и другим советы давать, когда сам ресурс тянет максимум на работу абитуриента сантехнического ПТУ.
в наше время антивирусы бесплатны, из хороших – аваст и от майкрософт.
про радужные таблицы и вовсе смешно, да и нужны они уже после того, как сайт взломали и вытащили хэшь паролей. соль нужна чтобы паролями, подобранными по таблице не могли воспользоваться на другом ресурсе.
непонимания принципов работы сессий тоже на лицо, они хранятся на сервере, единственная загвоздка – на шаред гавнохостингах они хранятся в общей папке, но это легко изменяется одной строчкой php кода.
а сайтег и вовсе не доступен. это не пиар, а позорный столб.
#30 "соль нужна чтобы паролями, подобранными по таблице не могли воспользоваться на другом ресурсе".
Соль нужна чтоб изменить результат функции хеширования исделать невозможным применение любых просчитанных таблиц.
а я о чём? просто указал, что сразу имеем хэшь со взломанного сайта, а затем по нему подбирают слова, дающие такой же результат. ясное дело, соль делает это не возможным, если ей не одинаково посыпают, как любят делать некоторые мастера. тогда как раз возможно.
#15
Брутально!
Можно ещё такhash(md5(md5($password)));
Мне странно такое недоброе отношение к своим коллегам.В этой группе принято хамство? Извините, я не знал.
Вы, ругатели, еще очень и очень молоды и, я думаю вас еще пот не прошибал от того, что корпоративная сеть не работает из-за вирусной атаки, а шеф орет на вас, что фирма теряет деньги. Или какая-нибудь девочка оставляет работающим комп и идет по магазинам, а в это время кто-нибудь подделывает ее сессию. Или пароли на экранах фотографируют из соседнего офисного здания. Или ддосят сервера и несколько интернет-магазинов становятся недоступны.
Аваст и другие "бесплатные" вирусы бесплатны только для домашнего использования. Читайте лицензионные соглашения! (Я же не могу подумать, что вы еще и пираты!) Поставьте себе аваст и через очень короткое время вы в полной мере ощутите себя тем самым …, который виноват в убытках своей фирмы.
Так что ставьте md5(md5(md5(md5($password))));
и почувствуйте, наконец, себя защищенными!
Еще одна порция бредятины.
Полуэкт Сидоров я сижу на авасте уже давно, с тех пор, как заразился вирусом пользуясь касперычем. весь список популярных антивирусов облажался, случайно человек пожаловался, что нашёл вирус в расшаренной папке. аваст вылечил. так что проблемы у компании будут скорее из-за твоей некомпетентности.
тебя не оскорбляли, а указали на пункты в которых ты не разбираешься.
на нас шеф не будет кричать, тем более из-за вирусной атаки или что заддосили, для этого бог создал сисадминов, а php-шники занимаются безопасностью веб приложений.
какая нафик подделка сессий. а фотографирование паролей на экранах – это вообще пёрл: "я угадаю пароль из шести звёздочем, а я из семи".
даже если я сейчас заявлю что ты – воинствующий невежда, это будет не оскорбление, а констатация факта, так как это было уже доказано выше.
Плиско AmdY Вячеслав, ту же самую грязь могу налить и на нод и на аваст. Все из личного опыта. Т.ч. не нужно тут обсирать друг друга.
какой нахрен толк от солей если для md5 легко можно коллизию сгенерировать? как минимум sha256 и это не мода как кто-то выразился.
#33 да хоть 30 раз оберни один хер можно коллизию найти (строку дающую тот же результат), надо быть дятлом чтобы md5 подбирать по словарю или алфавиту.
а вообще парольная аутентификация сама по себе полное говно. что лучше? протоколы с открытым ключем.
Какой вы умный, Сергей Сергеевич! А почему же тогда все сайты на эту систему не перейдут?
Сергей Сергеевич соль для того, чтобы добыв базу хэшей и подобрав слова или коллизии их нельзя было применить в другом месте
md5('соль'.'пароль') !=md5('соль2'.'пароль')
пользователи любят использовать ОДИН пароль на разных ресурсов, если сломали ваш сайт, то здесь уже ничего не поделаешь, но зато даже зная хэш и соль этими данными нельзя будет воспользовыаться