Регистрация и авторизация

Здравствуйте!

Последние 4 часа искал в интернете инструкции по созданию нормальной регистрации и авторизации.
Исходя из того, что я начитался (а это: "в куках не хранить пароль и логин" и т.д.), пришел к выводу: хорошей готовой регистрации для себя я не нашел.

Т.к. с PHP я все еще на "Вы", снова прошу помощи у жителей форума =)

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

По сути, это сессии, так?

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

P.S.: для регистрации и авторизации самый оптимальный вариант - делать хеш, забивать его в куки и БД? А потом сверять? Или?..

0

В гугле миллион решений..

0

Сессии – это дополнительная нагрузка. Фраза "в куках не хранить пароль и логин" вовсе не означает "куки использовать не нужно". Ну, логин еще можно хранить в куках, холя лучше числовой id. Даже пароль можно, но очень сильно "засоленный", хотя лучше какой-нибудь редко повторяющийся сложный ключ, чтобы его можно было при необходимости сбрасывать (повторно генерировать) на сервере без смены пароля. Лично я обычно храню id и ключ в одной строке, тем самым добиваясь полной уникальности ключа в отдельно взятый момент времени и упрощения в том плане, что работаю с одним значением в куках, а не с двумя, хотя ключ в общем получается сложнее и часто содержит избыточную информацию на стороне сервера (id), пусть даже и в каком-либо измененном (закодированном) виде.

0

Сообщение от miketomlin Сессии – это дополнительная нагрузка.

Сообщение от Владислав В. На сайте будет уйма данных, которая выводится из строки пользователя.

По этому сессия очень нужна.

Сообщение от miketomlin Фраза "в куках не хранить пароль и логин" вовсе не означает "куки использовать не нужно". Ну, логин еще можно хранить в куках, холя лучше числовой id.

Не говорил, что куки плохи. И они тоже будет нужны.
Числовой ID, логин и засоленный пароль - вообще отлично. Только как солить то? Я в этом толком не разбираюсь ЕЩЕ. По этому прошу помощи тут. В принципе, все тоже зависит от сайта? У меня там не будет хранится денег, секретных данных государства, или чего-то ценного. Однако от горе-взломщиков, у которых руки чешутся, хочется спастись. Так бы, в принципе, написал и регу и авторизацию. Но без какой-либо безопасности. Единственное - покрыл бы двойным md5 (это же и есть что-то типа "соли"?).

0

php md5()

0

Сообщение от Владислав В. Единственное - покрыл бы двойным md5 (это же и есть что-то типа "соли"?).

md5() - это один из простых алгоритмов хеширования и использовать его для паролей - далеко не лучшая идея. Рекомендуется шифрование по алгоритму blowfish. И "двойное покрытие md5" - к соли никакого отношения не имеет, но подробней об этом лучше прочитать, чем пересказывать.

0

Сообщение от Владислав В. По этому сессия очень нужна.

Обычно все в БД хранится. В любом случае в сессиях постоянно хранить данные пользователя не получится.

Сообщение от Владислав В. Не говорил, что куки плохи. И они тоже будет нужны. Числовой ID, логин и засоленный пароль - вообще отлично. Только как солить то? Я в этом толком не разбираюсь ЕЩЕ. По этому прошу помощи тут. В принципе, все тоже зависит от сайта? У меня там не будет хранится денег, секретных данных государства, или чего-то ценного. Однако от горе-взломщиков, у которых руки чешутся, хочется спастись. Так бы, в принципе, написал и регу и авторизацию. Но без какой-либо безопасности. Единственное - покрыл бы двойным md5 (это же и есть что-то типа "соли"?).

Числовой id – это альтернатива логину для хранения в куках. В сессиях можете явно хранить логин (т.к. переменные сессий хранятся на стороне сервера, а не на стороне клиента), правда, по числовому id поиск обычно происходит быстрее. Сложность посола зависит исключительно от развитости вашей фантазии. md5 и т.п. не помешает для полного изменения внешнего вида простых паролей (коротких, с повторяющимися фрагментами и т.п.). Правда, богатая фантазия не избавит вас от недостатков "засоленных" паролей.

0

Сообщение от Lazy_Den Рекомендуется шифрование по алгоритму blowfish

А смогу ли я разобраться в нем, если никто не подскажет? =)

Сообщение от miketomlin Обычно все в БД хранится. В любом случае в сессиях постоянно хранить данные пользователя не получится.

У меня все в БД и храниться.
Я так понимаю, нужно будет хранить либо в сессии, либо в куках ID пользователя, и все mysql запросы прогонять через этот ID?

