Я никогда не работал на стороне безопасности веб-приложений, так как я просто из колледжа. Теперь я ищу работу и работаю над некоторыми сайтами на стороне, чтобы сохранить свои навыки острыми и получить новые. Один сайт, над которым я работаю, в значительной степени скопирован из оригинального MEAN стека из парней, которые его создали, но пытается понять его и сделать что-то лучше, где я могу.
Чтобы вычислить хэш и соль, создатели использовали PBKDF2. Мне не интересно слышать о аргументах за или против PBKDF2, поскольку это не тот вопрос, о котором идет речь. Кажется, они использовали буферы для всего, что я понимаю, это обычная практика в node. Меня интересуют причины использования base64 для кодирования буфера, а не просто использование UTF-8, которое является опцией с объектом буфера. Большинство компьютеров в настоящее время могут обрабатывать многие символы в Unicode, если не все из них, но создатели могли бы выбрать кодирование паролей в подмножестве Unicode, не ограничиваясь 65 символами base64.
Под "выбором между кодировкой как UTF-8 или base64" я подразумеваю преобразование двоичного кода хэша, вычисленного из пароля, в данную кодировку. node.js указывает пару способов кодирования двоичных данных в объект Buffer. На странице документации для класса Buffer:
Pure JavaScript is Unicode friendly but not nice to binary data. When dealing with TCP
streams or the file system, it necessary to handle octet streams. Node has several
strategies for manipulating, creating, and consuming octet streams.
Raw data is stored in instances of the Buffer class. A Buffer is similar to an array
of integers but corresponds to a raw memory allocation outside the V8 heap. A Buffer
cannot be resized.
Что класс Buffer делает, как я понимаю, принимает некоторые двоичные данные и вычисляет значение каждого 8 (обычно) бит. Затем он преобразует каждый набор бит в символ, соответствующий его значению в указанной вами кодировке. Например, если двоичные данные 00101100 (8 бит), и вы указываете UTF-8 в качестве кодировки, выход будет , (запятая). Это то, что каждый, кто смотрит на выход буфера, увидит, глядя на него с помощью текстового редактора, такого как vim, а также на то, что компьютер "увидит" при "чтении". Класс Buffer имеет несколько доступных кодировок, таких как UTF-8, base64 и binary.
Я думаю, они чувствовали, что, сохраняя любой символ UTF-8, который можно вообразить в хэше, как они должны были бы сделать, не будет фазировать большинство современных компьютеров с их гигабайтами ОЗУ и терабайтами пространства, фактически показывая все эти символы, так как они могут захотеть делать в журналах и т.д., будут вызывать у пользователей пользователей, которым придется смотреть на странные китайские, греческие, болгарские и т.д. символы, а также контрольные символы, такие как кнопка Ctrl или кнопка Backspace или даже звуковые сигналы. Им никогда не понадобилось бы разбираться ни в одном из них, если бы они не были опытными пользователями, которые сами тестировали PBKDF2, но первая задача программиста - не давать никому из его пользователей инфаркт. Использование base64 увеличивает накладные расходы примерно на треть, что вряд ли стоит отметить в эти дни, и уменьшает набор символов, что ничто не мешает безопасности. В конце концов, компьютеры написаны полностью в двоичном формате. Как я уже говорил, они могли выбрать другой подмножество Unicode, но base64 уже является стандартным, что упрощает работу и сокращает работу программиста.
Я правильно понимаю причины, по которым создатели этого репозитория решили кодировать свои пароли в base64 вместо всего Юникода? Лучше ли придерживаться их примера, или я должен идти с Unicode или большим подмножеством?