Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 154
Вчера пробовал, но так и не получилось залить туда. Либо ничего не происходит, либо на 10-20 % вешается. Chrome использовал
Я вчера и сегодня заливаю — все отлично. Несколько файлов по 5-7 метров. Использую Хром
попробовал заливать файлы размером около гига — уходят на отлично. Скорость 3 — 5м/c. Скорее всего упирается в скорость моего провайдера или вайфай. Использовал фаерфокс.
Поражает конечно как они подготовились. 50gb, на каждого пользователя. Это некислая такая инфраструктура. Большинство зареганых конечно и на 10% не используют это место, но все равно они отожгли.
А кто-то знает они используют свою инфраструктуру (железки) или используют чьи то?
Поражает конечно как они подготовились. 50gb, на каждого пользователя. Это некислая такая инфраструктура. Большинство зареганых конечно и на 10% не используют это место, но все равно они отожгли.
А кто-то знает они используют свою инфраструктуру (железки) или используют чьи то?
Залил 10 гигов без проблем. Скорость конечно не ахти но проблем не возникло.
DropBox и Rapidshare не сильно обидятся — сервисы выполняют разные задачи (по крайней мере сейчас).
Тем неменее, в западной прессе «Мегу» часто сравнивают именно с Дропбоксом и подобными облачными хранилищами.
Разве у Меги есть нативные клиенты для синхронизации?
Yandex.Disk — 10Gb
box.com (got in old times) — 50Gb
COMODO Cloud — 5Gb
Yandex.Disk — 258Gb, после некоторых манипуляций :)
Что за манипуляции для получения 258 Гиг?
При покупке ультрабука компании Samsung. Только вот теперь осталось придумать зачем же мне все эти гигайбайты :)
Или 31Гб у Яндекс Диска для тех, кто там оказался по приглашению (+1Гб), выполнил ряд стандартных инструкций по увеличению объема (+10Гб), наприглашал знакомых (+10Гб) и приобрел подписку Яндекс Музыки для iPhone в декабре минувшего года (+10Гб). То ли еще будет (не сочтите за рекламу).
Раз такая пьянка: habrastorage.org/storage2/b7b/515/65b/b7b51565bdfd6738a0e863ad45ca9e81.png
Правда из них 48Гб кончатся через два года, но тем не менее 29.85Гб останется.
Правда из них 48Гб кончатся через два года, но тем не менее 29.85Гб останется.
А вообще, для предложений больше 10Гб, большую роль уже играют скорости.
Меряться так меряться
help.yandex.ru/disk/desktop/add-250.xml
Я правильно Вас понял? Как же тогда каждому сделать себе такой?
Я правильно Вас понял? Как же тогда каждому сделать себе такой?
шах и мат :)
То, что пишут в прессе, называется «пиар», а попроще говоря, трындёж.
И лимит скорости на загрузку. Неявный способ ограничить размер.
Бесплатно — 10 ГБ. В сад!
Starting in early 2013, Bitcasa will remain free up to 10 GB, or $10/month for infinite storage.
Starting in early 2013, Bitcasa will remain free up to 10 GB, or $10/month for infinite storage.
А что из этого поддерживает заливку файлов без клиента, через SSH / SFTP или другим стандартным *nix способом?
Я тоже об этом подумал. Сайтом Дропбокса вообще пользуется лишь некая часть их пользователей: остальные пользуются нативными клиентами. А вот то, что Мега обогнала Рапидшаре, это конечно чтото значит.
Скорость заливки колеблется, вчера даже загрузить ничего не получалось.
Старался не поддаться истерии и не регистрироваться там без дела, но вы меня таки вынудили :) Визуально красиво, удобно и понятно — осталось их в деле проверить через месяцок, когда ажиотаж спадет.
Folder Upload вижу, а где-же Folder Download?
двойной клик по файлу или используя контекстное меню на файле.
А я параноик, поэтому у меня флеш и java отключены в основном браузере. К тому же он еще и запускается от бесправного пользователя.
Используя другой получаю «Your browser requires the latest version of Flash to transfer files on MEGA.». Интересно чего они там такого накрутили, что залить файл можно, а скачать без самого последнего флеша или хрома нельзя.
А я параноик, поэтому у меня флеш и java отключены в основном браузере. К тому же он еще и запускается от бесправного пользователя.
Используя другой получаю «Your browser requires the latest version of Flash to transfer files on MEGA.». Интересно чего они там такого накрутили, что залить файл можно, а скачать без самого последнего флеша или хрома нельзя.
дали ответы на большинство вопросов по безопасности
Ответы-ответами, но основная претензия остается: Мега ввела (или до сих пор вводит, не проверял) в заблуждение пользователей, утверждая про использование пары RSA ключей в сервисе, где личный ключ никогда не покидает клиентскую часть. И даже красиво так писала при регистрации: «Генерирую ключи, использую энтропию от мышки и т.д. и т.п.». В сущности, никакого нового безопасного способа сервисом не предложено.
Ответы-ответами, но основная претензия остается: Мега ввела (или до сих пор вводит, не проверял) в заблуждение пользователей, утверждая про использование пары RSA ключей в сервисе, где личный ключ никогда не покидает клиентскую часть. И даже красиво так писала при регистрации: «Генерирую ключи, использую энтропию от мышки и т.д. и т.п.». В сущности, никакого нового безопасного способа сервисом не предложено.
Это противоречит их декларации, я цитирую: «The client machines are responsible for generating, exchanging and managing the encryption keys. No usable encryption keys ever leave the client computers (with the exception of RSA public keys)», и заявлениям лично Доткома, что Мега использует исключительно безопасный способ шифрования, не держа ключа для шифрования (приватного RSA ключа) вообще. Посмотрите одну из предыдущих тем, там уже была дискуссия.
Если пароль хранится на сервисе, ничего нового и безопасного сервис не предоставляет. Данные могут быть скомпрометированы извлечением ключа по очередному нажиму властей или по ошибке (как уже однажды случалось на Дропбоксе). Не биг дил, но люди должны об этом знать, особенно, если маркетингом утверждалось особенное внимание шифрованию и новизна в полной отвязке ключей.
Если пароль хранится на сервисе, ничего нового и безопасного сервис не предоставляет. Данные могут быть скомпрометированы извлечением ключа по очередному нажиму властей или по ошибке (как уже однажды случалось на Дропбоксе). Не биг дил, но люди должны об этом знать, особенно, если маркетингом утверждалось особенное внимание шифрованию и новизна в полной отвязке ключей.
Пароль не хранится на сервере
Я не знаю как хранится пароль, и вы не знаете. Совершенно очевидно одно: вы вводите пароль при логине. Что с ним потом происходит — 3й вопрос. Но теоретически перехват пароля возможен, а с ним и дешифрование данных.
RSA-ключи — это BLOB
В данном случае RSA ключи не нужны вообще. Приватный ключ, создавшийся при генерации аккаунта, очевидно не переходит на другую клиентскую машину или браузер, а доступ к файлам у пользователя с другой машины есть.
Я не знаю как хранится пароль, и вы не знаете. Совершенно очевидно одно: вы вводите пароль при логине. Что с ним потом происходит — 3й вопрос. Но теоретически перехват пароля возможен, а с ним и дешифрование данных.
RSA-ключи — это BLOB
В данном случае RSA ключи не нужны вообще. Приватный ключ, создавшийся при генерации аккаунта, очевидно не переходит на другую клиентскую машину или браузер, а доступ к файлам у пользователя с другой машины есть.
No usable encryption keys ever leave the client computers
Напишу чуть более детально… При регистрации на вашей машине генерируется ключ, шифруется вашим паролем, передается на сервер. При логине — сервер присылает вам зашифрованный ключ, он на вашей машине расшифровывается вашим же паролем и используется при передаче. Имеем стандартный механизм шифрации с двумя ключами (при этом закрытый знаете только вы и никто другой, как и полагается), что еще не ясно?
Я зарегистрировался на одной машине, сгенерировал ключ. Потом залогинился с другой машины. С ДРУГОЙ, понимаете? Ввел логин, пароль и получил… свои файлы взад. КАК приватный ключ с куков первой машины попадает на вторую?!
Ответ: генерация ключа — фикция. Он не нужен. Или нужен для внутренних алгоритмов, неважно. Для шифрования файлов используется ТОЛЬКО ваш пароль, причем неважно какими дальнейшими преобразованиями. И этот пароль вы ПЕРЕДАЕТЕ на сайт каждый раз при логине. Ни о какой особенной секретности речи идти не может. Хранит ли Мега пароль, будет ли Дотком до смерти защищать ваш пароль — это вопросы ДОВЕРИЯ, а не криптографии. С точки зрения безопасности нового слова сказано не было, хотя Дотком его напрямую обещал.
Этот ответ не только Вам, но и всем минусующим.
Ответ: генерация ключа — фикция. Он не нужен. Или нужен для внутренних алгоритмов, неважно. Для шифрования файлов используется ТОЛЬКО ваш пароль, причем неважно какими дальнейшими преобразованиями. И этот пароль вы ПЕРЕДАЕТЕ на сайт каждый раз при логине. Ни о какой особенной секретности речи идти не может. Хранит ли Мега пароль, будет ли Дотком до смерти защищать ваш пароль — это вопросы ДОВЕРИЯ, а не криптографии. С точки зрения безопасности нового слова сказано не было, хотя Дотком его напрямую обещал.
Этот ответ не только Вам, но и всем минусующим.
приватный ключ — ваш пароль, и вы его НЕ ПЕРЕДАЕТЕ, ну сколько можно…
еще вопросы?
function u_login(ctx,email,password,uh,permanent)
{
ctx.result = u_login2;
ctx.permanent = permanent;
api_getsid(ctx,email,prepare_key_pw(password),uh);
}
function prepare_key_pw(password)
{
return prepare_key(str_to_a32(password));
}
function prepare_key(a)
{
var i, j, r;
var pkey = [0x93C467E3,0x7DB0C7A4,0xD1BE3F81,0x0152CB56];
for (r = 65536; r--; )
{
for (j = 0; j < a.length; j += 4)
{
key = [0,0,0,0];
for (i = 0; i < 4; i++) if (i+j < a.length) key[i] = a[i+j];
aes = new sjcl.cipher.aes(key);
pkey = aes.encrypt(pkey);
}
}
return pkey;
}
еще вопросы?
Знаете, я устал чего-то доказывать и надоедать всем этой темой. Последний раз для тех, кто хочет быть услышанным.
Пароль — это ни разу не приватный ключ. Представление private_key = f(password) — это профанация, тем более, что Мега прямо говорит(ла) про RSA пару ключей и о хранении публичного ключа на серверах.
Скрипт превращает пароль в некий ключ (еще раз прошу не путать с общепризнанным определением приватного ключа!) в сегодняшней версии Меги. Если завтра Доткому предложат отдать ваши файлы, иначе сесть на 150 лет в тюрьму, или над вебмастером будут стоять с пистолетом, или сервер арестуют, скрипт поменяют, а ваша логин-форма передаст пароль на сайт вообще плейнтекстом.
Есть колоссальная разница между «мы обещаем не хранить пароль для дешифрования» и мы «не знаем пароля для дешифрования». Дотком обещал именно второе, а я не люблю, когда безопасность подменяется маркетингом.
Второй вариант реализуется как раз парой RSA ключей, где приватный RSA ключ действительно никогда не попадает на сервис, а используется лишь для шифрования одноразовых AES паролей, которыми в свою очередь шифруются файлы. Тогда грози Меге хоть тюрьмой, хоть пистолетами, файлы останутся в безопасности. Да, клиенту надо будет хранить (и переносить между своими компьютерами) приватный ключ, но это и есть определение полностью защищенного файлового хранилища. Обещанного. И таким образом представленного. И даже якобы генерирующего с помпой вышеуказанную пару…
Хотите продолжать верить в теоретическую безопасность Меги — ради бога, ваше право.
Пароль — это ни разу не приватный ключ. Представление private_key = f(password) — это профанация, тем более, что Мега прямо говорит(ла) про RSA пару ключей и о хранении публичного ключа на серверах.
Скрипт превращает пароль в некий ключ (еще раз прошу не путать с общепризнанным определением приватного ключа!) в сегодняшней версии Меги. Если завтра Доткому предложат отдать ваши файлы, иначе сесть на 150 лет в тюрьму, или над вебмастером будут стоять с пистолетом, или сервер арестуют, скрипт поменяют, а ваша логин-форма передаст пароль на сайт вообще плейнтекстом.
Есть колоссальная разница между «мы обещаем не хранить пароль для дешифрования» и мы «не знаем пароля для дешифрования». Дотком обещал именно второе, а я не люблю, когда безопасность подменяется маркетингом.
Второй вариант реализуется как раз парой RSA ключей, где приватный RSA ключ действительно никогда не попадает на сервис, а используется лишь для шифрования одноразовых AES паролей, которыми в свою очередь шифруются файлы. Тогда грози Меге хоть тюрьмой, хоть пистолетами, файлы останутся в безопасности. Да, клиенту надо будет хранить (и переносить между своими компьютерами) приватный ключ, но это и есть определение полностью защищенного файлового хранилища. Обещанного. И таким образом представленного. И даже якобы генерирующего с помпой вышеуказанную пару…
Хотите продолжать верить в теоретическую безопасность Меги — ради бога, ваше право.
О б-же мой. Вы таки тролите, при этом очень даже толсто. Я вам не собираюсь больше ничего доказывать, пойдите почитайте о шифровании.
ЗЫ. если найдете насоотвествие между алгоритмом шифрования с двумя ключами и исходниками меги — можем продолжить беседу в личке )
ЗЫ. если найдете насоотвествие между алгоритмом шифрования с двумя ключами и исходниками меги — можем продолжить беседу в личке )
Нет, это вы либо покажете второй ключ при входе в систему только по одному паролю, либо публично извинитесь за «тролля».
Смотрите не позеленейте
Я надеюсь комент не поломал хабр
POST eu.api.mega.co.nz/cs?id=345352429
200 OK
Запрос
POST /cs?id=345352429 HTTP/1.1
User-Agent: Opera/9.80 (Windows NT 6.2; WOW64) Presto/2.12.388 Version/12.12
Host: eu.api.mega.co.nz
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: ru-RU,ru;q=0.9,en;q=0.8
Accept-Encoding: gzip, deflate
Referer: mega.co.nz/
Connection: Keep-Alive
Content-Length: 64
Origin: mega.co.nz
Content-Type: text/plain;charset=UTF-8
[{«a»:«us»,«user»:"----",«uh»:"---"}]
Ответ
HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept
Content-Encoding: gzip
Content-Length: 1012
Connection: Keep-Alive
[{«csid»:«CABLoiwQx408H8wEo2TXYirl3ZmrbKJgEPtvyrZee2L9kulhCO1_zyJHxJOK94oam1kb2CkKWxjogu2b4A284TPLjzwpyn9xCid0QY26HV2P_UQOzfCrBSqN_z14fOOeaXgPlrGMrcEYBDGtEYLvbvXTqyJ3x8sAEQfnAiCW2fnCPr61I3QFFOdzxCxPCdOdhZ9nrJuKLm1PJwBBvQlnw-yaT2k6lcKUasA6bzz8_58pFKU3swUT-Qde5tcLJCWXwss2BV1EowcOXsZQceovVfXYwp7KE8xUqB5dmDUQNZX8ve7Pt6mu61T9R4KVC_GLypQpfj-sP_s3dCZxTbkzJFqT»,«privk»:«yevr_h_N2bgKwARElpKC8XoLutlTdmlqXtgaQeDVt8bqTTWuwrczXKIQpi9-VnpnjPXto7aj49uLJ6LDw98cUv5LIdaRZIRMqZHRaSuHBb0znjj5uUNlxYHwXa9XN-BkbNhIS8HjKRBR5j8L2CDSQ8hsVt2KjzJaksJ8yxuN0HOE3REwliRtUa1QCDg9Iy_ywZ7TUh7WmdwdTn3h_JqCF3U1_9d882T-Z6oDrxkZEMpGcOwwuumIU_oaeyy9L95lImPVaB7cJY-7qC6visJri2GDUYfO1li84c1bgXeWTZvD3NZ6mqpN_ZByw4uUKKWuEvHojgwgTgtl8MhCfYlbbAF8Z8KktigQgDxCHIOYNMmO53GgonI22bZw7h_4fqfgVpbf2A5f1H18Iq36rIVHTBKC5jL34tHJY_Dq6RkO9ViyNDEiXso9GawPbqTcadSmYYeIXMEHvp1fbk180nIOlJ4JrAuNyP04cAFXg3q7qNQxnHa5oFajxmqJSK8t3rjgGHRKbWqAhvRtCzHWnY8W7Z-jZw3dDl2KllHP1rWx4S60clXchHajlufwpQoUUE8GpOkcZugUvatTCCcTdqEKdQGi4QS6De8rXSHtqjQ_w1-WS1kULjjNQ4ZtAlbpovdRE8cM5AUwhtCN5hx_ji9v_R57kCiHpgeHYK1SPb4oXv4WdjWgE_OwBT9kluwuwtbT5yE0i2cuPl4f8Tdecc7zlXXAlQSoZn-QPX4b3-r-0LP0PPsY3rZFS8a7b44tzSaKMCSA9hz8oEmYHwt6CB3ngDuamRoilMHOVLI6Bd4MSQVtzs1GVOSLISrpcBhtkzWjKDQlXbH6oXjfEhLcM7jEEXEbE7DtYSUetKz6lELJ7PM»,«k»:«Igc01fFij63336KUerhLWw»}]
Я надеюсь комент не поломал хабр
Вы бы почитали про ассиметричное шифрование, хотя бы в той же википедии. Там же основная идея в том, чтобы передавать зашифрованное сообщение, при этом не передавая свой приватный ключ. А тут по сути обычное симметричное шифрование, со всеми вытекающими.
Тут скорее всего приватный ключ шифруется симметричным ключом выведенным из пароля (pbkdf2 например) и в таком виде хранится на сервере. Это сделано для удобства доступа с других машин, и вообще-то в любом zero-knowledge хранилище (кроме Tarsnap) реализовано что-то подобное.
В FAQ кстати есть вопрос «а что если в будущем вы тайком измените свои скрипты чтобы получить пароль/ключ?». Ответ — пользуйтесь другими интерфейсами, которым вы доверяете (opensource?) и которые появятся когда опубликуют API.
В общем, пока API не опубликовано рано безоговорочно заявлять что сервис не безопасен в принципе. Текущая javascript реализация действительно выглядит сомнительно, но это не исключает возможности написать безопасный клиент.
В FAQ кстати есть вопрос «а что если в будущем вы тайком измените свои скрипты чтобы получить пароль/ключ?». Ответ — пользуйтесь другими интерфейсами, которым вы доверяете (opensource?) и которые появятся когда опубликуют API.
В общем, пока API не опубликовано рано безоговорочно заявлять что сервис не безопасен в принципе. Текущая javascript реализация действительно выглядит сомнительно, но это не исключает возможности написать безопасный клиент.
Тут скорее всего приватный ключ шифруется симметричным ключом выведенным из пароля (pbkdf2 например) и в таком виде хранится на сервере.В этом-то и проблема. Самое слабое звено — это пароль. А все заморочки с асимметричным шифрованием ничего не стоят, так как ключи гуляют по сети туда и обратно.
А в чем проблема-то, в том что его можно «подобрать»? Так слабый пароль всегда будет проблемой безопасности, никакие ключи эту проблему не решат.
Не подобрать, а перехватить. Асимметричное шифрование решает именно эту проблему — приватный ключ (секрет) не передается никогда, поэтому перехватывать нечего и единственный вариант — подбирать, а это намного дольше.
Так и здесь ничего никуда не передается.
В правильно реализованной описанной схеме что-то перехватывать бесполезно habrahabr.ru/post/166847/#comment_5766847
В правильно реализованной описанной схеме что-то перехватывать бесполезно habrahabr.ru/post/166847/#comment_5766847
и да, за необоснованный минус в карму публичное вам спасибо ))
Минус в карму вам обоснован. Я вел с вами диалог совершенно спокойно и даже несколько раз терпел ваших «троллей» и нагловатый тон в виде отсылок почитать о шифровании (которым занимаюсь профессионально чуть меньше лет, чем вы живете на свете, к слову).
И честно тратил на вас свое время.
А потом вот «позеленел», как видите.
И честно тратил на вас свое время.
А потом вот «позеленел», как видите.
Выше говорят, что есть API, а значит, думаю, сторонние клиенты — это вопрос времени. В этом и заключается безопасность, можно использовать свой собственный клиент, и никакая подмена протокола Доткомом не позволит ему получить доступ к вашим данным, что принципиально невозможно в сервисах с отсылкой закрытого ключа на сервер.
Во-первых, уже поздно. Надежные системы должны быть надежны с 1й секунды. Если вы логинились на Мегу, скажем, 30 раз, вы не можете быть уверенными в том в один раз из 30 скрипт не передал пароль в открытом виде. Факты говорят лишь о том что при регистрации и логине вы вводите свой пароль. Теоретически это — компрометация.
Во-вторых, в системе с одним паролем API тоже нельзя доверять. Сегодня система присылает случайное число, которое скрипт на стороне клиента шифрует паролем, и это используется в качестве пароля для шифрования. Однако случайное число может стать совсем не случайным, если сервис скомпрометирован. И тогда ваш пароль может попасть в руки плохих парней (или хороших полиуейских), а с ним — и все до единого пароли шифрования.
Во-вторых, в системе с одним паролем API тоже нельзя доверять. Сегодня система присылает случайное число, которое скрипт на стороне клиента шифрует паролем, и это используется в качестве пароля для шифрования. Однако случайное число может стать совсем не случайным, если сервис скомпрометирован. И тогда ваш пароль может попасть в руки плохих парней (или хороших полиуейских), а с ним — и все до единого пароли шифрования.
Мне кажется, неверно говорить о ненадежности системы. Система предоставляет инструменты, которые можно использовать для безопасности. Если вам угодно, можете зарегистрироваться заново уже сейчас, и проверять скрипты каждый раз, когда вы логинитесь. Передача пароля в этом случае исключается.
Что касается второго, существуют ли алгоритмы восстановления ключа путем подмены случайного числа специально сгенерированным?
Что касается второго, существуют ли алгоритмы восстановления ключа путем подмены случайного числа специально сгенерированным?
Криптосистема не может быть немножко беременной: она либо безопасна, либо скомпрометирована. На самом деле моя претензия заключалась не в методе шифрования Меги, а в том, что изначально декларировался совсем другой метод. Системы «вы нам верите, что ваш пароль безопасен» имеют полное право на существование. Более того, такиз систем — 99.999% в интернете. А Дотком обещал нечто другое, а именно: «верите вы нам или нет, захватят нас власти или нет, засудят ли копирасты — ваш пароль нам не получить», вот и все.
Касательно вопроса, конечно можно восстановить: AES — симметричный метод шифрования.
Касательно вопроса, конечно можно восстановить: AES — симметричный метод шифрования.
Если они сейчас ничего не сохраняют, то даже когда им паяльник куда надо вставят они ваш пароль никому не скажут если вы перестанете пользоваться недоверенными клиентами.
А сохраняют/отправляют ли сейчас, кто вам лично мешает каждый раз проверять загруженный javascript на предмет закладок. Возможность есть? Есть! Какие проблемы?
Как вы вообще понимаете гарантированную безопасность? Всегда будет кем-то написанный код и его надо смотреть, а не кричать на каждом углу «ваш пароль могут стырить»
А сохраняют/отправляют ли сейчас, кто вам лично мешает каждый раз проверять загруженный javascript на предмет закладок. Возможность есть? Есть! Какие проблемы?
Как вы вообще понимаете гарантированную безопасность? Всегда будет кем-то написанный код и его надо смотреть, а не кричать на каждом углу «ваш пароль могут стырить»
Вы не сможете поклясться, что сейчас пароль не сохранился, не перехватился или каким-либо другим способом не покинул систему. В терминах безопасности это означает компрометацию, точка.
Нельзя использовать ключ и для аутентикации, и для шифрования одновременно, это тоже азы безопасности, Нарушение этого принципа — тоже компрометация.
Нельзя использовать ключ и для аутентикации, и для шифрования одновременно, это тоже азы безопасности, Нарушение этого принципа — тоже компрометация.
По такому определению безопасности не существует. Вы можете поклясться что у вас на машине нет трояна?
Правильно один ключ и не используется, как минимум из пароля нужно получить три производных ключа: для аутентификации, шифрования и MAC.
Правильно один ключ и не используется, как минимум из пароля нужно получить три производных ключа: для аутентификации, шифрования и MAC.
Безопасность существует. Вот у меня, например, в сервисе LastPass используется Ubikey. При этом не только LastPass не знает мой приватный ключ, я и сам его не знаю, «не вытаскиваю» и следовательно, не могу скомпрометировать.
Трояны и социальные виды атак относятся к другой области.
Три производных ключа из одного — это все еще один ключ :).
Трояны и социальные виды атак относятся к другой области.
Три производных ключа из одного — это все еще один ключ :).
Трояны и социальные виды атак относятся к другой области.Наконец-то мы пришли к очевидному. Большая часть ваших претензий не относится к дизайну криптографической системы. Если кто-то может поменять код отдаваемый index.html, он также может просунуть закладку в очередной апдейт LastPass и никакой токен от этого не спасет.
Если их трех производных ключей один скомпрометирован это никак не поможет угадать другие два. Так что это все-таки три разных ключа.
Большая часть ваших претензий не относится к дизайну криптографической системы
Разумеется. К дизайну их криптосистемы у меня тоже есть претензии, но они слишком технические, слишком теоретические и уже озвучены реальными аудиторами в Интернете. Я же везде говорил не про дизайн, а про его «маркетинговое представление».
в очередной апдейт LastPass и никакой токен от этого не спасет
Спасет. Ключ останется в безопасности, дотсупа к нему нет. Закладка может украсть расшифрованную часть данных на локальном компе, но получить ключ и украсть все мое зашифрованное облачное хранилище — не может!
Разумеется. К дизайну их криптосистемы у меня тоже есть претензии, но они слишком технические, слишком теоретические и уже озвучены реальными аудиторами в Интернете. Я же везде говорил не про дизайн, а про его «маркетинговое представление».
в очередной апдейт LastPass и никакой токен от этого не спасет
Спасет. Ключ останется в безопасности, дотсупа к нему нет. Закладка может украсть расшифрованную часть данных на локальном компе, но получить ключ и украсть все мое зашифрованное облачное хранилище — не может!
Может я неправильно вас понимаю, вы говорите, что клиент шифрует пользовательский пароль использую присланный «случайный» ключ, а потом отсылает обратно результат в качестве ключа для шифровки данных, т.е. на стороне сервера оказывается и зашифрованный пароль, и только отосланный «случайный» ключ, пригодный для его расшифровки?
Я не знаю как оно на самом деле, но если их заявления имеют какое-то отношение к реальности, то схема должна быть примерно такой (упрощенно):
Регистрация:
— Пользователь вводит пароль, который преобразуется в симметричный ключ П1 через KDF (key derivation function). Этот пароль и ключ никуда и никогда не передаются! (но могут для удобства храниться локально).
— Генерируется случайный мастер-ключ М1 (или несколько). Все они шифруются ключом П1 и отсылаются на сервер.
Загружаем файл:
— Запрашиваем мастер ключ М1 и расшифровываем их нашим секретным ключом П1.
— Шифруем файл Ф1 случайным ключом К1. Ключ К1 шифруем мастер-ключом М1. Файл и его уникальный ключ отсылаем на сервер.
Итого на сервере хранится:
— Файл Ф1 (зашифрованный К1)
— Ключ К1 (зашифрованный М1)
— Мастер ключ М1 (зашифрованный П1)
Скачиваем:
— Запрашиваем М1, расшифровываем его нашим П1
— Запрашиваем К1, расшифровываем его полученным М1
— Запрашиваем файл, расшифровываем его К1
Т.е. пользователю достаточно только знать свой пароль, который однозначно преобразуется в его секретный ключ П1. Сервер этот ключ никогда в глаза не видит.
Бонус: смена пароля
1. Качаем М1, расшифровываем его П1
2. Зашифровываем новым паролем П2 и закачиваем обратно на сервер
Регистрация:
— Пользователь вводит пароль, который преобразуется в симметричный ключ П1 через KDF (key derivation function). Этот пароль и ключ никуда и никогда не передаются! (но могут для удобства храниться локально).
— Генерируется случайный мастер-ключ М1 (или несколько). Все они шифруются ключом П1 и отсылаются на сервер.
Загружаем файл:
— Запрашиваем мастер ключ М1 и расшифровываем их нашим секретным ключом П1.
— Шифруем файл Ф1 случайным ключом К1. Ключ К1 шифруем мастер-ключом М1. Файл и его уникальный ключ отсылаем на сервер.
Итого на сервере хранится:
— Файл Ф1 (зашифрованный К1)
— Ключ К1 (зашифрованный М1)
— Мастер ключ М1 (зашифрованный П1)
Скачиваем:
— Запрашиваем М1, расшифровываем его нашим П1
— Запрашиваем К1, расшифровываем его полученным М1
— Запрашиваем файл, расшифровываем его К1
Т.е. пользователю достаточно только знать свой пароль, который однозначно преобразуется в его секретный ключ П1. Сервер этот ключ никогда в глаза не видит.
Бонус: смена пароля
1. Качаем М1, расшифровываем его П1
2. Зашифровываем новым паролем П2 и закачиваем обратно на сервер
Спасибо за разъяснения! В общих чертах так я и представлял.
выше написано про RSA, а вы про симметричный ключ
Я написал как работает (должна работать) МЕГА. Если вам нравится RSA, можете заменить М1 на RSA ключевую пару.
Если вы хотите чтобы RSA был top-level ключ, то вам сюда www.tarsnap.com/crypto.html
Если вы хотите чтобы RSA был top-level ключ, то вам сюда www.tarsnap.com/crypto.html
Хм, небольшой рефакторинг: если П1 = KDF (пароль), то можно не вводить термин «симметричный секретный ключ П1», а вместо него везде подставлять термин «пароль». Получится такое же корректное рассуждение, но короче :)
В общем, самое слабое место — пароль, который я, во-первых, знаю, и, который, во-вторых, другие имеют теоретическую возможность тоже узнать, применив ко мне методы социальной инженерии, спектр которых широк — где-то в середине этого спектра находятся трояны и кейлоггеры, а уж что на его границах, каждый может представить себе сам, а лучше даже и не представлять.
Если же с практической стороны, то от того, что сервис выдаст мне плохую версию index.html, которая передаст мой драгоценный пароль открытым текстом куда мне не надо (проблема «недоверенного клиента», вроде так называется?) в принципе теоретически в какой-то мере мог бы защитить институт PKI, аналогичный применяемому сейчас для SSL, только подписывать надо не доменное имя, а хэш хорошего, надежного index.html, который, как подтвердили независимые аудиторы, никуда налево мой драгоценный пароль не передает. Это по сути и делали в Microsoft, когда подписывали свои msi-инсталляторы, но в последнее время они мне не попадаются, что наводит на мысли, что они морально устарели. Боюсь, что вместе с институтом «подписи exe-шников».
В общем, самое слабое место — пароль, который я, во-первых, знаю, и, который, во-вторых, другие имеют теоретическую возможность тоже узнать, применив ко мне методы социальной инженерии, спектр которых широк — где-то в середине этого спектра находятся трояны и кейлоггеры, а уж что на его границах, каждый может представить себе сам, а лучше даже и не представлять.
Если же с практической стороны, то от того, что сервис выдаст мне плохую версию index.html, которая передаст мой драгоценный пароль открытым текстом куда мне не надо (проблема «недоверенного клиента», вроде так называется?) в принципе теоретически в какой-то мере мог бы защитить институт PKI, аналогичный применяемому сейчас для SSL, только подписывать надо не доменное имя, а хэш хорошего, надежного index.html, который, как подтвердили независимые аудиторы, никуда налево мой драгоценный пароль не передает. Это по сути и делали в Microsoft, когда подписывали свои msi-инсталляторы, но в последнее время они мне не попадаются, что наводит на мысли, что они морально устарели. Боюсь, что вместе с институтом «подписи exe-шников».
Да, на стороне сервера оказывается зашифрованный файл и это случайное число. Для дешифровки файла процесс обратный: зашифрованный файл + ассоциированное с файлом (или аккаунтом) случайное число + ваш локальный пароль = открытый файл.
Такая схема кажется вполне безопасной, пока сервер не имеет вашего локального пароля. Насколько я понял, вы утверждали, что фактически сервер может получить ваш пароль, искусственно подделав некое случайное число. Можете пояснить?
Нет, я утверждал, что сервер может тупо поменять html на мега.ко.нз (или какой там адрес), а вы спокойно отдадите логин и пароль совершенно открыто, в обычном POST запросе. Коль скоро используется симметричная криптография, пароли для входа в систему и шифрования обязаны быть разными!
Я также утверждал, что в качестве случайного числа, присылаемого сервером, могут использоваться заранее фиксированные последовательности, зная которые (и имея их зашифрованными), можно зареверсить ваш пароль, т.е. скомпрометировать не сам сайт, а API.
Я также утверждал, что в качестве случайного числа, присылаемого сервером, могут использоваться заранее фиксированные последовательности, зная которые (и имея их зашифрованными), можно зареверсить ваш пароль, т.е. скомпрометировать не сам сайт, а API.
Сценарий «сервер отдал не затрояненую страницу» не имеет отношения к криптографии.
Ключи обязаны быть разными, пароль может быть один en.wikipedia.org/wiki/PBKDF2.
Не понимаю зачем клиенту спрашивать у сервера какие-то случайные числа?
Ключи обязаны быть разными, пароль может быть один en.wikipedia.org/wiki/PBKDF2.
Не понимаю зачем клиенту спрашивать у сервера какие-то случайные числа?
В данном случае речь идет не о троянах (или вообще кейлогерах), а о стойкости самого сервиса в т.ч. и от ФБР, владельцев авторских прав и т.д. Да, вы правы, это не криптография, но я и не ругал нигде криптографию. Я подвергаю сомнению высказывания г-на Доткома «а сейчас, чуваки, мы сделаем настолько безопасную систему, что все козлы из enforcement сдохнут от злости».
зачем клиенту спрашивать у сервера какие-то случайные числа?
Это правильно делать в плане надежности ГСЧ — критического компонента key derivation. Принято считать, что генератор псевдослучайных чисел у клиента очень ненадежен (и оно так и есть). Т.к. случайное число (соль) разделяется между сервером и клиентом, лучше его генерировать на сервере из заведомо надежного источника ГСЧ.
зачем клиенту спрашивать у сервера какие-то случайные числа?
Это правильно делать в плане надежности ГСЧ — критического компонента key derivation. Принято считать, что генератор псевдослучайных чисел у клиента очень ненадежен (и оно так и есть). Т.к. случайное число (соль) разделяется между сервером и клиентом, лучше его генерировать на сервере из заведомо надежного источника ГСЧ.
Что-то у меня не вяжется
Т.к. даже дилетанту очевидно, что если очень хочется, то можно по-XOR-ть случайное число клиента (неизвестное серверу на данном этапе) с тем что вернет сервер. Но заменять его это, извините, полный бред. Если совсем правильно, то сначала обмениваются хешами солей, а потом самими солями и итоговая соль это «соль1^соль2».
Т.к. случайное число (соль) разделяется между сервером и клиентом, лучше его генерировать на сервере из заведомо надежного источника ГСЧ.с
занимаюсь профессионально шифрованием
Т.к. даже дилетанту очевидно, что если очень хочется, то можно по-XOR-ть случайное число клиента (неизвестное серверу на данном этапе) с тем что вернет сервер. Но заменять его это, извините, полный бред. Если совсем правильно, то сначала обмениваются хешами солей, а потом самими солями и итоговая соль это «соль1^соль2».
Итоговая соль все равно зальется на сервер, какая разница?! Мы же говорим не о соли как таковой, а о части ключа для шифрования файла. Для расшифровки файла эта часть должна быть в неизменности передана обратно клиенту для того, чтобы клиент построил полный ключ и дешифровал файл.
Разница в том что ни сервер ни клиент не могут предсказуемо повлиять на итоговое значение и значит выбрать что-то уязвимое.
Если речь идет об индивидуальном ключе файла, то это все-таки соль (если сервер принимает участие), а сам ключ получается из мастер-ключа filekey = kdf(masterkey, randomsalt) или hmac(masterkey, randomsalt).
Если речь идет об индивидуальном ключе файла, то это все-таки соль (если сервер принимает участие), а сам ключ получается из мастер-ключа filekey = kdf(masterkey, randomsalt) или hmac(masterkey, randomsalt).
Документацию на API пока не выложили, вы действительно отреверсили протокол или гадаете? «Сервер присылающий случайное число» это конечно сильно, такого не бывает нигде и никогда (если МЕГА напишет «ключи только из наших случайных чисел» то тут конечно вопросов уже не будет).
Единственное что можно уверенно заявить сейчас, это что официальный javascript клиент (без аудита кода и средств контроля целостности проверенного кода) не безопасен, с параноидальной криптографической точки зрения. Заявлять что весь сервис небезопасен, пока рановато. Ну и если потом появятся вменяемые сторонние клиенты, естественно аккаунт и пароль нужны будут новые.
Единственное что можно уверенно заявить сейчас, это что официальный javascript клиент (без аудита кода и средств контроля целостности проверенного кода) не безопасен, с параноидальной криптографической точки зрения. Заявлять что весь сервис небезопасен, пока рановато. Ну и если потом появятся вменяемые сторонние клиенты, естественно аккаунт и пароль нужны будут новые.
Я не собираюсь делать аудит системы, она мне не интересна вообще. У меня было просто другое представление о том, что Дотком называет «абсолютно безопасным хранилищем». Более того, они неоднократно намекали на асиметричную крипотграфию, говорили про пары ключей, про публичный ключ, хранящийся на сервере и т.д, и т.п. А физически решение оказалось другим. Более удобным для неискушенного пользователя (можно залогиниться отовсюду), но менее безопасным. Я против использования а) симметричной криптографии на внешних сервисах, б) против использования одного пароля в качестве базы для аутентикации и шифрования.
С какого бока вообще нужна асимметричная криптография в облачном хранилище? Она нужна когда есть необходимость обмена сообщениями между различными сущностями.
а) Что такое «симметричная криптография на внешних сервисах»?
б) Не вижу проблемы. Если есть риск компрометации одного пароля, то также есть риск компрометации обоих.
а) Что такое «симметричная криптография на внешних сервисах»?
б) Не вижу проблемы. Если есть риск компрометации одного пароля, то также есть риск компрометации обоих.
Асимметричная криптография нужна для генерации случайных паролей для шифрования объектов без использования (т.е. компрометации) дешифровального ключа. Таким образом, дешифровальный ключ можно спрятать в банковский сейф, хранить на смарткарте/токене или вообще уничтожить. Есть еще плюс при необходимости расшаривать зашифрованные файлы, но это мы уже слишком углубимся.
Симметричная криптография легче для использования, но хуже в плане безопасности. Неважно, пользуетесь ли вы паролем, функцией от пароля или функцией от функции от пароля. Компрометация любой части приводит к раскрытию всей цепочки, всех мастер-ключей и всех зашифрованных файлов. А использование одного пароля для логина и шифрования тем более опасно, что сервис может вдруг стать нечестным. С асимметричной криптографией проблемы нечестности сервиса не стоит вообще.
Симметричная криптография легче для использования, но хуже в плане безопасности. Неважно, пользуетесь ли вы паролем, функцией от пароля или функцией от функции от пароля. Компрометация любой части приводит к раскрытию всей цепочки, всех мастер-ключей и всех зашифрованных файлов. А использование одного пароля для логина и шифрования тем более опасно, что сервис может вдруг стать нечестным. С асимметричной криптографией проблемы нечестности сервиса не стоит вообще.
Мда, давайте зашифруем всё публичным ключом, а приватный сотрём. Безопасности будет через край, а полезности ноль.
Для генерации случайных паролей нужна не «асимметричная криптография», а (сюрприз) генератор случайных чисел.
У каждого файла свой уникальный ключ, проблем с расшариванием нет. Есть проблема передачи ключа, которая перекладывается на пользователя.
Во-первых это сервис онлайн хранения данных, дизайн на основе токенов и асимметричных ключей будет настолько неудобен, что никто таким сервисом пользоваться не будет.
Во-вторых если данными вы пользуетесь хоть иногда, то независимо какой у вас там супер приватный ключ в суперсекретном токене, вам еще нужен софт который этот токен использует и проблема нечестности сервиса возвращается.
Для генерации случайных паролей нужна не «асимметричная криптография», а (сюрприз) генератор случайных чисел.
У каждого файла свой уникальный ключ, проблем с расшариванием нет. Есть проблема передачи ключа, которая перекладывается на пользователя.
Во-первых это сервис онлайн хранения данных, дизайн на основе токенов и асимметричных ключей будет настолько неудобен, что никто таким сервисом пользоваться не будет.
Во-вторых если данными вы пользуетесь хоть иногда, то независимо какой у вас там супер приватный ключ в суперсекретном токене, вам еще нужен софт который этот токен использует и проблема нечестности сервиса возвращается.
Безопасности будет через край, а полезности ноль.
Далеко не ноль, когда Доткома в наручниках поведут в турму, а у вас там 100500 пиратских фильмов или детская порнуха. Вы очень обрадуетесь возможности уничтожить приватный ключ и навсегда похоронить зашифрованные данные. Понятно, я говорю не о Вас лично, а о принципе :).
Для генерации случайных паролей нужна не «асимметричная криптография», а (сюрприз) генератор случайных чисел.
Нет, для сулчайного пароля нужен и ваш пароль тоже. Случайное число вообще не секретно, иначе вы никогда не могли бы расшифровать зашифрованный файл. Секретен в формуле key = f(password, random) только пароль.
будет настолько неудобен, что никто таким сервисом пользоваться не будет
Вот тут соглашусь полностью. Более того, уже 10 раз в этой ветке заявлял, что методы защиты выбраны ради удобства пользователей, а не степени защиты. Может мне очень хотелось появления отличного от других сервиса…
Далеко не ноль, когда Доткома в наручниках поведут в турму, а у вас там 100500 пиратских фильмов или детская порнуха. Вы очень обрадуетесь возможности уничтожить приватный ключ и навсегда похоронить зашифрованные данные. Понятно, я говорю не о Вас лично, а о принципе :).
Для генерации случайных паролей нужна не «асимметричная криптография», а (сюрприз) генератор случайных чисел.
Нет, для сулчайного пароля нужен и ваш пароль тоже. Случайное число вообще не секретно, иначе вы никогда не могли бы расшифровать зашифрованный файл. Секретен в формуле key = f(password, random) только пароль.
будет настолько неудобен, что никто таким сервисом пользоваться не будет
Вот тут соглашусь полностью. Более того, уже 10 раз в этой ветке заявлял, что методы защиты выбраны ради удобства пользователей, а не степени защиты. Может мне очень хотелось появления отличного от других сервиса…
Точно также можно стереть симметричный ключ. Лично мне важнее возможность держать ключ (в виде пароля) в голове, чем возможность его разбить молотком (в случае токена). Если асимметричная криптография используется без аппаратных средств шифрования, то разницы с симметричной нет.
Даже с аппаратным шифрованием, если сравнивать по пунктам, то преимуществ у асимметричной схемы очень мало, тк большая их часть обходится «некриптографическими» атаками, типа затроянивания.
Только, если вы файл один раз зашифровали и никогда больше не использовали, то ассиметриный случай выигрывает. Но это настолько нетипичный случай использования, что строить дизайн хранилища ориентируясь на него бессмысленно. Гораздо проще навесить еще один уровень шифрования сверху, а не на уровне облачного хранилища.
Даже с аппаратным шифрованием, если сравнивать по пунктам, то преимуществ у асимметричной схемы очень мало, тк большая их часть обходится «некриптографическими» атаками, типа затроянивания.
Только, если вы файл один раз зашифровали и никогда больше не использовали, то ассиметриный случай выигрывает. Но это настолько нетипичный случай использования, что строить дизайн хранилища ориентируясь на него бессмысленно. Гораздо проще навесить еще один уровень шифрования сверху, а не на уровне облачного хранилища.
Ничего там сервер не присылает. Реверсить его — пятиминутное дело, открываем консольку js и видим весь код
Не разбираюсь в теме, но как должна выглядеть система из второго варианта? Если приватный ключ хранится в браузере, то что мешает отправить его на сервер меги?
Хранить в куках — небезопасно, да. Можно хранить в личном хранилище или еще лучше на security token-е. В любом случае обеспечение безопасности приватного ключа, который не участвует ни в какой интеракции с сервисом, намного легче обеспечения безопасности постоянно вводимого при логине и зависящего от скрипта на серверной части пароля.
С рапидой сравнивать смешно, после того, как они изменили свою политику, туда перестали заливать пиратское добро.
Хм… Нравится минималистичность сервиса, предоставляемый объем…
Но одно не пойму — общедоступную ссылку на папку сейчас никаким образом не получить? Чтобы пользователь перешел по ссылке, попал в подпапку, оттуда скачал. Возможна данная операция только с файлом?
Но одно не пойму — общедоступную ссылку на папку сейчас никаким образом не получить? Чтобы пользователь перешел по ссылке, попал в подпапку, оттуда скачал. Возможна данная операция только с файлом?
Вот как раз в тему о их секьюрити модели:
fail0verflow.com/blog/2013/megafail.html
fail0verflow.com/blog/2013/megafail.html
насколько я понимаю, все усилия по шифрованию Меги направлены главным образом на правообладателей.
Если хостинг не знает что хранит — его не в чем обвинить.
наверное, и торрент-треккерам пора подумать над таким.
Если хостинг не знает что хранит — его не в чем обвинить.
наверное, и торрент-треккерам пора подумать над таким.
Интерестно такое настырное предложение перейти на гугл хром действительно обусловлено в таком сильном отставании других браузеров вроде фаерфокса или просто гугл подсуетился вовремя?
Ну а почему бы нет, при таком то пиаре :)
50 GB free!!! Как выйдет клиент для винды, променяю dropbox на мегу!
По-моему, все стали тестить его сразу на десятигигабайтных фильмах — вот и слег сервис :)
Старым сервисом не пользовался, а тут такой пиар — не удержался :)
50 GB это круто! Да и интерфейс порадовал, русский даже есть. Неплохо, лишь бы не накрылось, если вдруг к нему привыкнешь.
50 GB это круто! Да и интерфейс порадовал, русский даже есть. Неплохо, лишь бы не накрылось, если вдруг к нему привыкнешь.
Про адекватность рейтингов Alexa хорошо раскрыто в первом комментарии здесь: roem.ru/2013/01/23/mavrodi61088/
У меня тут вопрос: при попытке полностью расшарить файл (получить ссылку с ключом) выскакивает предупреждение:
Осторожно: Безопасность модели шифрования зависит от безопасности ключей отображенных выше. Старайтесь не передавать их небезопасными каналами.
И в справке:
Убедитесь, что Вы передаете их только защищенными каналами. Стандартная электронная почта не достаточна.
Это относится только к конкретному расшариваему файлу, или ко всем? Ну, то есть, могу ли я смело дать ссылку на конкретный файл где-нибудь на форуме, не опасаясь за остальные?
Осторожно: Безопасность модели шифрования зависит от безопасности ключей отображенных выше. Старайтесь не передавать их небезопасными каналами.
И в справке:
Убедитесь, что Вы передаете их только защищенными каналами. Стандартная электронная почта не достаточна.
Это относится только к конкретному расшариваему файлу, или ко всем? Ну, то есть, могу ли я смело дать ссылку на конкретный файл где-нибудь на форуме, не опасаясь за остальные?
Что-то у меня скорость больше 50 KB/s не поднимается…
рисую java клиента, настрою резервный бакап домашнего сервера с фотками туда.
mega.co.nz/ недоступен. У меня одного так?
Интересный загрузчик — сначала показывает, что загрузилось 5%, потом 10%, а потом снова 5%.
Клиент радует. Почти сутки загружал двухгиговый архив со скоростью ~40кб/с (3G), сейчас на отметке 99% он бодро начал с нуля! :)
Ну чё, просто отлично! Безопасность файлов настолько высокая, что даже самим пользователям нельзя их получить. Пытаюсь раз за разом скачать сбэкапленный на мегу полугиговый файлик, получаю «ошибку дешифрования».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Через 5 дней после запуска файл-хостинг Mega обошёл Rapidshare и Dropbox