Найкращий спосіб зберігання пароля в базі даних [закрито]

Я працюю над проектом, який повинен мати автентифікацію (ім’я користувача та пароль)

Він також підключається до бази даних, тому я подумав, що я зберігатиму ім'я користувача та пароль там. Однак, здається, не дуже гарна ідея мати паролі, як просто текстове поле в таблиці, що знаходиться в базі даних.

Я використовую C # і підключаюся до сервера експресів 2008 року. Чи може хтось запропонувати (з якомога більше прикладів), який найкращий спосіб зберігати цей тип даних?

PS Я відкритий для думки, що ця інформація не зберігатиметься в базі даних, якщо можна надати вагомі причини

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

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

• Як найкраще зберігати інформацію про користувачів та логін та пароль користувача
• Найкращі практики зберігання паролів баз даних
• Солити свій пароль: кращі практики?
• Чи завжди добре зберігати пароль у простому тексті у змінній php чи константі php?

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

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

Hash It: Зберігайте хешовані паролі користувачів (одностороннє шифрування) за допомогою сильної хеш-функції. Пошук "паролів шифрування c #" дає безліч прикладів.

Дивіться в Інтернеті SHA1-хеш-творця, щоб дізнатись про те, що виробляє хеш-функція (Але не використовуйте SHA1 як хеш-функцію, використовуйте щось сильніше, наприклад, SHA256).

Тепер хешовані паролі означають, що ви (і злодії бази даних) не повинні мати змогу повернути цей хеш у вихідний пароль.

Як ним користуватися: Але, скажете, як я можу використовувати цей пюре, збережений у базі даних?

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

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

Додатковий кредит:

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

Відповідь: Так ... так, вони можуть.

Отже, вам слід «посолити» ваші паролі. Дивіться статтю Вікіпедії про сіль

Див. Приклад C # "Як хеш-дані з сіллю"

Як затверджений хеш-сольовий хеш, використовуючи захищений алгоритм, такий як sha-512.

Найкраща практика безпеки - це не зберігати пароль взагалі (навіть не зашифровано), а зберігати солоний хеш (з унікальною сіллю на пароль) зашифрованого пароля.

Таким чином, неможливо отримати пароль простого тексту.

Я ретельно рекомендую прочитати статті " Досить із таблицями веселки": Що потрібно знати про безпечні схеми паролів [мертве посилання, скопіюйте в Інтернет-архіві ] та як безпечно зберігати пароль .

Багато кодерів, включаючи мене, думаю, що вони розуміють безпеку та хеширование. На жаль, більшість із нас просто цього не робить.

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

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

Це може бути непридатним, якщо мова йде лише про внутрішнє використання

RPX забезпечує приємний простий спосіб інтегрувати підтримку OpenID в додаток.

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

Для цього створено все, перевірте членство на asp.net

Я б сказав MD5 / SHA1 пароль, якщо вам не потрібно мати змогу повернути хеш. Коли користувачі входять, ви можете просто зашифрувати вказаний пароль і порівняти його з хешем. У цьому випадку зіткнення хешу майже неможливо, якщо хтось не отримає доступ до бази даних і не побачить хеш, для якого вже зіткнення.