Кто-либо знает, какое шифрование техники Разработчик JDeveloper/SQL использует для сохранения учетных данных?
Честно говоря, это выглядит как семантическое различие, а не техническое различие. Фраза «Объект доступа к данным» вообще не относится к «базе данных». И, хотя вы могли бы спроектировать его так, чтобы он был ориентирован на базу данных, я думаю, что большинство людей посчитают это недостатком дизайна.
Цель DAO - скрыть детали реализации механизма доступа к данным. Чем отличается шаблон репозитория? Насколько я могу сказать, это не так. Сказать, что репозиторий отличается от DAO, потому что вы имеете дело с / возвращаете коллекцию объектов, не может быть правильным; DAO также могут возвращать коллекции объектов.
Все, что я читал о шаблоне репозитория, похоже, опирается на это различие: плохой дизайн DAO против хорошего дизайна DAO (он же шаблон проектирования репозитория).
7 ответов
Для любопытных, на самом деле вы видите секретный ключ, соединенный с зашифрованным паролем. Например, я попытался зашифровать пароль «SAILBOAT», используя:
DatabaseProviderHelper.goingOut("SAILBOAT")
В этом конкретном случае результат был:
0527C290B40C41D71139B5E7A4446E94D7678359087249A463
Первый байт является константой:
05
Следующие 8 байтов представляют собой случайно сгенерированный секретный ключ (для DES cipher):
27C290B40C41D711
Оставшиеся байты представляют собой зашифрованный пароль:
39B5E7A4446E94D7678359087249A463
Следовательно, чтобы расшифровать пароль, вы просто используете это:
public static byte[] decryptPassword(byte[] result) throws GeneralSecurityException {
byte constant = result[0];
if (constant != 5) {
throw new IllegalArgumentException();
}
byte[] secretKey = new byte[8];
System.arraycopy(result, 1, secretKey, 0, 8);
byte[] encryptedPassword = new byte[result.length - 9];
System.arraycopy(result, 9, encryptedPassword, 0, encryptedPassword.length);
byte[] iv = new byte[8];
for (int i = 0; i < iv.length; i++) {
iv[i] = 0;
}
Cipher cipher = Cipher.getInstance("DES/CBC/PKCS5Padding");
cipher.init(Cipher.DECRYPT_MODE, new SecretKeySpec(secretKey, "DES"), new IvParameterSpec(iv));
return cipher.doFinal(encryptedPassword);
}
Я не уверен в этом, но я всегда думал, что хеши нельзя расшифровать, только по сравнению с другим хешем. MD5 генерирует хэш. Сохраненный пароль в SQL Developer необходимо расшифровать и отправить на сервер. Таким образом, лучше использовать процедуры DES3Encrypt и DES3Decrypt в пакете dbms_obfuscation_toolkit. Но расшифровку следует вызывать перед подключением к базе данных, поэтому, вероятно, это крипто-пакет Java с методами DES.
Не знаю, но я не удивлюсь, если DBMS_OBFUSCATION_TOOLKIT будет использоваться примерно так:
l_hash := dbms_obfuscation_toolkit.md5(input_string=>:username||:password);
Длина хэша составляет 50 шестнадцатеричных символов, что составляет 200 бит, поэтому это может быть хеш пароля с солью, к которой добавляется соль, например:
salt | hash(salt | password)
где | означает конкатенацию.
Это просто предположение. Я предполагаю, что это будет 40-битная соль и хэш SHA-1, поскольку SHA-1 производит 160-битные хэши.
Было бы полезно предоставить некоторые тестовые данные ввода / вывода для проверки!
FYI пароль 'apps_ro' шифруется как:
<StringRefAddr addrType="password">
<Contents>051DC8A88C574538CC4AEE32D326E9480659C06CEC271EA6D7</Contents>
</StringRefAddr>
Обратите внимание, что хэш пароля Тима выше не для "apps_ro" - предположительно, он вырезал и вставил не из того места... Я не буду публиковать настоящий пароль на случай, если он не захочет, чтобы его разглашали!
У меня была похожая проблема: я пытался хранить учетные данные базы данных централизованно (для незащищенных баз данных!), а затем экспортировать sql-разработчику xml-файлы. Я понятия не имею, что это за алгоритм - впрочем, вам и не нужно знать алгоритм, поскольку вы можете просто вызвать java API Oracle самостоятельно. Если у вас есть SQLDeveloper, просто возьмите нужные Jar-файлы:
cp /Applications/SQLDeveloper.App/Contents/Resources/sqldeveloper/BC4J/lib/db-ca.jar .
cp /Applications/SQLDeveloper.App/Contents/Resources/sqldeveloper/jlib/ojmisc.jar .
Затем либо загрузите их в свое Java-приложение, либо используйте что-то вроде JRuby, как это делаю я:
$jirb
> require 'java'
> require 'ojmisc.jar'
> require 'db-ca.jar'
> Java::oracle.jdevimpl.db.adapter.DatabaseProviderHelper.goingOut("password")
=> "059D45F5EB78C99875F6F6E3C3F66F71352B0EB4668D7DEBF8"
> Java::oracle.jdevimpl.db.adapter.DatabaseProviderHelper.goingOut("password")
=> "055CBB58B69B477714239157A1F95FDDD6E5B453BEB69E5D49"
> Java::oracle.jdevimpl.db.adapter.DatabaseProviderHelper.comingIn("059D45F5EB78C99875F6F6E3C3F66F71352B0EB4668D7DEBF8")
=> "password"
> Java::oracle.jdevimpl.db.adapter.DatabaseProviderHelper.comingIn("055CBB58B69B477714239157A1F95FDDD6E5B453BEB69E5D49")
=> "password"
Обратите внимание, что алгоритм, каким бы он ни был, имеет случайный фактор, поэтому один и тот же пароль, использованный дважды, может дать две разные шестнадцатеричные строки.
Тот же код, что и kornelissietsma, но написанный на java:
import oracle.jdevimpl.db.adapter.DatabaseProviderHelper;
class Decode {
String pass = "";
public Decode() {
pass = DatabaseProviderHelper.comingIn("HASH");
System.out.println(pass);
}
public static void main(String[] args){
new Decode();
}
}
Может быть выполнен следующим образом:
# javac -classpath .:/full/path/to/sqldeveloper/BC4J/lib/db-ca.jar:/full/path/to/sqldeveloper/jlib/ojmisc.jar sqldeveloper_hash_decode.java
# java -classpath .:/full/path/to/sqldeveloper/BC4J/lib/db-ca.jar:/full/path/to/sqldeveloper/jlib/ojmisc.jar Decode