I am working on an embedded system that should support SNMPv3, and I am wondering how to let the user add new USM?
Is it reasonable to let the user add it by SNMP? by HTTPS?
Thanks
Avner
Depends on where you are aiming at with your product:
There are users out there that will only expect to receive some traps from your SNMPv3 device - Those users might not necessarily have access to tooling allowing them to add users via SNMP (or don't want to be bothered with having to install and operate free tooling).
Whether it makes sense to implement a user administration frontpage using HTTPS strongly depends on the amount of muscle your platform has. To me, that sounds a bit heavy-weight.
Most SNMPv3 devices I have come across so far had a simple ssh command-line-based interface for user management, so I would expect that is common practice in the market. Remember, adding users is a one-time activity in most environments.
What you should and must allow in any case is changing users' encryption and authentication keys using the USM MIB - The whole SNMPv3 security concept will cease to be of any value when keys cannot be frequently (ideally, in an automated way) changed.
Related
What considerations are needed when creating a web app that is intended to be used in an industrial plant setting for a company? My specific use case is an industrial facility with several different production plants that would each have its own device for the application interface.
How do companies enforce the usage of such apps on a monitor/tablet? For example, could I prevent them from using other stuff on the tablet?
Importantly, how would security work? They'd share a device. There may be multiple operators that use the app in a given shift. Would they all use the same authentication session (this is not preferable, as I'd like to uniquely identify the active user)? Obviously I could use standard username/passwords with token based sessions that expire, however, this leaves a lot of potential for account hijacking. Ideally, they'd be able to log on very quickly (PIN, perhaps?) and their session would end when they are done.
As long as there is internet connection, I would presume that there isn't much pro/con regarding the use of native applications versus web based or progressive web apps. Is this assumption correct?
What's the best way of identifying which device the application is being run on?
Is this a common thing to do in general? What other technologies are used to create software that obtains input from industrial operators?
--
Update - this is a good higher level consideration of the question at hand, however, it has become apparent why focused, specific questions are helpful. As such, I will follow up with questions that are specific.
Identifying the Area/Device a Web Application is Accessed On
Enforcing Specific Application Use on Tablets
Best Practices for Web App Authentication in Industrial Settings
I'm not able to answer everything in great detail but here are a few pointers. In the environment as you describe we usually see these two options. 1) you tell them what you need, internet, security, if they give you device and how it will be configured 2) they tell you exactly what you need to deliver.
I do not think you can 100% prevent them. We did it by providing the tablet( well laptops in our case) and the OS configuration took care of that, downside we had few devices to support. You seem to hint that there is always an internet connection so I guess you can collect all info about the system and send it back to you daily?
We were allowed to "tap" into their attendance SW and when you entered the facility you were able to use your 4 digit pin to log in if you were out of premisses you could not log in at all. I can imagine the following: you log in with your username and password - this does full verification, after that, you can use 4 digit pin to login for next n hours.
maybe, kinda, depends on what you are doing. Does the browser have all features you need? Our system needs multicast to perform really fast, so we have a native app
touched on this in 1. You could also use device enrolment process. You can also contractually force them that there will be only your software and it may invalidate support contract. It really depends on your creativity. My favourite( and it works - just tell them, there will only be installed my software and if not you will pay me double for support. I only saw one customer who installed some crap on the device when there were told not to
it really depends on what industry you are talking about, every industry is different. We almost always build a custom solution
The enforcement of the device/app usage depends on the customer, if the customer asked for help in the enforcement, then you can provide guide, training and workshops. If the customer serious about the enforcement then it will be a policy that's adapted by all the organization from top to down. Usually seniors will resist a workflow change more than juniors, so top management/executive should deal with that. Real life story: SAP team took 6 months to transform major newspaper workflow, during that few seniors got fired because they refuse to adapt the change.
Security shouldn't handicap the users, usually in industrial environment the network is isolated or at least restricted through VPN to connect multiple sites (plants in your case), regarding the active user: we usually provide guide/training/workshop for the users and inform them that using colleague account or device will prevent the system from tracking your accomplishment/tasks, so each user is responsible to make sure the active account/device is the one assigned to him/her.
It depends, with native you have more controls than web, but if the app is just doing monitoring then most of today apps use web for monitoring and the common way to receive input is REST APIs (even if the industrial devices doesn't support REST API, a middleware could be written to transform the output). If you need more depth about native vs web you need to ask new question with more details about the requirements.
Depends on the tech you are using (native or web), and things I mentioned in point 2: you can use whitelist of devices that's allowed to run the app. overall there are many best ways to track down the device.
How common in general? I think such information can only be achieved by survey, the world full of variations. And having something common not mean its safe or best, our industry keep changing at all levels. So to stay in the loop, we must keep learning and self-updating without reboot.
Every application that generates dynamic content must have a server whose address is embedded inside the application to enable communication with server.
Now in the case of WhatsApp definitely they have also embed the server's address inside the WhatsApp application. For example someone reverse engineer the WhatsApp apk and found the address of the server, as well as he also found the parameters and all the stuff that the application sends to the server (i-e session, token, authentication key etc etc) for successful communication, so is that mean he can use these same parameters structure and the server address in different third party app to play/communicate with the WhatsApp server? Because server is just an electronic device that works on the digital signals and thats it. Server don't know that these parameters are coming from the authorized WhatsApp apk or from third party apk.
If yes, then don't you guys think that there should be solution to that problem?
If no, then what are the techniques and algorithms they are using to stop requests from unauthorized/fake apps.
I believe not any employee from WhatsApp will answer here to share the algorithm, but i know SOF is full of geeks, if someone knows how WhatsApp stops these kind of issues please share, otherwise i will be still glad to know about the advice and ideas that you guys have in your mind for the best security practices.
How banking, paypal etc and messaging apps including WhatsApp works in that scenario and how they stop the issue that i described above?
Important:
I am not going to reverse engineer the WhatsApp, i am just creating a server and fighting with this issue to be solved to secure my server and only accept request from my app but stop requests from unauthorized/fake apps.
Thanks & respect to all in advance who will contribute.
There is no way to prevent malicious reverse-engineering, resulting in a fake app pretending to be the real thing. While you are working on your server, you need to do defensive programming, that is, your server shouldn't assume that the request was sent via the app. So, if you protect your server against all kinds of malicious and deliberate misuses, then your server is safe.
However, that's easier said than done, because your project is developed by a finite amount of people and - if it becomes successful then - the audience contains a swarm of smart bad people.
You will therefore need to detect a subset of features that you need to absolutely protect against misuses and prioritize testing and improving those, by thinking with the mind of a fictional hacker, who would like to either gain unearned profits or do harm to your project. Schizophrenic, I know, but you need to do that on the server. You also need to improve the security of less than critical features, but at a lower priority and log the requests you get, so if SHTF, then you will have at least a chance to deduce what caused it and how.
If the phone app is in your hands as well, then you might implement some additional authentication for each version, like generating a version token for each user that downloads your app. Since the version token generator algorithm would not be in the hands of hackers, they would have to solve that on a per user basis, which is extremely laborius to solve this for several users if done by hand and if they work it out in a way to make it automatic, their solution would be viable only for a version.
So, there is no 100% accuracy in this area, but you can make life very hard and miserable for people payed to hack through your application.
Im using basic auth in nginx, no issue there, but i would like to limit the number of distinct locations a user is authenticated,
The end goal is to prevent user sharing access data to website, since the website does real time "monitoring" of some data, i wan't that if the same user/pass combination is used from another ip, that or either both users stop getting data,
or one of them stops getting data.
I don't think that is a good idea, because a user may log in via pc and mobile phone at the same time and has two different ip addresses that way. Also http-auth isn't designed to do what you want it to. It would have to remember the ip-address and make it expire somehow, when the user leaves without logging out. Altogether would it be difficult to guess for how long the session is valid. Another problem is, that most users don't have static IPs and get disconnected by their providers every 24 hours. What happens if that occurs after a valid login?
The most popular method to deal with this kind of problems are session-cookies. These can be described as a one time password and you can use that for as long as you want or until it expires. SessionIDs are usually saved in some kind of database and making those sessions unique would not be a big deal and may therefor be what you want. Luckily the
ngx_http_auth_request_module would allow you to only implement this missing part and would bring you as close as you can get without developing your own nginx-module (see https://www.nginx.com/resources/wiki/modules/ for available modules).
On the other hand: Don't do that. Seriously. If you care for security, do not try to reinvent the wheel and use something, that has already proven. E.g. ngx_http_auth_jwt_module allows you the use of OpenID, which also sets you free from saving sensible user data on your server (because nobody wants to save passwords unless it is absolutely necessary).
Both of these methods require nginx-modules, which may not be installed on your server. If you don't have the permissions to build them, I would suggest to add that to your question, so that others can suggest solutions for non root servers.
If you want to keep it simpler you should also consider to generate download links each and every time and save ip-address and download link address in a database. Delete entries when a user downloads that file and you are done. For that to work you can use the
Content-Disposition: attachment; filename=FILENAME-HTTP-Header, so that your download.php doesn't save a file that called alike.
May be you can also find some kind of javascript to replace ngx_http_auth_jwt_module and use OpenID with http-auth. That can work, because it is possible to do the authentication with ajax as well.
Last but not least: If you still want to do http-auth, also use HTTPS, because your passwords won't be encrypted by this auth-method by default.
What you want to do is unusual so you will need to write a lot of the logic to handle the process.
Your code will need to store a User ID and IP Address pair for each loged in user and validate each attempted log in against this. As the previous answer pointed out, you will need to expire logins etc. Basically, you need to roll a session handler.
This is not impossible or particularly difficult but you need to write it yourself in one of the scripting languages available to Nginx which are either Perl, which is not recommended due to limited ecosystem in Nginx, or Lua, which is highly recommended due to the massive Nginx lua ecosystem (used by Cloudflare for instance).
You will need to compile in the 3rd party Nginx Lua Module and associated modules or just uninstall Nginx and use the Openresty Bundle which already has everything you will need included instead ... including Redis for storage if you need to scale up.
Here are some tools you can use as your building blocks
Openresty Session Library
Openresty Redis Session Library
Openresty Encrypted Session Module
Note that you can implement Openresty stuff directly in Nginx if you wish without having to run Openresty as it is just a convenient bundle of Nginx and useful module.
I recently finished one of my first AgilityJS projects, which is a web-based file browser that lets you create and manage folders and files, and navigate around the folder tree. I followed the various AgilityJS recommendations regarding the design and ended up with all my HTML and Javascript in a single Javascript file.
Now, I would like to provide a "read-only" version of this app which does not have the ability to add/edit/remove files and folders. I'd like to have 2 user types on the website, one type which can only read the files and folders, and another user type who can administer.
My question is, how do I proliferate these permission differences to my AgilityJS app? I know how to secure my endpoints and operations on the server side, but I'm wonder about the best way to do this on the client side. Should I create a separate version of the app with a limited set of functionality? Should I simply hide certain buttons/features? Are there theories, frameworks, etc.? which deal with this issue? Any point in the right direction would be helpful.
LOL - probably one could write books about that topic. Some very basic ideas:
I would start with the philosophical debate according to MVC. There are people argue with the help of MVC that any piece of code and also any piece of data model should never be implemented twice. Business logic and model to the server. The opposite view is focussing on serving users at any cost - even if that means to double maintain code or the model for the sake of avoiding extra round trips. The way in between defines a master source for business code and model and makes sure to follow on other places that leading master (the master will be changed first). Take your choice. Your answer to that question results into boundaries for how the user interface can/have to look like for the user.
You need to think by hard about a permissions concept. Looking at Microsoft I would assume that they invested for all their applications a couple of dozens man years to make up the permission concepts. The ideal permission concept very much depends on your application. So it is close to impossible to work this out without knowing at least a very little of your application. However the permission concept has to come up with policies deciding on roles, groups, access rigths, access levels, context driven permissions (eg. based IP address), permissions black or white listing (permissions each user has at creation). An example from Microsoft: http://office.microsoft.com/en-us/windows-sharepoint-services-help/permission-levels-and-permissions-HA010100149.aspx
Data on the client is not secured!!! Whatever you do on the client, be it data hiding, encryption, compression... - if this is done on the client there are ways to read the data (even by disabling the data manipulation) or by reverting those. Somebody can send data to your server, where the client should not even have given an update form could be implemented by hackers. So as soon as you start to implement permissions make sure, that for all data you send to clients users are permitted to read and that you inlcude permissions checking for each time you add/update data to the database.
My friend proved it to me by taking the WP7 papertoss games and getting the .xap from it and then posting his own high scores.
Is there any fool proof way to stop this ? (I think xbox live integration makes hacking the high scores impossible but that is for special people )
It depends first of all how the high-scores are sent. I can only assume that what your friend did was take the XAP and modify some internal file or track the HTTP web requests that are used to send the scores to the centralized locations. I have two recommendations for you.
Encrypt. Don't keep scores in plaintext. There are plenty of strong encryption methods that you can take advantage of that will render the scoreboard useless unless the person who tries to read it has the key.
If you send the scores to a web service, never send it in plaintext (once again). From my own experience I can say that web requests can be easily altered and sniffed. So if I see that the app sends http://yourservice/sendscore?user=Den&score=500, I might as well invoke http://yourservice/sendscore?user=Den&score=99999999. Same applies if you plan on using headers.
Be aware, that using the Xbox Live services is only possible if you are a registered Xbox developer, and this is not easy to get.
First of all - is a high score list really that critical that you're worried about an edge case (the common person isn't going to have a dev unlocked phone with ability to modify the *.xap file)?
Second of all, no. There's no fool-proof way to protect your high score list if it is being stored locally on the device. The only way to protect the high score list would be to store it in the cloud via a web service or some other mechanism.
It is tricky to have a secure high score system since users can always modify information on the client side. It's impossible to prevent a determined hacker from looking at your code, but you can make it more difficult by obfuscating your code. PreEmptive's Dotfuscator is currently free for Windows Phone 7 developers and also has analytics built in if you want to use it. This will obfuscate your code and make it harder to read your code. Although it's not fool proof, it's an extra hurdle for hackers to overcome.
The obfuscation would make it harder to find the encryption key you're using to authenticate the high score.