Неслучайная соль для хэшей пароля
Вы уверены, что у вас установлена правильная платформа SDK?
Если нет, перейдите в Android Studio, затем Android Studio> Настройки> Внешний вид и amp; Поведение> Системные настройки> Android SDK. Выберите Android 8.1 с API Level 27 и установите его.
Надеюсь, это поможет.
8 ответов
Соль традиционно хранится как префикс к хешированному паролю. Это уже делает известным любому взломщику с доступом к хэшу пароля. Используя имя пользователя как соль или не не влияет на то знание и, поэтому, это не имело бы никакого эффекта на безопасность единой системы.
Однако использование имени пользователя или любого другого управляемого пользователями значения как соль уменьшило бы безопасность кросс-системы, как пользователь, у которого были то же имя пользователя и пароль в нескольких системах, которые используют тот же алгоритм хеширования пароля, закончил бы с тем же хэшем пароля в каждой из тех систем. Я не считаю это значительной ответственностью, потому что я, как взломщик, попробовал бы пароли, которые целевая учетная запись, как известно, использовала в других системах сначала прежде, чем делать попытку любых других средств взлома учетной записи. Идентичные хеши только сказали бы мне заранее, что известный пароль будет работать, они не сделали бы фактическое нападение немного легче. (Обратите внимание, тем не менее, что быстрое сравнение баз данных учетной записи предоставило бы список целей более высокого приоритета, так как оно скажет мне, кто и кто не снова использует пароли.)
большая опасность от этой идеи состоит в том, что имена пользователей обычно снова используются - примерно любой сайт, который Вы хотите посетить, будет иметь учетную запись пользователя по имени "Dave", например, и "администратор" или "корень" еще более распространены - который сделал бы конструкцию таблиц радуги, предназначающихся для пользователей с теми общими названиями намного легче и более эффективный.
Оба из этих дефектов могли быть эффективно обращены путем добавления значения старой соли (или зафиксированный и скрытый или выставленный как стандартная соль) к паролю прежде, чем хешировать его, но в той точке можно также просто использовать стандартную энтропическую соль во всяком случае вместо того, чтобы работать имя пользователя в него.
Отредактированный для Добавления: Много людей говорит об энтропии и важна ли энтропия в соли. Это, но не по причине большинство комментариев, это, кажется, думает.
общая мысль, кажется, что энтропия важна так, чтобы соль была трудной для взломщика предположить. Это неправильно и, на самом деле, абсолютно не важно. Как был указан несколько раз различными людьми, нападения, которые будут затронуты солью, могут только быть сделаны кем-то с базой данных пароля, и кто-то с базой данных пароля может просто надеяться видеть, какова соль каждой учетной записи. Является ли это отгадываемым или не не имеет значения, когда можно тривиально искать его.
причина, что энтропия важна, состоит в том, чтобы не кластеризироваться соленых значений. Если соль основана на имени пользователя, и Вы знаете, что большинству систем назовут учетную запись или "корень" или "администратор", то можно сделать таблицу радуги для тех двух солей, и это взломает большинство систем. Если с другой стороны, случайная 16-разрядная соль используется, и случайные значения имеют примерно даже распределение, то Вам нужна таблица радуги для всех 2^16 возможные соли.
Это не о препятствовании тому, чтобы взломщик знал, какова соль отдельной учетной записи, именно о не предоставлении им, большая цель единственной соли будет использоваться на существенной пропорции потенциальных целей.
Используя высоко-энтропийную соль абсолютно необходимо для хранения паролей надежно.
Берут мое имя пользователя 'gs' и добавляют, что оно к моему паролю 'MyPassword' дает gsMyPassword. Это легко повреждается с помощью таблицы радуги, потому что, если имя пользователя не имеет достаточной энтропии, могло бы случиться так, что это значение уже хранится в таблице радуги, особенно если имя пользователя коротко.
Другой проблемой являются нападения, где Вы знаете, что пользователь участвует в двух или больше сервисах. Существует много общих имен пользователей, вероятно, самые важные являются администратором и корнем. Если бы кто-то создал таблицу радуги, которые имеют соли с наиболее распространенными именами пользователей, то он мог использовать их для взлома учетных записей.
Они раньше имели 12-разрядную соль . 12 битов являются 4 096 различными комбинациями. Это не было достаточно безопасно, потому что так много информации может легко храниться в наше время . То же касается 4 096 наиболее используемых имен пользователей. Вероятно, что несколько Ваших пользователей будут выбирать имя пользователя, которое принадлежит наиболее распространенным именам пользователей.
я нашел этот средство проверки пароля , который разрабатывает энтропию Вашего пароля. Наличие меньшей энтропии в паролях (как при помощи имен пользователей) делает это намного легче для rainbowtables, поскольку они пытаются покрыть по крайней мере все пароли низкой энтропией, потому что они, более вероятно, произойдут.
Мне нравится использовать обоих: высоко-энтропийная случайная соль на запись, плюс уникальный идентификатор самой записи.
, Хотя это не добавляет много к безопасности против атак с подбором по словарю, и т.д., она действительно удаляет случай края, где кто-то копирует их соль и хеш к другой записи с намерением заменить пароль их собственным.
(По общему признанию трудно думать об обстоятельстве, где это применяется, но я не вижу вреда в поясах и фигурных скобках когда дело доходит до безопасности.)
Если соль является известной или легко отгадываемой, Вы не увеличили трудность атаки с подбором по словарю. Даже может быть возможно составить измененную таблицу радуги, которая принимает "постоянную" соль во внимание.
Используя уникальные соли увеличивает трудность ОБЪЕМНЫХ атак с подбором по словарю.
уникальное Наличие, криптографически сильное соленое значение было бы идеально.
Я сказал бы, что, пока соль отличается для каждого пароля, Вы, вероятно, будете в порядке. Точка соли, то, так, чтобы Вы не могли использовать стандартную таблицу радуги для решения каждого пароля в базе данных. Таким образом, если Вы применяете другую соль к каждому паролю (даже если бы это не случайно), взломщик должен был бы в основном вычислить новую таблицу радуги для каждого пароля, так как каждый пароль использует различную соль.
Используя соль с большей энтропией не помогает много, потому что у взломщика в этом случае, как предполагается, уже есть база данных. Так как необходимо смочь воссоздать хеш, необходимо уже знать, какова соль. Таким образом, необходимо сохранить соль или значения, которые составляют соль в файле так или иначе. В системах как Linux известен метод для получения соли, таким образом, там бесполезен в наличии секретной соли. Необходимо предположить, что взломщик, у которого есть значения хэш-функции, вероятно, знает соленые значения также.
Сила хеш-функции не определяется ее входом!
Используя соль, которая известна взломщику, очевидно, делает построение таблицы радуги (особенно для трудно кодированных имен пользователей как корень ) более привлекательный, но это не слабеет хеш . Используя соль, которая неизвестна взломщику, сделает систему тяжелее для нападения.
конкатенация имени пользователя и пароля могла бы все еще обеспечить запись для интеллектуальной таблицы радуги, таким образом с помощью соли ряда, псевдослучайные символы, снабженные хешированным паролем, являются, вероятно, лучшей идеей. Как иллюстрация, если у меня было имя пользователя "картофель" и пароль "пиво", связанный вход для Вашего хеша является "potatobeer", который является разумной записью для таблицы радуги.
Изменение соли каждый раз, когда пользователь изменяется, их пароль мог бы помочь победить продленные нападения, как будет осуществление разумной политики паролей, например, смешанный случай, пунктуация, продолжительность минуты, изменение после n недели.
Однако я сказал бы, что Ваш выбор алгоритма выборки сообщений более важен. Использование SHA-512 собирается оказаться большим количеством боли для кого-то генерирующего таблицу радуги, чем MD5, например.
Соль должна иметь как можно больше энтропии, чтобы гарантировать, чтобы это было должно данное входное значение быть хешированным многократно, получающееся значение хэш-функции будет, настолько близко, как может быть достигнут, всегда отличающийся.
Используя постоянно меняющиеся соленые значения с как можно большей энтропией в соли гарантирует, что вероятность хеширования (говорят, пароль + соль) произведет совершенно различные значения хэш-функции.
, Чем менее энтропийный в соли, тем более случайный Вы имеете из генерации того же соленого значения, как таким образом более случайное, которое Вы имеете генерации того же значения хэш-функции.
Это - природа значения хэш-функции, являющегося "постоянным", когда вход является известным и "постоянным", которые позволяют атакам с подбором по словарю или таблицам радуги быть настолько эффективными. Путем варьирования получающееся значение хэш-функции как можно больше (при помощи высоких энтропийных соленых значений) гарантирует, что хеширование того же input+random-salt приведет ко многим различным результатам значения хэш-функции, таким образом, побеждая (или по крайней мере значительно уменьшая эффективность) нападения таблицы радуги.
Энтропия является точкой Соленого значения.
, Если существует некоторая простая и восстанавливаемая "математика" позади соли, чем, она совпадает с солью, не там. Просто добавляющее время значение должно быть прекрасным.