Nano Hash - криптовалюты, майнинг, программирование

Насколько безопасно хранить пароль пользователя в памяти на короткое время в виде обычного текста?

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

Это похоже на то, как вы входите на большинство крупных сайтов:

  1. Введите пароль в браузере
  2. Зашифруйте пароль в браузере с помощью открытого ключа асимметричного шифрования
  3. Отправить пароль на сайт
  4. Расшифровать пароль с помощью секретного ключа асимметричного шифрования
  5. Хеш-пароль с использованием алгоритма одностороннего хеширования (и соли)
  6. Сравните хешированный пароль с таким же хешированным паролем в базе данных
  7. Если хеши совпадают, вход выполнен успешно. В противном случае - не удалось войти.

Посмотрите между шагами 4 и 5

  1. Расшифровать пароль с помощью секретного ключа асимметричного шифрования

    4.5. Вкратце есть переменная на стороне сервера с обычным текстовым паролем

  2. Хеш-пароль с использованием алгоритма одностороннего хеширования (и соли)

Это означает, что, хотя вся схема хеширования предназначена для предотвращения доступа злоумышленника к паролям, ДАЖЕ, ЕСЛИ сервер скомпрометирован, опытный хакер все равно может добраться до него.

Я что-то пропустил? Что еще более важно, есть ли более безопасная альтернатива?

encryption passwords security hash
15.02.2015

  • Нужна дополнительная помощь? Если да, то обновлю свой ответ. 09.05.2015
  • @SilverlightFox Если вы не возражаете добавить дополнительную информацию, я определенно признателен. Моя настоящая область внимания здесь - безопасность даже на взломанной машине. 10.05.2015
  • Конечно, готово. Пожалуйста, дайте мне знать, если вам что-нибудь понадобится. 10.05.2015
  • @TheEnvironmentalist Афайк. безопасность - это предотвращение взлома сервера злоумышленниками. Если они находятся внутри, то это только вопрос времени, когда они смогут прочитать ваши пароли. Вы не можете защитить память. Все, что вы можете сделать, это правильно установить права пользователя и попытаться вовремя обнаружить злоумышленников. Обратите внимание, это только мое впечатление непрофессионала, вероятно, другие знают это лучше. 30.10.2017

Ответы:


1

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

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

Широко разрекламированная ошибка Heartbleed позволяла злоумышленникам извлекать элементы из памяти серверов фрагментами по 64 КБ. Однако стратегия здесь состоит в том, чтобы иметь возможность управлять уязвимостями (процесс исправления), а не кодировать эти типы проблем.

Что касается шифрования паролей - это то, для чего вам следует полагаться на HTTPS, а не на их шифрование на клиенте в Javascript. Когда они поступят на ваш сервер, сохраните и сравните их в хешированном формате, используя медленный алгоритм, такой как bcrypt, scrypt или pbkdf2. Также используйте файлы cookie, отмеченные флажками secure & http only, реализуйте политику HSTS, и вы должны быть готовы перейти к хранению и передаче паролей.

Рекомендации CERT относительно обработки конфиденциальных данных в памяти здесь.

Части, наиболее важные для вашего вопроса:

  • Отключить дампы памяти.
  • Не храните конфиденциальные данные по истечении времени их использования в программе.
  • Не храните конфиденциальные данные в виде открытого текста (ни на диске, ни в памяти).
  • Если вам необходимо хранить конфиденциальные данные, сначала зашифруйте их.
  • Надежно стирайте конфиденциальные данные с диска и памяти.

Это означает, что, хотя вся схема хеширования предназначена для предотвращения доступа злоумышленника к паролям, ДАЖЕ, ЕСЛИ сервер скомпрометирован, опытный хакер все равно может добраться до него.

Помните, что наличие защищенной системы не только означает, что вам нужны безопасные методы кодирования и безопасная инфраструктура. Это потому, что у вас никогда не может быть 100% безопасности. Частью головоломки, которой здесь не хватало бы, является обнаружение / предотвращение вторжений в любой форме (IDS / IPS). При этом учитывается, что в какой-то момент системы будут скомпрометированы, поэтому вместо того, чтобы пытаться предотвратить все мыслимые типы атак, вы вместо этого обнаруживаете их, позволяя предпринять соответствующие немедленные действия. Это будет касаться вас в том случае, если злоумышленнику удалось скомпрометировать вашу систему и начать сбор учетных данных по мере их поступления во время процесса входа в систему.

