1. Решение для сайтов-анонимайзеров
    -----
    Обновлен скрипт для ограничение доступа работникам госорганов: http://roscenzura.com/threads/713/
    -----
    Наш реестр запрещенных сайтов с широким функционалом.
    -----
    Кто захламляет реестр запрещенных сайтов?
    Скрыть объявление

secserv.me, анонимный чат

Тема в разделе 'Анонимность в сети', создана пользователем Алексаня Тюрик, 10 июн 2016.

  1. Алексаня Тюрик

    Алексаня Тюрик Ч0ткий!

    Симпатии:
    16
    Репутация:
    0
    Нашел сервис secserv.me

    От похожих ресурсов мы отличаемся:
    - у нас нет никакой веб-аналитики в коде страниц
    - используем HTTPS AES 256 encryption RSA 2048 bit
    - возможность шифровать документы и фото размером до 7MB
    - не храним пароль на сервере — ссылку с пассфразой нельзя открыть больше, чем в 1 вкладке!
    - для создания ключа используем random data браузера, randoma data сервера, фраза-пароль и алгоритм Fortuna PRNG (pool of unique random data) — конкуренты используют random data браузера,который можно подобрать.
    - возможность ОТКРЫТИЯ ссылки 1 раз вне зависимости от правильности ввода пароля — доказательство, что сервер не проверяет пароль на правильность.
    - разные сроки «жизни» ссылки до момента прочтения

    СЛАБЫЕ СТОРОНЫ ИСПОЛЬЗОВАНИЯ SECSERV.ME:
    Если у Вас слабая фраза пароль, то это первая возможность перехватить и расшифровать сообщение.
    Если у Вас вживлен кейлоггер или троян — то это вторая возможность перехватить сообщение.

    Код страниц абсолютно прозрачен для любых проверок.

    pgpru.com/forum/prakticheskajabezopasnostj/secservmeinteresnyjjproekt?show_comments=1&p=1#Comment76435 клирнет обзор
     
  2. Roscenzura.com

    Roscenzura.com Администратор Staff Member

    Симпатии:
    166
    Репутация:
    0
    Алексаня Тюрик нравится это.
  3. Vlad_CZ

    Vlad_CZ New Member

    Симпатии:
    0
    Репутация:
    0
    Хотелось бы поделиться последним обзором данной проблематики - не все такие сайты "безопасны" как они о себе пишут
    http://roscenzura.com/threads/1145/#post-3946
     
  4. Roscenzura.com

    Roscenzura.com Администратор Staff Member

    Симпатии:
    166
    Репутация:
    0
    А кто автор обзора? Просто если они не безопасны значит SSL не безопасен.
     
    Алексаня Тюрик нравится это.
  5. Vlad_CZ

    Vlad_CZ New Member

    Симпатии:
    0
    Репутация:
    0
    Я бы не хотел ставить под сомнение SSL хотя вот такое вполне с 1 августа будет и в РФ https://habrahabr.ru/post/272207/
    Но тут я хотел подметить особенность, что в привноуте и сексерве на сервер идет шифрованная инфа в отличии от "аналогов"
    Поэтому отличие остальных сервисов от гугла или вк нулевое - все они могут читать вашу переписку несмотря на SSL который только от 3 лиц защитит.
     
  6. Roscenzura.com

    Roscenzura.com Администратор Staff Member

    Симпатии:
    166
    Репутация:
    0
    А кто по вашему не может читать переписку?
    Гуглу это не надо, разве что только в особых случаев - слишком важна репутация. А остальным? Может ли сервис читать переписку или нет зависит только от его порядочности.
     
  7. Vlad_CZ

    Vlad_CZ New Member

    Симпатии:
    0
    Репутация:
    0
    Переписку читать не может тот кто не может ее читать технически )
    Порядочность тут не при чем ) какой смысл ломать сервер того сервиса, который действительно хранит всю информацию шифрованной? Ведь почему мы часто видим сливы всяких баз данных в сеть? Потому что в этом есть смысл их пытаться ломать - на серверах данные пользователей в открытом виде - но если же все внутри децентрализированно и скрыто - то смысла теряется это делать. Я не спорю, что завтра привноут или сексерв поменяют код сайтов и станут другуими - хранящими инфу в откыртом виде как гугл - но такими они могут стать или не стать, а вот onetimesecret и комания такими уже ЕСТЬ, хотя пишут что информация шифруется перед передачей на сервер - ЗАЧЕМ? Гугл не обманывает юзером тем, что заверяет об отсутствии возможности расшифровать переписку - они просто об этом молчат. Но странно декларировать одно - а если взглянуть на код - мы видим циничную ложь и провокацию )
    Вы никогда не сольете ту информацию к которой у вас не было доступа изначально)
    Зачем обещать что то не выдавать или не хранить если легче это просто не получать в таком виде - чтобы был толк ее запрашивать или мониторить?
     
  8. Roscenzura.com

    Roscenzura.com Администратор Staff Member

    Симпатии:
    166
    Репутация:
    0
    Просто я не понял к чему сказаны эти слова "который только от 3 лиц защитит". Собственно и задача любого анонимного сервиса защитить переписку от третьих лиц, остальное - вопрос доверия к сервису.
    Вы не можете ручаться, что сервис хранит информацию шифрованной. Может и хранит, но и ключи шифрования тоже хранятся на этом же сервере. Если пароль (хеш) от переписки является ключом - это надежнее.
    Но мы не можем знать наверняка как оно работает на стороне сервера.
     
  9. mimo

    mimo New Member

    Симпатии:
    0
    Репутация:
    0
    Я думаю, тут имеется ввиду, что есть сервисы, которые шифруют передаваемые данные только с помощью SSL - это шифрование канала клиент-сервер. В этом случае, сервер получает, а потом и передает данные в открытом виде (внутри SSL канала, конечно). По-этому, шифрует сервер данные, которые хранит, или нет - не имеет значения. Он должен хранить информацию так, чтобы иметь возможность расшифровать её для передачи, если нужно.

    В то же время, есть сервисы (privnote.com, secserv.me), в которых сообщения шифруются таким образом, что ключ к шифрованию не передается на сервер, соответственно сервер не имеет технической возможности их расшифровать. В этом случае сервер хранит данные в зашифрованном виде. Механизм передачи ключа - в адресной строке типа http(s)://service.com/...#encryption_key. Сервер не получает то, что находится после символа # (RFC 3986), а javascript-клиент имеет доступ к этой части адреса и использует её для расшифровки. Если нужно, сюда подмешивается пароль с помощью kdf. По такой схеме, защита от 3х лиц получается более эффективной.

    Про то, как узнать как конкретный сервис работает. Обычно, достаточно посмотреть на данные, которые передает сервис по сети. Если там пароль и текст, то очевидно, что сервис относится к первому типу. Если там абра-кадабра, то надо смотреть клиентский код - более простого варианта нет. Может быть криптография реализована криво. Либо доверится какому-то обзору.
     
    Last edited: 29 июл 2016

Поделиться этой страницей