Шифрование хешем пароля!

Допустим, я создаю такое приложение для заметок (своеобразный дневник), в котором пользователь мог бы изливать душу, рассказывать, как классно он сегодня поабузил армлет, как покушал и покакал, и при этом не бояться, что я, как админ сервера, это всё прочту.

 

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

 

Если использовать просто обычный пароль от аутентификации, то тогда его придется хранить в незащищённом виде, и его могут украсть в ходе XSS атаки (если речь о браузере).

 

Поэтому я придумал гениальное решение - использовать хеш пароля! (офк хеш другим алгоритмом, нежели на сервере)

 

Таким образом, пользователь на любом новом устройстве просто введёт свои логин и пароль, как обычно, и не испытает абсолютно никаких трудностей. А злоумышленник, проведя условную XSS атаку, получит лишь хеш пароля, а не сам пароль. Офк не супер-безопасно, но приемлемо, я считаю.

 

Что скажете? Есть ли изъяны в моей системе? Имеет ли право на жизнь?

отлично, скачаю одно приложение на телефон а второе своему корешу джахиду на ноутбук

будем взрывать башни близнецы, переписка у тебя в приложении, спасибо брат

_бабка_в_кедах_ сказал(а):↑

отлично, скачаю одно приложение на телефон а второе своему корешу джахиду на ноутбук

будем взрывать башни близнецы, переписка у тебя в приложении, спасибо брат

Нажмите, чтобы раскрыть...

такое приложение создавать незаконно что-ли? нужно срочно экспертное мнение юриста

_бабка_в_кедах_ сказал(а):↑

отлично, скачаю одно приложение на телефон а второе своему корешу джахиду на ноутбук

будем взрывать башни близнецы, переписка у тебя в приложении, спасибо брат

Нажмите, чтобы раскрыть...

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

ну я слышал о том что это в общем-то распространенная практика

 

правда сверху еще добавляют соль, чтобы случайно утекшая база данных не совпала с уже утекшими базами данных

 

ну условно обычный хеш:

qwerty123 -> 0x3fc0a7…

 

а с солью:

qwerty123 . salt -> 0xdeadf00d…

 

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

Lancer.Rev.X сказал(а):↑

такое приложение создавать незаконно что-ли? нужно срочно экспертное мнение юриста

 

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

Нажмите, чтобы раскрыть...

да я не знаю, думаю если правительство захочет выставить приложение в нужном свете тебя ниче не спасет, я не юрист но задумка на рискичах

Lancer.Rev.X сказал(а):↑

Допустим, я создаю такое приложение для заметок (своеобразный дневник), в котором пользователь мог бы изливать душу, рассказывать, как классно он сегодня поабузил армлет, как покушал и покакал, и при этом не бояться, что я, как админ сервера, это всё прочту.

 

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

 

Если использовать просто обычный пароль от аутентификации, то тогда его придется хранить в незащищённом виде, и его могут украсть в ходе XSS атаки (если речь о браузере).

 

Поэтому я придумал гениальное решение - использовать хеш пароля! (офк хеш другим алгоритмом, нежели на сервере)

 

Таким образом, пользователь на любом новом устройстве просто введёт свои логин и пароль, как обычно, и не испытает абсолютно никаких трудностей. А злоумышленник, проведя условную XSS атаку, получит лишь хеш пароля, а не сам пароль. Офк не супер-безопасно, но приемлемо, я считаю.

 

Что скажете? Есть ли изъяны в моей системе? Имеет ли право на жизнь?

Нажмите, чтобы раскрыть...

а я неправильно понял (как всегда )

я думал ты просто авторизацию проводишь

 

по идее незашифрованный текст вообще не должен оказываться у тебя на сервере

 

иначе в чем смысл всех этих танцев

 

шифрование/дешифрование должен делать клиент пользователя

 

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

Ты как-то всё слишком перемудрил

Вот у тебя есть на сервере зашифрованный текст каким-то паролем

Ты его берешь копируешь с сервера вставляешь в дешифратор у себя на компьютере

 

Получаешь расшифрованный изначальный свой текст

 

Редактируешь его как тебе надо

Зашифровываешь у себя на компьютере и ложишь обратно на сервер

 

Даже если тебе придется запоминать ключ (на самом деле нет, ведь он лежит у тебя на компьютере), то это не так сложно как ты думаешь

Lancer.Rev.X сказал(а):↑

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

Нажмите, чтобы раскрыть...

для такого дела есть всякие токены

Lancer.Rev.X сказал(а):↑

Что скажете? Есть ли изъяны в моей системе? Имеет ли право на жизнь?

Нажмите, чтобы раскрыть...

