Миф про 3 минуты памяти у золотой рыбки был опровергнут. В начале этого года ученые из Израиля представили доказательства того, что рыбка может вспомнить события 4-5 месячной давности.
Хорошо, золотая рыбка, раз уж такое через 4 часа, то 10 лет комы даже мастер-пароль не переживет, и правда. Напоминаю, ваш посыл был:
Не понимаю, для чего люди пытаются изобрести велосипед или вообще все удержать в голове.
Доводы и аргументы именно к этой фразе я написал выше, объяснив практически "на пальцах" бессмысленность всяких "кипасов" по всем пунктам кроме юзабилити, и плюсы предложенного автором темы решения.
Все случаи про "спецслужбы", "доступ к хранилищу", "ограбление" — это куда больший риск, чем утеря базы. Но вне этих случаев всякие "кипасы" не имеют смысла. Вы забыли упомянуть про терморектальный взлом базы, сделаю это за вас и тут же отвечу: это тоже форс-мажор, к которому всякие "кипасы" снова не имеют отношения.
В сухом остатке имеем: зашифрованную базу, которую можно украсть, и алгоритм+ключ, который даже украсть нельзя. При всех равных рисках, связанных с терморектальным брутфорсом всякие "кипасы" выигрывают только в юзабилити, где термин "юзабилити" рядом с ИБ даже не пробегал.
Если же вы имели ввиду получение удаленного доступа к моей сети, то тоже непонятно, к чему это было сказано, к теме это не относится и я вполне в состоянии этого не допустить.
В чем тогда смысл шифровать базу?
Если вы считаете, что доступа до хранилища никто получить не сможет, можно не бояться за базу с паролями.
В противном случае риски гораздо выше, чем утечка паролей, в них входит заражение вашей системы, прослушка, кейлоггинг и проч.
То, о чем вы говорите, имеет смысл лишь в корпоративных сетях, где сетевой доступ между системными администраторами допустим, а пассшеринг — нет.
Пароли нужно хранить так, чтобы даже после комы в 10 лет, когда всю вашу технику и недвижимость отдали в счет оплаты кредитов на лечение и поддержание жизни — вы все равно смогли легко восстановить любой доступ.
Метод, предложенный автором поста, позволяет. А всякие "кипасы" — нет.
Утечка базы не является проблемой, при использовании сильного мастер-пароля.
Уважаемый, уже ночь, глазки слипаются, все понимаю. Я говорил о том, что вариант "базу слили" даже не рассматривается, потому что это значит, что у вас слили не только базу, но и весь жесткий диск, а может, даже подложили чего "в нагрузку" обратно. В этом случае вот вообще не имеет никакой разницы "сильность" вашего мастер-пароля.
Перечитайте комментарий еще раз) Вот очнулись вы в ванне со льдом и без почки. Пароль от облака с базой с паролями у вас тоже в базе с паролями в облаке?
Тут мы приходим к исключениям. Исключения порождают дыры в безопасности, а облака порождают историю версий базы, что порождает кучу интересных векторов атак.
Я говорю о том, чего у всяких "кипасов" нет — независимой восстанавливаемости.
И да, восстановление пароля от облака по SMS/E-mail тоже сводит на ноль всякую пользу от "кипасов", особенно учитывая низкую защиту первого мобильного фактора.
Брутфорс базы кипаса?
Брутфорс пароля к веб-ресурсу?
Во-первых, этой трухой уже лет 10 не занимаются даже "киддисы": "никто" не расшифровывает базы, не брутфорсит ресурсы и пр. Только если вы не селебрити какой-нибудь, взлом учетки которого окупит затраченные средства.
Во-вторых, если у вас сперли базу, значит, у кого-то есть доступ до вашего носителя данных. С этого момента проблема утечки базы — ничтожна по сравнению с новым открытием.
На защищенность пароля влияет только его непохожесть между ресурсами. Сумма вероятностей взлома каждого из ресурсов, которыми вы пользуетесь, вполне себе большое число, и хотя бы один из них обязательно взломают. Достаточным будет использовать различающиеся пароли между ними — это достигается как в случае со всякими "кипасами", так и решением, которое предлагает автор темы.
Только вот восстанавливаемость пароля у метода, предложенного в посте, выше, чем у кипаса — удалите свою базу, и все. А в случае формулы "ресурс + логин + фраза + хеш-функция" любой пароль может быть вами восстановлен, даже если вы очнулись без своего кипаса в ванне со льдом, без почки и без телефона.
В пользу "кипасов" работает только юзабилити. И да, ее для обывателей более чем достаточно. Все встроенное шифрование — сюр для защиты совести.
Пока коллеги по форуму выше меряются своими кипасами и не умеют Шнайера, спешу выразить поддержку.
Я еще нигде не видел идеи использовать "чисто техническое" раскрытие короткой, легко запоминаемой фразы в множество стойких к подбору паролей в форме, удобной для "человеческого" использования.
И пусть народ с пароль-генераторами считает себя лучше всех, но после потери хранилища, кражи ноутбука в багаже при перелете или еще какой напасти — формула "ресурс + логин + запоминаемая фраза + хеш-функция" выглядит куда надежнее, потому что последние два компонента восстановимы строго автором, и подбору не подлежат, а результат достаточно стойкий и не имеет необходимости быть где-либо сохраненным, чтобы не волноваться за него.
Они постоянно с API косячат. Если верить комментариям к их же постам, начиная с поиска аналитиков данных, косяки со скриптами, раскрывающими уязвимости почти в каждом проекте.
Налогоплательщик много за что не готов платить, в т.ч. за работу некоторых гос.аппаратов, но разрешают не платить только за электронный дневник независимого разработчика.
Заключение договора с паспортными данными пользователя API под его ответственность за то, что он размещает в приложении — не? Кажется, кого-то покусал РКН.
По инициативе города = Собянина? Солонина? Пархоменко? Путина? Какого города?
Кто поименно на каком собрании и резолюцией в виде какого документа эту самую инициативу "родил" ?
Что ж, повторю свой комментарий из поста Яндекса про его "шифрование" referrer во славу безопасности пользовательских данных (нет).
Если в посте яндекса на хабре нет развернутой технической части — это 100% маркетинговое дерьмо :)
Причем, нет никакой разницы: про погоду это или про то, как они для защиты своих пользователей referrer-ы начали шифровать.
В каждом абзаце реклама функций ябраузера. Тезис ничем не подкреплен, информации о том, через что заливают код на госуслуги, нет. Кому принадлежат найденные домены — тоже не расследовали.
15 из 16 уже фильтруются, но внимание (!) "авторы кода вряд ли предполагали, что получат доступ к пользователям портала государственных услуг". То есть iframe все-таки дружественный?
Серьезная компания, технологичная. А пользователей хабра считаете за аудиторию Московского Комсомольца.
Это хороший пример, который показывает, что для сложной и действительно удобной для пользователя (а мы работаем на удовольствие наших пользователей), связка pattern+CSS является так себе средством.
А когда мы учтем все необходимые требования к каждому полю, а также (sic!) зависимости между полями, pattern будет неподъемным для понимания по сравнению с парой удобных функций JS.
Видел, и не раз :)
А в соседнем бложике от PVS-Studio еще и примеры из реальных проектов есть.
Код-ревью делают такие же люди — это самый веский довод в пользу того, чтобы делать fail-proof design, а не надеяться на то, что ревьювер будет в здравом уме в каждый конкретный момент проверки.
По части "рыхлости" — первая скобка на той же строке, а закрывающая — на новой. Перед ревью код должен быть автоматически отформатирован, чтобы отступы полностью соответствовали вложенности.
А если ревью нет, то все описанное выше все равно сработает, чего не скажешь о случае, когда нет общего согласия на использование скобок в коде.
Есть подозрение, что здесь не ошибка, а поиск конца списка. Очевидно, что для большей прозрачности и защиты от случайных ошибок нужно было бы применить while вместо вырожденного варианта for.
Прошу прощения.
Хорошо, золотая рыбка, раз уж такое через 4 часа, то 10 лет комы даже мастер-пароль не переживет, и правда. Напоминаю, ваш посыл был:
Доводы и аргументы именно к этой фразе я написал выше, объяснив практически "на пальцах" бессмысленность всяких "кипасов" по всем пунктам кроме юзабилити, и плюсы предложенного автором темы решения.
Все случаи про "спецслужбы", "доступ к хранилищу", "ограбление" — это куда больший риск, чем утеря базы. Но вне этих случаев всякие "кипасы" не имеют смысла. Вы забыли упомянуть про терморектальный взлом базы, сделаю это за вас и тут же отвечу: это тоже форс-мажор, к которому всякие "кипасы" снова не имеют отношения.
В сухом остатке имеем: зашифрованную базу, которую можно украсть, и алгоритм+ключ, который даже украсть нельзя. При всех равных рисках, связанных с терморектальным брутфорсом всякие "кипасы" выигрывают только в юзабилити, где термин "юзабилити" рядом с ИБ даже не пробегал.
В чем тогда смысл шифровать базу?
Если вы считаете, что доступа до хранилища никто получить не сможет, можно не бояться за базу с паролями.
В противном случае риски гораздо выше, чем утечка паролей, в них входит заражение вашей системы, прослушка, кейлоггинг и проч.
То, о чем вы говорите, имеет смысл лишь в корпоративных сетях, где сетевой доступ между системными администраторами допустим, а пассшеринг — нет.
В домашней экосистеме — сюр для защиты совести.
Пароли нужно хранить так, чтобы даже после комы в 10 лет, когда всю вашу технику и недвижимость отдали в счет оплаты кредитов на лечение и поддержание жизни — вы все равно смогли легко восстановить любой доступ.
Метод, предложенный автором поста, позволяет. А всякие "кипасы" — нет.
Уважаемый, уже ночь, глазки слипаются, все понимаю. Я говорил о том, что вариант "базу слили" даже не рассматривается, потому что это значит, что у вас слили не только базу, но и весь жесткий диск, а может, даже подложили чего "в нагрузку" обратно. В этом случае вот вообще не имеет никакой разницы "сильность" вашего мастер-пароля.
Перечитайте комментарий еще раз) Вот очнулись вы в ванне со льдом и без почки. Пароль от облака с базой с паролями у вас тоже в базе с паролями в облаке?
Тут мы приходим к исключениям. Исключения порождают дыры в безопасности, а облака порождают историю версий базы, что порождает кучу интересных векторов атак.
Я говорю о том, чего у всяких "кипасов" нет — независимой восстанавливаемости.
И да, восстановление пароля от облака по SMS/E-mail тоже сводит на ноль всякую пользу от "кипасов", особенно учитывая низкую защиту первого мобильного фактора.
Брутфорс базы кипаса?
Брутфорс пароля к веб-ресурсу?
Во-первых, этой трухой уже лет 10 не занимаются даже "киддисы": "никто" не расшифровывает базы, не брутфорсит ресурсы и пр. Только если вы не селебрити какой-нибудь, взлом учетки которого окупит затраченные средства.
Во-вторых, если у вас сперли базу, значит, у кого-то есть доступ до вашего носителя данных. С этого момента проблема утечки базы — ничтожна по сравнению с новым открытием.
На защищенность пароля влияет только его непохожесть между ресурсами. Сумма вероятностей взлома каждого из ресурсов, которыми вы пользуетесь, вполне себе большое число, и хотя бы один из них обязательно взломают. Достаточным будет использовать различающиеся пароли между ними — это достигается как в случае со всякими "кипасами", так и решением, которое предлагает автор темы.
Только вот восстанавливаемость пароля у метода, предложенного в посте, выше, чем у кипаса — удалите свою базу, и все. А в случае формулы "ресурс + логин + фраза + хеш-функция" любой пароль может быть вами восстановлен, даже если вы очнулись без своего кипаса в ванне со льдом, без почки и без телефона.
В пользу "кипасов" работает только юзабилити. И да, ее для обывателей более чем достаточно. Все встроенное шифрование — сюр для защиты совести.
Пока коллеги по форуму выше меряются своими кипасами и не умеют Шнайера, спешу выразить поддержку.
Я еще нигде не видел идеи использовать "чисто техническое" раскрытие короткой, легко запоминаемой фразы в множество стойких к подбору паролей в форме, удобной для "человеческого" использования.
И пусть народ с пароль-генераторами считает себя лучше всех, но после потери хранилища, кражи ноутбука в багаже при перелете или еще какой напасти — формула "ресурс + логин + запоминаемая фраза + хеш-функция" выглядит куда надежнее, потому что последние два компонента восстановимы строго автором, и подбору не подлежат, а результат достаточно стойкий и не имеет необходимости быть где-либо сохраненным, чтобы не волноваться за него.
Они постоянно с API косячат. Если верить комментариям к их же постам, начиная с поиска аналитиков данных, косяки со скриптами, раскрывающими уязвимости почти в каждом проекте.
Налогоплательщик много за что не готов платить, в т.ч. за работу некоторых гос.аппаратов, но разрешают не платить только за электронный дневник независимого разработчика.
Заключение договора с паспортными данными пользователя API под его ответственность за то, что он размещает в приложении — не? Кажется, кого-то покусал РКН.
По инициативе города = Собянина? Солонина? Пархоменко? Путина? Какого города?
Кто поименно на каком собрании и резолюцией в виде какого документа эту самую инициативу "родил" ?
Что ж, повторю свой комментарий из поста Яндекса про его "шифрование" referrer во славу безопасности пользовательских данных (нет).
В каждом абзаце реклама функций ябраузера. Тезис ничем не подкреплен, информации о том, через что заливают код на госуслуги, нет. Кому принадлежат найденные домены — тоже не расследовали.
15 из 16 уже фильтруются, но внимание (!) "авторы кода вряд ли предполагали, что получат доступ к пользователям портала государственных услуг". То есть iframe все-таки дружественный?
Серьезная компания, технологичная. А пользователей хабра считаете за аудиторию Московского Комсомольца.
Можно, конечно, назвать это придиркой, но все же:
Это хороший пример, который показывает, что для сложной и действительно удобной для пользователя (а мы работаем на удовольствие наших пользователей), связка pattern+CSS является так себе средством.
А когда мы учтем все необходимые требования к каждому полю, а также (sic!) зависимости между полями, pattern будет неподъемным для понимания по сравнению с парой удобных функций JS.
Управление мышью как в Agar.io на Phaser.js
[конец]
а ваша защита обнаружила и поймала WannaCry до сообщений о нем или только 4 дня назад?
Видел, и не раз :)
А в соседнем бложике от PVS-Studio еще и примеры из реальных проектов есть.
Код-ревью делают такие же люди — это самый веский довод в пользу того, чтобы делать fail-proof design, а не надеяться на то, что ревьювер будет в здравом уме в каждый конкретный момент проверки.
По части "рыхлости" — первая скобка на той же строке, а закрывающая — на новой. Перед ревью код должен быть автоматически отформатирован, чтобы отступы полностью соответствовали вложенности.
А если ревью нет, то все описанное выше все равно сработает, чего не скажешь о случае, когда нет общего согласия на использование скобок в коде.
Есть подозрение, что здесь не ошибка, а поиск конца списка. Очевидно, что для большей прозрачности и защиты от случайных ошибок нужно было бы применить while вместо вырожденного варианта for.
Угадаю автора сообщения с одного кек
Одновременная работа двух версий приложений с разной структурой БД?
Лол, я 3 года назад сделал zen-SQL, чтобы избавиться от этих всех сраных стрелочек и скобочек)
https://gist.github.com/mrXCray/3bf126a6087e11cdf062