Comments 81
Наверняка сервис найдёт своих пользователей, а параноики на то и параноики.
Ещё файлик атачить можно было бы…
Ещё файлик атачить можно было бы…
Настоящий параноик таким сервисом пользоваться не станет. Где гарантия, что данные действительно удаляются после просмотра?
Это я и имел ввиду что параноикам не прокатит, а кто-то другой наверняка заинтересуется.
Исходники на github, дать поставить у себя, потискать, попытаться взломать — успокоиться и юзать свою копию/разочароваться и дать фидбэк.
Кто мешает выложить на гитхаб исходники, а юзать на сервере форк?
Даже если на сервере не форк, то удалится информация или нет сильно зависит от СУБД.
Большинство СУБД не удаляют информацию (я уж молчу про затирание) по запросу DELETE, а только ставят в записи пометку, что она удалена. Таким образом обеспечивается её отсутствие в выдаче по какому-либо запросу. При наличии физического доступа к серверу все записи в БД можно будет восстановить.
Большинство СУБД не удаляют информацию (я уж молчу про затирание) по запросу DELETE, а только ставят в записи пометку, что она удалена. Таким образом обеспечивается её отсутствие в выдаче по какому-либо запросу. При наличии физического доступа к серверу все записи в БД можно будет восстановить.
Зашифруйте отправляемые данные, пароль передайте по телефону после скачивания по ссылке
Гарантию, конечно, обеспечить сложно. Можно предложить человеку пользоваться несколькими независимыми каналами передачи данных, одним из которых может стать secureshare. Например, если Вы передаёте реквизиты доступа к серверу по ssh, то логин можно передать в письме или смс, а хост и пароль — в одноразовой ссылке.
Файлики — одна из приоритетных задач на ближайшее время, скоро будет
UFO just landed and posted this here
Вы совершенно правы, генерировать хеш или случайную строку — в данном случае всё равно. Теоретически, если генерировать строку той же длины из б0льшего алфавита (не 0-9a-f, а, скажем, A-Za-z0-9), то возможных сочетаний получается больше и вероятность случайно угадать хеш снижается. Но на практике оба этих варианта обеспечивают достаточную устойчивость к перебору.
UFO just landed and posted this here
Я имел в виду не брать хеш от случайного числа, а именно генерировать случайную строку. То есть, иными словами, генерить число в 62-ричной системе (если используем алфавит A-Za-z0-9). Таким образом, если хеш, как сейчас, будет 40 байт, то различных вариантов будет 62^40. Согласитесь, это больше чем RAND_MAX :-)
rand вообще-то не особо случайные числа выдает, /dev/random куда лучше, да и размер не ограничен, берите сколько нужно.
Так вы от этой случайной строки хеш берете или нет? Если берёте — то не надо, это ничего не улучшит. Если не берёте — то не называйте её хешом.
А если посолить?
UUID4
нет, вероятность коллизии с использованием хеш-функции — больше
UFO just landed and posted this here
Удаление действительно нельзя считать достаточно надёжным, но примите во внимание то, что в базе хранятся зашифрованные данные. Если злоумышленнику удастся восстановить удалённые данные, то он получит лишь кусок мусора. Для расшифровки нужен ключ, а в базе хранится только его часть.
Если у злоумышленника нет второй половинки ключа, то и ссылку нет нужды делать одноразовой :)
Изначальная идея была все же что даже если злоумышленник получит со временем эту половинку, то открыть ссылку все равно не сможет. Впрочем это уже мелочи.
Изначальная идея была все же что даже если злоумышленник получит со временем эту половинку, то открыть ссылку все равно не сможет. Впрочем это уже мелочи.
Ну тут злоумышленник получит доступ к ссылке если он украдёт вторую половинку ключа И получит доступ к базе И СУБД к тому времени ещё не перезатрёт удаленную первую половинку.
Следует различать атаку на пользователя (прочитали почту, увидели ссылку, хотим прочитать конкретное сообщение) и атаку на сервис в целом (влозмали сервер, хотим прочитать все сообщения).
Это вариант атаки на пользователя, просто он включает в себя нетривиальный шаг по получению доступа к сервису. Это нормально для рассмотрения криптографических схем. Например 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 никуда не уйдет из браузера (в логи апача, провайдера и тп)
Если уж параноить тут можно так сделать еще интереснее:
анкор (хэш) урлы не уходят из браузера. Браузер при переходе вот по такой урле http://habrahabr.ru/#search_form отшлет на сервер get запрос только habrahabr.ru/
Это можно заюзать таким образом. Оставляем всю вашу схему с серверным шифрованием но перед этим еще и шифруем на клиенте (в браузере перед отправкой на сервер). Ключик клиентского шифрования пока храним в браузере. После того как сервер вернул сгенеренную урлу, дописываем ключ клиентского шифрования через хэш:
secureshare.pw/s/617cde716b6f4bfb34...#client_side_secret_password
теперь все стало еще сложнее потому как client_side_secret_password никуда не уйдет из браузера (в логи апача, провайдера и тп)
Поздравляю, вы только что придумали mega.co.nz
ну клиентское шифрование — чего такого ) Наверняка Mega не хранит ключик в хэш урле. Тут фишка именно в том чтобы без регисрации и паролей придумать самый секьюрный способ передачи данных через веб сервис
Начал писать этот же комментарий. Хорошо, что глянул двумя строчками выше и заметил ваш. Вот для полноты ссылка на JS AES.
чтоб не палить данные в access логе — используем POST
мне кажется не суть, ну возьмет он из access логов вторую половину ключа а первую из кода, раз уж добрался. Разделение этого ключа на 2 части ничего не решает.
Суть в том, что если злоумышленник будет знать вторую часть ключа из ссылки, то он сможет посмотреть только данные доступные по ссылке, остальные данные, которые хранятся в БД он узнать не сможет.
После шифрования ключ делится на две половинки, одна из которых сохраняется в БД вместе с зашифрованными данными, а вторая половинка встраивается в ссылку, которая отдаётся клиенту
Получается, что после взлома неизвестная часть ключа содержит в два раза меньше бит, чем исходный. Насколько это устойчиво к brute-force?
Может имеет смысл не делить ключ, а «удваивать» его: один в базе, другой передавать через url?
Вопрос к автору: ловит ли он заходы по ссылкам сервисов передачи сообщений?
Некоторые сервисы, например ВК, Фейсбук (даже gmail раньше) забирали заголовки, или весь контент с посланной через них ссылки (для удобства пользователя конечно)
Некоторые сервисы, например ВК, Фейсбук (даже gmail раньше) забирали заголовки, или весь контент с посланной через них ссылки (для удобства пользователя конечно)
Как насчет guid в качестве первичного ключа использовать?
Интересно, а если добавить возможность еще установить время начала действия ссылки, чтобы нельзя было раньше времени ей воспользоваться, это бы предотвратило преждевременный перехват
Интересно, а если добавить возможность еще установить время начала действия ссылки, чтобы нельзя было раньше времени ей воспользоваться, это бы предотвратило преждевременный перехват
Копировать ссылку потом неудобно. 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Сократил, спасибо. Понимаю, секюрно, все дела, но для сервиса коротких ссылок слишком длинно.
хорошо бы еще придумать план монетизации…
Исходник можно посмотреть? Если вы делаете хеш обычной блочной функцией, а не специально предназначенным для этого HMAC, будьте осторожны с подводными камнями.
Поддерживаю. Zerobin например имеет открытый исходный код ;)
Есть перевод на хабре habrahabr.ru/post/181372/
оффтоп
Мой друг занимается типографикой. На досуге он адаптировал афишу этого фильма на русский язык по всем правилам оригинала. Было это пять лет назад, поэтому ни разу не реклама.
А то как выполнен официальный постер — стыд и позор.
Мой друг занимается типографикой. На досуге он адаптировал афишу этого фильма на русский язык по всем правилам оригинала. Было это пять лет назад, поэтому ни разу не реклама.
Сжечь после прочтения
А то как выполнен официальный постер — стыд и позор.
Хороший стиль изложения у вас, понравилось. А на сайте хочется календарик для ввода дат :)
Далеко не новая и определенно не заслуживающая такого внимания тема. Уже довольно продолжительное время существует, например, Privnote, у которого ко всему прочему и шифрование осуществляется на стороне клиента, а ключ передается в качестве хеша в URL.
Сделайте фичу, что ссылка удаляется только через минуту. А то при любой технической проблеме у пользователя вроде случайно глюканувшего 3G будет недогруженная страница (без данных) и удалённая запись в БД.
FYI: StartSSL.com раздаёт Class 1 сертификаты бесплатно.
UFO just landed and posted this here
Заметил в статье пассивную рекламу 2 сайтов с пиратским контентом. Вы чего, майл.ру?
Шестой подход:
Переносим шифрование не клиентскую сторону.
Переносим шифрование не клиентскую сторону.
Почему не работает?
Sign up to leave a comment.
После прочтения сжечь