самое главное, не делай это все через куки, как требует того дебил заказчик у нас на проекте

Kemoin сказал(а):↑

для такого дела есть всякие токены

самое главное, не делай это все через куки, как требует того дебил заказчик у нас на проекте

Нажмите, чтобы раскрыть...

а зачем куки, в localstorage положу. серверу же этот хеш отправлять не нужно будет, он чисто для пользования самим клиентом

YoshkinKot сказал(а):↑

а я неправильно понял (как всегда )

я думал ты просто авторизацию проводишь

 

по идее незашифрованный текст вообще не должен оказываться у тебя на сервере

 

иначе в чем смысл всех этих танцев

 

шифрование/дешифрование должен делать клиент пользователя

 

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

Нажмите, чтобы раскрыть...

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

Lancer.Rev.X сказал(а):↑

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

Нажмите, чтобы раскрыть...

ну на самом деле симметричные шифры достаточно шустрые

 

ты например при https всю информацию входящую дешифруешь и исходящую шифруешь постоянно

 

а еще процессоры часто поддерживают аппаратное ускорение тех или иных алгосиков (AES например): если стандартными либами пользоваться, то всё будет хорошо

YoshkinKot сказал(а):↑

ну на самом деле симметричные шифры достаточно шустрые

 

ты например при https всю информацию входящую дешифруешь и исходящую шифруешь постоянно

 

а еще процессоры часто поддерживают аппаратное ускорение тех или иных алгосиков (AES например): если стандартными либами пользоваться, то всё будет хорошо

Нажмите, чтобы раскрыть...

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

 

Вопрос из технического превращается в философский!

Lancer.Rev.X сказал(а):↑

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

 

Вопрос из технического превращается в философский!

Нажмите, чтобы раскрыть...

ну ты тем самым сам себя защищаешь от силовиков и прочих товарищей в фуражках

 

я не знаю как у нас, но на Западе либо тебя полностью закрывают как например с lavabit было, либо дают работать и не лезут вообще: на нет — и суда нет

 

в любом случае ты остаешься честным со своими пользователями

 

а если ты имеешь какую-то возможность читать, то тебя вежливо и не очень попросят сотрудничать)

 

Lancer.Rev.X сказал(а):↑

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

 

Вопрос из технического превращается в философский!

Нажмите, чтобы раскрыть...

ну в целом да, поэтому обновления — зло, как говорится

 

нельзя пользователей принуждать к обновлениям непрерывным

 

обновления ПО должны быть неперсонифицированными и опциональными

 

с доставкой произвольного джаваскрипта по вебу — это все очень плохо стакается, и в этом смысле веб-приложениями вообще не стоит пользоваться

 

но мы находимся в проклятом таймлайне где людей всё это совершенно не волнует и видимо потребуется какой-то кошмар: как в каком-нибудь Deus Ex: Human Revolution или в Appleseed, прежде чем станет очевидно, зачем нужны меры предосторожности

Приложение при смене пароля автоматически и рандомно присваивает себе новый auth key. И приравнивает его к новому паролю. При входе приложение сравнивает их. Как бы проверка приложением изнутри. 

Чето выдал, надеюсь не совсем бред

Lancer.Rev.X сказал(а):↑

все-таки придется защищать дневник отдельным ключом.

Нажмите, чтобы раскрыть...

Проблема этого метода в том, что паяльник в жопе заставит тебя выдать всё

Lancer.Rev.X сказал(а):↑

Допустим, я создаю такое приложение для заметок (своеобразный дневник), в котором пользователь мог бы изливать душу, рассказывать, как классно он сегодня поабузил армлет, как покушал и покакал, и при этом не бояться, что я, как админ сервера, это всё прочту.

 

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

 

Если использовать просто обычный пароль от аутентификации, то тогда его придется хранить в незащищённом виде, и его могут украсть в ходе XSS атаки (если речь о браузере).

 

Поэтому я придумал гениальное решение - использовать хеш пароля! (офк хеш другим алгоритмом, нежели на сервере)

 

Таким образом, пользователь на любом новом устройстве просто введёт свои логин и пароль, как обычно, и не испытает абсолютно никаких трудностей. А злоумышленник, проведя условную XSS атаку, получит лишь хеш пароля, а не сам пароль. Офк не супер-безопасно, но приемлемо, я считаю.

 

Что скажете? Есть ли изъяны в моей системе? Имеет ли право на жизнь?

Нажмите, чтобы раскрыть...

 

 

 

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

 

 

В фастапи это реализуется через pwd context. 

 

 

P.S перечитал и понял о чём ты, шифровать записи пользвателя его же хэшом. Но надо будет решать проблему персистентности данных при смене приватного ключа тобишь самого пароля. Ну это самый главный гемор шифрований данных. 

 

 

