Can we rely on Hyperledger Composer ACL for privacy? - acl

Composer provides some pretty good ACL features, with enough granularity to prevent unauthorized access based on complex business logic.
I understand that using composer's APIs, an unauthorized user will not be able to read data.
However, what if the user uses Fabric's APIs? How does composer implement their ACL at the Fabric level? Is a business network sharing a single channel? In which case, does it mean that any participant/node can look at the block manually and see private data?
So my question is, can we rely on Composer and assume that if we correctly wrote our ACL file then the data is secured?

I would put it this way, the Composer ACLs are as secure as if you had written Fabric chaincode in Go and had included explicit conditional checks on what data a given transaction can access or update.
The data is stored unencrypted on the blockchain, and it is stored in world-state (in CouchDB for example). So if someone has local access to the files on disk, or the CouchDB database for world-state, they can circumvent the ACL rules. This is not specific to Composer however, and would apply equally to Fabric chaincode written in Go.

Related

how to configure hyperledger sawtooth permission

newbie for sawtooth here. Currently I am working on a POC for supply chain by using sawtooth as their record storage and there is one use case that i am still trying to sort it out. Here is the usecase, let say there is company A and company B, both companies will upload document to the supply chain system and the file url will store into sawtooth. In this case, may i know what is the best design for the permission control? As those documents able to view by all company A and company B staff. thanks!
Once the file URL is stored in the chain, anyone with access to the node will be able to view it. Only allowing certain people to read from the sawtooth chain can be done, similar to how traditional access restriction is given for APIs or servers. You can put the sawtooth system, behind a proxy and an API and give permissions for the access. That is one way to do it.

Hosting JSON Files for Mobile Application

