Im currently in the early stages of engineering a system that utilises a microservices architecture.
I'm at the point where I'm implementing a user login system. I had the idea to have one service that handles all insensitive user information (e.g. username, email, age etc) and then have another service that handles passwords (e.g. storing them, encryption, verification etc).
Having this architecture would mean that user data and passwords would be stored in two completely seperate databases.
I think this is a feasible approach and could improve security.
Is this approach overkill? Obviously I am going to be salting and hashing passwords but having these stored completely seperately gives another level of security.
Are there any drawbacks to this approach?
This approach with storing the credentials in a separate database can indeed make your application more secure. It really depends on how it is implemented, and what privileges an attacker can get.
One example is SQL-injection, it can be difficult to make your whole application bullet proof, but it is easy to make the only request to get the credentials safe. Usually an attacker can get the credentials whenever (s)he finds a leak, not so if the credentials are stored in a separate database.
If the attacker has privileges on the server, there may be no advantage, but I cannot see any drawbacks neither.
If your goal is to improve security I would advice against building your own user login system. However, I think it is a good idea to separate the authentication/authorization from the profiles.
Related
I have a Web base System and I'm using Xampp on it, my database has a password and I'm accessing it through phpMyAdmin.
I have some people working on the same machine where the Web base System is running, we're using the System for specific task.
One thing I'm afraid of is if they can get or find out the password of database (these not include overriding or resetting the password).
Since they are physically accessing the Server, is is possible to get or lets say decrypt the current password? if so, what are the possible ways?
I want to be aware of it and I want to improve the security of the System base on the method that they can do.
There are several layers of security here.
I believe the correct answer to your question is "no, this isn't a risk," but a thorough answer will address all the possible means of exposure.
System accounts
Your operating system has user accounts. This is how you, other users, and various system services (such as the MySQL server itself) authenticate to the operating system. It's a good practice to not share user accounts. These passwords are stored in a salted and hashed form on the server and are not recoverable or reversible (at least, for the purposes of this discussion). There is essentially little danger in this information being compromised by other users on the machine.
MySQL user accounts
MySQL has individual user accounts. These are how individual MySQL users authenticate to the database server and generally should not be shared between users, applications, or services. Like system accounts, these passwords are stored in a hashed form that makes it relatively secure so that there is again little danger in other users looking at the hashed password.
Application passwords
This is the difficult one. Many applications create a user table within the application database in MySQL. This can be incredibly simple; such as a username and plain text password, or can be quite elaborate and secure. Applications such as WordPress, Joomla, phpBB, and virtually everything else implement their own application-level password methods. This may be properly hashed and secure, or it may be plain-text. Without knowing the details of the application, we can't say with certainty. You can get some hint by looking at the password field in the database itself, but this doesn't make it immediately obvious if the password is salted, or hashed with a weak algorithm. Therefore, this is a possible attack vector with which you should probably be concerned.
Another interesting aspect here is network sniffing; an attacker could sniff network traffic to determine a user's MySQL password. A simple workaround is to enforce only SSL-encrypted communications for the users to connect to the MySQL server, and/or only use the socket connection method.
I think that covers on a relatively high level all the possible attack vectors here. I've taken some liberties for the sake of simplifying things; for instance there are some older operating systems that use weakened hashing methods which mean mean those hashes aren't cryptographically secure, and any user with access can probably escalate their privileges (for instance, a user with physical access to the server can restart with another bootable drive, reset the root system password, install whatever keylogger they wish, and restore things. Similar warnings would apply to a user without physical access but with administrative privileges. Depending on your attack vector, these aspects may or may not be of concern to you.
Sure it is possible....
All I would need to do is open up the phpMyAdmin configuration file and have a look at the database access information as it is unencrypted there. Basically any configuration setting which is itself not encrypted will be a security issue.
(Once I have DB access which will probably be System Admin (sa) access I could reverse engineer the users and passwords in the system given enough time as I would have access to the salt in the DB as well)
Other scenarios (I don't know your exact setup) would be:
Checking logs
Sniffing network traffic for any unsecure DB access. Say you aren't using TLS for instance
As I also have physical access to the machine I could also crack the OS users and passwords or even add one for my own use for later on
Short answer is that when people have access to the physical machine your attack surface goes up exponentially.
If you are worried about the system (OS) passwords, they are all hashed with the salt method. Read full here which takes too long to decrypt.
https://en.wikipedia.org/wiki/Salt_(cryptography)
But if it's related to phpMyAdmin, that is totally related how you store user's passwords. You might need to store the hash of the passwords, although the phpMyAdmin admins can override their own hashes and access to user's data.
I'm designing a web application, my first serious web application. It'll have some users with different privileges (RBAC/ACL). As you can imagine, I'm a little bit worried about permission management and security
This is why I was wondering why, in a web application, users are usually stored in the database instead of being database users (e.g. Joomla!). I feel that this is an insecure authentication method: database connection is always done using a db user with full or very high privileges on the db, so what can and can not be done is managed by the web application by writing an RBAC/ACL authorization layer (so I have a bunch of tables in the DB which holds users, privilege levels etc.).
From a conceptual point of view I think that a better approach would be to use more database users (at least one for each level of privileges, or better one for each web application's user) in order to protect the data in the db (if I have a security breach and an attacker finds out the db's connection info, his privileges will be limited by the privileges of the hacked user's account).
I see that this approach is quite clumsy to implement, but on the other hand it's more secure.
Why isn't this approach used? It's just a matter of convenience's sake, or it's a matter of seeking the right tradeoff between security and ease of coding? Or maybe I'm just making a mess and mixing two different things (db and application users) which are meant for two different scopes.
Sorry if the question is stupid, but when studying you learn about DB users and permissions and when you see real software things are done (apparently) in a different way.
Thanks!
That approach does sound more secure, but it is an implementation nightmare, and even more so when you start considering scaling to a million+ users :-O
The best approach (from a security standpoint as well as a feasibility standpoint) is to have two user accounts for the DB. One with read only privileges and one with read/write privileges. Only use the read/write credentials when you need to add a user or change a password. Don't be stupid with these credentials. Never let them make it to the client side either in the form of client side code or comments (I've seen DB credentials inside HTML comments *sigh*).
If your app/user base is really small and always will be, then maybe you can have each user account assigned a sandboxed DB account. That would be more secure. However I would never assume you'll always have a small user base. You never know what the future will bring and it would suck to have to re-implement that.
Recently I had to make an application that later on had to be uploaded to multiple web-servers. Doing this I realized that when storing the admin pass and username's into a json file does not need a db connection so it works all the time. Also when saving the configuration inside json I can just copy my application to web-server and then just go to the browser to do the configuration.
When using a database for this I have to configure this hard coded. Than the db connection would be declared inside a connect.php or config.php. When uploading the application I can't use it because there is no db connection. And I cant set A db connection from within the application itself because I can't login even if I could it would be like a car-key inside a closed car.
My dilemma: Is this the right way, is this save, is this efficient and above all how did you guys do this.
What is the best way to store admin login and configuiration data
The usual solution is to move the password out of source-code into a configuration file. Then leave administration and securing that configuration file up to your system administrators. That way developers do not need to know anything about the production passwords, and there is no record of the password in your source-control.
In other words, it is perfectly normal to have a config.php containing a define("DB_PASS", "topSecret");
Provided access to the config.php file is correctly administered, this method is secure.
Lynks is correct that this is common and is better than having the password in your source control, however if this is a production system that you are designing, I strongly recommend using a different mechanism for user authentication.
Most databases will allow you to use local system users and groups, or external LDAPs to manage your user credentials. Most application servers will have mechanisms for this as well, this is not a new problem. Some systems will allow you to create secure keys (like SSH keys) for trusted users to allow password-less login.
Having passwords in clear anywhere on a production systems is a BAD IDEA, at least use a lossy hashing method to scramble it. Remember as soon as you are dealing with passwords it is YOUR responsibility as a designer and developer to make your best effort to keep it safe. Please evaluate all your options before deciding on the easy solution that could cost you and your customer serious embarrassment later. What technologies are you using? Maybe we can help you find the options available to you.
Remember, nothing lives in total isolation. For example even if this is not a critical system, a lot of places will use a certain pattern for passwords which will give potential hackers a clue for hacking other accounts. If you manage passwords for multiple users, some users use the same password for a lot of things.
This post is not meant as a lecture but a plea for you to make sure you explore all avenues available to you to keep you reputation and your customer safe. Think of it as a challenge, or puzzle and have fun tackling it.
I am assuming the answer is that storing a password in a WEBSQL database on the client side, unencrypted is not safe, but i thought i would ask anyway, the reason I am asking, is I am trying to add a dropbox uploading tool to a web app, but i need the password in plain text in order to access the user's dropbox account, i surely could come up with some foobar way to hash the passwords client side, and unhash them when needed, but if I will be able to unhash them, anyone will be able to do so as well, does anyone have a work around if this is the case?
There is no such thing as 100% secure or safe. The goal of security is to be safe enough. You determine what is the risk, and what is the level of pain you are willing to go through and find the sweet spot.
If you have to get a plain text back from a cypher you have no choice but to use encryption not hashing. Of course you have to have the key somewhere, whether user entered or stored somewhere so the key is vulnerable.
Since this is on a client computer, it may be vulnerable to phishing attacks, social engineering attacks, trojan/keylogger/virus attacks, physical security risks, etc.
storing clear text is a bad idea, but other than that you have to decide what level of pain the users will suffer through.
PKI tokens are a good option if the cost is worth it. otherwise most languages have many various encryption algorithms that can be used effectively.
No, it's not safe to store plaintext passwords, period.
Assuming your users log into your web app with a password, why not use that password to encrypt their (salted) dropbox password? That's still less than satisfactory from a security standpoint, but it's better than nothing.
Using the words "foobar" and "dropbox" in the same paragraph is a clear signal that you're asking for trouble with a home-grown solution. You're asking your users to trust you with the security of their dropbox data, which means you're accepting an awful lot of liability. You're also asking your users to violate one of the fundamental laws of security: Never trust your security to a third party.
The best advice I can offer is to delegate all security-related tasks to an expert, and have that code audited by another expert.
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?
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.
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:
You will have to explain to everyone that audits the system why you are not hashing the passwords.
You will have to have some way of proving that a system admin did not look at a user’s password then logon as the user.
A lot of programmers will think you don’t know what you are doing.
What if the system is changed at some point, or the code gets copied into another system.
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)
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.
Yes, because, e.g., people having access to the database can easily impersonate other users.
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 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.
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.
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.