Take a coffee machine that remembers user's preferences. Some users can only use the machine, others can configure it, still others can upgrade the software...
The first idea to implement these 'user-specific' settings and privileges would be to start creating a User class, a Privilege class, assigning privileges to certain actions, ...
But is that a good idea?
Would it be possible to reuse the OS's user account system to accomplish this?
If so, would it be a good idea?
Related
I wrote a small application that is commercially used by an company. The application runs stable, but I am currently trying to get it to work on the companys computers after they have updated their security policy.
I am using Visual Studio 2019 and publish the application as an One-Click Application. It works on my personal system and also had worked on the companys systems. Besides the .Net system libraries, I am using the File Dialog to save and load files, TCP sockets to communicate with one other software and read and write one registry key in the user space.
Before their policy switch, it was possible to install it and run it. After the switch they required Admin Rights to install it and it will work, but as soon as the IT department revokes the admin rights, the program will not launch.
I am a stuck, because the users I work with are not very technically versed and Information I get is usually not very helpful. It is also not very helpful that I can't reproduce the issue and at that point it is just stabbing in the dark.
So would be glad about any help regarding to fix it on my end, be it settings for the publishing process, information they can extract and send me, or how I would be able to reproduce it.
I tried a few things on changing how the application is published, but that didn't change if it runs after the revoked.
I'd recommend working on two sides concurrently :
First, trying to have a usual process / documentation for the IT of your clients so that they are aware that your software needs admin rights.
It's not uncommon that some employees need some specific software, which requires elevated rights, while the IT department put restrictions on the actual user rights.
You need to make the IT departments of your customers aware that your software falls into this category. It's "their problem" to make it work, and for future clients you should even add some words about this in your contract.
This will ease the things if you give some clear, standard formatted documentation about this to your customers, so that they can forward it to their IT department for proper collaboration.
Of course, in parallel, you want to understand what is going on, and see if you can "fix as much as possible" yourself, as you are trying to do.
For that, a very good way is to have some "special users", some of your customers that you know are willing to help you by giving you reports of installation, because they have a more cheerful personality and/or are more technically savvy so they can easily give you some meaningful information.
With these users, you can try to experiment a bit more, add some proper logging to the installation process as much as you can and do rapid iterations to try to improve things.
I have noticed some websites allow creating user profiles without a database such as MySQL, at least the wappalyzer does not detect it. How do they create such user profiles? Perhaps they create a file with the user details in it?
For that to work the only real requirement is to be able to save some data, no matter how. A database is the typical approach, but by no means the only.
Besides that, a file on the server filesystem is possibly the easiest way. Just drop one on some folder and add lines to it when users register, and read and parse them when a user wants to login. This is, more or less, how Unix-based systems store user accounts, for example. Any website could use the same approach when it doesn't has much traffic.
Other options could be delegating the login work entirely. Things like OpenId or use a Facebook account for example. That way the site ask for account details to external sources, and are those who actually store that data, so your site would have no database at all. A webservice operated on another server is also a variation.
In short, the only requirement is to be able to store information in some way or another, and databases are just one option, but many other alternatives exist.
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 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.