Просто для того, щоб бути безпечним, реєстрація в моєму поточному додатку не зберігає параметри, передані для входу або методів скидання пароля. Виклик журналу має необов'язковий параметр, який керує цим, який, коли встановлено значення true, замінює об'єкт збережених параметрів на [Redacted]. Звичайно, тому я пропускаю трохи даних, але у мене є їхні IP-адреси, і я краще не ризикую отримати щось чутливе в простому тексті.
Якщо ви дійсно хочете зареєструвати подібні речі, я б радив, щоб під час реєстрації спроби входу ви перевіряли базу даних для користувачів з ім'ям, що відповідає тому, що у вас є у полі імені користувача, і зберігаєте її лише у тому випадку, якщо у вас є відповідність. В іншому випадку ви просто зберігаєте його як "невідомого користувача". Ви можете пофантазувати, перевіривши, чи містить це значення те чи інше, але завжди є ризик отримати комбінації, такі як [Користувач] [Пароль] та [КористувачPas] [меч], і в цьому випадку ви можете перевірити IP-адресу та вивести це ви ненароком зберегли початок чийогось пароля в чистоті. Ви можете поширити це на малоймовірні, але можливі [Користувач] [Пароль] та [UserPassword] [??], і в цьому випадку ви можете побачити "невдалий вхід від UserPassword" з подальшим "Успішним входом користувача" та вивести всіпароля користувача. Як правило, для безпеки я б сказав, щоб не реєструвати імена користувачів, якщо реєстрація не буде успішною.
Редагувати, щоб додати:
Більшість аргументів, які публікують люди для реєстрації імені користувача для невдалих спроб входу, на мою думку, краще обробляються за допомогою інших методів.
Наприклад, сказано, що, коли клієнт запитує "чому я не можу ввійти?", Іменовані імена користувачів дозволять вам вказати помилки друку. Це правда, але ризикувати захопленням паролів також не варто; Я б це зробив, замість того, щоб переспрямовувати користувача назад до форми входу під час відмови, виділяючи поле ім’я користувача та повторно заселяючи його тим, що вони ввели, щоб вони могли бачити самі.
Ще один аргумент полягав у тому, що він дозволяє ідентифікувати спроби злому; рядок відмов проти одного імені користувача цілком може бути спробою жорстокого введення пароля. Я б зробив це, встановивши стовпчик "BadLogins" на таблиці "Користувачі", який збільшується кожного разу, коли вхід не вдається з ім'ям користувача, що відповідає цьому користувачеві, і скидається до нуля при успішному вході після повідомлення користувача "там були x невдалі спроби входу з моменту останнього входу "та порадивши їх, що робити, якщо вони не вважають, що спроби були з них". Якщо ви хочете бути дуже ретельними, у вас може бути інший стовпець, який зберігає останнє значення стовпця BadLogins навіть після успішного входу, та / або стовпець, який зберігає найвище значення цього стовпця та / або стовпець, який зберігає загальну кількість помилкових входів, які цей обліковий запис коли-небудь мав.