Софт для безопасного общения URL shortener – идеальный бесплатный инструмент для сокращения URL, для преобразования длинных уродливых ссылок в красивые, запоминающиеся короткие URL - https://ls-la.cc File sharing – простой файлообменник для небольших файлов. Без регистрации и абсолютно бесплатно - https://ls-la.cc Secure message – ваши идеи только для Вас и Вашего собеседника - https://ls-la.cc Открыты для всех предложений и конструктивной критики, будем рады любому отзыву о наших сервисах: jabber: [email protected] (резервный: [email protected]) email: linky@ls-la.in Telegram: https://t.me/ls_la_cc
Здравствуйте. Будем рады рассмотреть варианты сотрудничества, идеи дальнейшего развития. Кому интересно обращайтесь по моим контактам: jabber: [email protected] (резервный: [email protected]) email: linky@ls-la.in Telegram: https://t.me/ls_la_cc
На эту , тему тоже есть некоторые соображения.А, что если делать на основе ВК,к примеру где- то там в закрытой группе писать и удалять записи - но,уж не в пустой естественно.Важно удаление ,востановление с заданной периодичностью.
ls-la.cc Очень прост в использовании Убедись в этом сам! По всем вопросам пиши нам: jabber: [email protected] (резервный: [email protected]) email: linky@ls-la.in Telegram: https://t.me/ls_la_cc
Ссылки, картинки и сообщения также можно конвертировать в QR-код. Попробуй и убедись насколько это удобно По всем вопросам пиши нам: jabber: [email protected] (резервный: [email protected]) email: [email protected] Telegram: https://t.me/ls_la_cc
Проще некуда! По всем вопросам пиши нам: jabber: [email protected] (резервный: [email protected]) email: [email protected] Telegram: https://t.me/ls_la_cc
После первого же перехода по ссылке, информация удаляется на стороне сервера. Поэтому, перейти по сгенерированной ссылке второй раз - невозможно. Это значит, что мы не имеем технической возможности видеть ваши ссылки и сообщения, и как результат, не можем передать ваши данные третьим лицам. Кроме того, у Вас есть возможность ставить на сообщение пароль, который будет захеширован системой, внутри системы пароль существует только в виде хэша и не хранится в открытом виде, поэтому узнать мы его не можем. По всем вопросам пиши нам: jabber: [email protected] (резервный: [email protected]) email: [email protected] Telegram: https://t.me/ls_la_cc
В Новом году - скоро обновления! А также будем рады рассмотреть варианты сотрудничества и идеи дальнейшего развития. Кому интересно обращайтесь по моим контактам: jabber: [email protected] (резервный: [email protected]) email: linky@ls-la.in Telegram: https://t.me/ls_la_cc
На ls-la.cc сейчас возможно загрузить изображение не больше 100kb По всем вопросам пиши нам: jabber: [email protected] (резервный: [email protected]) email: [email protected] Telegram: https://t.me/ls_la_cc
Похвально, однако, есть несколько особенностей, которые не позволяют назвать ваш сервис хотя бы немного безопасным: Нет никаких строгих гарантий что ваши слова соответствуют действительности (в части хранения только хешей паролей, удаления информации после прочтения адресатом и т.д.). Слова и обещания это хорошо, но нужна вполне определенная математическая доказуемость, ни на что другое опираться в контексте разрабатываемых вами сервисов невозможно; Невозможность прочтения сообщений администрацией сервиса как следствие того что она удаляется после первого перехода по ссылке — явное лукавство, ибо вы, как оператор хранилища, можете просмотреть эту информацию и любым другим доступным способом. Таким образом, администрация сервиса потенциально может читать файлы и сообщения, равно как и человек который скомпрометировал вашу файловую систему / сервисы целиком. Чтобы устранить замечания выше, навскидку могу предложить лишь одно средство: end-to-end encryption. А вот реализация может быть уже различна. Тем не менее, принимая во внимание следующее: Искомое шифрование должно работать исключительно на клиенте; Ваши решения позиционируются как веб-сервисы. Естественным образом напрашивается вариант реализации на JavaScript, как самом популярном языке программирования для сценариев в браузерах (и не зря, текущие стандарты ECMAScript весьма неплохи). Подводя итоги своих замечаний, резюмирую: если вы правда хотите сделать безопасное средство с заявленным функционалом, то вам стоит, как минимум: Генерировать сложный ключ на клиенте. Одного достаточно — по причине достаточности симметричного шифрования в данном случае, никакие открытые ключи потенциально не требуются; Шифровать с помощью вышеуказанного ключа файлы/сообщения от пользователя на этом же клиенте, т.е. непосредственно в браузере (см. современные безопасные алгоритмы симметричного шифрования); Только после этого отправлять данные на сервер. Лишь в этом случае строго гарантируется что сырых данных не увидит как никто посередине, так и администрация сервиса (в хранилище и транспорте будет видна только зашифрованная "каша"); Само собой, ключ отдаётся пользователю в браузере (и не передаётся на сервер — в этом пользователь сможет убедиться путем мониторинга траффика средствами Network, которые доступны в любом современном браузере. Более того, он сможет самостоятельно изучить JS код и проверить на предмет вредоносных манипуляций, ведь он (исходный код шифрования) доступен на клиенте); Всё это при желании можно оснастить дополнительным паролем с проверкой на бэкенде, который у вас сейчас уже "реализован" (надеюсь, хеши в нём у вас не MD5) — правда смысла уже сильного нет, т.к. с помощью примеси контрольной строки в начале/конце сообщения/файла можно понять что ключ был верный (и это не единственный метод). Более того, достаточно генерировать ссылки на файлы/сообщения с использованием guid либо иного сложного уникального идентификатора, а не последовательного int/long — тогда никто и не сможет подобрать так просто ссылку; Дешифрование происходит аналогично — строго на клиенте. Что очевидно. По поводу скорости такого решения можно не переживать, даже для файлов. С вашими объёмами (до 100КБ) всё будет происходить со свистом, а вы избавите серверные ресурсы от доп. нагрузки (ведь теперь они потребуются лишь для хранения). Вся эта схема некоторым образом похожа на хранение архива со сложным паролем на каком-нибудь общедоступном файлообменнике — вполне себе сносное решение с точки зрения безопасности (ведь шифровали архив на клиенте, да и алгоритм тоже был симметричный). А приятная особенность в том, что юзабилити от этого ни сколько не пострадает. Да и если сервер будет скомпрометирован злоумышленниками то они не смогут извлечь сырую полезную информацию из уже находящихся там данных (равно как и вы в лице администрации). Ещё неплохо бы дать возможность пользователю вводить ключ самостоятельно (но строго ограничить его хорошей политикой по сложности ключа). Также неплохо делать padding сообщений/файлов до фиксированной длины на клиенте (до шифрования), чтобы в хранилище они занимали ~одинаковый объем, что исключит всяческие "догадки" о содержимом.
Большое спасибо за Ваш отзыв и отличный совет! Будем использовать эти рекомендации для улучшения этого проекта!
Открыты для всех предложений и конструктивной критики, будем рады любому отзыву о наших сервисах: jabber: [email protected] (резервный: [email protected]) email: linky@ls-la.in Telegram: https://t.me/ls_la_cc
ls-la.cc Удобный, анонимный и быстрый конвертер ссылок, изображений и сообщений с установкой пароля. Конвертированную ссылку можно открыть всего один раз, все для вашей анонимности! jabber: [email protected] (резервный: [email protected]) email: [email protected] Telegram: https://t.me/ls_la_cc
jabber: [email protected] (резервный: [email protected]) email: [email protected] Telegram: https://t.me/ls_la_cc
