Как стать автором
Обновить

Комментарии 81

Настоящий параноик таким сервисом пользоваться не станет. Где гарантия, что данные действительно удаляются после просмотра?
Это я и имел ввиду что параноикам не прокатит, а кто-то другой наверняка заинтересуется.
Исходники на github, дать поставить у себя, потискать, попытаться взломать — успокоиться и юзать свою копию/разочароваться и дать фидбэк.
Кто мешает выложить на гитхаб исходники, а юзать на сервере форк?
Даже если на сервере не форк, то удалится информация или нет сильно зависит от СУБД.
Большинство СУБД не удаляют информацию (я уж молчу про затирание) по запросу DELETE, а только ставят в записи пометку, что она удалена. Таким образом обеспечивается её отсутствие в выдаче по какому-либо запросу. При наличии физического доступа к серверу все записи в БД можно будет восстановить.
Зашифруйте отправляемые данные, пароль передайте по телефону после скачивания по ссылке
Настоящий параноик передает информацию только лично. Написанную на бумаге и запечатанную в непрозрачный конверт.
Берем какую-нибудь экзотическую длину волны света (что там проходит через бумагу) и профит!
Гарантию, конечно, обеспечить сложно. Можно предложить человеку пользоваться несколькими независимыми каналами передачи данных, одним из которых может стать secureshare. Например, если Вы передаёте реквизиты доступа к серверу по ssh, то логин можно передать в письме или смс, а хост и пароль — в одноразовой ссылке.
Файлики — одна из приоритетных задач на ближайшее время, скоро будет
файлики тоже шифровать надо
НЛО прилетело и опубликовало эту надпись здесь
Вы совершенно правы, генерировать хеш или случайную строку — в данном случае всё равно. Теоретически, если генерировать строку той же длины из б0льшего алфавита (не 0-9a-f, а, скажем, A-Za-z0-9), то возможных сочетаний получается больше и вероятность случайно угадать хеш снижается. Но на практике оба этих варианта обеспечивают достаточную устойчивость к перебору.
НЛО прилетело и опубликовало эту надпись здесь
Я имел в виду не брать хеш от случайного числа, а именно генерировать случайную строку. То есть, иными словами, генерить число в 62-ричной системе (если используем алфавит A-Za-z0-9). Таким образом, если хеш, как сейчас, будет 40 байт, то различных вариантов будет 62^40. Согласитесь, это больше чем RAND_MAX :-)
rand вообще-то не особо случайные числа выдает, /dev/random куда лучше, да и размер не ограничен, берите сколько нужно.
В /dev/random с таким сервисом может и энтропия закончиться. Лучше выглядят решения с совместной генерацией случайного числа клиентом и сервером, в таком случае можно и /dev/urandom использовать.
Да и так можно urandom использовать. Ведь это не криптографическое применение — это число не будет ни ключом, ни вектором и никаким образом ни будет связано с исходным текстом (в отличии от хэша). И кстати, urandom тоже криптографически сильный генератор, чего не скажешь о rand.
Так вы от этой случайной строки хеш берете или нет? Если берёте — то не надо, это ничего не улучшит. Если не берёте — то не называйте её хешом.
А если посолить?
Мертвому припарки это называется. Для генерирования случайных чисел, от случайности которых зависит безопасность — надо использовать специальные криптографические генераторы. Точка.
Убедили, спасибо)
UUID4
нет, вероятность коллизии с использованием хеш-функции — больше
НЛО прилетело и опубликовало эту надпись здесь
Удаление действительно нельзя считать достаточно надёжным, но примите во внимание то, что в базе хранятся зашифрованные данные. Если злоумышленнику удастся восстановить удалённые данные, то он получит лишь кусок мусора. Для расшифровки нужен ключ, а в базе хранится только его часть.
Если у злоумышленника нет второй половинки ключа, то и ссылку нет нужды делать одноразовой :)
Изначальная идея была все же что даже если злоумышленник получит со временем эту половинку, то открыть ссылку все равно не сможет. Впрочем это уже мелочи.
Ну тут злоумышленник получит доступ к ссылке если он украдёт вторую половинку ключа И получит доступ к базе И СУБД к тому времени ещё не перезатрёт удаленную первую половинку.
Я понимаю :). Просто такая атака все же реалистична, а когда речь заходит о криптографических схемах то обычно стараются избежать любых реалистичных атак, даже самых сложных.
Следует различать атаку на пользователя (прочитали почту, увидели ссылку, хотим прочитать конкретное сообщение) и атаку на сервис в целом (влозмали сервер, хотим прочитать все сообщения).
Это вариант атаки на пользователя, просто он включает в себя нетривиальный шаг по получению доступа к сервису. Это нормально для рассмотрения криптографических схем. Например MITM-атаки подразумевают возможность заблаговременного встраивания в канал связи между абонентами, что тоже технически сложно реализовать, но атаками на пользователя они от этого быть не перестают.
Я не о том. Многие не переживают о персональных атаках («кому я нужен»), но беспокоятся о массовом взломе и массовой утечке чувствительных данных. Защиты от профессиональных персональных атак практически нет, но если сервис делает невозможным (в криптографическом смысле слова — очень маловероятным) массовую утечку by design (приватного ключа на стороне сервера не хранится), то доверие к нему возрастает.
удаление данных by DELETE имеет обратную сторону медали: дефрагментация пространства. Я бы вместо РСУБД базы использовал бы какое-нибудь NoSQL, например тот же маилрушный тарантул: и можем использовать первичный ключ, и персистентность, и производительность и с кроном заморачиваться не надо, можно хранимку в рамках самого хранилища написать.
Перед удалением можно написать поверх какого-нибудь мусора.
Хотя, с реализованной защитой данных это, возможно, уже и лишнее.
Интересные мысли, понравилось про половинки ключей.
тогда получается вообще незачем делить случайное число на две части. Пришли данные от поьзователя, сгенерил случаное число, зашифровал данные, сложил их в базу. Клиенту отдал сгенерированное случайное число и id записи.
В чем прикол хранить половину у себя? от жесткого перебора это все равно не спасет
Прикол не в том, чтобы хранить половину у себя, а в том, чтобы не хранить ключ целиком у себя. Представьте такую ситуацию: хакеру удалось проникнуть в систему, он смог восстановить зашифрованные данные из базы. Теперь ему нужен ключ. Если бы мы отдавали весь ключ целиком клиенту, его можно было бы вытащить, к примеру, из access-логов сервера. А так хакеру потребуется приложить больше усилий для взлома.