I am creating a mobile application using swift for my organization. The application reads in data in JSON format to populate the information that gets displayed on the application. I already have a method to generate the JSON files, but I need somewhere to host the actual files. I have an AWS account and an instance running, this is where I initially was hosting my JSON files but I got an email from AWS saying that having the app constantly grab the JSON files that I stored on the site resembled scanning behaviour, which is not allowed apparently. So I was wondering where I could host JSON files so that my mobile app can read in the information it needs. The biggest thing that I need is that I can host it with a static URL that I can keep calling with my app.
I was thinking of potentially putting the files on an AWS bucket with read permissions and having those get accessed, but since AWS already complained about me doing something like that I'm iffy. I was also thinking of putting the JSON files on Github, but again I'd hate to get an email from github telling me that they don't like that an application keeps grabbing the data.
For background, the app essentially has a hardcoded URL that grabs the JSON data and parses it. I didn't do an api because an API takes some time to grab all the information that doesn't really change that often, it's much easier to generate the JSON files locally and just post them online somewhere. The information on it can be read by anyone too it's not private or anything.
Message from AWS:
Hello,
We've received a report(s) that your AWS resource(s)
information
has been implicated in activity which resembles scanning remote hosts on the internet for security vulnerabilities. Activity of this nature is forbidden in the AWS Acceptable Use Policy (https://aws.amazon.com/aup/). We've included the original report below for your review.
Please take action to stop the reported activity and reply directly to this email with details of the corrective actions you have taken. If you do not consider the activity described in these reports to be abusive, please reply to this email with details of your use case.
If you're unaware of this activity, it's possible that your environment has been compromised by an external attacker, or a vulnerability is allowing your machine to be used in a way that it was not intended.
We are unable to assist you with troubleshooting or technical inquiries. However, for guidance on securing your instance, we recommend reviewing the following resources:
I'm new so it won't let me post links but they attached a couple help links
If you require further assistance with this matter, you can take advantage of our developer forums:
more links I can't have
Or, if you are subscribed to a Premium Support package, you may reach out for one-on-one assistance here:
link
Please remember that you are responsible for ensuring that your instances and all applications are properly secured. If you require any further information to assist you in identifying or rectifying this issue, please let us know in a direct reply to this message.
Regards,
AWS Abuse
Abuse Case Number:
Using an AWS EC2 instance to host static files (which is what it sounds like you were doing?) is pretty standard and I suspect that this is not what Amazon is complaining about. More likely, your instance has been infected by some sort of software which is causing it to request many files from other random servers on the web ("scanning for remote vulnerabilities"). You should check that you have not accidentally publicly posted your AWS credentials (in any form), and consider wiping the instance and resetting it. And of course reply to the email explaining this to AWS.

What is the correct way to create a database desktop application?

I just realized that there is no best way to hide MySQL string connection password in my executable file, especially in JAR file. Even encrypting it in EXE would only slow down the process (although I'm not sure how much time would it take to get an encrypted password from an EXE file).
So, from my understanding, I need something in the middle that would do the add, edit, delete etc to the database. Seems like a job for REST API or maybe SOAP services.
My question is, which one should I use? Or should I use something else? I was thinking Zend Framework to create those REST APIs. Then, I would use Qt to create a desktop application to call those APIs. But if I proceed with REST, my application would be a 3 tier application. Wouldn't it be better if I just create a web application? Maybe I should just stick to desktop application call those APIs since the application is already finished and I just need to change from connecting directly to MySQL to calling those APIs to perform tasks rather than changing the whole application to a web.
Any advice would be very helpful. Thanks in advance.
UPDATE:
I'm looking for a security that would protect my MySQL password connection.
Obfuscator would only obfuscate the code, it won't hide my string database information which In my opinion can be easily found using grep after decompiling the JAR using tools like JAD.
About my application:
Using a centralized MySQL database
Thousands of user
Contains sensitive information
My client uses Linux and Windows
My server uses Linux
All access are done in LAN, no outside connection (from Internet etc)
My current solutions (comments please):
Using REST APIs (safer since MySQL password is in the server)
Using Qt with encryption to the password
It depends on what kind of security are you looking for. Is this to protect the application from the user? To protect the user's data from other users? To protect multiple users' data from one another? To protect the user's data from an attacker?
In a lot of applications there's nothing wrong with storing the database login credentials in plain text. In other cases, you might try:
encrypting a user-chosen database password using a reasonably strong algorithm, e.g. Blowfish, using a hard-coded key;
having the user provide the password and "log in" to the program each time;
storing the database password in plain-text, but encrypt the data using a hard-coded key;
same as the above, but encrypt each user's data using their own provided password;
same as 2 but store each user's data in their own database with their login info as the database credentials;
storing the data on a secure remote database that users have to log into to access via a SOAP API;
using the native filesystem permissions to protect the configuration file holding the login credentials;
same as #1 but rolling your own really elaborate key-generation system: e.g. run the machine SID or a hardware id through MD5 using a randomly-generated salt, and then using the result to encrypt the login credentials.
Remember, there's no such thing as perfect security, so whatever you settle on doesn't need to be unbreakable. It just needs to be tough enough to break to make the hassle of circumventing the security mechanism exceed the value of the data. So, for example, if the data is a list of the top scores in Minesweeper, then ROT13 would probably be enough.
Edit:
I just want to add that, even if you can't get around having to hard-code an encryption key in your application, there are obfuscators for Java, .NET, and most other popular languages/frameworks. One of the key uses of these tools is to hide sensitive hard-coded strings like encryption keys.
Edit 2:
Given the additional details about the app in question, only 1, 6 and 8 would apply in this case. And a SOAP API is more appropriate for #6 as George rightly pointed out.
I also want to mention that there are Java resource obfuscators that encrypt string literals. This is just one example.
It pretty much depends in what environment your app runs
a) db and client local
b) db and client in a local network
c) db is in the internet
my two cents:
a) I would create a single db user and wouldn't use a password but restrict acces to localhost
b) direct connect to the database is fine but I would each user have to login with his own password and grant only the permissions he needs.
c) It's a bad idea to allow mysql connections to a public server. In this case webservices would be a good solution.
Anyway if your case is b or c I would stick with a login dialog for the user.
Maybe you should have a look at this http://www.greensql.net/ tool.
It is like a firewall but for mysql/postresql
So you can deny anything and only allow queries you want to.
If you are using Java for implementing your database desktop application, I would recommend to use Java DB as the database. There is a few ways of securing it, and there are alternatives to having a password in the connection string. I would recommend to read Java DB Security - Security Features in Java DB Release 10.4
It is easy to deploy your application with Java DB, since you can have much of it embedded in the same jar file. I have used it in a Point of Sale application implemented in Java.

