I am building a project, which has a pretty basic login system. There will NO REGISTRATION system available, the users will be added manually. Also i protected the databases data input gates very well. So after all, do i still need to hash and even salt the users passwords?
And if your answer is yes, the next question is why?
Yes, because your database is still there and a user system and its database are no more difficult to compromise without a registration form than with one.
Even if you protect your "database data input gates" very well, your database still isn't 100% attacker-proof. If someone still manages to slip through your defenses and sees everything in your database, and all the passwords are in plain text, your users' accounts are still compromised. By hashing them at least you're costing attackers more time, and at the same time protecting your users.
Yes, because, e.g., people having access to the database can easily impersonate other users.
Well, what would be the consequence of an intruder being able to impersonate another user? Weigh those consequences against the difficulty (which isn't very great) of adding hashing and salting.
One risk which you may want to consider is that if a user has the same password on multiple sites, then their security is only as safe as the weakest site. Even if you're manually assigning the passwords yourself (and not allowing the user to choose it) they may go on to use the same password in other sites.
Absolutely. It's one of the most important obligations to your users you have to honor - to treat their personal data very carefully.
Yes, because there is always risk of compromising database. Remember, that many people uses the same password for many sites, IMs etc so you are making risk for not only information in your system.
People use their same password for more than just your site as well. If an attacker gets the passwords, there are more consequences than just your site. That user's email, bank accounts, etc may also be compromised. Do the diligent thing.
In some jurisdictions/industries, storing login credentials in plain text could be a violation of data protection laws. If you're doing something like that in the US on a system that has even the slightest bit to do with medical or financial records, and you get audited, even if there's been no breach, you'll be lucky if the worst that happens is your clients and suppliers refuse to do business with you until your systems pass audit. There could be hefty fines as well. Even if your system doesn't work with sensitive data, if it's intended for use by people who routinely work with such data, the possibility that they may reuse passwords that are also used to access regulated data would at the very least make an auditor very nervous, and make their client extremely reluctant to work with you, even if you were technically in compliance.
Why wouldn't you hash passwords? It protects you, your staff and your users and it costs almost nothing to implement. Users have a right to expect that your system administrators / DBAs / whoever cannot see their passwords and your administrators have a right not to be exposed to that information needlessly. In any internal/external technical security audit one of the first things the auditors will do is home in on any password columns in the database and determine whether they are hashed or not.
If you generate the password for each user and do not let the user change the password, then you can make a case for not hashing them.
However:
I think of this like crossing a road.
You always look both ways even if the green man says it is OK to cross.
(It is quicker to look both ways, then explain to any watching children etc why you don’t need to in this case)
Also i protected the databases data input gates very well.
I bet every system designer/administrator for every compromised password file in the history of computing thought the same thing.