Это не единственный способ, но так делает большинство стран мира (например, 99,999%), и, насколько я могу судить, 100% веб-программистов.
Подумайте об этом: еслипароль где-то жестко запрограммирован в источнике, зачем?Почему бы не сделать учетную запись без пароля и просто ограничить ее доступ к веб-серверу?Некоторые могут сказать: «Ооооооо! Не делай этого!»Но я снова спрашиваю, в чем разница?Какая дыра в безопасности открыта, чего в любом случае нет?
Реальная проблема безопасности - это защита себя от внедрения SQL.Эта широко открытая учетная запись делает вас уязвимым, если:
1) у вас есть сбой в коде, который можно использовать для выполнения действий, которые пользователь не должен делать, или
2) они могутОбманите ваш db-сервер, чтобы он выполнял код с помощью SQL-инъекции.
Так что SQL-инъекция - ваш большой багбу, от которого нужно защищаться.
Есть и вторичные защиты.Например, большинство людей параноидально относятся к своей таблице «пользователи», которая содержит пользователей и (к сожалению, большую часть времени) простые текстовые пароли, которые необходимы, если вы собираетесь отправить пользователю пароль по электронной почте.
Вы можетеустановить второй уровень защиты для этой таблицы (в случае, если они преодолеют защиту от SQL-инъекций или найдут эксплойт, заставляющий вашу программу делать то, что вы думали, что она этого не сделает), заблокировав ее, чтобы пользователи вообще не могли ее увидеть или написатьк этому.Затем вы пишете две хранимые процедуры: «addUser (имя пользователя, пароль)» и «checkPassword (имя пользователя, пароль)».Это пример "глубокой безопасности", когда у вас есть несколько уровней безопасности для более конфиденциальных данных.