к сожалению это не ты придумал)

просто посмотри реализации сайты с е2е зашифрованными данными, например мега/битварден 

Aerolife сказал(а):↑

к сожалению это не ты придумал)

просто посмотри реализации сайты с е2е зашифрованными данными, например мега/битварден 

Нажмите, чтобы раскрыть...

ладно это я перепутал, думал юзер сам себе отправляет через сайт)))

YoshkinKot сказал(а):↑

а я неправильно понял (как всегда )

я думал ты просто авторизацию проводишь

 

по идее незашифрованный текст вообще не должен оказываться у тебя на сервере

 

иначе в чем смысл всех этих танцев

 

шифрование/дешифрование должен делать клиент пользователя

 

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

Нажмите, чтобы раскрыть...

Всё, я понял, как решить задачу:

Пользователь пользуется устройством А и шифрует свои данные сколько угодно длинным ключом, хоть миллион символов, хранит ключ на своём устройстве.

Пользователь хочет подключить устройство Б, но не хочет перепечатывать весь миллион символов ключа с клавиатуры. Тогда устройство Б создаёт пару закрытый/открытый ключ для какого-нибудь условного RSA и отправляет открытый ключ устройству А прямо тупо через мой сервер. Устройство А открытым ключом шифрует ключ пользователя и отправляет его устройству Б, тоже через мой сервер.

 

С точки зрения пользователя всё максимально примитивно, нужно просто открыть одновременно устройства А и Б и нажать там на кнопки. Единственный момент, что если пользователь случайно удалит свой ключ, браузер почистит, например, то потеряет все свои данные. Но это уже будут не мои проблемы! (только если пользователь - не я сам)

Lancer.Rev.X сказал(а):↑

Всё, я понял, как решить задачу:

Пользователь пользуется устройством А и шифрует свои данные сколько угодно длинным ключом, хоть миллион символов, хранит ключ на своём устройстве.

Пользователь хочет подключить устройство Б, но не хочет перепечатывать весь миллион символов ключа с клавиатуры. Тогда устройство Б создаёт пару закрытый/открытый ключ для какого-нибудь условного RSA и отправляет открытый ключ устройству А прямо тупо через мой сервер. Устройство А открытым ключом шифрует ключ пользователя и отправляет его устройству Б, тоже через мой сервер.

 

С точки зрения пользователя всё максимально примитивно, нужно просто открыть одновременно устройства А и Б и нажать там на кнопки. Единственный момент, что если пользователь случайно удалит свой ключ, браузер почистит, например, то потеряет все свои данные. Но это уже будут не мои проблемы! (только если пользователь - не я сам)

Нажмите, чтобы раскрыть...

ну возьми просто TLS какой-нибудь или SSH

Lancer.Rev.X сказал(а):↑

Всё, я понял, как решить задачу:

Пользователь пользуется устройством А и шифрует свои данные сколько угодно длинным ключом, хоть миллион символов, хранит ключ на своём устройстве.

Пользователь хочет подключить устройство Б, но не хочет перепечатывать весь миллион символов ключа с клавиатуры. Тогда устройство Б создаёт пару закрытый/открытый ключ для какого-нибудь условного RSA и отправляет открытый ключ устройству А прямо тупо через мой сервер. Устройство А открытым ключом шифрует ключ пользователя и отправляет его устройству Б, тоже через мой сервер.

 

С точки зрения пользователя всё максимально примитивно, нужно просто открыть одновременно устройства А и Б и нажать там на кнопки. Единственный момент, что если пользователь случайно удалит свой ключ, браузер почистит, например, то потеряет все свои данные. Но это уже будут не мои проблемы! (только если пользователь - не я сам)

Нажмите, чтобы раскрыть...

 

а твой сервер в этот момент берет и генерит свою пару ключей и отправляет публичный устройству А, как будто бы он идет от Б

 

А шифрует им и возвращает серверу, сервер расшифровывает секрет, и зашифровывает публичным ключом Б и отправляет Б

 

в такой схеме у тебя нет аутентификации обоих сторон. без доверенного СА такое не взлетит

 

 

насчет хеширования: все так и делают уже десятки лет, как минимум по двум причинам:

 

- не зависеть от длины секрета, будет ли он длиной 2 символа или 2ккк символов

 

- в случае утечки секретов с конкретного устройства, паролей в чистом виде не будет, ибо мало ли для каких других ресурсов они могут быть валидны

 

 

в излишне длинных секретных фразах нет особого смысла, это даже к обратному эффекту может приводить, в случае с bcrypt, к примеру

 

