Comments 18
Я чего-то не понимаю, или вместо всего этого можно было бы использовать стандартный HTTPS???
И, в-третьих, на сервер могут быть произведены хакерские атаки, что позволит злоумышленникам похитить информацию, либо недобросовестный администратор сервера воспользуется ею в личных целяхЭто тоже сомнительная выгода перед HTTPS, т.к. очень сложно доказать широким массам пользователей, что ваша реализация JS-шифрования не содержит уязвимостей и бэкдоров.
Когда вся обработка информации происходит на сервере, пользователи точно не уверены, что там данные хранятся действительно в зашифрованном виде. Если же обработка происходит у них, то это можно проверить, изучив JS-код. Согласен, обычный пользователь вряд ли знаком с этим. Но люди, которые будут использовать это на серьёзном уровне (работа с информацией, защищённой авторским правом, например), думаю, могут себе позволить найти людей, которые проверят отсутствие всякой нечисти в коде. Плюс, если нет доверия стандартным алгоритмам шифрования, можно подключить свои. Насчёт HTTPS — никто не запрещает использовать его в связке с предложенным способом.
Причём тут HTTPS? Автор решал вообще другую задачу — чтобы данные на стороне получателя (сервера) были уже зашифрованы, а значит они должны попадать в передачу уже зашифрованными. Для этого автор и пытается реализовать некий алгоритм на стороне клиента.
Эээ, а в сторону нормальных алгоритмов шифрования смотреть не пробовали?
Есть например Stanford Javascript Crypto Library. Работает достаточно шустро.
Есть например Stanford Javascript Crypto Library. Работает достаточно шустро.
Упор был на том, чтобы обработка данных производилась на стороне клиента. Реализация конкретных методов шифрования (будь то банальное XOR-шифрование или использование методов указанной Вами библиотеки) в данном случае не столь важна, потому что их легко подключать и отключать при необходимости простой заменой функции шифрования в коде.
Э… А в чем смысл этих манипуляций? Хакер будет настолько ленив, что даже не станет смотреть в Javascript-код?
Конечно, не лень. Но, как минимум, ему нужно будет узнать ключ, используемый для шифрования. Плюс, пользователю можно предложить возможность выбора алгоритма из нескольких. То есть, хакеру нужно будет узнать не только ключ, но и метод шифрования, который использовал конкретный пользователь для конкретной информации.
Ключ он найдет на странице в открытом виде. Алгоритм шифрования он узнает, читая Javascript-код. Потратит он на это сильно меньше времени, чем потрачено на написание шифровального кода ))))
Ключ он узнает с помощью сниффера клавиатуры или как?
А, так ключ вводит пользователь. Да, ломать будет чуток сложнее. Сначала хакер скачает файл (который, видимо, ничем, кроме пароля, не защищен?). Потом в зависимости от типа файла будет искать текст для дешифрования. Например, для JPEG картинок он поищет строку JFIF.
Кстати, а как пользователь узнает, что файл расшифрован правильно?
В принципе, схема имеет право на жизнь, но она сильно слабее, скажем, клиентских сертификатов.
Кстати, а как пользователь узнает, что файл расшифрован правильно?
В принципе, схема имеет право на жизнь, но она сильно слабее, скажем, клиентских сертификатов.
Да, файл хранится на сервере зашифрованным с помощью ключа. Если выбирать достаточно сложные алгоритмы, то и взломать его будет сложно.
Насчёт правильности расшифровки — думаю, пользователь, шифруя данные и запоминая ключ, знает, как они выглядят изначально. Честно говоря, я не уверен, что какая-либо существующая технология/схема защиты информации может обеспечить 100% надёжность. Но описанная мной схема как отдельная часть системы защиты информации вполне жизнеспособна.
Насчёт правильности расшифровки — думаю, пользователь, шифруя данные и запоминая ключ, знает, как они выглядят изначально. Честно говоря, я не уверен, что какая-либо существующая технология/схема защиты информации может обеспечить 100% надёжность. Но описанная мной схема как отдельная часть системы защиты информации вполне жизнеспособна.
Жесть-то какая, просто слов нет.
особенно:
какой смысл шифровать почти в полтора раза больше данных?
Да и вообще все эти криптографии на базе js — это так, поиграться.
Нужно шифрование — используйте https и не выпендривайтесь.
Пользователь ведь никогда не будет уверен в том, что js, загруженный как-бы с вашего сайта будет что-то расшифровывать, а не просто сольёт ваши пароли/куки/данные нехорошим людям.
особенно:
кодируем в формат Base64
шифруем с помощью функций Java Script
какой смысл шифровать почти в полтора раза больше данных?
Да и вообще все эти криптографии на базе js — это так, поиграться.
Нужно шифрование — используйте https и не выпендривайтесь.
Пользователь ведь никогда не будет уверен в том, что js, загруженный как-бы с вашего сайта будет что-то расшифровывать, а не просто сольёт ваши пароли/куки/данные нехорошим людям.
Это, конечно интересно. Но если применять это на практике остаётся вопрос о хранении ключа (уже не помню какой длины должен быть ключ того же RSA, но она точно больше, чем может запомнить человек). Допустим, вы решили не использовать https, и генерировать какой-нибудь ключ рандомно. Юзать локалсторадж (кукисы и пр.) не вариант по двум причинам:
1. Кулхацкер может включить ваш компьютер и посмотреть ключ (человеческий фактор)
2. На другой машине вы не сможете это расшифровать, не зная своего ключа. Это касается и обычной переустановки браузера.
Можно использовать какой-нибудь удаленный сервер аутентификации, который по запросу отдаст вам ваш ключ, но здесь придется юзать тот же https.
И да, нет такого языка, как Java Script. Есть Javascript одним словом.
Вы случайно в институте преподом не работаете (исходя из «важности» заголовка)?
1. Кулхацкер может включить ваш компьютер и посмотреть ключ (человеческий фактор)
2. На другой машине вы не сможете это расшифровать, не зная своего ключа. Это касается и обычной переустановки браузера.
Можно использовать какой-нибудь удаленный сервер аутентификации, который по запросу отдаст вам ваш ключ, но здесь придется юзать тот же https.
И да, нет такого языка, как Java Script. Есть Javascript одним словом.
Вы случайно в институте преподом не работаете (исходя из «важности» заголовка)?
Хранение ключа планировалось только в голове у пользователя, как обычный пароль. Думаю, ничто не мешает налету делать из легко запоминаемого пароля криптостойкий ключ нужной длины. И, как я писал выше, никто не отменяет связку описанной мной схемы и htpps.
Про «Javascript» запомню, спасибо. Преподом не работаю, хотя название, согласен, звучит академически.
Про «Javascript» запомню, спасибо. Преподом не работаю, хотя название, согласен, звучит академически.
Гляньте вот этот пост, может Cryptico.js пригодится.
Неплохая попытка, но метод шифрования откровенно слаб. Глядя в код
заключаем, что от ключа используется только последний байт. Ключ достаточно быстро получаем двумя способами:
Способ 1. Получаем 256 вариантов расшифровки и выбираем нужный.
Способ 2. Если хочется немного поразгадывать ребус — частотный анализ.
Поэтому рекомендации использовать готовые библиотеки справедливы. Советы использовать HTTPS — несправедливы, так как решается совсем другая задача.
Кроме того, вот в этом случае:
ничто не мешает недобросовестному администратору добавить свой код в Ваш скрипт.
var newRes = new Int8Array(newResult);
...
result[i] = arr[i] - parseInt(keyForDecrypt, 10);
заключаем, что от ключа используется только последний байт. Ключ достаточно быстро получаем двумя способами:
Способ 1. Получаем 256 вариантов расшифровки и выбираем нужный.
Способ 2. Если хочется немного поразгадывать ребус — частотный анализ.
Поэтому рекомендации использовать готовые библиотеки справедливы. Советы использовать HTTPS — несправедливы, так как решается совсем другая задача.
Кроме того, вот в этом случае:
либо недобросовестный администратор сервера воспользуется ею в личных целях
ничто не мешает недобросовестному администратору добавить свой код в Ваш скрипт.
Sign up to leave a comment.
Шифрование/дешифрование данных на стороне клиента в web-ориентированных системах