Web services Security

Hi I have a question regarding security, and web services.
I need a web service to provide an interface for the underlying mySQL database. I am trying to get a Blackberry Application to store data on the web servers mySQL database through a web service.
My question is, how can I ensure that the bb-application is the only thing that is using the web service? The web service will essential insert data into a table. I want to ensure that only the bb-application is allowed to use this service and not someone who figures out the service and starts spamming my table.
Any pointers, best practices or links are greatly appreciated.
Also what sort of web service is best in this scenario?
Take a look at basic authentication over SSL. Configuring the application to include the username/password in the header should be fairly straightforward and the SSL connection will ensure they're not being transmitted in cleartext.
Use net.rim.device.api.crypto.HMAC to implement HMAC authentication and validation. Establishing end to end SSL connections on a Blackberry can be problematic and dependent on wireless provider support unless your users are activated on a corporate BES (which I srongly recommend as part of the solution if you want robust security).
I am going to assume that the BlackBerry application is made by yourself as well. How you can then do this is by creating a sequence or hash that only your application can create, that the web service can verify. For instance, in the beginning of the process, or better, for each step the web service sends down a key sequence, which maps to an internal dictionary within your application on the method to make the unique hash.
The flow would then be as follows:
Perform data task in BB application
Ready to transmit data to web service
Create unique hash from data + your own information from the mapped dictionary
Transmit the data with the key
Web Service verifies the key. If validation fails, it discards the data completely, if succeeds, it will then do what it needs to do.
Continue.
HTH
Disclaimer: Assuming this is an open ended WS.
Also see my answer here.
I would go with a REST web service over HTTPS it would take your problems away. I dunno anything about blackberry apps so I can't give u any pointers on how to use HTTPS in that platform.
If you are creating a SOAP web service then you want to read about ws-security.
Others have indicated using SSL to secure the site. However, that is only one part of the puzzle. Kyle was close with the second, but didn't quite cut it.
The answer is that every single transaction which is posted to your web service must contain some type of authorization key. That key can be pre-shared and baked into the application OR it can be acquired through some other means and set up as part of the application install / configuration process.
Nearly all companies which provide web services online following this method. The idea is that regardless of the underlying protocol (ssl for example) you have to validate that the request is indeed coming from an authorized device / program. Some vendors have the users create a unique key for each user, some for each device, and others just 1 key for the entire organization. Regardless of how deep you take it there is in fact a key.
The key usually isn't that large. It might be anywhere from 15 to 40 alphanumeric characters.

Linux web front-end best practices

I want to build a web based front-end to manage/administer my Linux box. E.g. I want to be able to add users, manage the file system and all those sorts of things. Think of it as a cPanel clone but more for system admin rather that web admin.
I was thinking about creating a service that runs on my box and that performs all the system levels tasks. This way I can have a clear separation between my web based front-end and the actual logic. The server pages can than make calls to my specialized server or queue tasks that way. However, I'm not sure if this would be the best way to go about this.
I guess another important question would be, how I would deal with security when building something like this?
PS: This just as a pet project and learning experience so I'm not interested in existing solutions that do a similar thing.
Have the specialized service daemon running as a distinct user -- let's call it 'managerd'. Set up your /etc/sudoers file so that 'managerd' can execute the various commands you want it to be able to run, as root, without a password.
Have the web server drop "trigger" files containing the commands to run in a directory that is mode '770' with a group that only the web server user and 'managerd' are members of. Make sure that 'managerd' verifies that the files have the correct ownership before executing the command.
Make sure that the web interface side is locked down -- run it over HTTPS only, require authentication, and if all possible, put in IP-specific ACLs, so that you can only access it from known locations, in advance.
Your solution seems like a very sensible solution to the 'root' issue.
Couple of suggestions:
Binding the 'specialised service' to localhost as well would help to guarantee that requests can't be made externally.
Checking request call functions that perform the actions and not directly give the service full unrestricted access. So calling a function "addToGroup(user,group)" instead of a generic "performAction(command)".