Защита HTML5 кеша (localStorage)?

Что бы защитить приложение. Таким образов, код будет недоступен конечному пользователю. Соединение тоже недоступно для просмотра. Он будет иметь доступ только к единственному узкому месту - файловой системе. Необходимо как-то защитить эти файлы.

Griboks, я имел ввиду как это достигнуто

RidgeA, клиент со встроенным cef. Конечно же, абсолютной защиты нет, но 80% атак должно отразить.

Griboks, А что мешает воспользоваться эмулятором cef с полноценной машины и снифить соединение?

cicatrix, а что это за эмулятор такой?))

Griboks, учитывая, что cef - опенсорсный на базе хромиум, даже если сейчас нет такого эмулятора (в чём я сомневаюсь), но мне очень надо, то я его напишу.
Да и вообще, вы как отличаете, подключился к вам cef или обычный браузер?

cicatrix, никак. Точнее, там сложная система, но в двух словах: клиент - это сервер, а сервер - это клиент. Таким образом, невозможно создать подставной клиент.

Griboks, Ну вам виднее, только если злоумышленник контролирует машину с какой-либо стороны, разумно в модель угроз вводить предположение, что ему доступны все ресурсы этой машины. В принципе исходите из того, что соединение скомпрометировано - вся передаваемая информация доступна злоумышленнику, т. .к от man-in-the-middle вы не убережетесь никак.
Отсюда вывод - трафик должен быть зашифрован. Обмен ключами по протоколу Диффи-Хеллмана. Но в целом, это тоже не даёт 100% гарантии.

cicatrix, смысл текущей архитектуры в том, что внешние атаки на машину не имеют смысла. Необходимо только хорошо защитить само приложение и его "кеш".

Griboks, от чтения не защитите. Даже если кэш зашифрован, приложение должно располагать ключом для его расшифровки, следовательно, этот ключ будет так же доступен злоумышленнику. Получить его можно либо "подслушивая" трафик между клиентом и сервером, либо просканировав память компьютера, на котором выполняется приложение. Соответственно, расшифровав содержимое, злоумышленник так же может его изменить.
В целом, применяемая вами модель защиты, может и действенна на уровне домохозяек и "продвинутых пользователей", но не представляет абсолютно никакой защиты против целенаправленной атаки. Правило обычно простое - всё, что вы передаёте клиенту, доступно врагу. Секретные данные лучше хранить на сервере.

cicatrix, как же тогда защищать десктопные приложения?

Griboks, в целом - никак (я серьёзно). Мне не известно ни одно десктопное приложение, которое бы не было рано или поздно взломано (кроме, конечно, "неуловимых Джо", которые не взламывают не потому, что там сложная защита, а потому что это нахрен никому не надо).
Ваш программный код всегда можно загрузить в дебаггер и подвергнуть реверс-инжинирингу. Частично в этом помогает обфускация, но это лишь усложняет атаку, а не предотвращает её.
В компьютерной безопасности есть понятие "модель угроз". Защиты на 100% добиться невозможно никакими способами, поэтому определяют ключевые угрозы, от которых неободимо защищаться.
Например, модель "случайный доступ" - защита в виде пароля
модель "случайное прочтение" - защита в виде "звёздочек" при вводе пароля.
и т. д. от простого к сложному (именно так, потому что злоумышленник не будет дизассемблировать ваше приложение, если имеются более простые способы).
Вы не можете никак защитить приложение на десктопе, ваша задача - сделать взлом экономически не выгодным, когда затраты времени/ресурсов/денег не окупают ценности получаемой информации.
Если у вас клиент-серверная архитектура, ключевые данные лучше всего хранить на контролируемой и более безопасной стороне.

cicatrix, ну вот поэтому я и смотрю в сторону обычного приложения+js шифрования данных в открытом local storage.

Griboks, вполне возможно, что этого и достаточно. "Знайте своего врага", кто ваш злоумышленник, что он может, а что - нет, что ему нужно и пр. Понимание того, от кого именно вы защищаетесь - от спецслужб или от школьника, который хочет сжульничать в игре, сильно помогает в оптимизации затрат на защиту.

Спасибо, интересная штука. Вы пользовались? Смутил немного этот момент:

For the genration of such strings, secretPhrase is being used and can be found in code easily but that won't make it unsecure, PBKDF2's layer on top of that will handle security.

Griboks, нет, я не пользовался. Но думаю, если других альтернатив нет, то стоит попробовать.

Griboks, я думаю, можно не хранить secretPhrase в коде, а брать с сервера, но так, чтобы это было не заметно.