AS
и источник
Size: a a a
2020 August 14
AS
формально вы правы, но на практике вашей жизни не хватит чтобы дешифровать (взломать) соленый современный хеш
D
а если его менять раз в неделю то не получится взломать
запарно же, проще везде разный и длинный держать кмк
NN
Теоретически да, хэш можно обернуть. Технически он разрабатывается необорачиваемым
AS
PASSWORD_HASHERS = [
'django.contrib.auth.hashers.PBKDF2PasswordHasher',
'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
'django.contrib.auth.hashers.Argon2PasswordHasher',
'django.contrib.auth.hashers.BCryptSHA256PasswordHasher',
]
'django.contrib.auth.hashers.PBKDF2PasswordHasher',
'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
'django.contrib.auth.hashers.Argon2PasswordHasher',
'django.contrib.auth.hashers.BCryptSHA256PasswordHasher',
]
AS
по умолчанию в джанге PBKDF2PasswordHasher
AS
подозреваю что в совокупности с длинным секретным ключом вы даже на суперкомьютере пароль 123456 не расшифруете
AS
от слова никогда
NN
подозреваю что в совокупности с длинным секретным ключом вы даже на суперкомьютере пароль 123456 не расшифруете
Потому что будет хэшироваться не 123456, а длинная строка
AS
как раз с солью
NN
Именно
D
подозреваю что в совокупности с длинным секретным ключом вы даже на суперкомьютере пароль 123456 не расшифруете
а есть статьи с попытками атак на pbkdf2? Это же он используется для LUKS?
NC
формально вы правы, но на практике вашей жизни не хватит чтобы дешифровать (взломать) соленый современный хеш
при чем тут взломать? ну можно же читать нормально а не через строку, хэш не только для хранения паролей придуман, использование соли как раз переводит это в сферу криптографии - читай шифрования
DT
как раз с солью
я возможно ошибаюсь, может кто поправит
но хешироваться будет не 123456 с солью
а произодные хеши от этой строки в цикле из 1000 итераций
но хешироваться будет не 123456 с солью
а произодные хеши от этой строки в цикле из 1000 итераций
D
я возможно ошибаюсь, может кто поправит
но хешироваться будет не 123456 с солью
а произодные хеши от этой строки в цикле из 1000 итераций
но хешироваться будет не 123456 с солью
а произодные хеши от этой строки в цикле из 1000 итераций
4.2 Iteration Count
An iteration count has traditionally served the purpose of increasing
the cost of producing keys from a password, thereby also increasing
the difficulty of attack. For the methods in this document, a minimum
of 1000 iterations is recommended. This will increase the cost of
exhaustive search for passwords significantly, without a noticeable
impact in the cost of deriving individual keys.
https://www.ietf.org/rfc/rfc2898.txt
An iteration count has traditionally served the purpose of increasing
the cost of producing keys from a password, thereby also increasing
the difficulty of attack. For the methods in this document, a minimum
of 1000 iterations is recommended. This will increase the cost of
exhaustive search for passwords significantly, without a noticeable
impact in the cost of deriving individual keys.
https://www.ietf.org/rfc/rfc2898.txt
NN
я возможно ошибаюсь, может кто поправит
но хешироваться будет не 123456 с солью
а произодные хеши от этой строки в цикле из 1000 итераций
но хешироваться будет не 123456 с солью
а произодные хеши от этой строки в цикле из 1000 итераций
Ну судя по докам джанги - там именно так в целом. Причем может быть разными алгоритмами
NN
Ладно, теоретики и практики шифрования, желаю всем хорошего дня (или у кого там что)
