java constant против обратного проектирования байткода

Я хотел бы знать, могу ли я зашифровать строку внутри скомпилированного java-файла. Например, мне нужно декодировать почтовый файл с симметричным ключом, и мне нужно хранить этот ключ в классе Java в частной константе:java constant против обратного проектирования байткода

private static final String ZIP_PASSW="secret"

Но я не хочу, чтобы просто реверсивный байткодом показывает сырой пароль ... Как вы думаете, существует что-то, чтобы избежать этого?

Спасибо

PS: Я не могу понять, почему С.О. сказал, что мой вопрос не соответствует его стандартам без этого PS

источник

2012-06-11 Tobia

Я думаю, что это хороший вопрос, а в некоторых случаях асинхронный крипто (как все кричат, что это модное слово здесь) не поможет вам с этой проблемой. Например. когда вы хотите сохранить указанный пользователем пароль в своей базе данных приложений, который вам нужно получить в открытом виде, но вы не хотите хранить его в открытом тексте в db. Таким образом, ваше приложение должно быть в состоянии зашифровать И расшифровать его => у вас будет такая же проблема с ключом (соответственно два ключа для асинхронного шифрования), которые вам придется предоставить. Независимо от того, используете ли вы что-то синхронное как AES или нет. – tObi

Когда вы говорите, что вам нужно декодировать zip-файл с симметричным ключом, является то, что определенно что вам нужно сделать? Вместо того, чтобы думать о том, как хранить пароль в виде открытого текста или как его закодировать или что-то еще, вам может потребоваться посмотреть на вашу общую архитектуру. Например, возможно, ваш код мог бы вызвать защищенный веб-сервис, чтобы получить ключ, а не хранить его? Очевидно, что без лучшего представления о том, на что вы нацеливаетесь, сложно предложить жизнеспособную альтернативу, но то, что вы описываете, будет трудно поддерживать должным образом - это будет безопасно с помощью неизвестности, но оно не будет сильным против кого-то, решившего найти ваш ключ.

Если это недостаточно безопасно для того, что вам нужно сделать, то наиболее стандартным ответом, вероятно, будет интеграция какого-то обмена ключами PGP, а не с использованием симметричного шифрования.

источник

2012-06-11 15:16:18 glenatron

Мне нужно создать файл дампа базы данных, чтобы позволить пользователю делать резервную копию всех данных во внешней памяти. Но я не хочу простой файл ... – Tobia

Howsabout пользователь загружает открытый ключ, тогда вы можете шифровать данные, но вы не можете расшифровать его без закрытого ключа. Они загружают его в зашифрованном виде и могут расшифровать его в свободное время. – glenatron

Я не могу понять, почему асиметрические ключи могут решить мою проблему ... Мне все еще нужно хранить закрытый ключ внутри моего кода, или я ошибаюсь? – Tobia

Как насчет хранения уже зашифрованного пароля?

источник

2012-06-11 15:07:13

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

источник

2012-06-11 15:09:32 James

Лучшее, что вы могли бы сделать, это сделать его более трудным для доступа. Любая зашифрованная строка может быть расшифрована с использованием пароля, хранящегося в коде. Вы можете принять меры, чтобы скрыть пароль, но использование частных констант не является одной из таких мер.

источник

2012-06-11 15:16:45

Настоящий хакер все еще сможет расшифровать пароль, но вы можете сделать его немного сложнее, если вы не храните пароль в виде строкового литерала. Вы можете использовать:

private static final String KEY = new String(new char[]{'s', 'e', 'c', 'r', 'e', 't'});

Это приведет к кодам байт:

javap -c -v TestObfuscate 

static {}; 
    Code: 
    Stack=6, Locals=0, Args_size=0 
    0: new #10; //class java/lang/String 
    3: dup 
    4: bipush 6 
    6: newarray char 
    8: dup 
    9: iconst_0 
    10: bipush 115 
    12: castore 
    13: dup 
    14: iconst_1 
    15: bipush 101 
    17: castore 
    18: dup 
    19: iconst_2 
    20: bipush 99 
    22: castore 
    23: dup 
    24: iconst_3 
    25: bipush 114 
    27: castore 
    28: dup 
    29: iconst_4 
    30: bipush 101 
    32: castore 
    33: dup 
    34: iconst_5 
    35: bipush 116 
    37: castore 
    38: invokespecial #12; //Method java/lang/String."<init>":([C)V 
    41: putstatic #16; //Field KEY:Ljava/lang/String; 
    44: return

, тогда как

private static final String ZIP_PASSW="secret"

возвращает

Constant pool: 
const #8 = String #9; // secret

Пожалуйста, обратите внимание, что я не называю постоянный PASSWORD o r ZIP_PASSW (это важно, если строка является общедоступной).

В качестве альтернативы или в дополнение к этому вы можете использовать инструмент обфускации, такой как ProGuard.

источник

2012-06-11 15:22:23

публичная строка не очень хорошая идея :-) Мне нравится это решение ... :-) Я знаю, что это не очень безопасно, но что-то лучше, чем ничего – Tobia

jad все равно декомпилирует его в это: 'private static final String KEY = new String (новый char [] {'s', 'e', 'c', 'r', 'e', 't'}); ' – maksimov

@maksimov вы правы, это все еще ужасно очевидно ... –

Если вы храните ключ в своем коде, он всегда может быть получен путем обратной инженерии. Также не имеет значения, сохраняете ли вы ключ до или после компиляции.

Вы не можете предоставить какой-либо (незашифрованный) ключ с вашей программой без возможности его обратной инженерии. Вот почему асимметричное шифрование было изобретено на первом месте.

Итак, если вы настаиваете на использовании симметричного шифрования, вы должны хранить ключ вне своего приложения (например, в текстовом файле) и доставлять файл на безопасном канале пользователям вашей программы. (Кто, конечно, может использовать ключ любым способом).

Если это не то, что вы хотите, вы должны изучить асимметричные методы шифрования.

источник

2012-06-11 15:23:22 Peter

java constant против обратного проектирования байткода

ответ

Смежные вопросы