Звідки беруться значення сольового хешу?

12

Якщо ви додаєте значення солі до хеш-значень для чогось типу пароля, який не може бути збережений у простому тексті, яке найкраще місце для отримання значень солі? Для контексту, припустимо, це стосується паролів для входу на веб-сторінку.

security hashing

— Морган Херлокер
джерело

@DevArt, я подумав, що тут краще підходить, тому що він вимагає дуже суб’єктивної відповіді. Значення солі можна витягнути з будь-якого місця, тому я запитую "Де ви вважаєте, що найбільш безпечне місце для отримання значень солі з: клієнта чи сервера?"

— Морган Херлокер

7

Зазвичай created TIMESTAMPу таблиці користувачів є стовпець, щоб я міг бачити, коли користувач зареєструвався. Мені не подобається додавати додатковий стовпчик для солі, тому я використовую стовпчик мітки як сіль:

SHA1(password + created)

— Йонас
джерело

Тоді я припускаю, що коли користувач знову ввійде, ви виберете дату, засновану на імені користувача, коли ви повторно проходите перевірку?

— Морган Херлокер

1

@Prof: Так, як і у вас, якщо у вас є специфічний стовпчик для солі, тому різниці в цій перспективі немає.

— Йонас

7

Це важливо?

Сіль служить двом цілям. Недоцільно використовувати великі таблиці попередньо заздалегідь заздалегідь заздалегідь заздалегідь заздалегідь заздалегідь заздалегідь заздалегідь встановлених паролів ("веселкові таблиці"), і це робить однакові паролі у списку хешей різними. Здійснення вигляду однакових паролів допомагає уникнути проблеми, коли декілька людей використовують один конкретний пароль, який, мабуть, є загальним слабким.

Тому кожен рахунок повинен мати власну унікальну сіль, і солі не повинні бути надмірно передбачуваними, в тому сенсі, що не буде групи солей, які, ймовірно, є. (Якщо багато сайтів почали з 1 і підраховували, погані хлопці могли б створити таблиці з веселок, включаючи солі з низькою кількістю.) Вони не повинні бути випадковими в будь-якому сенсі, крім загального непередбачуваного. Вони не є більш секретними, ніж сам хеш, тому їх не потрібно бути спеціально непридатними.

Використовуйте будь-який зручний метод для отримання солі. Якщо існує багато потенційних значень солі (ранні системи Unix часто використовували два байти (можливе число 65536)) порівняно з кількістю облікових записів, напіввипадкове призначення майже ніколи не видало б дублікат солі.

— Девід Торнлі
джерело

1

Я взагалі бачив другий випуск - однакові паролі, які виглядають по-різному - вирішуються шляхом об'єднання імені користувача, солі та пароля та хеширування всієї рядка. Це виключає необхідність генерування унікальної солі на рахунок.

— Джастін Печера

1

@Justin: цікаво, я ніколи не бачив імені користувача, що використовується як частина хешу, але це дійсно хороший спосіб додати трохи ентропії. Я б все-таки використовував псевдовипадкову сіль, тільки тому, що вона не коштує багато для її отримання.

— Матьє М.

2

@Matthieu З недоліком необхідності зберігати його десь, і якщо це потрібно обом сторонам транзакції, потрібно також надіслати. Ім'я користувача обидві сторони це вже знають.

— Меттью Фредерік

2

@Justin: У такому випадку ім'я користувача використовується як сіль. Він відповідає обом цілям солі: робити таблиці веселки непрактичними, а подібні паролі виглядають по-різному.

— Девід Торнлі

@David - Правда, ви можете розглядати це як ім'я користувача, що стає частиною солі. Я все ще хотів би додаткової солі, щоб зловмисник не міг використовувати таблицю веселки для пошуку комбінацій імені користувача / пароля. Без явної солі ви просто збільшуєте розмір рядка, якому потрібен нападник із таблиці веселки на довжину імені користувача (яке, швидше за все, буде коротким, або зовсім низьким або повністю великим регістром). Постійної солі достатньо для запобігання атаки веселкового столу, якщо ваш сайт не є достатньо великим, щоб зловмисник створив специфічну для веселки таблицю.

