Двустороннее шифрование в PHP

Правильно ли это делается?

blockquote>

Помимо выполнения бизнес-логики неэффективный способ в методе управляемых компонентов боба и использование слишком широкая область управления, она выглядит нормально. Если вы переместите вызов службы из метода getter в метод @PostConstruct и используйте @RequestScoped или @ViewScoped вместо @SessionScoped, он будет выглядеть лучше.

См. Также:


Правильно ли моя терминология?

blockquote>

Все в порядке. Пока вы согласны с этим, и код читается разумным образом. Только ваш способ именования классов и переменных несколько неудобен (нелогично и / или дублирование). Например, я лично использовал бы users вместо userList и использовал var="user" вместо var="u" и использовал id и name вместо userId и userName. Кроме того, «UserListService» звучит так, что он может обрабатывать только списки пользователей, а не пользователей в целом. Я бы предпочел использовать «UserService», чтобы вы могли также использовать его для создания, обновления и удаления пользователей.

См. Также:


«Служба» больше похожа на DAO?

blockquote>

It не является точно DAO. В принципе, JPA является настоящим DAO здесь. Раньше, когда JPA не существовало, все домашние интерфейсы DAO, так что методы обслуживания могут продолжать использовать их, даже когда базовая реализация («простой старый» JDBC или «старый добрый» Hibernate и т. Д.) Изменяется. Реальная задача метода сервиса - прозрачное управление транзакциями. Это не является обязанностью DAO.

См. Также:


И контроллер чувствует, что выполняет некоторую работу службы.

blockquote>

Я могу представить, что он делает это в этой относительно простой установке. Однако контроллер фактически является частью интерфейса, а не бэкэнд. Служба является частью бэкэнд, которая должна быть сконструирована таким образом, что она может использоваться повторно во всех разных интерфейсах, таких как JSF, JAX-RS, «простой» JSP + Servlet, даже Swing и т. Д. Кроме того, контроллер, специфичный для интерфейса (например, также называемый «поддерживающим bean-компонентом» или «презентатором») позволяет вам иметь дело с конкретным интерфейсом с успехом и / или исключительными результатами, например, в случае JSF, отображающем сообщение лиц в случае исключения, вызванного службой.

См. также:


В общем, правильный подход будет следующим:


    #{user.id}
    #{user.name}

@Named
@RequestScoped // Use @ViewScoped once you bring in ajax (e.g. CRUD)
public class UserBacking {

    private List users;

    @EJB
    private UserService userService;

    @PostConstruct
    public void init() {
        users = userService.listAll();
    }

    public List getUsers() {
        return users;
    }

}
@Stateless
public class UserService {

    @PersistenceContext
    private EntityManager em;

    public List listAll() {
        return em.createQuery("SELECT u FROM User u", User.class).getResultList();
    }

}

Вы можете найти здесь настоящий мир здесь используется каноническая практика Java EE / JSF / CDI / EJB / JPA: Java EE kickoff app .

См. также:

29
задан benjy 7 September 2009 в 22:12
поделиться

6 ответов

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

-3
ответ дан scragar 7 September 2009 в 22:12
поделиться

PHP 5.3 представил новый метод шифрования, который действительно прост в использовании: openssl_encrypt и openssl_decrypt. Это не очень хорошо задокументировано, поэтому вот простой пример:

$textToEncrypt = "My super secret information.";
$encryptionMethod = "AES-256-CBC";  // AES is used by the U.S. gov't to encrypt top secret documents.
$secretHash = "25c6c7ff35b9979b151f2136cd13b0ff";

//To encrypt
$encryptedMessage = openssl_encrypt($textToEncrypt, $encryptionMethod, $secretHash);

//To Decrypt
$decryptedMessage = openssl_decrypt($encryptedMessage, $encryptionMethod, $secretHash);

//Result
echo "Encrypted: $encryptedMessage <br>Decrypted: $decryptedMessage";

Я выбрал 256-AES, потому что он надежный и быстрый. Он был принят правительством США для шифрования сверхсекретных документов. Это быстро, учитывая машину и программное обеспечение. Вот список доступных методов шифрования:

