IMHO
session+md5+хеши в базе, а доступ к таблице через процедуру (от овнера)

Сессии - механизм временного хранения значения переменных скрипта в файле на сервере (по одному файлику на каждую сессию пользователя :)...) подробнее по ссылке (на том же сайте и про md5 найдёшь)
http://ua.php.net/manual/ru/ref.session.php
md5 - алгоритм хеширования (ф-ция md5($string)) ... правда говорят что есть технологии и поновее...
хеширование- "шифрование в оду сторону" - расшифровке практически (кроме метода тупого перебора) не поддаётся (вот эти то значения и храни в базе, и с ними сравнивай хеш проля введенного пользователем)...
Но вообще чем нестандартней будет подход к этому делу тем лучше...смотри сам...

В начальной, а уж скрипт преобразует в хеш, и этот хеш сравнит с существующим в таблице НО заметь, если у тебя пароль в сессии, то в течении сессии с клиентским браузером по сетке он гонится ТОЛЬКО ОДИН РАЗ при её создании (сессии в смысле), т.е. дальше значения берутся из сессионного файла на серваке и отрабатываются там-же, т.е. рискуем только один раз...
А хеш нужен для того, чтобы какой нибудь зловещий хацкер пробравшись в базу и сперев данные таблицы после этого долго над ними плакал (т.к. там всего лишь хеш)...
Да, и в базе сделай процедуру, чтобы она проверяла пароль а не скрипт...чтобы не давать прямой доступ из нета к таблице с паролями
Существует тогда два споба чего-то напакостить
- модификация скрипта
- прослушка всего трафика с целью выделить исходную комбинацию пароля (которая посылается всего-лишь один раз)...

:-))
Но надеемся на лучшее а готовимся к худшему...Т.е. бэкап, резервный сервак..если не поможет - вертолёт на крыше, подводная лодка...если не поможет - пуля собственной рукой в висок как русскому офицеру , или харакири как самураю...
Дерзайте, удачи вам....

ну начнём с того, что хранимые процедуры побыстрее будут (всё-таки компиленые уже), но в данном случае роли это большой не играет...:)
Дело в том что закрывая прямой доступ к таблицам мы избавляемся от проблем при следующей ситуации
скрипт модифицирован....тогда select *from Mytab_with_posswords выложит нам всё на блюдечке....
а вот закроем доступ напрямую, тогда модифицируй, не модифицируй скрипт а хоть чего-то добиться от хотимой таблицы без выполнения процедуры мы не сможем (а в процедуре только проверка на присутствие в таблице, т.е. ответ Y/N), и тогда хацкеру остаётся только перебор...
я не беру случай когда злоумішленик получил доступ и к скрипту и к базе - это без вариантов...
1) Защита скриптов средствами веб сервера (и операционки)
2) Защита средствами операционки сессионных файлов
3) Защита скуль сервером базы
и наконец SSL от прослушки....AFAIK вполне достаточно для безопасности....
Если где-то просчитался прошу ткнуть пальцем (если без матов то я не против)
P.S. Я не помешан на безопасности - просто написать процедуру из семи строчек несложно, да и в скрипте вызвать её тоже...а эфект по-моему от этого есть...

С мнением, что нет абсолютной защиты я согласен полностью - всегда надо создавать резерв для быстрого восстановления...и не потому что кто не хацкер, тот плохой программер - просто, по определению, "ломать - не строить"
2Mакс
Ответить на вопрос насчёт скорости не могу, т.к. разницу всё равно не ощутил бы (писал для внутренних нужд, и записей там с паролями чуть более сотни, да и сетка 100мб)...а так "на лету" могу только порассуждать...но тут ещё не понятна технология совместной работы скуля с пхп (вот тут и может скорость упасть, и запрос будет быстрее)...
А насчёт select *from ... если говорить за мсскуль, то там такой запрос при отсутствии прав просто не прокатит, получим Access denided да и все...

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

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

P.S. Если угонщик имеет ключи, то вся безопасность до одного места...

вот это
$row = mysql_fetch_row($result);
считывает в массив строку с результатами и передвигает её дальше...
следовательно если результат запроса будет нулевым то ф-ция выдаст ошибку
а вот этим
if (mysql_num_rows($result) == 1)
мы проверяем существует ли результат и (что самое главное) один ли он (если их два или более - опасность)
а дальше пожалуйста делай
$row = mysql_fetch_row($result);

if ($row[0] != $passw): print "Пароль не верный";

else:

ботва всякая.

2Alienzzzz
>их там нет
нет, а в MS есть :-))
по этому делать чего-то типа
> if cSecurityClass -> TestPass($vLogin,vPassword) {}
не обязательно