I am searching for a stornger plan than simply password salting-and-hashing.
I would like passwords file/DB that won't compromise:
- Quantity of customers
- User names
- User passwords
My fundamental idea would be to hash and salt both usernames and also the passwords, also to add thousands of 'trap' records in to the database (for instance, random user names ending with _xxxx with random passwords ending with _yyyy which will not be valid legitimate customers).
Obviously, when someone attempts to sign in, I'm going to check it against all lines within the database.
Is plan secure?
- The customers are added by hand. If your user needs to be removed - the login names are saved inside a safe.
- I am unsure basically can safeguard this plan againt brute-pressure techniques, however i think speculating both title and password is harder
I am safeguarding against a leak from the user/password file (along with the application that look at this file). As stated, I have to safeguard the particular quantity of customers, in addition to their details (or something that may disclose their details).
Quantity of customers appears to become the toughest datapoint to safeguard. You are able to mask this by creating large amounts of fake customers with nonsense names encoded while you describe. These may serve dual purpose because the traps you describe, however you have to have the ability to distinguish a trap from the real user meaning it's possible to have an attacker to complete exactly the same whether they can compromise the trap-checker.
Who're you attempting to secure it against?
Would you like to secure it against somebody that compromises the DB, e.g by SQL injection, or perhaps a rogue sysadmin?
Would you like to secure it against somebody that compromises the OS and gains accessibility files that back the database tables?
The previous could be mitigated by restricting accessibility table to well-examined saved methods, and hard DB access controls.
The second could be mitigated by putting DB files with an encoded partition, though this could decelerate access and/or complicate startup.
Ironically, the bigger the amount of customers, the much more likely a brute pressure attacer would be to stumble on the valid combination - and when they are fully aware that you've a large amount of customers with _xxxx or _yyyy within their usernames/passwords, that could provide them with a cryptographical advantage.
So, I'd absolutely suggest that you allow your bogus customers no actual rights, to ensure that a succesful guess yields no privileges somewhere.
Next, you might like to consider who you are safeguarding against, and just how - it's broadly recognized that the good hash/salt combination safeguards against most credible attacks adding the username to that particular plan means you are safeguarding against attacks that do not presently exist.
However, you are not doing anything to safeguard from the much more common attack vector of "username on publish-it note", "password = sex", etc.
The most typical method to enhance "username/password" would be to require customers to possess something physical.