AES-128-CBC, AES-128-CFB, AES-128-CFB1, AES-128-CFB8, AES-128-ECB, AES-128-OFB, AES-192-CBC, AES-192-CFB, AES-192-CFB1, AES-192-CFB8, AES-192-ECB, AES-192-OFB, AES-256-CBC, AES-256-CFB, AES- 256-CFB1, AES-256-CFB8, AES-256-ECB, AES-256-OFB, BF-CBC, BF-CFB, BF-ECB, BF-OFB, CAMELLIA-128-CBC, CAMELLIA-128-CFB, CAMELLIA-128-CFB1, CAMELLIA-128-CFB8, CAMELLIA-128-ECB, CAMELLIA-128-OFB, CAMELLIA-192-CBC, CAMELLIA-192-CFB, CAMELLIA-192-CFB1, CAMELLIA-192-CFB8, CAMELLIA- 192-ECB, CAMELLIA-192-OFB, CAMELLIA-256-CBC, CAMELLIA-256-CFB, CAMELLIA-256-CFB1, CAMELLIA-256-CFB8, CAMELLIA-256-ECB, CAMELLIA-256-OFB, CAST5-CBC, CAST5-CFB, CAST5-ECB, CAST5-OFB, DES-CBC, DES-CFB, DES-CFB1, DES-CFB8, DES-ECB, DES-EDE, DES-EDE-CBC, DES-EDE-CFB, DES- EDE-OFB, DES-EDE3, DES-EDE3-CBC, DES-EDE3-CFB, DES-EDE3-CFB1, DES-EDE3-CFB8, DES-EDE3-OFB, DES-OFB, DESX-CBC, RC2-40- CBC, RC2-64-CBC, RC2-CBC, RC2-CFB, RC2-ECB, RC2-OFB, RC4, RC4-40, SEED-CBC, SEED-CFB, SEED-E CB, SEED-OFB, aes-128-cbc, aes-128-cfb, aes-128-cfb1, aes-128-cfb8, aes-128-ecb, aes-128-ofb, aes-192-cbc, aes- 192-cfb, aes-192-cfb1, aes-192-cfb8, aes-192-ecb, aes-192-ofb, aes-256-cbc, aes-256-cfb, aes-256-cfb1, aes-256- cfb8, aes-256-ecb, aes-256-ofb, bf-cbc, bf-cfb, bf-ecb, bf-ofb, камелия-128-cbc, камелия-128-cfb, камелия-128-cfb1, камелия- 128-cfb8, камелия-128-ecb, камелия-128-ofb, камелия-192-cbc, камелия-192-cfb, камелия-192-cfb1, камелия-192-cfb8, камелия-192-экб, камелия-192- ofb, камелия-256-cbc, камелия-256-cfb, камелия-256-cfb1, камелия-256-cfb8, камелия-256-ecb, камелия-256-ofb, cast5-cbc, cast5-cfb, cast5-ecb, cast5-ofb, des-cbc, des-cfb, des-cfb1, des-cfb8, des-ecb, des-ede, des-ede-cbc, des-ede-cfb, des-ede-ofb, des-ede3, des-ede3-cbc, des-ede3-cfb, des-ede3-cfb1, des-ede3-cfb8, des-ede3-ofb, des-ofb, desx-cbc, rc2-40-cbc, rc2-64-cbc, rc2-cbc, rc2-cfb, rc2-ecb, rc2-ofb, rc4, rc4-40, seed-cbc, seed-cfb, seed-ecb, seed-ofb

<час>

ВАЖНО ОБНОВЛЕНИЕ !!!

Спасибо Хобо и Джорвину за то, что они указали, что в PHP 5.3.3> есть новый параметр, который делает эту функцию немного более безопасной.

Джорвин ссылался на эту ссылку в в своем комментарии , и вот выдержка, которая применима:

В 5.3.3 они добавили новый параметр, string $iv (вектор инициализации) Действительными параметрами являются: string openssl_encrypt ( string $data , string $method , string $password, bool $raw_output = false, string $iv )

Если $iv отсутствует, выдается предупреждение: «Использование пустого вектора инициализации (iv) потенциально небезопасно и не рекомендуется».

Если $iv слишком короткое, другое предупреждение: «Переданный IV имеет длину всего 3 байта, шифр ожидает IV ровно 8 байтов с заполнением \ 0»

, тот же IV следует использовать в openssl_decrypt()

95
ответ дан Ry- 7 September 2009 в 22:12
поделиться

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

HMAC (по сути, хеши с ключами) являются одним из способов получения криптографической аутентификации. Сопоставьте UID с HMAC UID (PHP имеет реализацию HMAC ), используя ключ, который знает только сервер. В начале каждого запроса проверяйте HMAC.

В основном, используйте правильный инструмент для правильной работы.

28
ответ дан caf 7 September 2009 в 22:12
поделиться

Для двустороннего шифрования проверьте mcrypt или, если вы предпочитаете чистую реализацию , phpseclib .

2
ответ дан rogeriopvl 7 September 2009 в 22:12
поделиться

Во-первых, шифрование параметров URL-адреса обычно является плохой идеей , и отдельный поиск (на основе столбца индекса CHAR, сгенерированного CSPRNG) лучше для 99,9% случаев использования.

С учетом сказанного: да, вы можете использовать расширение OpenSSL ( не использовать mcrypt ) для шифрования данных , как предложил espradley , однако я бы предостерег вас не останавливаться просто шифрование.

Шифрование без аутентификации сообщения опасно , , особенно , если вы доверяете конечному пользователю зашифрованный текст.

Поэтому решение заключается в использовании аутентифицированного шифрования , к которому легко получить доступ с помощью libsodium, доступного на PECL .

Если по какой-либо причине вы не можете установить расширение PECL, можно выбрать одну из двух библиотек PHP: defuse / php-encryption и zend-crypt . Они оба предлагают совместимое со стандартами шифрование с проверкой подлинности и оба безопасны в использовании (для чего бы это ни стоило, я часто выполняю аудиты кода для реализации криптографии в PHP, я не просто , случайный человек в интернете).

0
ответ дан Scott Arciszewski 7 September 2009 в 22:12
поделиться

Хотя PHP поддерживает множество двухсторонних алгоритмов хеширования, я не считаю, что это полезно в этом примере. Что вам нужно сделать:

  1. Загрузить строку из хранилища по предоставленному идентификатору.
  2. Проверить, что владельцем строки является аутентифицированный пользователь, и, если нет, выбросить исключение и сообщить пользователю, чтобы он не делал этого снова

Но если ваше сердце настроено на хеширование, просто выберите один из предложенных алгоритмов .

3
ответ дан 28 November 2019 в 00:36
поделиться
Другие вопросы по тегам:

Похожие вопросы: