Это пожалуй единственный случай, когда соединяются несколько БД. Ведь у поля с авто инкриментом может быть только одно уникальное значение. Можно и не ставить LIMIT 1, вот только я не уверен в том, что mysql не кинется искать еще значения.. На всякий случай можно сказать, что нужно только одно

_____________
FC Barcelona - она всегда будет в моем сердце!

а то будет ругаться на несуществующую переменную.

А если имя у меня (или логин, не важно) O'Relly, а понадобится куда нибудь вывести, в приветствие или еще куда? Что на экран выползет? Эта функция ни как не предназначена для баз данных.
В третьих, куку вы ставите аж на полтора месяца, если я правильно прикинул. А выход где? Если я в интернет кафе допустим тусуюсь, после меня полтора месяца можно с этого компа под моим логином шастать?
Не аккуратно это все как то...

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Вот это ИМХО глупое замечание, ибо если у тебя есть куки юзера (пароль+логин) то нафига брутить пароль? Подменил куку и всего делов. В этом случае хоть "засоли" пароль вусмерть - не поможет. Другое дело, что если юзер использует такой пароль везде (почте и пр.), в этом случае владелец сайта не отвечает за то, что юзер где-то засветил свой пасс, сам виноват. Редко какие сайты шифруют пароль с солью (этот форум IPB не исключение), потому как если кому-нибудь нужно будет тебя ломануть, он это сделает в любом случае =)

Не совсем понял.. На экран выползет O& #039;Relly

Этот вопрос должен сам прийти в процессе написания логинилки =)

Я вот именно про это. Вы думаете зачем пароли тырят, чтоб на сайт Васи Пупкина попасть и там гадость написать какую нибудь? Глубоко заблуждаетесь. Именно для получения материальной выгоды. И юзер не виноват в том, что безалаберное отношение к его собственности со стороны неаккуратных сайтостроителей приведет к плачевным результатам. Тогда пишите большими буквами на сайте - "За сданные в гардероб вещи администрация ответственности не несет!". Ведь он Вам доверяет.

А тут чего не понятно? Посмотрите наверху, там надпись - Привет, kirik! Красиво будет, если там к примеру напишут Привет, U +006BiriU +006B! А ведь по сути это одно и то же...

Не придет. Сто пудов не придет, потому что человек, намучавшись со своим скриптом, будет даже дышать бояться на Ваш рабочий. Скопирует его и вставит. По этому, если советуете что то по безопасности, то советуйте до конца или ставьте ремарку - мол это только основа, требует серьёзной проработки.
Очень здорово, когда помогают друг другу, и ценность ответа разумеется не умаляется. Но это такой щепитильный вопрос, отвечая на который сто раз нужно подумать.
Я не говорю, что мой ответ, это гарантия успеха. Защита, дело - сугубо интимное и каждый решает её реализацию по своему. Но основные правила и принципы желательно соблюдать, Вы же невольно становитесь виновником казуса, коли тот случиться.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Че-то всеравно не понял.. Ведь htmlspecialchars заменяет символы на ХТМЛ сущности, а они, как правило, в браузерах отображаются без всяких проблем.

Страдать паранойей тоже плохо. Давайте тогда на всех гостевухах повесим ssl авторизацию + кучу токенов и пр. ерунды? Если юзер использует пароль от банковского аккаунта на порнсайте, то как минимум он пять раз подумает, чтобы использовать одинаковый пароль на всех сайтах, после того как его один раз крякнут.

twin, то что вы написали про одноразовое хэширование пароля не является дырой, ровно как использование протокола http - дырка. А вот sql инъекция - это огромная черная дырень в безопасности.

Вот именно. Вы два раза обработаете этой функцией апостороф и он вылезет на экран как сущность, а не как символ. Как в базе будет записан в виде & #039; так и вылезет. Не как апостроф. Функция htmlspecialchars предназначена для обработки информации непосредственно перед выводом в браузер, но не как не для обработки литеральных констант для SQL запросов.

Это не параноя, это элементарная гигиена. Ни кто не заставляет Вас ходить два раза в день в баню, но зубы то надо чистить...

Не уловил... Что и где я про одноразовое хэширование писал? И где я призывал бросить борьбу с инъекциями?
Просто есть специальные функции для работы с бд. mysql_escape_string() или mysql-real-escape-string(). Не зачем изобретать велосипед, всё давно придумано.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Вот фигня..) Мы не понимаем друг друга =) 2 раза обработать апостроф не получится в силу того, что при обработке второй раз апостроф уже будет как сущность, а так как сущность кавычек не имеет - все будет ОК!
Попробуйте -

Вы писали

Если я все правильно понял, то вы намекали на добавление "соли" в пароль, не так-ли?
ЗЫ. md5('pass') - это "одноразовое" хэширование

Вы не призывали, я просто показал, что ТС нужна была защита от взлома - он ее получил. "Все остальное решается с помощью зонта"

Я считаю эти функции ущербными. В разы проще (и эффективнее) преобразовать "неправильные символы" в сущности всего лишь раз при занесении инфы в БД (и можно забыть про эксплоиты, sql инъекции и пр.), чем каждый раз при любом выводе фильтровать эти долбанные бэкслэши. А если нужны не сущности (например где нужно вывести ХТМЛ) - просто тыдынь - htmlentities и мы имеем хтмл с кавычками и прочими красивостями.

Ничего OK не будет. Попробуйте элементарно вытащить то, что записано у Вас в базе, вот так:

и поймёте. Функцию htmlentities, а так же htmlspecialchars_ decode придумали специально для таких заблудших душ, как Вы. Что бы исправить наделанные единожды глупости. В базу данных нужно писать нормальные, не искаженные данные, потому что они могут быть применимы не только для вывода, но и для других целей. Для регулярных выражений допустим.

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

Отнюдь. Ни двойное, ни тройное хэширование никакой пользы не приносит. Я имел в виду саму постановку вопроса - писать пароль в кукис. Пусть даже хэшированный. Нельзя этого делать.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Да ничего страшного не происходит! А вот в вашем случае если юзер введет что-то типа - test \', то при выводе получит test \\\', если конечно вы не будете применять stripslashes(), а если будете, то +несколько килобайт кода вам в минус и скорость работы не в плюс.

Во-первых, почему нельзя в рег. выраженияъ юзать те же сущности? Во-вторых, если уж приспичило к какому-то полю применять рег. выражение, то можно и записать как вы говорите.

Другое дело. Вопрос снят. Продолжаем холиворить на тему htmlspecialchars vs mysql_escape_string