Spring управление аутентификации безопасности уязвимости

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

base64 (имя пользователя + ":" + ExpirationTime + ":" + md5Hex (имя пользователя + ":" + ExpirationTime + ":" + пароль ":" + ключ))

у меня есть следующие неурядицы -

Почему использовать n небезопасный хеш, например MD5, для обработки информации вместо использования SHA-1 или SHA-2. Будет ли производительность удачной от них быть значимой для такой небольшой части информации?
Зачем передавать эту информацию по сети вообще? Почему бы не сохранить карту криптографически безопасного случайного числа и эту информацию на сервере, возвращая только ключ карты в качестве файла cookie. AFAIK - это подход, используемый API Servlet, и считается более безопасным.

источник

2012-04-20 Kshitiz Sharma

Давайте начнем со второго вопроса, потому что это более актуально один:

второй вопрос «Почему передавать пароль по сети на всех ....» ответ:

Потому что вы описали только Simple Hash-Based Token Approach

Если вы прокрутите страницу вниз по странице Spring Security Reference: Chapter 10 Remember-Me Authentication, вы увидите, что весенняя безопасность также может использовать другой, который меня помнит: Chapter 10.3 Persistent Token Approach. И это то, что вы предложили в своем втором вопросе.

первый вопрос: Короткий ответ «? Будет ли падение производительности из них иметь важное значение для такой небольшой кусочек информации» - Нет

Так что, если вы хотите использовать Simple Hash-Based Token Approach и почувствовать, что MD5 является необеспеченным, то вы можете создать подкласс TokenBasedRememberMeService[javadoc] и переопределить метод String makeTokenSignature(long tokenExpiryTime, String username, String password). Так, например (непроверенных)

protected String makeTokenSignature(long tokenExpiryTime, String username, String password) { 
    String data = username + ":" + tokenExpiryTime + ":" + password + ":" + getKey(); 
    MessageDigest digest; 
    try { 
     digest = MessageDigest.getInstance("SHA-256"); 
    } catch (NoSuchAlgorithmException e) { 
     throw new IllegalStateException("No SHA-256 algorithm available!"); 
    } 

    return new String(Hex.encode(digest.digest(data.getBytes()))); 
}

источник

2012-04-20 06:27:35 Ralph

Переопределение makeTokenSignature() выглядит неплохим способом, так как я не думаю, что SHA-2 можно сломать. Интересно, в каком случае нужно было бы использовать постоянный подход к токенам вообще. –

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

Постоянный подход к токенам определенно лучше, но я не уверен, что небезопасно использовать MD5 в этом сценарии, где он в основном используется в качестве подписи. Вам понадобится доступ как к хэшированному паролю, так и к ключу, который воспроизводит хеш MD5. – sourcedelica

MD5-хеш используется Simple на основе хэш-маркера не является уязвимостью этого подхода.

Использование MD5 для хеш-паролей является опасным, поскольку, учитывая хешированное значение существующего пароля, вы можете найти еще один пароль, который имеет хэши того же значения (с использованием таблицы радуги).

Однако в этом случае MD5 не используется для хеш-паролей, а используется как MAC. Если вы использовали таблицу радуги, чтобы найти значение, которое сталкивается с этим хешем, как именно вы могли бы использовать это значение?

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

Если вам нужна дополнительная безопасность, вы должны использовать подход Persistent Hash token. Простой хэш-токен предоставляет имя пользователя в открытом виде и уязвим для повторных атак. Постоянный токен избегает этих проблем.

В любом случае вы должны защитить свой файл cookie помнить, установив флаг Secure и Http-only.

источник

2012-04-21 04:20:15 sourcedelica

(+1) для четкого объяснения плюсов подхода Persistent Hash token - даже это было только вопросом из комментариев – Ralph

Spring управление аутентификации безопасности уязвимости

ответ

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