[Iska]

-хранение логина и пароля происходит в разных таблицах »

Чушь. Именно поэтому:

пропадает смысл хранения данных в 2-х таблицах, »

но не поэтому:

потому что если "злоумышленник" получает доступ к БД и »

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

Запрос первично к таблицам происходит от "гостевого" пользователя в базу с целью прочесть требуемый логин и пароль, »

С какого перепуга? Какие «гостевые пользователи»? Вы о чём? Запрос к базе делает Ваш http-сервер.

[shisik]

если "злоумышленник" получает доступ к БД и открывает таблицу, то он может открыть вторую таблицу и найти соответствие »

То тогда хана вашему сайту в любом случае. Если злоумышленник получил доступ к БД, то он получил полный контроль над сайтом. Никакие пароли больше не нужны. Это как «если выстрелить в голову, то можно испоортить причёску». Не до причёски, знаете ли, будет...

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

Нет. Пользователь вводит логин и пароль, скрипт хэширует пароль и посылает запрос к базе типа «дай мне запись с логином X и хэшем пароля Y». Если такой есть (в случае если логин/пароль правильные) - выполняется вход в систему, если нет - база вернёт пустой ответ и скрипт сообщит об ошибке (неправильный логин/пароль). Конечно, это не единственный вариант, но в любом случае данные из базы клиенту не отправляются и обрабатываются исключительно на серверной стороне. Так что «прочесть» пользователь ничего не сможет.

[Busla]

в маленьких наколенных вэбсайтах пароль хэшируют, потому что инфраструктура неподконтрольна владельцу, и БД может слить младший техник ЦОДа

в серьёзных системах пароль хранится как есть на площадке с особым режимом доступа, а хэшируется/шифруется ещё на стороне клиента, чтобы опять же младший техник ЦОДа не мог узнать слишком много

[Volrath]

ОК. Про хэш я уже сказал - "опускаем" используем термин "пароль"
Из всего сказанного имеем:
таблица "Usr" с полями "log"\"pass"
html - страница с полями для ввода "log"\"pass" при нажатии кнопки "sign in" пытается запустить скрипт для проверки связки "log"\"pass"

вопрос: с какими правами этот скрипт обращается к БД?

Я к тому, что если делать запрос через тот же .php нужно усатновить сперва соединение с БД, чтобы проверить "есть ли в таблице 'Usr' хэш 'pass', где 'log' = введенный 'log' "
Если это так, то в скрипте указывается пользователь и пароль у которого есть права на чтение из таблицы "Usr".
Как результат возникает еще вопрос:
-"как защащают доступ из вне, чтобы потльзователь не получил доступ к скриптам"?
Например: можно попробовать скачать файл "www.mysite.net/scripts/signin.php"

Как это реализуется в "нормальных" движках?
Если закрыть доступ, то будут ли права на серевере у скриптов для обращения из папки \scripts\ в папку ..\sites\account.html?
Каким способом делается "отображение" скрытых элементов?
Например: вот страница index.html на ней поля для входа, когда прошел верификацию, то отображается та же самая страница, но отображено имя пользователя или информация для конкретного пользователя, или становятся доступными скрытые возможности для редактирования или еще чего-либо...?
Например, читаю данынй форум, могу отвечать, если выйти, то могу читать тот же форум, но ответ недоступен для меня. Какие способы? Не просто любые "как можно придумать", а "как это принято в нормальном промышленном смысле сайтостроения"

[Iska]

вопрос: с какими правами этот скрипт обращается к БД? »

Ни с какими. Ибо не обращается к базе данных. Скрипт на клиенте общается с только с http-сервером, никакого доступа, ни логического, ни физического, к базе у него нет и быть не может. Всё его действо — сделать хэш и передать пару логин/хэш http-серверу. И уже сам сервер получив данные и проверив их валидность, обращается к базе данных примерно так, как это было выше описано коллегой.

Volrath, у Вас не возникало неодолимого желания взять любой известный открытый движок — даже не CMS, а банального форума, того же PunBB или phpBB — и просто посмотреть, как там сие реализовано, а?

[Volrath]

спасибо, конечно, погляжу, но еще один вопрос:

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

блеать, но если все так, то в любом случае файл .php должен устанавливать соединение с БД! значит можно его попробовать качнуть и найти параметры подключения.
-"как с этим борятся обычно?"

[Iska]

Попробуйте. Качните. А потом таки сделайте то, на что я Вам намекаю.

[shisik]

Я к тому, что если делать запрос через тот же .php нужно усатновить сперва соединение с БД, чтобы проверить "есть ли в таблице 'Usr' хэш 'pass', где 'log' = введенный 'log' " Если это так, то в скрипте указывается пользователь и пароль у которого есть права на чтение из таблицы "Usr". »

Совершенн оверно. Серверные скрипты устанавливают соединение с БД, используя логин и пароль пользователя этой базы (не путать с учётками на сайте). Права у этого пользователя могут быть разными, но как минимум они позволяют выполнять запросы SELECT, UPDATE, INSERT и DELETE, то есть серверные скрипты имеют возможность не только получать, но и изменять данные в базе.

Опасно ли это? Нет, не опасно. Если только скрипты не позволяют кому угодно выполнять произвольные запросы. Ну то есть допустим у нас есть скрипт login.php, котооые при POST запросе к нему извлекает аргументы login и pasword, санитизирует их (в смысле экранирует управляющие символы, исключая возможность вставить произвольный SQL код в запрос), после чего выполняет SQL запрос и формирует ответ. Если логин или пароль не указан - перенаправляет на страницу логина с сообщение о неполных данных. При этом никакие данные из базы клиенту не отправляются.

-"как защащают доступ из вне, чтобы потльзователь не получил доступ к скриптам"? Например: можно попробовать скачать файл "www.mysite.net/scripts/signin.php" »

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