Есть ли причина, по которой я не должен использовать SHA1 соли + имя сайта + мастер-пароль для моего пароля на веб-сайтах?


2

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

  0

Crazy steve снова. 10 авг. 132013-08-10 02:47:22

  0

Да, не делайте этого. Не только пустая трата времени, но и не поможет, когда у вас нет доступа к программе. 10 авг. 132013-08-10 03:12:01

  0

Ну, дело в том, что я смогу запомнить это и реализовать его легко, если я потерял программу. 10 авг. 132013-08-10 09:27:15

7

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

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

  0

Я думаю: «Я не знаю, но использую чью-то программу» - это не ответ. 10 авг. 132013-08-10 09:25:49

+1

@ user29349 О нет, я прекрасно понимаю причину. Если вы сами напишете его для фактического использования, вы ** будете делать что-то неправильно. Это небезопасно и пустая трата времени. Честно говоря, другие дали лучшие ответы, когда речь заходит о более глубоких объяснениях.Я больше заинтересован в предоставлении вам и будущим посетителям этого вопроса лучшего решения рядом с быстрым объяснением. 10 авг. 132013-08-10 10:41:06


3

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

Непонятно, как «соль» подходит в этом случае - если она случайна, откуда вы знаете, какую соль использовать для определенного сайта? Если это не так (то есть это фиксированный секрет), то как он отличается от основного пароля в природе?

Если у вас есть случайная соль, и вы храните ее на генераторном устройстве, вы также можете произвольно генерировать весь пароль и хранить его на устройстве (например, Keepass et al). Практически это имеет то преимущество, что у вас есть запись обо всех именах сайтов, на которые у вас есть ключи. Без этого становится трудно вспомнить, что такое каноническое имя для сайта. Например, вы собираетесь ссылаться на этот сайт как «Exchange Security Stack Exchange», «Security StackExchange», «Безопасность», «security.stackexchange.com», «www.security.stackexchange.com» или «user29349.openidprovider .com»...?

  0

Это правда, что планшет не имеет никакого отличия в природе от главного пароля. На каноническом имени я намерен использовать первый уровень над расширением TLD +. Я думаю, что вероятность того, что веб-мастер осознает, что я использую это, является достаточно низким, чтобы сделать это жизнеспособным. 10 авг. 132013-08-10 10:08:32

  0

В любом случае, я хотел использовать это на сайтах с ограничениями «никаких специальных символов». 10 авг. 132013-08-10 10:09:05


4

Есть несколько веских причин, чтобы не сделать это:

  • Один SHA-1 экземпляр слишком быстро; при получении вещей из паролей, которые вы хотите применить правильно password hashing. Соль - это хорошо, но это лишь часть уравнения.

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

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

  0

Вы предлагаете веб-мастеру, глядя на мой хешированный пароль в его базе данных, изменит хэш, а затем изменит мой хеш? Возможно ли это в разумные сроки? Я бы предпочел объяснения, а не этот поток «избегайте криптования, если это вообще возможно», который пытается ослабить вопрос. 10 авг. 132013-08-10 10:17:54

  0

@ user29349 Обратите внимание, что никто не говорит вам избегать криптографии, мы говорим вам избегать импровизации криптографии. Мы совсем не снисходительны, я уверен, что даже Том Лик (Томас Порнин, Google он), который является нашим экспертом №1 по криптовым вопросам, напишет свой собственный криптографический и пользовательский интерфейс в производственной среде. Как вы можете видеть, он дал вам очень веские причины не делать этого, с точки зрения безопасности и удобства использования. 10 авг. 132013-08-10 10:36:17

  0

Я не считаю, что «сайты, которые я намереваюсь использовать только для краткосрочных», являются производственной средой. Я задал этот вопрос из личных интересов, и все больше и больше я забочусь о том, почему. 10 авг. 132013-08-10 11:40:02

  0

@ user29349 - Я не совсем уверен, что правильно понял ваш вопрос, но имейте в виду, что сегодня (2013) можно рассчитать о [3 Giga SHA1 хешах в секунду] (http://hashcat.net/oclhashcat-lite/#) с общим оборудованием. Это оставляет много места для грубой силы. 10 авг. 132013-08-10 13:33:50

  0

Я вхожу в поле «пароль» данного сайта строку, созданную из моего существующего пароля + название веб-сайта. 10 авг. 132013-08-10 14:07:50

  0

Извинения за то, что я не читал все ваши «как безопасно хэш-пароли» раньше, я думал, что это было короче, чем было, я очень ценю эту информацию. 10 авг. 132013-08-10 16:16:47