предисловие
Эта серия изначально была подготовлена для моего собственного интервью, потом я обнаружил, что сортировок становится все больше и больше, почти 120 000 символов, и, наконец, решил поделиться со всеми.
Чтобы поделиться ими и упорядочить их, я потратил много времени, по крайней мере, в три раза больше времени, которое я только использовал.Если вам это нравится, добро пожаловать, чтобы собрать и подписаться на меня!Спасибо!
Ссылка на статью
- Интервью перед интерфейсом для проверки утечек и заполнения вакансий -- (1) Защита от встряски и дросселирования
- Предварительное интервью для проверки пропусков -- (2) Механизм сбора мусора
- Предварительные собеседования для проверки и заполнения вакансий -- (3) Междоменные и общие решения
- Предварительное собеседование для проверки и заполнения вакансий -- (4) Переднее локальное хранилище
- Предварительное собеседование для проверки утечек и заполнения вакансий -- (5) Механизм рендеринга, перерисовка и перекомпоновка
- Интервью переднего плана для проверки пропусков -- (6) Кэш браузера
- Начальное собеседование для проверки и заполнения вакансий — (7) XSS-атака и CSRF-атака
- Предварительное собеседование для проверки и заполнения вакансий -- (8) Переднее шифрование
- Предварительное собеседование для проверки и заполнения вакансий — (9) HTTP и HTTPS
- Предварительное собеседование для проверки и заполнения вакансий -- (10) Передняя аутентификация
- Начальное собеседование для проверки и заполнения вакансий — (11) Образец архитектуры программного обеспечения внешнего интерфейса MVC/MVP/MVVM
- Предварительное собеседование для проверки упущений и заполнения вакансий — (12) Весь процесс от ввода URL-адреса до просмотра страницы (включая три рукопожатия и четыре волны для подробного объяснения)
- Предварительное собеседование для проверки утечек и заполнения вакансий -- (13) Утечки памяти
- Предварительные собеседования для проверки и заполнения вакансий--(14) Алгоритмы и сортировка
- Предварительные собеседования для проверки и заполнения вакансий -- (15) Event Loop
Коллекция:
Предварительные собеседования для проверки пропусков и заполнения вакансий — индекс (набор из 120 000 слов)Содержит более дюжины других статей из серии, которые были написаны до сих пор.Последующие новые статьи с добавленной стоимостью больше не будут добавлять ссылки на каждую статью.Настоятельно рекомендуется ставить лайк и следить за коллекцией!!!!, спасибо!~
Последующий план обновления
Будет продолжать добавлять в будущемШаблоны проектирования,Фронтенд-инжиниринг,процесс проекта, развертывание, замкнутый цикл,Vue часто проверяет очки знанийДождитесь контента. Если вы считаете, что контент хорош, добро пожаловать, собирайте и подписывайтесь на меня! Спасибо!
Спросите инсайдера
В настоящее время я тоже готовлюсь к смене работы, надеюсь, вы и HR дамы порекомендуете надежную.УханьФронтальный пост! Электронная почта: bupabuku@foxmail.com. Спасибо!~
Значение внешнего шифрования
Это неизбежная тема, и мнений определенно много, но на мой взгляд: фронтальное шифрование вроде бы имеет смысл, но иногда кажется, что оно «не имеет смысла». Но в целом имеет смысл использовать аналогию:Поскольку большинство имеющихся на рынке замков можно взломать за 20 минут, есть ли смысл вешать замок на дверь?
Значительное:
По протоколу HTTP данные передаются в виде открытого текста, а сетевой сниффинг может напрямую получать данные в процессе передачи. Например, пароль пользователя и информация, связанная с кредитной картой, после получения посредником, это создает большие риски для безопасности пользователя. С другой стороны, в процессе незашифрованной передачи злоумышленник может изменить данные или вставить вредоносный код. Тогда смысл внешнего шифрования: то есть хэширование данных или их шифрование открытым ключом перед отправкой. Если данные получены посредником, они больше не являются открытым текстом.
Конечно, есть и другие преимущества: например, он позволяет избежать печати журналов, таких как серверная часть, для прямого раскрытия незашифрованных паролей, а также позволяет избежать сбоя открытого текста в библиотеке.
Бессмысленно":По сути, внешнее шифрование может толькоЗащита от джентльмена не может защитить от злодея.Управление интерфейсной системой полностью находится в руках пользователя, то есть пользователь имеет полный контроль над тем, что делает интерфейс. Даже внешнее шифрование не может предотвратить атаки «человек посередине», в том числе HTTPS, потому что посередине все еще существуют различные прокси, прокси на стороне клиента и прокси на стороне сервера.
Вот краткое описание:
- Шифрование не решает проблему воспроизведения, хотя вы отправляете на сторонные серверы, зашифрованы, но после хакера, чтобы перехватить данные после шифрования, так что еще раз, все еще подтверждается. Прослушайте непосредственно к вашему так называемую шифровающую текст, а затем используйте скрипт для инициирования HTTP-запроса. HTTP передается в четко по сети, прокси и шлюзы могут увидеть все данные в той же локальной сети можно понюхать. Какое шифрование не увеличивает сложность атаки, потому что злоумышленник не нужно расшифровать оригинальный пароль, может войти в систему, и это выражена цель достигнута, поэтому нет никаких сложностей.
- Поскольку это шифрование, ключ и алгоритм шифрования должны храниться во внешнем интерфейсе, и злоумышленник может получить алгоритм и ключ, просмотрев исходный код. Если только вы не сделаете плагин для браузера, инкапсулируете алгоритм и ключ в плагине, а затем запутаете отметку времени в открытом тексте при шифровании, так что даже если хакер перехватит данные запроса, процесс воспроизведения быстро завершится сбоем.
В заключение:
- 1. Безопасность — это то, что должны делать как передняя, так и задняя части.Если передняя часть не может быть зашифрована, внутренняя часть будет проигнорирована.
- 2. HTTPS по-прежнему необходим.Пока соединение HTTPS и алгоритм безопасного хеширования на стороне сервера используются правильно, криптографическая система может быть очень безопасной.
Здесь я просто кратко разбираюсь.Если у вас все еще есть сомнения и вы хотите изучить (си) и обсудить (би) подробно, вы можете посмотреть вверху.эта статья
Несколько практик внешнего шифрования
• Передача с шифрованием JavaScript (подробности см. в следующих распространенных методах шифрования)
• Зашифрованная передача в плагине для браузера (используется нечасто, поэтому я не буду здесь вдаваться в подробности)
• HTTPS-транспорт
Алгоритм шифрования
В отличие от хеширования (описанного ниже), шифрование (Encrypt) преобразует целевой текст вобратимый зашифрованный текст. Другими словами, алгоритм шифрования является обратимым, и длина зашифрованного текста, сгенерированного после шифрования, связана с длиной самого открытого текста. такЕсли впоследствии защищенные данные необходимо восстановить в виде открытого текста, необходимо использовать шифрование.
В алгоритме шифрования он делится на симметричное шифрование и асимметричное шифрование.
Симметричное шифрование
В симметричном шифровании используется технология кодирования симметричного шифра, которая характеризуется использованием одного и того же ключа для шифрования и дешифрования файлов.И шифрование, и дешифрование используют один и тот же ключ, который в криптографии называется симметричным алгоритмом шифрования.
Алгоритм симметричного шифрования прост и быстр в использовании, ключ короткий и его трудно расшифровать.Помимо стандарта шифрования данных (DES), еще одной системой шифрования с симметричным ключом является Международный алгоритм шифрования данных (IDEA), который имеет лучшее шифрование, чем DES, и требования к компьютерным функциям не так высоки.
Распространенными алгоритмами симметричного шифрования являются DES, 3DES, Blowfish, IDEA, RC4, RC5, RC6 и AES.
Уведомление:Из-за прозрачности передней части,Для конфиденциальной информации, такой как пароли для входа, не используйте JavaScript для симметричного шифрования.Поскольку другие могут получить ключ от внешнего интерфейса, они могут расшифровать информацию напрямую!
Асимметричное шифрование
Алгоритмы асимметричного шифрования требуют два ключа: открытый ключ и закрытый ключ. Открытый ключ и закрытый ключ представляют собой пару,Если данные зашифрованы с помощью открытого ключа, их можно расшифровать только с помощью соответствующего закрытого ключа; если данные зашифрованы с помощью закрытого ключа, можно расшифровать только соответствующий открытый ключ.Поскольку для шифрования и дешифрования используются два разных ключа, этот алгоритм называется алгоритмом асимметричного шифрования.
Основной процесс алгоритма асимметричного шифрования для реализации обмена конфиденциальной информацией состоит в следующем: Сторона А генерирует пару ключей и раскрывает один из них другим сторонам в качестве открытого ключа; Сторона Б, получившая открытый ключ, использует этот ключ для шифрования данных. Конфиденциальная информация Затем отправьте ее стороне А, после чего сторона А расшифрует зашифрованную информацию другим закрытым ключом, хранящимся у нее. Сторона А может использовать только свой закрытый ключ для расшифровки любой информации, зашифрованной ее открытым ключом.
Распространенными алгоритмами асимметричного шифрования являются: RSA, ECC (для мобильных устройств), Diffie-Hellman, El Gamal, DSA (для цифровых подписей).
алгоритм шифрования хэшей
Алгоритм хеширования (Хэш)
Хэш — это преобразование целевого текста в строку фиксированной длины (или дайджест сообщения).При изменении ввода результирующее значение хеш-функции также совершенно другое. С математической точки зрения, хеш-алгоритм представляет собой отношение отображения «многие к одному».Для целевого текста T алгоритм H может однозначно сопоставить его с R, и для всех T R имеет одинаковую длину, поэтому H не существует обратного отображения , то естьАлгоритмы хеширования необратимы.
Исходя из характеристик алгоритма хеширования, он подходит для этого сценария: защищенные данные используются только для проверки сравнения и не требуют восстановления в открытый текст.Наиболее часто используемые алгоритмы хэширования — MD5 и SHA1.
Нам больше знаком пример использования хэша для хранения данных: когда мы заходим на зарегистрированный сайт, если мы забываем пароль, нам нужно сбросить пароль, в это время сайт пришлет вам случайный пароль или ссылку активации по электронной почте вместо отправки вам предыдущего пароля, потому что алгоритм хэширования необратим.
должен быть в курсе: в веб-приложенииХэш-шифрование также используется на стороне сервера, когда хэш-шифрование используется в браузере.
Причина шифрования хэша на стороне сервера:С одной стороны, нет необходимости расшифровывать зашифрованный текст в открытый текст для сравнения пароля, а с другой стороны, после утечки алгоритма шифрования и ключа вся пользовательская база данных эквивалентна хранилищу открытого текста. Если внешний интерфейс отправляется в виде открытого текста, он будет хеширован и сохранен в базе данных во время регистрации. При входе сравнивайте хэш пароля с данными, соответствующими базе данных, если они совпадают, то пароль правильный.
Теперь основными методами атаки на простые алгоритмы хеширования являются: метод коллизии поиска и метод полного перебора. Поэтому для обеспечения безопасности данных вы можетеДальнейшее шифрование основано на алгоритме хэширования, распространенными методами являются: соление, медленное хеширование, хеширование ключа, XOR и т. д.
Добавление соли
Соленое шифрование — это метод шифрования паролей для входа в систему путем связывания каждого пароля с n-значным случайным числом, называемым «солью».
Для простоты понимания: вот цитата этого одноклассникастатьяБыть объясненным:
Основная идея использования шифрования с солью заключается в следующем:
- 1. Когда пользователи регистрируются, посыпьте солью их пароли. Создавайте аромат, помните аромат.
- 2. Когда пользователь снова войдет в систему, посыпьте введенный пароль солью, понюхайте его и оцените, такой же ли он на вкус, как первоначальный.
Поскольку при проверке пароля и при его первоначальном хешировании используется одна и та же соль,Соль хранится в базе данных. а такжеЭто значение генерируется системой случайным образом., не жестко запрограммировано. Это гарантирует конфиденциальность защищаемого объекта.
При регистрации:
- 1. Когда пользователь регистрируется, система случайным образом генерирует солт-значение.
- 2. Соедините значение соли и пароль, чтобы получить значение хэша.
- 3. Сохраните хэш-значение и значение соли в базе данных соответственно.
При входе в систему:
- 1. Система находит соответствующий хэш пароля по имени пользователя.
- 2. Хэшируйте введенный пользователем пароль и солт-значение.
- 3. Определите, совпадает ли сгенерированное значение хэша с хэшем в базе данных.
PS:На самом деле, этот вид входа в систему на рисунке также небезопасен, причина в повторном использовании солт-значения, упомянутом ниже.
При шифровании с помощью соли следует помнить о двух вещах:
- Короткая планка
Если солт-значение слишком короткое, злоумышленник может предварительно составить справочную таблицу для всех возможных солт-значений. Например, если значение соли составляет всего три символа ASCII, существует только 95x95x95=857 375 возможностей, что увеличивает вероятность атаки. Кроме того, не используйте предсказуемые соли, такие как имена пользователей, поскольку имена пользователей уникальны для системы и часто используются для других служб.
- Повторное использование соли
При разработке проекта иногда встречается, что значение соли жестко прописано в программе или только генерируется случайным образом в первый раз, а потом будет использоваться повторно, такой способ добавления соли не работает. Взяв в качестве примера пароль для входа в систему, если два пользователя имеют одинаковый пароль, то они будут иметь одинаковое хеш-значение, и злоумышленник может использовать метод обратного поиска по таблице для выполнения атаки по словарю для каждого хэш-значения, делая значения хеш-значения их легче взломать.
Таким образом, правильный способ добавления соли выглядит следующим образом:
(1) Солт-значение должно генерироваться зашифрованным безопасным генератором псевдослучайных чисел (криптографически безопасным генератором псевдослучайных чисел, CSPRNG), таким как функция rand() языка C, чтобы сгенерированные случайные числа были высоко случайный и совершенно непредсказуемый;
(2) Солт-значение смешивается с целевым текстом и вместе шифруется с использованием стандартной функции шифрования;
(3) Значение соли должно быть достаточно длинным (опыт показывает, что значение соли должно быть не меньше длины вывода хеш-функции) и никогда не повторяться;
(4) Солт-значение лучше всего предоставляется сервером, и используется внешнее значение.
Медленная хеш-функция
Как следует из названия, медленная хеш-функция делает хэш-функцию очень медленной, что делает метод атаки очень медленным, достаточно медленным, чтобы злоумышленник мог сдаться, и часто возникающая задержка не привлечет внимания пользователя. Техника растяжения ключа используется для снижения эффективности атаки, а реализация растяжения ключа использует хеш-функцию, интенсивно использующую ЦП. Это выглядит немного головокружительно~ или обратите внимание на то, как использовать эту функцию!
Если вы хотите использовать ключевое расширение в веб-приложении, вам нужно установить меньшее количество итераций, чтобы снизить дополнительные вычислительные затраты. Обычно мы используем стандартные алгоритмы напрямую, такие как PBKDF2 или bcrypt. И PHP, и библиотека шифрования JavaScript Стэнфордского университета включают в себя реализацию PBKDF2, и JavaScript можно рассматривать в браузере, иначе эта часть работы должна быть просчитана сервером.
ключевой хеш
Хеширование ключа — это шифрование добавления ключа к хэшу, чтобы только те, кто знает ключ, могли его проверить. В настоящее время существует две реализации: использование алгоритма ASE для шифрования хеш-значения и использование алгоритма хэширования ключа HMAC для включения ключа в хеш-строку. Чтобы сохранить ключ в безопасности, его необходимо хранить во внешней системе (например, на физически изолированном сервере).
Даже если выбран ключ хеш, необходимо добавить его удлинение соли или ключа. В настоящее время ключевые хеши в основном используются на стороне сервера, например, для решения общих атак для инъекций SQL.
XOR
Все знакомы с XOR, который относится к операции «исключающее или» в логических операциях. Возвращает false, если два значения совпадают, в противном случае возвращает true, чтобы определить, отличаются ли два значения.
Для бинарных операций в языке JavaScript существует специальный оператор XOR, записываемый ^.
1 ^ 1 // 0
0 ^ 0 // 0
1 ^ 0 // 1
0 ^ 1 // 1
Операция XOR имеет характеристику:Если вы дважды подряд выполняете операцию XOR со значением, возвращается само значение. Это также является основанием для его использования для шифрования информации.
message XOR key // cipherText
cipherText XOR key // message
Целевое текстовое сообщение, ключ является ключом, и зашифрованный текст будет получен при первом выполнении XOR; целевое текстовое сообщение будет восстановлено путем повторного выполнения XOR над зашифрованным текстом с помощью ключа. Чтобы обеспечить безопасность XOR, необходимо выполнить следующие два пункта:
(1) Длина ключа больше или равна длине сообщения;
(2) Ключ должен быть одноразовым и каждый раз генерироваться случайным образом.
В следующем примере используется шифрование пароля для входа в систему, чтобы представить использование XOR:
Первый шаг: используйте алгоритм MD5 для вычисления хэша пароля;
const message = md5(password);
Шаг 2: Создайте случайное значение ключа;
Шаг 3: Выполните операцию XOR, чтобы получить зашифрованное сообщение.
function getXOR(message, key)
const arr = [];
//假设 key 是32位的
for (let i = 0; i < 32; i++) {
const m = parseInt(message.substr(i, 1), 16);
const k = parseInt(key.substr(i, 1), 16);
arr.push((m ^ k).toString(16));
}
return arr.join('');
}
Как показано выше, используя XOR и одноразовый ключ для шифрования пароля, до тех пор, пока ключ не утек, целевой текст не будет взломан.
Сказав так много выше, возникает вопрос: какой алгоритм хеширования мы должны использовать?
(1) Выберите проверенный и зрелый алгоритм, такой как PBKDF2 и т. д.;
(2) Безопасная версия crypt;
(3) Избегайте использования разработанных вами алгоритмов шифрования.
HMAC
Я мало что знаю об алгоритме HMAC.После прочтения нескольких статей я чувствую, что это очень похоже на добавление соли, то есть соль генерируется бэкэндом случайным образом (это, кажется, предотвращает повторные атаки).Затем алгоритм HMAC используется для получения сводки.
Для части алгоритма HMAC вы можете прочитать это подробностатья, я подонок, и я не очень понимаю это после того, как долго читал. =.=
Примерный процесс выглядит следующим образом:
- 1. Клиент отправляет запрос на вход
- 2. Сервер возвращает случайное значение и сохраняет это случайное значение в записи сеанса.
- 3. Клиент использует случайное значение в качестве ключа, а пароль пользователя выполняет операцию hmac и отправляет его на сервер.
- 4. Сервер считывает пароль пользователя из базы данных, использует ключ для выполнения той же операции hmac, что и клиент, а затем сравнивает его с результатом, отправленным пользователем.Если он непротиворечив, личность пользователя является законной.
выгода:
- В отличие от пользовательского алгоритма плюс соль, алгоритм Hmac является общим для всех алгоритмов хеширования, будь то MD5 или SHA-1. Использование Hmac для замены нашего собственного солевого алгоритма может сделать программный алгоритм более стандартизированным и безопасным. (Отрывок из книги «Большой брат Сюэфэн».эта статья)
- Второй — безопасность пароля, так как ключ неизвестен, невозможно получить пароль пользователя.
Дополнение 1: внешнее шифрование в сочетании с проверочным кодом(На самом деле это динамический соленый хеш)
Внешний интерфейс сначала хэширует пароль, затем хеширует его с кодом подтверждения, введенным пользователем, и отправляет результат на сервер в качестве поля пароля. Сервер сначала подтверждает правильность кода подтверждения, а затем выполняет проверку пароля, в противном случае он напрямую возвращает сообщение об ошибке кода подтверждения.
Такая практика обеспечивает безопасность данных пароля при передаче, и даже если злоумышленник получит данные, их нельзя будет воспроизвести. Графический код проверки еще сложнее. С другой стороны, эта практика значительно увеличивает стоимость заполнения учетных данных.
Внешнее шифрование в определенной степени обеспечивает безопасность данных при передаче, поэтому поможет ли оно безопасности обоих концов (клиента и сервера)?
Полезно, использование некоторых методов внешнего шифрования может увеличить сложность взлома данных после перетаскивания библиотеки. Однако метод проверочного кода не имеет такой функции, потому что хранилище данных по-прежнему является результатом хэша открытого текста пароля, поэтому злоумышленник может обойти внешнее шифрование и может напрямую взломать методом грубой силы.
Дополнение 2: кодировка Base64
Все часто говорят о шифровании Base64, существует ли шифрование Base64?Настоящее дерево, только кодировка Base64.
Base64 — это представление двоичных данных, основанное на 64 печатных символах. Он часто используется для представления, передачи и хранения некоторых двоичных данных, включая электронную почту MIME, электронную почту через MIME, а также для хранения сложных данных в XML в ситуациях, когда обычно обрабатываются текстовые данные; в основном он используется для решения проблемы наполнения непечатаемым контентом. в печатный контент. Метод base64 в js используется следующим образом:
//1.编码
var result = Base.encode('shotCat好帅!'); //--> "c2hvdENhdOWlveW4hSE="
//2.解码
var result2 = Base.decode(result); //--> 'shotCat好帅!' 没错,我就是这么不要脸!!!
Таким образом, Base64 подходит для кодирования небольших фрагментов контента, таких как подписи цифровых сертификатов, содержимое файлов cookie и т. д. Base64 также является методом кодирования с помощью поиска по таблице и не может использоваться для шифрования. алгоритм.
PS:Для внешнего интерфейса наиболее часто используемым base64 является транскодирование изображений.
Приложение 3: Цифровая подпись
Цифровые подписи в основном используются для:Подтвердите, что информация исходит от определенного субъекта, и информация является полной и не подделана, отправитель создает подпись, а получатель проверяет подпись.
отправитель:Сначала вычислите дайджест (хеш-значение) целевого текста, подпишите дайджест закрытым ключом и отправьте целевой текст и электронную подпись получателю.
получатель:Шаги для проверки подписи следующие:
- 1. Расшифровать электронную подпись открытым ключом и получить дайджест D1 (в случае неудачи проверка источника информации не проходит);
- 2. Вычислить сводку целевого текста D2;
- 3. Если D1 === D2, это означает, что целевой текст завершен и не был изменен.
Разница между цифровой подписью и асимметричным шифрованием:
- Асимметричное шифрование (шифрование/дешифрование): шифрование с открытым ключом, дешифрование с закрытым ключом.
- Цифровая подпись (подписать/проверить): подпись с закрытым ключом, проверка с открытым ключом.
HTTPS-шифрование
Чтобы избежать повторения, эта часть подробно рассматривается в этой серии — HTTP и HTTPS.