более того, чистый пароль редко ключом может быть, в большинстве алгоритмов есть свои т.н. key derivation function

 

 

 

лениво все читать, опиши в двух словах в чем задача состоит:

 

- какие данные хранить? текст? бинари? 

 

- чем твоя затея лучше загрузки запароленного архива на условный гугл диск? или pgp в почте?

 

- кому можно доверять в этой схеме?

 

- кто должен иметь доступ к данным?

BrightFuture сказал(а):↑

 

а твой сервер в этот момент берет и генерит свою пару ключей и отправляет публичный устройству А, как будто бы он идет от Б

 

А шифрует им и возвращает серверу, сервер расшифровывает секрет, и зашифровывает публичным ключом Б и отправляет Б

 

в такой схеме у тебя нет аутентификации обоих сторон. без доверенного СА такое не взлетит

 

 

насчет хеширования: все так и делают уже десятки лет, как минимум по двум причинам:

 

- не зависеть от длины секрета, будет ли он длиной 2 символа или 2ккк символов

 

- в случае утечки секретов с конкретного устройства, паролей в чистом виде не будет, ибо мало ли для каких других ресурсов они могут быть валидны

 

в излишне длинных секретных фразах нет особого смысла, это даже к обратному эффекту может приводить, в случае с bcrypt, к примеру

 

более того, чистый пароль редко ключом может быть, в большинстве алгоритмов есть свои т.н. key derivation function

 

 

 

лениво все читать, опиши в двух словах в чем задача состоит:

 

- какие данные хранить? текст? бинари? 

 

- чем твоя затея лучше загрузки запароленного архива на условный гугл диск? или pgp в почте?

 

- кому можно доверять в этой схеме?

 

- кто должен иметь доступ к данным?

Нажмите, чтобы раскрыть...

чувак хочет на сервере хранить зашифрованный текст

 

поэтому ему нужен пароль, но он не хочет утруждать пользователя запоминанием

 

идея возникла — пароль использовать который при регистрации

 

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

 

а про публичные ключи — эт он хотел пароль от зашифрованного текста перебрасывать с одного устройства на другое

 

на самом деле никакой CA тебе не нужен, потому что пользователь владеет собственными устройствами и ну публичный ключ, fingerprint проверить в состоянии

 

но опять же непонятно зачем это городить, если у тебя есть пароль для аутентификации, который сервер всё равно не хранит

 

если хочется иметь отдельный пароль для текстов — ну запороль пароли паролем и перешли через свой сервер

 

пароль от аутентификации тут будет просто как master key работать

Сделай через асинхронное шифрование как с PASS

Спойлер

YoshkinKot сказал(а):↑

чувак хочет на сервере хранить зашифрованный текст

 

поэтому ему нужен пароль, но он не хочет утруждать пользователя запоминанием

 

идея возникла — пароль использовать который при регистрации

 

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

 

а про публичные ключи — эт он хотел пароль от зашифрованного текста перебрасывать с одного устройства на другое

 

на самом деле никакой CA тебе не нужен, потому что пользователь владеет собственными устройствами и ну публичный ключ, fingerprint проверить в состоянии

 

но опять же непонятно зачем это городить, если у тебя есть пароль для аутентификации, который сервер всё равно не хранит

 

если хочется иметь отдельный пароль для текстов — ну запороль пароли паролем и перешли через свой сервер

 

пароль от аутентификации тут будет просто как master key работать

Нажмите, чтобы раскрыть...

Кароче всё, отрезаю бритвой Оккама всю лишнюю чепуху и делаю тупо на доступ к дневнику пин-код из 4 цифр. Шифрую данные хешем пин-кода.

 

Просто я думал, что пин-код из 4 цифр будет слишком легко подобрать, но по сути какая разница? Мы уже выше обсудили, что разработчик (то есть я) всё равно сможет в любой момент всё взломать, если захочет.

Lancer.Rev.X сказал(а):↑

Кароче всё, отрезаю бритвой Оккама всю лишнюю чепуху и делаю тупо на доступ к дневнику пин-код из 4 цифр. Шифрую данные хешем пин-кода.

 

Просто я думал, что пин-код из 4 цифр будет слишком легко подобрать, но по сути какая разница? Мы уже выше обсудили, что разработчик (то есть я) всё равно сможет в любой момент всё взломать, если захочет.

Нажмите, чтобы раскрыть...

да не это совсем мало

сделай просто обычный пароль да и всё

Друг, ты придумал "посолить пароль".

Никто в адеквате, никогда не хранит пароли в открытом виде, их всегда, как минимум -- солят.

https://ru.wikipedia.org/wiki/Соль_(криптография)