16.02.2015
  • Моя точка зрения - безопасность, даже если сервер был скомпрометирован. Если эти компании рассчитывают на безупречную безопасность серверов, они не станут беспокоиться о хешировании паролей. В худшем случае, когда злоумышленник имеет root-доступ к серверу, идея состоит в том, чтобы раскрыть данные, а пароли - в безопасности. Если пароли в какой-то момент хранятся в виде обычного текста, даже просто в памяти, это уже не так. 16.02.2015
  • Разница здесь в том, что если злоумышленник украдет таблицу базы данных, содержащую пароли, он получит все это одним махом. Если вы правильно посолили и хешировали, то это не большая проблема, так как есть время, чтобы пользователи сменили пароли. Однако в вашей ситуации, когда ваш сервер был скомпрометирован, злоумышленник может получить каждый пароль только во время использования. Они могли бы сделать это довольно легко, добавив некоторый код в верхнюю часть обработчика входа в систему, чем отправив им имя пользователя и пароль. В конечном итоге для них это намного медленнее. 16.02.2015
  • Они создают шум, и они должны быть активны в вашей системе, чтобы продолжить атаку. В обеих ситуациях вы должны полагаться на обнаружение и мониторинг, чтобы локализовать нарушение. Если у вас есть конфиденциальная информация в вашей системе, вам нужна IDS, чтобы вы знали, что ваша система была взломана и этот код был добавлен для извлечения паролей. Имея хороший мониторинг и кто-то, кто будет реагировать на атаку, вы можете предотвратить успех метода злоумышленника и отключить его. Таким образом, хранение паролей в памяти во время их обработки не несет такого же риска, как небезопасное хранение. 16.02.2015
  • Хорошо сказано. Напоследок, что вы думаете о Идея Майка о хэшировании пароля на стороне клиента, а затем хешировании на стороне сервера с помощью чего-то более сильного, например bcrypt? 16.02.2015
  • Все зависит от того, стоит ли оно того для вашей системы. Итак, ваша конечная цель - защитить пароли пользователей, если они использовали тот же пароль в других системах, даже если ваша система была взломана? Добавление кода увеличивает сложность. Сложность снижает безопасность. Если вы хэшируете клиентскую сторону, вам нужно будет добавить соль - поскольку вы не знаете, какой пользователь входит в систему, это должна быть общесистемная соль (известная как перец). Зная об этом, злоумышленник может предварительно вычислить радужные таблицы для вашего алгоритма хеширования. 16.02.2015
  • Поэтому, если они взламывают вашу систему, они просто пропускают хешированный пароль на стороне клиента через свою радужную таблицу - и тогда у них есть пароль. Фактически, все пароли для пользователей, которые входят в систему во время атаки. Таким образом, большая сложность и код добавлены в вашу собственную систему с небольшой выгодой - это просто немного усложняет злоумышленнику задачу получить пароль от вашей системы, который может работать в другой системе, в которую входит пользователь. . 16.02.2015
  • Некоторые из ваших новых замечаний здесь, кажется, противоречат поведению в вопросе. Предполагая, что работа с данными как программными переменными квалифицируется как сохранение в памяти (где, конечно, хранятся переменные), Не храните конфиденциальные данные в виде открытого текста (ни на диске, ни в памяти) и Если вы должны хранить конфиденциальные данные, сначала зашифровать их, это означает, что процесс, описанный в вопросе, небезопасен на взломанной машине. Основная цель состоит в том, чтобы помешать злоумышленнику пассивно (без изменения кода, что было бы заметно) получить доступ к паролям. Не могли бы вы уточнить? 11.05.2015
  • @the я бы сказал, что хранение будет определяться как постоянное хранение - например, в сеансе. Использование - это не то же самое, что сохранение, однако вы все равно можете безопасно стереть переменные. 11.05.2015
  • Первоначальный вопрос был предназначен для решения вопросов безопасности с точки зрения злоумышленника, которая, как правило, является лучшей точкой зрения для выявления атак. Если бы я хотел собирать пароли из службы, которая реализует современные передовые методы безопасности, я мог бы собирать их либо с клиента, либо с сервера. Атака на огромное количество клиентских машин непрактична, и при нашем предположении о правильно реализованной безопасности база данных на стороне сервера будет содержать только соленые хэши. Единственный шаг в процессе, на котором пароли будут доступны на сервере в виде обычного текста, - это ... 11.05.2015
  • ... между расшифровкой зашифрованного пароля, отправленного клиентом, и хешированием и обработкой для сравнения с соленым хешем, хранящимся в базе данных на стороне сервера. В этот момент (шаг 4.5 в исходном вопросе, если хотите) пароль будет сохранен в памяти. Хотя синтаксический анализ памяти довольно сложен, это была бы лучшая атака, если предположить, что в современной архитектуре безопасности нет атакуемой части (нет математических бэкдоров, нет серверов, отправляющих фрагменты данных пульса и т. Д.). Затем я мог бы запустить в фоновом режиме процесс, который читает из памяти, что я пытаюсь предотвратить. 11.05.2015
  • @the: Я понимаю проблему - я все еще поддерживаю решение этой проблемы - протестировать вашу систему на проникновение и реализовать обнаружение вторжений, чтобы вы знали, если безопасность нарушена. Если риск, который вы пытаетесь контролировать, связан с паролями ваших пользователей, которые могли использоваться на других сайтах, то хеширование на клиенте предотвратит то, что пароль будет известен на стороне сервера. Вам все равно потребуется, чтобы клиент знал соль после имени пользователя известно, чтобы правильно хешировать для этого пользователя. Вам необходимо вернуть согласованное хеш-значение для несуществующих пользователей, иначе вы уязвимы для ... 11.05.2015
  • @the: перечисление пользователей - поэтому, если кто-то пытался войти в систему с несуществующим пользователем, вам нужно вернуть одна и та же соль каждый раз, иначе злоумышленник узнает, что их не существует. Поскольку злоумышленник может получить эту соль, он сможет заранее создать радужные таблицы для каждого пользователя. Затем ваш настойчивый злоумышленник сможет сравнить хэш, отправленный в вашу систему, со своими таблицами, чтобы таким образом получить пароль. Также обратите внимание, что если злоумышленник может читать память, он должен каким-то образом контролировать вашу машину. Они могли просто изменить код, обслуживаемый каждым 11.05.2015
  • @the: client и измените JavaScript, который хеширует, на JavaScript, который просто отправляет простой текст. Таким образом, вы увеличили сложность, но атакующий только что изменил тактику и сумел мгновенно обойти вашу защиту. Я думаю, что злоумышленник, который может только читать память, является мнимой угрозой - злоумышленник, который зашел так далеко, сделает все возможное, чтобы разрушить любую установленную вами защиту от хеширования. Ваш подход может сработать - и в этом случае - продолжайте, - но вам нужно просто защитить пользователей, которые повторно используют пароли. Даже Google ошибаются ... 11.05.2015
  • @the: попытка повысить безопасность путем добавления кода. 11.05.2015

    • 2

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

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

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

    15.02.2015

    3

    Это похоже на то, как вы входите на большинство крупных сайтов

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

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

    15.02.2015
  • Просто имейте в виду, что когда вы хешируете пароль на клиенте, хеш фактически становится паролем. Я понимаю это. Моей первой мыслью было хеширование хеша, второй мыслью было то, есть ли в этом какие-либо недостатки безопасности ... Как только вы начинаете играть в «что, если злоумышленник получает контроль над сервером, как вы обеспечиваете безопасность, тогда« игра, вы » лучше отложить в сторону бутылку аспирина. 16.02.2015
  • Я думаю, вы должны сначала подумать о том, что вы на самом деле пытаетесь предотвратить. Если вы пытаетесь помешать хакеру, который каким-то образом скомпрометировал сервер, получить доступ к чьей-то учетной записи, ну ... у вас уже есть более серьезные проблемы, о которых нужно беспокоиться, и если ваш сервер скомпрометирован, у них уже есть доступ к любым учетным записям, которые они хотят . В этом случае все равно отправьте пароль в виде обычного текста. Единственная полезная вещь, о которой я могу думать для хеширования на стороне клиента, - это запретить пользователям использовать один и тот же пароль в нескольких местах, поэтому, если ваш сервер был скомпрометирован, это 16.02.2015
  • не будет утечка паролей банков / PayPal / ebay / facebook ваших пользователей, поскольку большинство людей везде используют один и тот же пароль. Конечно, вы не сможете использовать соль для каждого пользователя, потому что пользователь также должен будет предоставить эту соль с хешем, о котором они не будут знать. Таким образом, ваша система по-прежнему будет уязвима для радужных таблиц. 16.02.2015
  • Мой совет - как можно сильнее усилить сервер. Отключите все ненужные службы, отключите telnet и ftp, включите SSH с аутентификацией с открытым ключом, не разрешайте вход в систему через небезопасное соединение по любому протоколу (даже HTTP), сохраните пароли с безопасным хешем (например, bcrypt), и все будет в порядке . Вы также можете изучить двухфакторную аутентификацию для своего приложения. Настроить что-то вроде Google Authenticator относительно просто. Это должно значительно повысить безопасность вашего веб-приложения. 16.02.2015
    • Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..