Итоговая соль все равно зальется на сервер, какая разница?! Мы же говорим не о соли как таковой, а о части ключа для шифрования файла. Для расшифровки файла эта часть должна быть в неизменности передана обратно клиенту для того, чтобы клиент построил полный ключ и дешифровал файл.
Далеко не ноль, когда Доткома в наручниках поведут в турму, а у вас там 100500 пиратских фильмов или детская порнуха. Вы очень обрадуетесь возможности уничтожить приватный ключ и навсегда похоронить зашифрованные данные. Понятно, я говорю не о Вас лично, а о принципе :).
Для генерации случайных паролей нужна не «асимметричная криптография», а (сюрприз) генератор случайных чисел.
Нет, для сулчайного пароля нужен и ваш пароль тоже. Случайное число вообще не секретно, иначе вы никогда не могли бы расшифровать зашифрованный файл. Секретен в формуле key = f(password, random) только пароль.
будет настолько неудобен, что никто таким сервисом пользоваться не будет
Вот тут соглашусь полностью. Более того, уже 10 раз в этой ветке заявлял, что методы защиты выбраны ради удобства пользователей, а не степени защиты. Может мне очень хотелось появления отличного от других сервиса…
Большая часть ваших претензий не относится к дизайну криптографической системы
Разумеется. К дизайну их криптосистемы у меня тоже есть претензии, но они слишком технические, слишком теоретические и уже озвучены реальными аудиторами в Интернете. Я же везде говорил не про дизайн, а про его «маркетинговое представление».
в очередной апдейт LastPass и никакой токен от этого не спасет
Спасет. Ключ останется в безопасности, дотсупа к нему нет. Закладка может украсть расшифрованную часть данных на локальном компе, но получить ключ и украсть все мое зашифрованное облачное хранилище — не может!
В данном случае речь идет не о троянах (или вообще кейлогерах), а о стойкости самого сервиса в т.ч. и от ФБР, владельцев авторских прав и т.д. Да, вы правы, это не криптография, но я и не ругал нигде криптографию. Я подвергаю сомнению высказывания г-на Доткома «а сейчас, чуваки, мы сделаем настолько безопасную систему, что все козлы из enforcement сдохнут от злости».
зачем клиенту спрашивать у сервера какие-то случайные числа?
Это правильно делать в плане надежности ГСЧ — критического компонента key derivation. Принято считать, что генератор псевдослучайных чисел у клиента очень ненадежен (и оно так и есть). Т.к. случайное число (соль) разделяется между сервером и клиентом, лучше его генерировать на сервере из заведомо надежного источника ГСЧ.
Асимметричная криптография нужна для генерации случайных паролей для шифрования объектов без использования (т.е. компрометации) дешифровального ключа. Таким образом, дешифровальный ключ можно спрятать в банковский сейф, хранить на смарткарте/токене или вообще уничтожить. Есть еще плюс при необходимости расшаривать зашифрованные файлы, но это мы уже слишком углубимся.
Симметричная криптография легче для использования, но хуже в плане безопасности. Неважно, пользуетесь ли вы паролем, функцией от пароля или функцией от функции от пароля. Компрометация любой части приводит к раскрытию всей цепочки, всех мастер-ключей и всех зашифрованных файлов. А использование одного пароля для логина и шифрования тем более опасно, что сервис может вдруг стать нечестным. С асимметричной криптографией проблемы нечестности сервиса не стоит вообще.
Безопасность существует. Вот у меня, например, в сервисе LastPass используется Ubikey. При этом не только LastPass не знает мой приватный ключ, я и сам его не знаю, «не вытаскиваю» и следовательно, не могу скомпрометировать.
Трояны и социальные виды атак относятся к другой области.
Три производных ключа из одного — это все еще один ключ :).
Нет, я утверждал, что сервер может тупо поменять html на мега.ко.нз (или какой там адрес), а вы спокойно отдадите логин и пароль совершенно открыто, в обычном POST запросе. Коль скоро используется симметричная криптография, пароли для входа в систему и шифрования обязаны быть разными!
Я также утверждал, что в качестве случайного числа, присылаемого сервером, могут использоваться заранее фиксированные последовательности, зная которые (и имея их зашифрованными), можно зареверсить ваш пароль, т.е. скомпрометировать не сам сайт, а API.
Я не собираюсь делать аудит системы, она мне не интересна вообще. У меня было просто другое представление о том, что Дотком называет «абсолютно безопасным хранилищем». Более того, они неоднократно намекали на асиметричную крипотграфию, говорили про пары ключей, про публичный ключ, хранящийся на сервере и т.д, и т.п. А физически решение оказалось другим. Более удобным для неискушенного пользователя (можно залогиниться отовсюду), но менее безопасным. Я против использования а) симметричной криптографии на внешних сервисах, б) против использования одного пароля в качестве базы для аутентикации и шифрования.
Вы не сможете поклясться, что сейчас пароль не сохранился, не перехватился или каким-либо другим способом не покинул систему. В терминах безопасности это означает компрометацию, точка.
Нельзя использовать ключ и для аутентикации, и для шифрования одновременно, это тоже азы безопасности, Нарушение этого принципа — тоже компрометация.
Да, на стороне сервера оказывается зашифрованный файл и это случайное число. Для дешифровки файла процесс обратный: зашифрованный файл + ассоциированное с файлом (или аккаунтом) случайное число + ваш локальный пароль = открытый файл.
Хранить в куках — небезопасно, да. Можно хранить в личном хранилище или еще лучше на security token-е. В любом случае обеспечение безопасности приватного ключа, который не участвует ни в какой интеракции с сервисом, намного легче обеспечения безопасности постоянно вводимого при логине и зависящего от скрипта на серверной части пароля.
Криптосистема не может быть немножко беременной: она либо безопасна, либо скомпрометирована. На самом деле моя претензия заключалась не в методе шифрования Меги, а в том, что изначально декларировался совсем другой метод. Системы «вы нам верите, что ваш пароль безопасен» имеют полное право на существование. Более того, такиз систем — 99.999% в интернете. А Дотком обещал нечто другое, а именно: «верите вы нам или нет, захватят нас власти или нет, засудят ли копирасты — ваш пароль нам не получить», вот и все.
Касательно вопроса, конечно можно восстановить: AES — симметричный метод шифрования.
Во-первых, уже поздно. Надежные системы должны быть надежны с 1й секунды. Если вы логинились на Мегу, скажем, 30 раз, вы не можете быть уверенными в том в один раз из 30 скрипт не передал пароль в открытом виде. Факты говорят лишь о том что при регистрации и логине вы вводите свой пароль. Теоретически это — компрометация.
Во-вторых, в системе с одним паролем API тоже нельзя доверять. Сегодня система присылает случайное число, которое скрипт на стороне клиента шифрует паролем, и это используется в качестве пароля для шифрования. Однако случайное число может стать совсем не случайным, если сервис скомпрометирован. И тогда ваш пароль может попасть в руки плохих парней (или хороших полиуейских), а с ним — и все до единого пароли шифрования.
Минус в карму вам обоснован. Я вел с вами диалог совершенно спокойно и даже несколько раз терпел ваших «троллей» и нагловатый тон в виде отсылок почитать о шифровании (которым занимаюсь профессионально чуть меньше лет, чем вы живете на свете, к слову).
И честно тратил на вас свое время.
А потом вот «позеленел», как видите.
Знаете, я устал чего-то доказывать и надоедать всем этой темой. Последний раз для тех, кто хочет быть услышанным.
Пароль — это ни разу не приватный ключ. Представление private_key = f(password) — это профанация, тем более, что Мега прямо говорит(ла) про RSA пару ключей и о хранении публичного ключа на серверах.
Скрипт превращает пароль в некий ключ (еще раз прошу не путать с общепризнанным определением приватного ключа!) в сегодняшней версии Меги. Если завтра Доткому предложат отдать ваши файлы, иначе сесть на 150 лет в тюрьму, или над вебмастером будут стоять с пистолетом, или сервер арестуют, скрипт поменяют, а ваша логин-форма передаст пароль на сайт вообще плейнтекстом.
Есть колоссальная разница между «мы обещаем не хранить пароль для дешифрования» и мы «не знаем пароля для дешифрования». Дотком обещал именно второе, а я не люблю, когда безопасность подменяется маркетингом.
Второй вариант реализуется как раз парой RSA ключей, где приватный RSA ключ действительно никогда не попадает на сервис, а используется лишь для шифрования одноразовых AES паролей, которыми в свою очередь шифруются файлы. Тогда грози Меге хоть тюрьмой, хоть пистолетами, файлы останутся в безопасности. Да, клиенту надо будет хранить (и переносить между своими компьютерами) приватный ключ, но это и есть определение полностью защищенного файлового хранилища. Обещанного. И таким образом представленного. И даже якобы генерирующего с помпой вышеуказанную пару…
Хотите продолжать верить в теоретическую безопасность Меги — ради бога, ваше право.
Я зарегистрировался на одной машине, сгенерировал ключ. Потом залогинился с другой машины. С ДРУГОЙ, понимаете? Ввел логин, пароль и получил… свои файлы взад. КАК приватный ключ с куков первой машины попадает на вторую?!
Ответ: генерация ключа — фикция. Он не нужен. Или нужен для внутренних алгоритмов, неважно. Для шифрования файлов используется ТОЛЬКО ваш пароль, причем неважно какими дальнейшими преобразованиями. И этот пароль вы ПЕРЕДАЕТЕ на сайт каждый раз при логине. Ни о какой особенной секретности речи идти не может. Хранит ли Мега пароль, будет ли Дотком до смерти защищать ваш пароль — это вопросы ДОВЕРИЯ, а не криптографии. С точки зрения безопасности нового слова сказано не было, хотя Дотком его напрямую обещал.
Этот ответ не только Вам, но и всем минусующим.
Пароль не хранится на сервере
Я не знаю как хранится пароль, и вы не знаете. Совершенно очевидно одно: вы вводите пароль при логине. Что с ним потом происходит — 3й вопрос. Но теоретически перехват пароля возможен, а с ним и дешифрование данных.
RSA-ключи — это BLOB
В данном случае RSA ключи не нужны вообще. Приватный ключ, создавшийся при генерации аккаунта, очевидно не переходит на другую клиентскую машину или браузер, а доступ к файлам у пользователя с другой машины есть.
Далеко не ноль, когда Доткома в наручниках поведут в турму, а у вас там 100500 пиратских фильмов или детская порнуха. Вы очень обрадуетесь возможности уничтожить приватный ключ и навсегда похоронить зашифрованные данные. Понятно, я говорю не о Вас лично, а о принципе :).
Для генерации случайных паролей нужна не «асимметричная криптография», а (сюрприз) генератор случайных чисел.
Нет, для сулчайного пароля нужен и ваш пароль тоже. Случайное число вообще не секретно, иначе вы никогда не могли бы расшифровать зашифрованный файл. Секретен в формуле key = f(password, random) только пароль.
будет настолько неудобен, что никто таким сервисом пользоваться не будет
Вот тут соглашусь полностью. Более того, уже 10 раз в этой ветке заявлял, что методы защиты выбраны ради удобства пользователей, а не степени защиты. Может мне очень хотелось появления отличного от других сервиса…
Разумеется. К дизайну их криптосистемы у меня тоже есть претензии, но они слишком технические, слишком теоретические и уже озвучены реальными аудиторами в Интернете. Я же везде говорил не про дизайн, а про его «маркетинговое представление».
в очередной апдейт LastPass и никакой токен от этого не спасет
Спасет. Ключ останется в безопасности, дотсупа к нему нет. Закладка может украсть расшифрованную часть данных на локальном компе, но получить ключ и украсть все мое зашифрованное облачное хранилище — не может!
зачем клиенту спрашивать у сервера какие-то случайные числа?
Это правильно делать в плане надежности ГСЧ — критического компонента key derivation. Принято считать, что генератор псевдослучайных чисел у клиента очень ненадежен (и оно так и есть). Т.к. случайное число (соль) разделяется между сервером и клиентом, лучше его генерировать на сервере из заведомо надежного источника ГСЧ.
Симметричная криптография легче для использования, но хуже в плане безопасности. Неважно, пользуетесь ли вы паролем, функцией от пароля или функцией от функции от пароля. Компрометация любой части приводит к раскрытию всей цепочки, всех мастер-ключей и всех зашифрованных файлов. А использование одного пароля для логина и шифрования тем более опасно, что сервис может вдруг стать нечестным. С асимметричной криптографией проблемы нечестности сервиса не стоит вообще.
Трояны и социальные виды атак относятся к другой области.
Три производных ключа из одного — это все еще один ключ :).
Я также утверждал, что в качестве случайного числа, присылаемого сервером, могут использоваться заранее фиксированные последовательности, зная которые (и имея их зашифрованными), можно зареверсить ваш пароль, т.е. скомпрометировать не сам сайт, а API.
Нельзя использовать ключ и для аутентикации, и для шифрования одновременно, это тоже азы безопасности, Нарушение этого принципа — тоже компрометация.
Касательно вопроса, конечно можно восстановить: AES — симметричный метод шифрования.
Во-вторых, в системе с одним паролем API тоже нельзя доверять. Сегодня система присылает случайное число, которое скрипт на стороне клиента шифрует паролем, и это используется в качестве пароля для шифрования. Однако случайное число может стать совсем не случайным, если сервис скомпрометирован. И тогда ваш пароль может попасть в руки плохих парней (или хороших полиуейских), а с ним — и все до единого пароли шифрования.
И честно тратил на вас свое время.
А потом вот «позеленел», как видите.
Пароль — это ни разу не приватный ключ. Представление private_key = f(password) — это профанация, тем более, что Мега прямо говорит(ла) про RSA пару ключей и о хранении публичного ключа на серверах.
Скрипт превращает пароль в некий ключ (еще раз прошу не путать с общепризнанным определением приватного ключа!) в сегодняшней версии Меги. Если завтра Доткому предложат отдать ваши файлы, иначе сесть на 150 лет в тюрьму, или над вебмастером будут стоять с пистолетом, или сервер арестуют, скрипт поменяют, а ваша логин-форма передаст пароль на сайт вообще плейнтекстом.
Есть колоссальная разница между «мы обещаем не хранить пароль для дешифрования» и мы «не знаем пароля для дешифрования». Дотком обещал именно второе, а я не люблю, когда безопасность подменяется маркетингом.
Второй вариант реализуется как раз парой RSA ключей, где приватный RSA ключ действительно никогда не попадает на сервис, а используется лишь для шифрования одноразовых AES паролей, которыми в свою очередь шифруются файлы. Тогда грози Меге хоть тюрьмой, хоть пистолетами, файлы останутся в безопасности. Да, клиенту надо будет хранить (и переносить между своими компьютерами) приватный ключ, но это и есть определение полностью защищенного файлового хранилища. Обещанного. И таким образом представленного. И даже якобы генерирующего с помпой вышеуказанную пару…
Хотите продолжать верить в теоретическую безопасность Меги — ради бога, ваше право.
Ответ: генерация ключа — фикция. Он не нужен. Или нужен для внутренних алгоритмов, неважно. Для шифрования файлов используется ТОЛЬКО ваш пароль, причем неважно какими дальнейшими преобразованиями. И этот пароль вы ПЕРЕДАЕТЕ на сайт каждый раз при логине. Ни о какой особенной секретности речи идти не может. Хранит ли Мега пароль, будет ли Дотком до смерти защищать ваш пароль — это вопросы ДОВЕРИЯ, а не криптографии. С точки зрения безопасности нового слова сказано не было, хотя Дотком его напрямую обещал.
Этот ответ не только Вам, но и всем минусующим.
Я не знаю как хранится пароль, и вы не знаете. Совершенно очевидно одно: вы вводите пароль при логине. Что с ним потом происходит — 3й вопрос. Но теоретически перехват пароля возможен, а с ним и дешифрование данных.
RSA-ключи — это BLOB
В данном случае RSA ключи не нужны вообще. Приватный ключ, создавшийся при генерации аккаунта, очевидно не переходит на другую клиентскую машину или браузер, а доступ к файлам у пользователя с другой машины есть.