Как зашифровать данные PIN-кодом?
Стандартные инструменты Web Crypto API позволяют сгенерировать пару закрытый-открытый ключ для шифрования и дешифрования данных.
А как сделать так, чтоб сначала пользователь придумал PIN-код, а потом система зашифровала какие-либо данные этим пин-кодом? А потом этим же пин-кодом расшифровала его? Предполагается, что пин-код состоит из 4 или 6 цифр.
<!DOCTYPE html>
<html lang="ru">
<head>
<meta charset="UTF-8">
<title>Encrypt PIN</title>
</head>
<body>
<style>
h1 {
margin: 0;
font-size: 22px;
}
p {
margin: 16px 0 12px;
}
.columns {
display: grid;
grid-template-columns: repeat(2, 1fr);
}
</style>
<h1>Шифрование данных PIN-кодом</h1>
<section class="columns">
<div>
<p>Придумать пин-код и зашифровать данные</p>
<form id="encryp">
<input id="encrypt-pin" type="password" placeholder="Придумайте пин-код">
<input id="encrypt-data" placeholder="Данные для шифрования">
<input id="encrypt-button" type="submit" value="Encrypt">
</form>
<div id="encrypt-export"></div> <!-- Здесь выводится зашифрованная информация -->
</div>
<div>
<p>Ввести пин-код и расшифровать данные</p>
<form id="decrypt">
<input id="decrypt-pin" type="password" placeholder="Пин-код шифрования">
<input id="decrypt-data" placeholder="Данные для расшифрования">
<input id="decrypt-button" type="submit" value="Decrypt">
</form>
<div id="decrypt-export"></div> <!-- Здесь выводится расшифрованная информация -->
</div>
</section>
</body>
</html>
|
https://developer.mozilla.org/en-US/...ypto/deriveKey
Там последний пример - как из некоего пароля получить ключ, а потом этим ключом шифровать данные. |
Цитата:
А как сделать так, чтобы пароль этот хранился локально в каком-либо виде, но и в то же время был недоступным для пользователей, которые обладают навыками программирования и потенциально могут просто получить его? |
Цитата:
В крипто апи для этого используется метод deriveKey() желательно по алгоритму PBKDF2 Цитата:
В крипто апи это методы encrypt() и decrypt() по алгоритму AES-GCM с этим алгоритмом желательно хранить/передавать уникальный вектор инициализации для каждого зашифрованного сообщения этот вектор не является секретным и может открыто передаваться однако его наличие сильно повышает криптостойкость. |
Цитата:
Так вы имеете ввиду?) |
Цитата:
В таких случаях пытаются реализовать другие меры например двух факторную авторизацию. Тогда злоумышленнику понадобиться доступ и к личному телефону или персональному ключу. |
Цитата:
|
Цитата:
1. salt 2. iv - почти тоже самое что и salt 3. зашифрованный текст И когда требуется расшифровка — вводим пароль и всё — данные расшифровываются. Сам пароль получается вообще никак не надо ни хэшировать, ни хранить где-либо. |
Цитата:
|
Цитата:
Что бы этого избежать в систему криптообмена вводят третий фактор не зависящий от скомпрометированной части системы. Например шифрование и расшифровку производит отдельное устройство вставленное в USB порт или сервис в интернете присылает SMS необходимое для расшифровки. В целом не так важно как третий фактор будет работать с системой главное не полагаться на скомпрометированную часть системы полностью. |
Цитата:
И чем же принципиально отличается USB-флешка от пароля, который вводится для расшифровки данных и вообще нигде не хранится (ну, если только в уме)? |
Цитата:
Например приложение стим на телефоне умеет генерировать код для двухфакторной авторизации при этом не имея доступа к сети интернет. в этом приложении храниться закрытый ключ который служит для получения удостоверяющей подписи к метки времени. У приложения стим на компьютере есть открытый ключ с помощью которого можно проверить подпись. В такой системе секрет(закрытый ключ) не раскрывается для уязвимой части системы (персонального компьютера) Цитата:
Эта и служит источником проблемы заставляя раскрыть секрет пароля уязвимой части системы шифрования. Цитата:
|
Цитата:
Цитата:
Цитата:
Цитата:
Идите лучше учите уроки, у вас ОГЭ скоро. Нечего тут сидеть и нести херню. Либо выражайтесь конкретно — фактами и доказательствами, без вставки ваших 5 копеек. |
voraa,
Может ты как-то прокомментируешь высказывания от MallSerg?)) |
Цитата:
Это явно противоречит заявлению - "нигде не хранится". |
Цитата:
Поэтому совершенно непонятно, что вам там "очевидно" — очередные пустые слова без подтверждений. |
Цитата:
1. существует таком момент когда пароль хранится (между вводом пароля и вызовом getKeyMaterial). 2. в этот моменть злоумышленник может его сохранить (имеет полный доступ к компьютеру). вывод Утверждение - "злоумышленник не сможете получить данные пароля" является ложью. очевидно или еще нет? |
Цитата:
В моём же случае имелось ввиду, что у злоумышленника может быть локальный доступ к системе в том случае, когда рядом нет владельца. Т.е., например, владелец каким-то образом оставил приложение открытым и злоумышленник начал там копаться, чтобы получить доступ к секретным данным. Он может попытаться взломать с помощью перебора паролей. И в нашем случае речь идет о мобильном приложении PWA. |
Цитата:
повторюсь Цитата:
Далеко не факт что это хорошее решение в рамках твоего приложения но не стоит считать такую систему шифрования надежной. |
MallSerg,
А как хранит секретные данные (SEED-фразу) MetaMask? |
Цитата:
поэтому сид-фразу MetaMask можно прочитать в обычном текстовом файле. подробнее https://nvd.nist.gov/vuln/detail/CVE-2022-32969 Что бы решать подобные вопросы серьезные организации разрабатывают Стандарты информационной безопасности. В таких стандартах описываются условия и требования к обмену информацией и на основании проверки соблюдения стандартов организации выдают сертификаты и лицензии на право какой либо деятельности. |
Цитата:
Цитата:
Дальше он пишет, мол Цитата:
Или я чего-то не догоняю? Представим условно, что a = hashPassword и b = sha256(promptPassword). Получается внутри системы должна быть функция, которая сравнивает a и b , и если всё ок, то открывает доступ к системе, а так же сохраняет этот пинкод в открытом виде (чтоб с помощью PBKDF2 расшифровывать seed-фразу)? Получается мне ничего не мешает без проверок выполнить код, который находится внутри этого if. Так всё и работает исходя из ответа ChatGPT? |
Цитата:
В случае если злоумышленник будет знать хеш от пароля это ему не поможет пройти авторизацию т.к. он не сможет узнать пароль из которого известный ему хеш был получен. |
Цитата:
Но когда у нас локально это всё работает — мне ничего не мешает просто взять функцию и запустить её через консоль. То есть локально я могу легко обойти этап сравнивания хешей. Поэтому какой в этом смысл тогда? |
Цитата:
т.е. проверка хеша лишь удостоверит что пароль(часть ключа) является верным и данные будут расшифрованы. |
Цитата:
Но у нас же это локально происходит. Получается хранить хеш пароля, чтоб потом его сравнивать на стороне клиента — в этом просто смысла нет? Или есть? |
Смысл в том что алгоритм будет знать что он работает правильно т.е. расшифрует сообщение а не покажет ошибку о неверно введенном пароле.
Использование сохраненного хэша сохраняет в тайне часть ключа (пароль). В такую систему можно добавить и другие части ключа и точно также с помощью хэша их проверять. Даже если злоумышленник будет знать алгоритм работы и хэши это не позволит ему получить доступ к системе без знания всех секретов системы (пароли пинкоды смс биометрические данные и тому подобного). |
Цитата:
|
Хранение пароля делает систему уязвимой по этому этого стараются избежать при создании алгоритмов работы защищенных систем.
Думаю самой распространенной практикой является создание сессии или токена актуальных в какой то заранее указанный промежуток времени. Где опять же используется свойство необратимости хеш функций способных подтверждать истинность события(цифровая подпись) не раскрывая при этом секрета. |
Цитата:
|
| Часовой пояс GMT +3, время: 00:04. |