Я закончил разработку приложения для Android и собираюсь опубликовать его под лицензией GPL - я хочу, чтобы оно было с открытым исходным кодом. Однако природа приложения (игры) заключается в том, что оно задает загадки и кодирует ответы в строковом ресурсе. Я не могу опубликовать ответы! Мне сказали, чтобы посмотреть на безопасное хранение паролей - но я не нашел ничего подходящего.
Можно ли опубликовать мой исходный код со строковым массивом, скрытым, зашифрованным или иным образом скрытым? Может быть, читая ответы из онлайн-базы данных?
Обновить
Решение Ювала Фильмуса ниже сработало. Когда я впервые прочитал это, я все еще не был уверен, как это сделать. Я нашел несколько решений для второго варианта: хранить хешированное решение в источнике и вычислять хеш каждый раз, когда пользователь угадывает. Для этого в JavaScript есть библиотека crypto-js по адресу http://code.google.com/p/crypto-js/ . Для Android используйте функцию MessageDigest . Существует приложение (на fdroid / github) под названием HashPass, которое делает это.
Ответы:
У вас есть как минимум два варианта, в зависимости от того, какую проблему вы хотите решить.
Если вы хотите, чтобы невинные читатели вашего кода не получили непреднамеренные ответы, или вы, по крайней мере, хотите сделать это немного сложным, чтобы пользователи не поддавались искушению, вы можете зашифровать решения и сохранить ключ как часть вашего кода, возможно, результат некоторых вычислений (чтобы сделать его еще сложнее).
Если вы хотите запретить пользователям получать ответ, вы можете использовать одностороннюю функцию или, на жаргоне компьютера, хеш-функцию . Сохраните хэш ответа, и вы сможете проверить, является ли ответ правильным, без возможности вывести ответ вообще, не найдя его сначала. Недостатком этого является то, что проверять ответ, который близок к правильному ответу, сложнее , хотя даже для этой проблемы есть некоторые решения.
источник
У вас есть
дваварианта:Храните ответы отдельно от остальной части исходного кода
Если вы хотите, чтобы ваш код был с открытым исходным кодом, но не хотите, чтобы ответы были с открытым исходным кодом, то вы открываете исходный код для приложения без вопросов и ответов, при этом вопросы и ответы являются отдельным «плагином» с закрытым исходным кодом. или файл данных. Ваше Android-приложение объединит их в одно приложение.
Положите ответы в свой исходный код
В качестве альтернативы, если вы считаете, что вопросы и ответы являются основной частью того, что вы хотите, с открытым исходным кодом, то вам следует поместить ответы в исходный код, желательно не обфусцированный, чтобы другие могли прочитать и изменить их . Запутывание исходного кода, чтобы его нельзя было понять и изменить, на самом деле не соответствует принципам открытого исходного кода.
Разместите ответы на сервере в интернете
С обоими вышеупомянутыми решениями кто-то, кто загрузил ваше приложение, может найти ответы без воспроизведения вашей программы в любом случае - независимо от того, как вы запутываете / шифруете свои ответы, если ваша программа может идентифицировать ответ без дополнительной информации, поэтому может ли человек исследовать ваше скомпилированное приложение.
Если вы действительно хотите убедиться, что никто не может найти ответы, тогда единственная реальная возможность - не давать им ответы, а заставить приложение вызывать веб-сервис и т. Д. ... всякий раз, когда они хотят знать ответ. Приложение должно отправить ответ, введенный пользователем, и веб-служба должна сообщить приложению, является ли ответ правильным или нет, таким образом, пользователь не может сказать, что это за ответ, до тех пор, пока у него уже нет правильного ответа (короткий веб-службы, которые вы можете обнаружить и защитить от перебора).
Если вы ищете способы запутать ваши ответы, то это наводит меня на мысль, что вы на самом деле не хотите открывать исходные ответы, поэтому вам следует рассмотреть первые варианты.
Если крайне важно , чтобы пользователь не смог заранее найти ответ, тогда третий вариант - ваш единственный реальный выбор, однако я изо всех сил пытаюсь придумать сценарий, в котором это стоило бы усилий, не в последнюю очередь потому, что это мешает вашим пользователям. от использования вашего приложения без подключения к Интернету.
источник
Если цель состоит в том, чтобы скрыть строки от случайного чтения исходного кода, но оставить их открытыми, чтобы другие люди могли легко вносить свои собственные изменения - например, если вы публиковали исходный текст в текстовом приключении и не хотели, чтобы появлялся какой-либо описательный текст который будет представлять собой спойлер, а затем использовать нечто обратимое, как rot13.
Фактически, вы можете сгнить 13 всех ваших файлов перевода и перевернуть их на лету.
Это держит открытый дух. Случайные «волшебные» хеши не очень удобны для программистов.
источник
Открытый исходный код требует обнародования и доступности исходного кода, а не игровых данных. Таким образом, вы можете легко поместить данные в другой файл и не публиковать его. Добавьте немного шифрования, если вы хотите предотвратить случайное чтение файла. Я сомневаюсь, что для вашего приложения нужна сильная криптография.
источник
Зачем вам хранить ответы в исходном коде GPL, если вы не хотите, чтобы их знали пользователи? Даже если они не известны или их легко взломать сейчас, они могут (и, вероятно, будут) в будущем.
Вместо того, чтобы хранить их в своем приложении, используйте внешнюю базу данных. Сделайте небольшой веб-сервис, который сравнивает ответы с тем, что находится в вашей базе данных. Затем позвольте вашему приложению обращаться к этому веб-сервису всякий раз, когда оно должно подтвердить. Основная проблема заключается в том, что, поскольку для этого требуется доступ в Интернет, вы потеряете некоторую скорость и потенциальную базу пользователей. Ваша лицензия на приложение должна применяться только для самого приложения, а не для веб-службы.
Вы также можете просто поместить свои ответы в небольшую базу данных и поместить их в свою программу. Насколько я знаю, GPL применяется только к исходному коду, а не к данным, которые хранит ваше приложение. Хотя я могу ошибаться в этом.
источник
Помните, что даже если вы храните базу данных на удаленном веб-сервере, ее можно дублировать, просто записав все правильные пары ключ / значение, которые были замечены. И вообще говоря, мобильные приложения должны стараться не давать ошибок или перестать функционировать, потому что сеть не работает (используйте обмен сообщениями в очереди и «обновляйте, когда можете»).
Поэтому, если вам нужна локальная база данных, но вам не нравится идея, что она будет явно дешифрована, вы можете использовать фильтр Блума (чтобы не общаться с сетью или иметь локальную расшифрованную базу данных). Так работали средства проверки орфографии, когда места в памяти было очень мало.
Итак, если вы добавите пары вопросов / ответов в фильтр, например:
Если вы спросите, есть ли в наборе «Капитолий Вирджинии? Ричмонд», он либо ответит «определенно нет», либо «почти наверняка да». Если вы получаете слишком много ложных срабатываний, увеличьте базу данных.
Вы могли бы иметь огромную базу данных в крошечном пространстве, предполагая, что пользователь будет писать вопрос и ответ точно так, как вы ожидаете. Небольшое сохранение базы данных помогает с обновлениями, потому что они, вероятно, должны быть переданы по беспроводным сетям.
источник