Если не понятно выражаюсь: пользователь с ID 5 логинится на сайте. Пользователь заходит в пункт "статистика" и видит всю свою статистику, которая лежит в БД в строке с ID 5. И вся работа сайта должна исходить и работать именно с этой строкой в БД.

Что то типа "SELECT * FROM users WHERE id='.$_SESSION['id'].'" - и выносятся все значения в массив.

P.S.: блондинкой себя чувствую

0

Сообщение от Владислав В. А смогу ли я разобраться в нем, если никто не подскажет?

А почему бы и нет? Для начала, войти в курс дела, почитав о Безопасное хэширование паролей . А потом перейти непосредственно к рассмотрению способов хэширования. Если после прочтения возникнут вопросы, то подсобим уже тут.

0

Сообщение от Владислав В. У меня все в БД и храниться. Я так понимаю, нужно будет хранить либо в сессии, либо в куках ID пользователя, и все mysql запросы прогонять через этот ID?

Это да. Тогда не понятно, что вы так за сессии уцепились. Сессии полезны в двух случаях:
1) когда куки в браузере отключены (такое даже рассматривать не хочу, т.к. в этой ситуации в сессиях используется достаточно разумный и один из немногих возможных подход с изменением адресации, но по нынешним временам не слишком актуальный);
2) когда нужно хранить большое число переменных в нескольких экземплярах на стороне сервера, дабы скрыть их состав и содержимое от клиента; информацию о пользователе можно спокойно хранить в соответствующей записи БД, а "временные" данные (помимо ключа) в тех же куках или даже некоторые данные уместно передавать в адресе (например, я часто передаю номер текущей страницы какого-то многостраничного перечня в адресе в GET-параметре даже при переходе на страницу, которая не особо нуждается в этом параметре, чтобы впоследствии по значению этого параметра вернуться к перечню именно на ту его страницу, которая указана в упомянутом GET-параметре).

Сообщение от Владислав В. Что то типа "SELECT * FROM users WHERE id='.$_SESSION['id'].'" - и выносятся все значения в массив.

Примерно так, только я обычно id беру из кук

0

Сообщение от miketomlin Примерно так, только я обычно id беру из кук

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

0

А почитать, чтобы не задавать таких простых вопросов, возможно?

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

0

Сообщение от Владислав В. Что то типа "SELECT * FROM users WHERE id='.$_SESSION['id'].'" - и выносятся все значения в массив.

как раз это и можете хранить в сессии. спокойно. выдрали все, из базы, при авторизации, положили в массив $_SESSION, и при следующем исполнении скрипта все останется в ней же. Клиенту отправится только лишь session_id, которая ничего ему не скажет и в ряде случаев (когда для генерации рандома применяются криптографически стойкие алгоритмы) подобрать ее невозможно.
Правда, хранить всю информацию о пользователе стоит или нет, в сесссии -- решать вам, и зависит от приложения. Просто есть такой прикол, что например, вы, как администратор, решили удалить или заблокировать пользователя, в базе будет находиться status=blocked, а в сессии status=good_man. В результате вам при каждом таком изменении пользователя надо либо обновить его данные в сессии, либо все равно при каждом запросе делать выборку из базы на предмет того, заблокирован он или нет.
Насчет того, что такое сессии в принципе, и зачем они нужны (также затронуты некоторые аспекты безопасности), если вам это интересно: Условие "Вошедший пользователь". Улучшить безопасность
Отдельно на тему безопасности кук я объяснял этому же человеку в соседнем треде: Кража куки

Сообщение от miketomlin Сессии полезны в двух случаях: 1) когда куки в браузере отключены

Без введения дополнительных механизмов (ручная установка session_id) они так же будут бесполезны. Вообще, для простоты, для Владислав В., проще всего принять, что сессии -- это просто надстройка над куками.

Сообщение от miketomlin Примерно так, только я обычно id беру из кук

судя по предыдущим постам, не думаю, что вы храните куки в виде user_id=123, иначе это прямая и легкоэксплуатируемая угроза безопасности. Подозреваю, что вы все же берете user_id из сессии.

Сообщение от Lazy_Den md5() - это один из простых алгоритмов хеширования и использовать его для паролей - далеко не лучшая идея.