Как известно, в таких ситуациях решающим фактором является цена информации и цена усилий для её получения. Если вторую цену мы поднимем достаточно высоко, то он скорее плюнет и бросит эту дурацкую затею.
мне кажется не суть, ну возьмет он из access логов вторую половину ключа а первую из кода, раз уж добрался. Разделение этого ключа на 2 части ничего не решает.

Если уж параноить тут можно так сделать еще интереснее:
анкор (хэш) урлы не уходят из браузера. Браузер при переходе вот по такой урле http://habrahabr.ru/#search_form отшлет на сервер get запрос только habrahabr.ru/

Это можно заюзать таким образом. Оставляем всю вашу схему с серверным шифрованием но перед этим еще и шифруем на клиенте (в браузере перед отправкой на сервер). Ключик клиентского шифрования пока храним в браузере. После того как сервер вернул сгенеренную урлу, дописываем ключ клиентского шифрования через хэш:
secureshare.pw/s/617cde716b6f4bfb34...#client_side_secret_password

теперь все стало еще сложнее потому как client_side_secret_password никуда не уйдет из браузера (в логи апача, провайдера и тп)
Поздравляю, вы только что придумали mega.co.nz
ну клиентское шифрование — чего такого ) Наверняка Mega не хранит ключик в хэш урле. Тут фишка именно в том чтобы без регисрации и паролей придумать самый секьюрный способ передачи данных через веб сервис
Именно что хранит: https://mega.co.nz/#!MANgUBIR!VYxIijCZsebOoSAA7aowPzFyhZQo8hXj_JwCKaJQttY

При нажатии на share там даже опция появляется, вставить ключик в хэш или скопировать отдельно (и тогда ссылка будет просто https://mega.co.nz/#!MANgUBIR)
хых, ну тогда прикольно получилось ) решение напрашивалось )
Начал писать этот же комментарий. Хорошо, что глянул двумя строчками выше и заметил ваш. Вот для полноты ссылка на JS AES.
чтоб не палить данные в access логе — используем POST
смысл в том чтобы послать эту ссылку человеку.
log_format postdata $request_body;
мне кажется не суть, ну возьмет он из access логов вторую половину ключа а первую из кода, раз уж добрался. Разделение этого ключа на 2 части ничего не решает.

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

Так я ведь об этом и говорю, я подумал что вы предлагаете хранить ключ полностью на сервере и решил пояснить.
После шифрования ключ делится на две половинки, одна из которых сохраняется в БД вместе с зашифрованными данными, а вторая половинка встраивается в ссылку, которая отдаётся клиенту


