Без понятия. MetaMask и им подобные программы/сервисы работают на доверии пользователей.
поэтому сид-фразу MetaMask можно прочитать в обычном текстовом файле.
подробнее https://nvd.nist.gov/vuln/detail/CVE-2022-32969

Что бы решать подобные вопросы серьезные организации разрабатывают Стандарты информационной безопасности. В таких стандартах описываются условия и требования к обмену информацией и на основании проверки соблюдения стандартов организации выдают сертификаты и лицензии на право какой либо деятельности.

Это не так. ChatGPT ответил:

— в принципе, это тоже самое о чём мы здесь и говорили ранее.

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

Или я чего-то не догоняю?

Представим условно, что a = hashPassword и b = sha256(promptPassword). Получается внутри системы должна быть функция, которая сравнивает a и b , и если всё ок, то открывает доступ к системе, а так же сохраняет этот пинкод в открытом виде (чтоб с помощью PBKDF2 расшифровывать seed-фразу)?

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

Так всё и работает исходя из ответа ChatGPT?

Хеш функции для паролей обладают свойством необратимости результата хеширования т.е. зная хеш от пароля никакими средствами нельзя узнать пароль. Когда пользователь авторизуется с помощью пароля алгоритм авторизации снова считает хеш и сравнивает его с сохраненным в базе данных если хеши совпадают пароль считается верным.

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

Вы научитесь внимательно читать? То что вы описали касается серверных операций. Т.е. пароль отправляется на сервер, хешируется и сравнивается с хешем который в базе. Если они сходятся, то выполняется функция.

Но когда у нас локально это всё работает — мне ничего не мешает просто взять функцию и запустить её через консоль. То есть локально я могу легко обойти этап сравнивания хешей.

Поэтому какой в этом смысл тогда?

Мешает тот факт что пароль является частью ключа.
т.е. проверка хеша лишь удостоверит что пароль(часть ключа) является верным и данные будут расшифрованы.

А зачем тогда вообще эта проверка нужна? Можно было бы понять, если бы это были серверные операции — чтобы каждый раз не отправлять пин-код на сервер и проверять его там — т.е. не создавать нагрузку на инфраструктуру (или для защиты от DDOS-атаки).

Но у нас же это локально происходит. Получается хранить хеш пароля, чтоб потом его сравнивать на стороне клиента — в этом просто смысла нет? Или есть?

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

А как тогда хранить пароль, если надо чтобы система его запомнила (и удалила, например, после 5 минут отсутствия активности)?

Хранение пароля делает систему уязвимой по этому этого стараются избежать при создании алгоритмов работы защищенных систем.
Думаю самой распространенной практикой является создание сессии или токена актуальных в какой то заранее указанный промежуток времени.
Где опять же используется свойство необратимости хеш функций способных подтверждать истинность события(цифровая подпись) не раскрывая при этом секрета.

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