Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 30
На мой взгляд проще написать себе букмарклет-шифровальчик и пользоваться любым обычным сервисом заметок.
Хм, букмарклет-шифровальчик? А есть пример посмотреть? Допустим, я хочу все супер важные пароли хранить в Evernote. Как?
Примерно как здесь, но с соответствующими поправками.
Смысл в том, чтобы тот JS-функционал, который вы описываете делать букмарклетом. Пишите в evernote заметку, жмакаете на букмарклет, вводите пароль и он шифрует, например, весь выделенный текст.
а! так понятнее. спасибо :) Просто СуперГерПасс не совсем про то. Ясно.
Из спортивного интереса попробовал (нашел расширение-шифровальщик для Хрома) — ну, с точки зрения разработчика проще, ничего делать не надо. Но пользоваться увы невозможно. Для каждого куска текста выделять и пароль вводить — быстро надоест.
Вот не пойму, вы исполнителя ищете? )
Чем вас не устраивает Google docs?
docs.google.com
Заведите себе там табличку да записывайте все что угодно, не нравится табличка — заведите форму которая в табличку будет пихать данные, не нравится ни то ни другое — заведите текстовый док… все бесплатно, безопасно, продумано и т.п., зачем изобретать велосипед, тем более кривой?
docs.google.com
Заведите себе там табличку да записывайте все что угодно, не нравится табличка — заведите форму которая в табличку будет пихать данные, не нравится ни то ни другое — заведите текстовый док… все бесплатно, безопасно, продумано и т.п., зачем изобретать велосипед, тем более кривой?
Ну не хочет доверять человек свои данные никому (гуглу в том числе, да)
Почему же. Гугл Док можно использовать и как менеджер заметок, слегка «чересчур», конечно, но можно. Спасибо.
ИМХО: реально если на вещи смотреть — то свое писать и выкладывать — менее безопасно, чем доверить данные гуглдоку запароленному строго на твой аккаунт, а данные твои (пароли там, компромат на соседа, рецепты сырников =) гуглу не нужны абсолютно, ему данных и так хватает. Опять же ИМХО =)
Как избежать ситуации, когда я ввел неверный пароль, получил нечитаемую кашу в заметке, и сохранил ее обратно на сервер?
Можно хранить не хеш или иную удостоверяющую последовательность для пароля, а оную для заметки (и хранить ее также в зашифрованном виде вместе с заметкой, конечно). Или (afaik так делается в RAR) генерировать N случайных байт, считать от них хеш, и шифровать на том же пароле (т.е. делать «мини-заметку для валидации», которая пользователю не видна; сходно с первым вариантом). Или валидировать, что «полученные данные — текст в такой-то кодировке» средствами js на стороне клиента.
Пардон, не силен в криптографии, но расшифровка на клиенте с помощью введенного пароля предполагает хранение алгоритма на клиенте же. Соотв-но, злоумышленник его знает. Соотв-но, криптостойкость всей системы значительно понижается, разве нет?
Да, пожалуй! Вообще, склоняюсь потихоньку к Гугл Доку + 2факторной authentication.
ru.wikipedia.org/wiki/Принцип_Керкгоффса
Алгоритм и должен быть известен
Алгоритм и должен быть известен
Вот за это я и люблю Хабр :-) Каждый вносит что-то интересное, и в результате ты быстро получаешь сразу много всего интересного! Спасибо!
Справедливо.
Но там же еще 6 требований того же автора. И предполагаемое хранение куки на устройстве вместе с хранением алгоритма там же, как мне кажется, приводит к тому, что система не удовлетворяет уже первому требованию. А именно, в случае кражи куки(это же считается за процесс взлома, верно?) и зная алгоритм, подобрать ключ конкретного пользователя несложно. Так что мое ламерское имхо, что лучше на клиенте не хранить. Если я глубоко неправ, буду очень признателен за новую порцию знаний.
Но там же еще 6 требований того же автора. И предполагаемое хранение куки на устройстве вместе с хранением алгоритма там же, как мне кажется, приводит к тому, что система не удовлетворяет уже первому требованию. А именно, в случае кражи куки(это же считается за процесс взлома, верно?) и зная алгоритм, подобрать ключ конкретного пользователя несложно. Так что мое ламерское имхо, что лучше на клиенте не хранить. Если я глубоко неправ, буду очень признателен за новую порцию знаний.
А как тогда по-вашему расшифровывать-то, если клиент не будет знать алгоритма? Серверу полностью доверять и открытые данные? Тут тогда еще больше «точек отказа» будет.
В одной работе Шнайера определено понятие криптографической стойкости:
1. Алгоритм является криптографически стойким, если не существует каких-либо методов его вскрытия, кроме метода «грубой силы» (brute force);
2. Кроме того, размер ключа алгоритма является достаточно большим для того, чтобы метод грубой силы стал невозможным при текущем уровне развития вычислительной техники.
Если использовать хороший симметричный алгоритм, и хорошую функцию деривации ключа из пароля, то перебор будет максимально затруднен, и останется только он. Методом перебора подобрать можно практически все, и похоже, что это нормально. А как еще-то?
Здесь Вы, кажется, путаете криптографическую защиту данных заметок и аутентификацию пользователя (вследствие которой он и получает некий набор зашифрованных заметок). Это разные вещи, и для достижения некоторой степени защищенности в каждой из них применяются разные методы. Систему аутентификации пользователя и авторизации его для получения своего набора зашифрованных заметок можно совершенствовать, и это не связано с методом хранения самих заметок.
Обратимся снова к указанному Вами первому принципу.
Здесь есть «если». А некоторую степень математической невскрываемости мы обеспечим использованием правильно спроектированной системы хороших, стойких алгоритмов, разве не так?
Снова обратимся к статье; на этот раз к той ее части, где высказана, пожалуй, самая соль этого принципа:
Второй пункт говорит фактически о том же:
Если подвести итог моих дилетантских излияний, то получаем следующее: конечно можно закрыть алгоритм на сервере, но это скорее больше ухудшит безопасность, потому что тогда сервер будет знать и открытые тексты заметок. Закрытие алгоритма конечно может слегка затруднить жизнь взломщику, но полагаться только на эту черту системы нельзя. Более того, если не видно других способов, кроме закрытия системы на сервере, то как мы ее будем потом «опенсорсить», как предложил автор, опять же для повышения уровня доверия к системе?
подобрать ключ конкретного пользователя несложно
В одной работе Шнайера определено понятие криптографической стойкости:
1. Алгоритм является криптографически стойким, если не существует каких-либо методов его вскрытия, кроме метода «грубой силы» (brute force);
2. Кроме того, размер ключа алгоритма является достаточно большим для того, чтобы метод грубой силы стал невозможным при текущем уровне развития вычислительной техники.
Если использовать хороший симметричный алгоритм, и хорошую функцию деривации ключа из пароля, то перебор будет максимально затруднен, и останется только он. Методом перебора подобрать можно практически все, и похоже, что это нормально. А как еще-то?
Здесь Вы, кажется, путаете криптографическую защиту данных заметок и аутентификацию пользователя (вследствие которой он и получает некий набор зашифрованных заметок). Это разные вещи, и для достижения некоторой степени защищенности в каждой из них применяются разные методы. Систему аутентификации пользователя и авторизации его для получения своего набора зашифрованных заметок можно совершенствовать, и это не связано с методом хранения самих заметок.
Обратимся снова к указанному Вами первому принципу.
Система должна быть физически, если не математически, невскрываемой;
Здесь есть «если». А некоторую степень математической невскрываемости мы обеспечим использованием правильно спроектированной системы хороших, стойких алгоритмов, разве не так?
Снова обратимся к статье; на этот раз к той ее части, где высказана, пожалуй, самая соль этого принципа:
Принцип Керкгоффса направлен на то, чтобы сделать безопасность алгоритмов и протоколов независимой от их секретности; открытость не должна влиять на безопасность.
Второй пункт говорит фактически о том же:
Нужно, чтобы не требовалось сохранение системы в тайне; попадание системы в руки врага не должно причинять неудобств;
Если подвести итог моих дилетантских излияний, то получаем следующее: конечно можно закрыть алгоритм на сервере, но это скорее больше ухудшит безопасность, потому что тогда сервер будет знать и открытые тексты заметок. Закрытие алгоритма конечно может слегка затруднить жизнь взломщику, но полагаться только на эту черту системы нельзя. Более того, если не видно других способов, кроме закрытия системы на сервере, то как мы ее будем потом «опенсорсить», как предложил автор, опять же для повышения уровня доверия к системе?
Систем, каким-либо образом защищенных от полного перебора на локальных данных, я не встречал, если честно, и слабо себе представляю возможность существования такой системы.
И да, физическая невскрываемость клиента и сервера — тоже разные вещи. Физически вскрыв сервер, вы не получите открытых текстовых заметок. Физически вскрыв клиент — тоже. Вопрос «кому сервер отдаст зашифрованные заметки, ключ к которым потенциальный злоумышленник сможет попытаться подобрать» — это уже вопрос аутентификации и авторизации, это совсем другая часть системы, которую вполне можно усовершенствовать.
Посмотрите на zerobin :)
И да, физическая невскрываемость клиента и сервера — тоже разные вещи. Физически вскрыв сервер, вы не получите открытых текстовых заметок. Физически вскрыв клиент — тоже. Вопрос «кому сервер отдаст зашифрованные заметки, ключ к которым потенциальный злоумышленник сможет попытаться подобрать» — это уже вопрос аутентификации и авторизации, это совсем другая часть системы, которую вполне можно усовершенствовать.
Посмотрите на zerobin :)
Идея не нова. И даже смотря на новые технологии реализуемая. У нас в компании, когда бывают перерывы между проектами, мы стараемся заполнить их какой-либо интересной работой, с использованием свежих технологий, и новых подходов к процессу веб-разработки. Такую идею реализовывали месяца 3-4 назад. Сейчас проект в архиве, если будет интерес, выложим публично.
Архитектура (части системы):
— есть серверная часть, которая выступает как прокси между джаваскриптом и хранилищем записей (насколько я помню — руби, или пхп, но можно любой провайдер сделаь самому).
— есть фронтенд — это чистый twitter bootstrap, javascript, html5, css.
— есть хранилище — был использован Amazon S3.
Взаимодействие:
— в хранилище каждая запись храниться под уникальным ключём, и с зашифрованным содержанием. А также, разбитый индекс записей.
— через html5 фронтенд можно создавать записи текстовые, и даже файлы прикреплять. всё это шифруется прямо в браузере пользователя, и зашифрованным передаётся на сервер.
— шифрование делается на основе пароля, который вводит пользователь только на клиентской части.
— иногда пароль передаётся на сервер для проверки и просчёта контрольной суммы хранилища (чтобы обезопасить от перезаписи, и перебора пароля), но на сервере не сохраняется. при использовании https с подлинным сертификатом — это не должно быть проблемой.
Активация устройств — не нужна. Всё работает из браузера с поддержкой HTML5. Возможно, нужен для провайдера-прокси логгер айпишников, или привязка к айпи.
Ещё раз скажу — идея не нова. Есть хорошая приблуда 1password, она также всё разблокирует и сохраняет в зашифрованном виде, но файлы хранит локально. Если положить в папку Dropbox, будет синкать между рабочими станциями.
Архитектура (части системы):
— есть серверная часть, которая выступает как прокси между джаваскриптом и хранилищем записей (насколько я помню — руби, или пхп, но можно любой провайдер сделаь самому).
— есть фронтенд — это чистый twitter bootstrap, javascript, html5, css.
— есть хранилище — был использован Amazon S3.
Взаимодействие:
— в хранилище каждая запись храниться под уникальным ключём, и с зашифрованным содержанием. А также, разбитый индекс записей.
— через html5 фронтенд можно создавать записи текстовые, и даже файлы прикреплять. всё это шифруется прямо в браузере пользователя, и зашифрованным передаётся на сервер.
— шифрование делается на основе пароля, который вводит пользователь только на клиентской части.
— иногда пароль передаётся на сервер для проверки и просчёта контрольной суммы хранилища (чтобы обезопасить от перезаписи, и перебора пароля), но на сервере не сохраняется. при использовании https с подлинным сертификатом — это не должно быть проблемой.
Активация устройств — не нужна. Всё работает из браузера с поддержкой HTML5. Возможно, нужен для провайдера-прокси логгер айпишников, или привязка к айпи.
Ещё раз скажу — идея не нова. Есть хорошая приблуда 1password, она также всё разблокирует и сохраняет в зашифрованном виде, но файлы хранит локально. Если положить в папку Dropbox, будет синкать между рабочими станциями.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Порка идеи — удобный и безопасный веб-менеджер сокровенных текстовых заметок с javascript