Заставить Django.contrib.auth хранить текстовые пароли

Question

У меня есть сайт на Django (еще не запущен, поэтому реальных пользователей нет), использующий обычный django.contrib.auth, и хочу хранить пароли в виде простого текста, а не хеш-хэшей SHA-1.

Вопрос в том, каков наилучший подход для этого, надеюсь, без исправлений (или исправлений обезьян) исходного кода Django?

ПРИМЕЧАНИЕ : Я прекрасно знаю, что это , конечно, менее безопасно. Открытый текст необходим для выполнения аутентификации «запрос-ответ», например CHAP для PPTP VPN, DIGEST-MD5 для IMAP4 и HTTP-дайджест для хранилища файлов на основе WebDAV. Итак, я торгую безопасностью уровня БД с безопасностью уровня соединения.

Конечно, я рассматриваю возможность обучения и поощрения пользователей к использованию сертификатов X.509 (а не к использованию каких-либо паролей), но это не так просто.

Реверсивное шифрование (обфусцирование) паролей и использование некоторых разрешений на уровне столбцов, чтобы пароль был ВСТАВЛЯЕМЫМ / ОБНОВЛЯЕМЫМ, но недоступным для ВЫБОРА веб-пользователем (доступен только для некоторых пользовательских функций проверки, таких как SELECT * FROM users WHERE 'somesha1hash' = USER_HMAC(id, 'salt')), поэтому пароли не будут "просто там" - это хорошая идея , и я постараюсь это сделать. Предложения по защите незашифрованных данных горячо приветствуются, но я больше всего хочу услышать, как взломать способ хранения паролей.

Answer 1

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

Тем не менее, вы никогда не должны хранить пароли в открытом тексте .
Суть в том, что люди, как правило, используют один и тот же пароль снова и снова, и поэтому, используя открытый текст на вашем сайте, вы подвергаете своих пользователей риску для злоумышленника получить доступ к их банковскому счету. Джефф Этвуд написал хороший пост на эту тему: Возможно, вы неправильно храните пароли ; Я предлагаю вам прочитать его, потому что он объяснит проблемы с открытым текстом в паролях гораздо лучше, чем я.
По крайней мере, вы должны поощрять своих пользователей использовать пароль, отличный от их «безопасных»; например, вы можете просто сгенерировать новые случайные пароли, даже если у этого подхода тоже есть свои ограничения.

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

Answer 2

Существует множество отличных сценариев для хранения паролей в открытом виде (сайты с детскими играми и т. Д.). Это на самом деле довольно легко сделать.

В ваших настройках добавьте:

PASSWORD_HASHERS = ('wereallfriendsinunikittyland.PlainTextPassword',)    

Чем создать файл wereallfriendsinunikittyland.py.

from django.contrib.auth.hashers import BasePasswordHasher

class PlainTextPassword(BasePasswordHasher):
    algorithm = "plain"

    def salt(self):
        return ''

    def encode(self, password, salt):
        assert salt == ''
        return password

    def verify(self, password, encoded):
        return password == encoded

    def safe_summary(self, encoded):
        return OrderedDict([
            (_('algorithm'), self.algorithm),
            (_('hash'), encoded),
        ])

Answer 3

Не делай этого. Это нарушает основные принципы безопасности. Лучше вообще не иметь пароля, чем делать это.

По поводу вашего обновленного вопроса: хранить эти пароли внешнего доступа в зашифрованном виде в отдельной таблице (в любом случае они могут не совпадать). Пароль пользователя для сгенерированного соленого ключа для этого шифрования. Затем, когда она входит в систему, ваше приложение может расшифровать и использовать эти ключи.

Это действительно очень трудно понять правильно. Удачи!

Answer 4

Почему?

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