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

if(enteredPassword == verifiedPassword)
     SendToRestrictedArea();
else
     DisplayPasswordUnknownMessage();

Здається, це легко бути ефективним, але я, звичайно, не заперечував би, якби це було все, що потрібно. Чи достатньо простої перевірки імені користувача / пароля?

Оновлення: конкретний проект є веб-службою, перевірка повністю стоїть на сервері, і не є відкритим кодом. Чи змінюється домен, як ви з цим вирішили?

Не без SSL

Це не є безпечним, якщо пароль надсилається по мережі простим текстом. Зберігання пароля на стороні сервера також не є безпечним, якщо пароль надсилається по мережі в простому тексті.

Оскільки <input type="password"/>тег HTML надсилає його вміст у простому тексті, це буде проблемою, незалежно від того, як ви зберігаєте пароль на сервері, якщо ваш веб-сайт не використовує SSL для передачі пароля.

(Автентифікація HTTP, яка спливає діалогове вікно в браузері з проханням ввести пароль, може бути, а може і не бути чітким текстом, залежно від того, які механізми аутентифікації мають спільний сервер і браузер. Таким чином, це може бути способом уникнути цього без використання SSL.)

Ні, якщо адміністратори сайтів підозрюються

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

Спосіб, що захищає паролі від адміністратора

Один безпечний спосіб зберігання та перевірки паролів:

def change_password user, new_password
  salt = random(65536).to_s(16) #will be 4 characters long
  password_hash = salt + hash(salt + new_password)
  store(user,password_hash)
end

def does_password_match? user, entered_password
  correct_password_hash = retrieve(user)
  salt = correct_password_hash[0...4]
  entered_password_hash = salt + hash(salt + entered_password)
  return correct_password_hash == entered_password_hash
end

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

Залежно від середовища, в якому ви перебуваєте, від мінливості вашої затримки в мережі та від того, чи призначені публічно відомі імена користувачів, вам може знадобитися інший розрахунок шляху коду, hash('0000'+entered_password)якщо користувача не існує, щоб запобігти появі зловмисників визначаючи, які імена користувачів є дійсними, виходячи з часу, необхідного для визначення, що пароль невірний.

Це може припустити, що ви зберігаєте паролі у відкритому тексті, що ні-ні, навіть у сценаріях низької безпеки.

Ви повинні мати:

if(hash(enteredPassword) == storedHash)

Ви можете використовувати простий хеш, наприклад, MD5

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

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

isSecuritySufficient = effortToBreak > rewardForBreaking

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

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

Загальні принципи захисту пароля

• Ніколи не зберігайте паролі в простому тексті
• Хеш із використанням захищеної хеш-функції, як SHA-1 або навіть SHA-512 (навіть MD5 занадто просто, щоб знайти відповідний хеш)
• Використовуйте значення додаткової солі. Сіль - випадкові байти, або додані до пароля, щоб ускладнити здогадки. Сіль повинна генеруватися під час виконання та використовувати інформацію про машину як значення насіння, а не зберігати та посилатися будь-яким чином.
• Використовуйте конкретне для користувача значення солі. Використовуйте це разом із сіллю програми.
• Зашифруйте всі запити на аутентифікацію, які переходять через мережу. Це означає використовувати SSL для веб-додатків.

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

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

Це добре, якщо пароль не використовується ні для чого іншого. Все ще існує ризик, що користувач вирішить, що він може повторно використовувати пароль, тому було б ще краще:

if(hash(enteredPassword) == hashOfValidPassword)

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

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

Ніколи не забувайте про безпеку, навіть якщо це не дуже важливо на вашу думку.

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

У кількох відповідях було відмічено, що потрібно зберігати не сам пароль, а хеш - і слід використовувати SSL.

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

І просто хешування пароля недостатньо. Потрібно розім’яти його з сіллю. Хакери мають таблиці зворотного пошуку хешу, тому для даного хешу вони можуть знайти відповідний пароль.

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

Поки це сторона сервера .. Тоді так.

Якщо ви хочете трохи більше захистити, перейдіть на https та зашифруйте \ хеш пароля в БД.