— Джастін Печера

3

Кожен раз, коли ви хочете зберегти новий пароль (реєстрація, скидання пароля, оновлення пароля), одна хороша методика:

генерують нову сіль
- використовувати криптографічно захищений генератор псевдовипадкових чисел
- використовуйте сіль пристойного розміру - хорошим значенням є розмір блоку алгоритму хеши, що лежить в основі (може бути SHA-256)
створити новий маркер пароля
- створити функцію hmac з алгоритму хешу, що лежить в основі (може бути SHA-256), використовуючи сіль як ключ hmac
- for i in (0...65536) { password = hmac(password) }
- результатом ітераційних додатків функції hmac є маркер пароля
зберігати сіль та маркер пароля
- не зберігайте оригінальний пароль
- необов'язково зберігати основний алгоритм хешу та розтяжки для відкриття

— yfeldblum
джерело

1

Використовуйте рамки. У .NET ви можете використовувати RNGCryptoServoiceProvider ...

        // If salt is not specified, generate it on the fly.
        if (saltBytes == null)
        {
            // Define min and max salt sizes.
            int minSaltSize = 4;
            int maxSaltSize = 8;

            // Generate a random number for the size of the salt.
            Random  random = new Random();
            int saltSize = random.Next(minSaltSize, maxSaltSize);

            // Allocate a byte array, which will hold the salt.
            saltBytes = new byte[saltSize];

            // Initialize a random number generator.
            RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();

            // Fill the salt with cryptographically strong byte values.
            rng.GetNonZeroBytes(saltBytes); 
        }

Інші рамки повинні мати подібні класи, на які можна використовувати. Для досягнення випадковості програмне забезпечення часто залучає користувача в порівнянні Randomіз зазначеним вище. Випадково переміщення миші в певному районі для надання солі - це варіант, який використовується TrueCrypt. Це зводиться до ваших конкретних потреб та рівня безпеки; оскільки ваша сіль може бути просто !@#$%.

— Аарон Маківер
джерело

1

Ви створюєте сольовий сервер і призначаєте його обліковому запису користувача при його створенні. Краще використовувати API криптогенерації, доступний у вашій базі, але в принципі будь-яка послідовність буде робити.

Зазвичай речі зберігаються так:

User
-------------------
ID
Username
PasswordHashWithSalt

Приклад:

PasswordHashWithSalt =

A15CD9652D4F4A3FB61A2A422AEAFDF0DEA4E703 j5d58k4b56s8744q

Призначте його, базуючись на чому? Чи не повинно виходити з якогось значення, яке залишиться на місці, щоб воно могло бути повторене, коли користувач підписується назад після створення?

— Морган Херлокер

Маючи на увазі "призначити", я маю на увазі генерувати сіль для пари імені користувача / пароля (акаунта) і зберігати її в базі даних. Коли вам потрібно виконати вхід, ви використовуєте цю збережену сіль для перевірки речей.

1

Використовуйте bcrypt і читайте цю статтю, оскільки звичайний хеш поодинці не є серйозним захистом у цей день та вік.

Подумайте про використання протоколу паролів з нульовим знанням SDR, який містить безліч бібліотек з відкритими джерелами і не є патентом.

SDR вимагає солі та найкращого місця для отримання клієнта; час їх натискань клавіш, рухів миші, хеш змінних їх середовища, випадкових чисел, часів створення файлів у папці temp, щоб зробити сіль в кінці непередбачуваним способом подалі від вашого сервера. SDR приймає сіль, великий прайм, пароль користувача та генерує ключ перевірки. Ви не зберігаєте пароль, він ніколи не залишає їх машину, але ви можете переконатися, що у них є пароль, який входить із ключем перевірки та сіллю. Він захищений від людини в середині та словникових атак. Зашифруйте ключі та сіль у стовпці бази даних, щоб бути впевненим.

— simbo1905
джерело