Получается, что после взлома неизвестная часть ключа содержит в два раза меньше бит, чем исходный. Насколько это устойчиво к brute-force?
Может имеет смысл не делить ключ, а «удваивать» его: один в базе, другой передавать через url?
На самом деле, имеет смысл передавать ключ целиком, не храня ничего в базе.
Вопрос к автору: ловит ли он заходы по ссылкам сервисов передачи сообщений?
Некоторые сервисы, например ВК, Фейсбук (даже gmail раньше) забирали заголовки, или весь контент с посланной через них ссылки (для удобства пользователя конечно)
Да, специально для этого сделал подтверждение просмотра, раньше ссылка неожиданно протухала, если её передавали через ВКонтакте или подобные сервисы.
т.е. в логах сервера ссылка появляется раньше чем ее открывают (для конкретных случаев). В таком варианте использовать hash (location#hash) куда правильнее. А при подтверждении уже POST-ом отдавать данные.
Как насчет guid в качестве первичного ключа использовать?

Интересно, а если добавить возможность еще установить время начала действия ссылки, чтобы нельзя было раньше времени ей воспользоваться, это бы предотвратило преждевременный перехват
Плохо — функции создания guid тоже предсказуемы, хотя и менее, чем rand()
Копировать ссылку потом неудобно. JS'ом сделайте, чтобы при нажатии на блок с ссылкой она выделялась полностью. Замените code на disabled input и добавьте такой скрипт (jQuery у вас подключен как я понял):

$('input[type="text"]').click(function() {
    $(this).select();
});
При редиректе с HTTP на HTTPS отсутствует заголовок HSTS

HTTP/1.1 302 Found
Date: Wed, 22 Jan 2014 11:56:52 GMT
Server: Apache/2.2.15 (Red Hat) mod_rpaf/0.6 DAV/2 PHP/5.3.27
X-Powered-By: PHP/5.3.27
Location: https://secureshare.pw/
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Connection: close
Note: The Strict-Transport-Security header is ignored by the browser when your site is accessed using HTTP; this is because an attacker may intercept HTTP connections and inject the header or remove it. When your site is accessed over HTTPS with no certificate errors, the browser knows your site is HTTPS capable and will honor the Strict-Transport-Security header.
Впрочем, этот заголовок в HTTPS-версии тоже отсутствует
HTTP/1.1 200 OK
Server: nginx/0.7.65
Date: Wed, 22 Jan 2014 12:12:43 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/5.3.27
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 6324
Секьюрно, так до конца — нужен csrf токен в форму сабмита + anti-clickjacking хидер :)
http://vk.com/app3406095 => https://secureshare.pw/s/2105e613792d1b1d938097ce7a90808a6da9f8325089e367e82d7ac3
Сократил, спасибо. Понимаю, секюрно, все дела, но для сервиса коротких ссылок слишком длинно.

А это и не является сервисом коротких ссылок…
хорошо бы еще придумать план монетизации…
Ну, так секреты же можно продавать :)
Поддерживаю. Zerobin например имеет открытый исходный код ;)
оффтоп
Мой друг занимается типографикой. На досуге он адаптировал афишу этого фильма на русский язык по всем правилам оригинала. Было это пять лет назад, поэтому ни разу не реклама.

Сжечь после прочтения


А то как выполнен официальный постер — стыд и позор.
Хороший стиль изложения у вас, понравилось. А на сайте хочется календарик для ввода дат :)
Далеко не новая и определенно не заслуживающая такого внимания тема. Уже довольно продолжительное время существует, например, Privnote, у которого ко всему прочему и шифрование осуществляется на стороне клиента, а ключ передается в качестве хеша в URL.
Сделайте фичу, что ссылка удаляется только через минуту. А то при любой технической проблеме у пользователя вроде случайно глюканувшего 3G будет недогруженная страница (без данных) и удалённая запись в БД.
… Лучше и правильней чтобы удаление происходило по AJAX по загрузке страницы.
Ох уж этот веб 2.0… AJAX может и не отработать, параноик зачастую что-нибудь типа NoScript использует.
FYI: StartSSL.com раздаёт Class 1 сертификаты бесплатно.
НЛО прилетело и опубликовало эту надпись здесь
Заметил в статье пассивную рекламу 2 сайтов с пиратским контентом. Вы чего, майл.ру?
спасибо, не заметили
Шестой подход:
Переносим шифрование не клиентскую сторону.
Почему не работает?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий