Защищенный паролем сайт с JavaScript

Question

У меня есть очередь, которая может быть простой / тупой или нет :).Другими словами, я понятия не имею, достаточно ли это справедливо или совершенно глупо.Просто несколько свободных мыслей.

Что если я войду в систему через JavaScript с паролем (да, я знаю), но пароль будет хэшироваться алгоритмом Secure Hash.Например:

Я генерирую проход с SHA, который выглядит как

var = 0xc1059ed8... //etc

и вставляю в код.Там будет также две функции.Один будет сравнивать два значения (данные мной с пользователем), а второй будет генерировать ввод Sha Sha пользователя.

Теоретически это может быть безопасно, или это ужасная модель и глупая идея?Может ли JS справиться с этим?

РЕДАКТИРОВАТЬ: Я не имел в виду серьезную проверку подлинности, как банковская.Просто когда у меня есть мои фотографии и я хочу, чтобы их смотрели только несколько человек, а 99,9% людей на земле не могут их смотреть :) Спасибо за ответы

Answer 1

Извините, никаких кубиков :) Безопасная аутентификация невозможна только с использованием Javascript на стороне клиента, поскольку положительный результат аутентификации может быть подделан. Вам всегда понадобится экземпляр на стороне сервера для аутентификации.

Answer 2

Общий ответ таков: «Нет, вы не можете выполнить аутентификацию на стороне клиента», и для обычных сценариев это правильно, но я могу придумать по крайней мере два способа заставить его работать:

1. Используйте хэш пароля SHA для перенаправления на статическую HTML-страницу (0xc1059ed8 ... html).До тех пор, пока виртуальный каталог не разрешает перечисление файлов, никто не сможет угадать имя файла, который вы хотите защитить.Это становится очень неуклюжим очень быстро.

2. Используйте реализацию алгоритма шифрования (AES и т. Д.) В Javascript для расшифровки блока текста, который составляет фактическое содержимое вашей страницы.Хотя это действительно практично только для одной очень ценной страницы.

Аутентификация на стороне сервера действительно лучшая, но неверно утверждать, что на стороне клиента это сделать невозможно.

Answer 3

Вы не можете защитить свой сайт только с помощью Javascript. Вам понадобится какой-нибудь способ аутентификации запросов на сервере.

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

Необходимо обеспечить безопасность на стороне сервера, период до конца. ASP.NET имеет встроенный способ сделать это, называемый «Аутентификация с помощью форм». Или вы можете использовать переменные Session в php-скрипте.

Answer 4

Ваш источник JS все равно будет виден, и любой может легко его подделать. Вы должны сделать проверку на стороне сервера

Answer 5

Вам было бы лучше вообще не пытаться аутентифицироваться - по крайней мере, таким образом, вы бы никого не создавали опасной иллюзии о том, что что-то, связанное с , может быть в безопасности.Предполагая, что вы имеете дело с общей секретной ситуацией, аутентификация действительно довольно проста.Вы используете довольно простой алгоритм «вызов-ответ».По сути, клиент отправляет на сервер сообщение о том, что хочет войти в систему. Сервер отвечает, отправляя назад случайное число.Клиент шифрует это случайное число с помощью правильного пароля и отправляет его обратно.Сервер сам шифрует случайное число и сравнивает результат с тем, что отправил клиент.Если они совпадают, аутентификация прошла успешно - вы подтвердили, что у клиента правильный пароль.

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

Answer 6

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

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

Это может быть предотвращено ответом на запрос, когда сервер отправляет со страницей «соль»: большое случайное число, которое перемешивается с паролем, а затем хэшируется, поэтому ответ всегда будет другим.

К сожалению, это приводит к тому, что серверу теперь нужно иметь незашифрованные пароли, что является плохой идеей (хорошо, здесь есть несколько хитростей). Таким образом, вам может потребоваться отправить соль, хэшировать свой пароль, смешать хэш с солью, снова хэшировать его и отправить на сервер. Сервер хэширует сохраненный хеш пароля от пользователя db с солью и сравнивает оба.

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

И в любом случае это будет сервер, у которого есть окончательное решение, кто может получить доступ.

Answer 7

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