Аутентификация библиотеки JavaScript

Question

Является ли кошерным выводить учетные данные аутентификации в javascript SDK из серверного кода?

Например, в шаблонизировании Django это может выглядеть следующим образом:

<script type="text/javascript">
    sdk = Sdk();
    sdk_username = "{{ users_sdk_username }}";
    sdk_password = "{{ users_sdk_password }}";
    sdk.connect(sdk_username, sdk_password);
</script>

немного схематично, но я не уверен, как аутентифицировать javascript SDK на сервере и передать токен клиенту.

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

Answer 1

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

Идея в том, что вы:

1. Возьмите пароль пользователя, указанный при первоначальной регистрации или с помощью функции «изменить свой пароль», и добавьте к нему некоторое количество случайных байтов («соль»);
2. Поместить случайные байты и пароль пользователя через криптографически безопасную хеш-функцию; Проверьте текущую литературу, чтобы увидеть, что использовать (SHA-1? Я не знаю, что лучше на данный момент, февраль 2012). Затем сохраните хешированный пароль плюс случайные «соленые» байты в базе данных. Соляные байты должны быть в виде простого текста; Их задача - сделать «радужную таблицу» из миллиардов возможных паролей менее практичной.
3. Чтобы проверить пароль пользователя при аутентификации, добавьте (или добавьте, в зависимости от случая) сохраненное солт-значение пользователя (доступное по заявленному имени пользователя) к предоставленному предполагаемому паролю и примените ту же хеш-функцию. Если результат хеширования соответствует сохраненному хешу, то пользователь предоставил правильный пароль.

Я не специалист по криптографии, поэтому я бы посоветовал вам (или всем, кто читает это) провести дополнительные исследования новейших методов и лучших практик. Например, в последние годы было выдумано несколько интересных атак против этих схем, связанных с определенным временем выполнения операций. Таким образом, сейчас лучше убедиться, что ваш ответ на неудачные (и, возможно, успешные!) Пароли связан с некоторой случайной задержкой. Даже это может быть предметом спора, если ваш злоумышленник может (для, возможно, дико наглядного примера) контролировать энергопотребление ваших серверов! Это страшный мир.

Answer 2

Совсем нет.

Ваши пользователи могут легко увидеть пароль в исходном коде.