using real/fake salt instead of lockouts
I've read various topics about php login scripts, so I'm not going to recap those discussions but I was wondering about the use of a real and fake salt in the password hash.
Instead of an ID / password login prompt, I was thinking about a ID# / ID / password login prompt. My users all have IDs, not related to my company that they use often in their profession. If they enter a real ID# and login ID that match, then they get the real salt. All non-matching entries result in a fake salt for the password. While these ID#s are probably obtainable in the Internet, you'd have to know the name of the user, and this would make all random attacks fail. The only way to make the attack work is to discover the user's name first, then attack my system. User identities are not commonly known.
Is this a viable approach? What could go wrong if I also tied in locking an ID after a certain number of attempts, and delaying login attempts after so many GLOBAL failed attempts. However, I wasn't going to do lockouts or throttling for any attempt that involved the fake salt. I was only going to implement these failsafes when they earned a real salt. However, I may consider throttling if they get an existing ID#.
Thoughts or suggestions? Would this be a secure alternative to banning IPs, asking personal questions, captcha, etc?
I am going to write this as an answer as it seems you are confused about what a salt is and how it works.
What is a salt?
A salt should be a random string generated for each user. Before you encrypt their password and store it in the database you add the salt and store it also, thus changing what the encrypted value would be. The salt ensures that should someone gain access to your database and in effect your user's encrypted passwords they can't use a rainbow table to quickly look up their unencrypted password.
A rainbow table is a list of values and their encrypted counterparts, by generating a list of values in advance the attacker does not need to bruteforce the encrypted password and can "decrypt" it in a O(1) lookup. Because you randomly generate a salt for each user you render their tables worthless.
It does not prevent them from bruteforcing the password and is not a substitute for strong encryption.
What is a fake salt?
Nothing. It does not exist, it serves no good purpose.
Issues with your method
Firstly the user should never see or be made aware of their salt value, this is stored in your database and used by your authentication logic. There is no reason not to use their actual salt when testing the validity of their password. If the password is wrong it will fail authentication anyway.
Secondly if an attacker is attempting to use a non-existent username to log in then fantastic, they will never gain access to an account and no further action needs to be taken apart from if they are overloading your server with requests in which case you need to find a way to block them temporarily.
The appropriate answer will depend on the level of security, or insecurity, that your company is able to live with. For example, will the system ever be audited? How are users created in the system? Will users ever access this resource from non-private computers?
Although, I could see reasons to implement a system like this, I would not recommend it. I think others would go so far as to claim it's outright ridiculous. The reason for that is that if you have any web-facing application, it is incredibly likely that the security of the system will be compromised.
Further, blocking an IP address entirely can result in atrocious user experiences. I would recommend to implementing a reverse Turing test (like Capthcha or Mathcha).
Ultimately though, I applaud the idea of trying to move away from password authentication. As a user, I hate passwords. And the security policies of my employer (and I'm assuming most) around passwords is itself laughable.
EDIT: I just re-read your comment saying this would make all random attacks fail . I'd like to add that that assumption seems not well grounded to me. It's much, much easier to guess a user's name than you might think. Especially if it's their real name.
上一篇: Spring Security：如何实施暴力检测（BFD）？
下一篇: 使用真实/假盐而不是锁定