Раскрою немного тему.
Вообщем-то идея и не самая плохая. Мы не говорим о проектировании систем класса А+, ТС как бы на это немного намекнул в самом начале. Да, в md5 нашли коллизии, да, его легко перебирать на gpu. Тем не менее, чтобы взломать пароль (а особенно, соленый, да еще и с неизвестной солью, как, например, описано тут), потребуется примерно 2^123.4/2 операций (с учетом "дней рождений"), по известным мне последним оценкам (ссылки на саму работу приложены). Таким образом, MD5 небезопасен для подписи сообщений, для хеширования файлов. Но что касается восстановления сообщения по хешу, то, на практике, оно все еще достаточно трудоемкое.
Однако, простота его перебора позволяет арендовать сервера для взлома конкретного хеша, по относительно недорогой цене. Вот тут приводят цену в 2000 баксов. Поэтому, если есть возможность, почему бы не применить более "крутые" хеши. Начиная с sha{256,384,512} и sha3 (относительно недавно приняли), и заканчивая scrypt, если вы ну совсем параноик Ну и есть еще Whirlpool, и некоторые другие. Битность у них высокая, и атаки на них маловероятны, в обозримом будущем.
Однако, я не уверен, что шифрование -- это хорошая идея. Пароль по своей природе таков, что его, в идеале, никто не должен знать, кроме пользователя, даже админ. Поэтому, на мой взгляд, необратимое преобразование нажеднее. Если говорить о шифровании, то вам еще придется куда-то сохранять и ключ... а какой смысл хранить ключ и шифр в одном месте? Если злоумышленник получит доступ к базе, то он получит доступ и к этим ключам.
Или вы собираетесь его в файле хранить? Ну это все ок, когда уязвима только база, но неуязвима ФС, и когда правильно выставлены разрешения для пользователя СУБД... Однако, опять же можно организовать подобный перебор, поскольку злоумышленник знает начальное сообщение и закодированное. С учетом той же простоты blowfish, вы не сильно-то ему жизнь усложнили.
Ну а если вас все эти сложности не пугают, и вам всенепременнейше необходимо обратное преобразование, то почему бы тогда не взглянуть на более современные AES, Twofish или Threefish? (по крайней мере первые два в mcrypt точно есть, AES также можно нагуглить и в чисто пхп-шной имплементации)

0

Сообщение от NEbO судя по предыдущим постам, не думаю, что вы храните куки в виде user_id=123, иначе это прямая и легкоэксплуатируемая угроза безопасности. Подозреваю, что вы все же берете user_id из сессии.

Храню в куках, но в неявном виде. Как знание id влияет на безопасность?

0

miketomlin, вы предусмотрели вариант, что ваш алгоритм сокрытия id раскроется (security from obscurity -- это плохо, вы же понимаете), и некая Труди сделает user_id равным f(1), ну или, в общем случае, f($admin_user_id), где f -- функция вашего преобразования в "неявный вид". не будет ли она авторизована под этим user_id?

0

Сообщение от NEbO вы предусмотрели вариант, что ваш алгоритм сокрытия id раскроется (security from obscurity -- это плохо, вы же понимаете)

Это отлично понимаю (кстати, обращаюсь к ТС-у, это вторая причина не использовать "засоленные" пароли). Нет цели сделать определение id какой-то невыполнимой задачей, поэтому даже допускаю хранение id в куках в явном виде, хотя сам обычно этого не делаю. Для меня числовой id – это ключ для быстрого поиска в БД или в каком-то другом хранилище, не более того.

Сообщение от NEbO и некая Труди сделает user_id равным f(1), ну или, в общем случае, f($admin_user_id), где f -- функция вашего преобразования в "неявный вид". не будет ли она авторизована под этим user_id?

Естественно, нет. Как я написал выше, для авторизации я использую сложный ключ доступа, никак не связанный с паролем. Для удобства могу разбавить ключ id-шником, но это некоим образом не сказывается на значимости основной части ключа при авторизации.

0

Сообщение от miketomlin кстати, обращаюсь к ТС-у, это вторая причина не использовать "засоленные" пароли

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

Сообщение от miketomlin Для меня числовой id – это ключ для быстрого поиска в БД или в каком-то другом хранилище, не более того.

то есть после поиска по id в базе вы все равно сверяете, тот ли это пользователь? не проще ли пользоваться пхп-шным механизмом сессий?

Сообщение от miketomlin я использую сложный ключ доступа

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

0

Да, естественно, после поиска по id проверяю корректность ключа авторизации. Сессиями тоже пользуюсь, но, видимо, не так часто, как другие. Действительно есть что-то общее с сессиями, но в качестве основного хранилища обычно выступает БД, а не файлы. Доп. нагрузка на БД не тревожит, ведь основной смысл как раз-таки в том, чтобы переложить нагрузку с файлов на БД. Естественно, ключ у каждого пользователя свой (есть вероятность появления дублирующихся ключей, но она крайне мала, к тому же при необходимости можно объединить id с ключом, чтобы сделать его уникальным).

0