We are developing open source benchmarking software that users can download, execute on their system (which runs some benchmarks for some stuff) and then uploads the results to a central database. Those anonymous, crowdsourced benchmark results are then displayed on a website for everyone to see.
A big feature of this software is that it's open source. It will be hosted on GitHub and will include instructions for anyone to download and compile the source themselves, for peace-of-mind or whatever just incase people don't trust our program.
But we obviously cannot divulge the security credentials that allows the software to upload benchmark results to our central database. So we aren't going to include these in the public source.
So people could compile the software themselves (which is good) and use it, but it would be useless because the software wouldn't be able to upload to the database, which is the entire purpose of the crowdsourcing software. So users would be forced to use "our build" of the software that has credentials hidden away inside. Many people are smart enough to not bother with unfamiliar .exe's these days, so that doesn't help the situation. Also, since the source is open, anyone could modify it, compile it and distribute with malicious intent, saying that it's our software.
How do you get around this problem of security credentials in open source software? Obviously rule #1 is you don't include it in the distributed source. But if the credentials are required for the software to function as intended, then what do you do? We want to keep it open source so that users have a reason to trust the software.
You can ask for each project owner to register into your site, create a public/private key pair for them and use an asymmetric encryption for identify your results source
Related
I am a doctor who is seeking a solution for my patients. I often receive medical CDs from my patients which contain their radiological data. What I need is a web solution which I can integrate with my web site. But the caveat is that I dont want this to happen via Choose File. Most of my patients are old people who doesnt know much about internet or computers. So I want a single button on my web site which will copy the entire CD in the CD drive and send it to me without any user intervention. Is it possible?
Update:
OK thank you all. I did not intend to break copyright issues. Actually, I thought a user who will hit that "button" will also give permission to access their files. I completely understand your concerns and I completely agree however - as an end-user - this is the problem requiring a solution in my case. After the COVID none of my patients can come to clinical visits and I need to see their follow-up. In neurosurgery, this is very important. I do not know if it is OK to send links (and sorry if it is not) here but for example, this web site makes something similar to my idea but it is not free and it is so complicated for my -low socioeconomic - patient profile.
My target population mostly deals with brain tumors and their level of concern for copyright issues is so low for that reason. I don't mean taking everything from them without their will but this is the case. So again thank you all for enlightening me and I am again sorry if I break the rules of this website.
Introduction
I'm going to go through the reasons as to why the specification as stated, cannot be implemented, and also as to why older technologies that may have allowed this implementation cannot be used.
Do note that even older technologies, would have required some sort of installation or agreement from the user- as a minimum 1 click.
Also note: It is possible to get files from a users system, but you still have to get their agreement through an action or prompt from their part!**
As to what you could do? Tukan already covers some nice alternatives but if I do think of something I will add it!
Basic Explanation
The most basic explanation is that this would be a giant unprecedented security hole. It would mean that browsers would allow a site to access files from a users computer hardware (DVD) without the permission of the user or the active actions of the user.
In your case you do have a valid non-malicious use for it. Imagine however all the malicious websites that would use this mechanism to steal stuff off the DVD/CD that is in the users tray. Imagine the privacy issues, security breaches, and even minor stuff like copyright issues.
Finally, and even worse, if the specific requested allowed access to the whole file system (including all drives like C:), a malicious site could steal everything on a user's system.
The positive (and negative for you) is that browsers have been incrementally locked down over the years and technologies/plugins/extensions/features have been incrementally either locked down, or deprecated/removed. Such technologies include: active X, java applets, and flash.
Finally, browsers like chrome and internet explorer themselves now'a'days run in sandboxes. See for example the article (and this is from 2013!!): Sandboxes Explained: How They’re Already Protecting You and How to Sandbox Any Program
They’re restricted to running in your browser and accessing a limited set of resources — they can’t view your webcam without permission or read your computer’s local files. If websites you visit weren’t sandboxed and isolated from the rest of your system, visiting a malicious website would be as bad as installing a virus.
Other programs on your computer are also sandboxed. For example,
Google Chrome and Internet Explorer both run in a sandbox themselves.
These browsers are programs running on your computer, but they don’t
have access to your entire computer. They run in a low-permission
mode. Even if the web page found a security vulnerability and managed
to take control of the browser, it would then have to escape the
browser’s sandbox to do real damage.
Active X (Deprecated) (Internet Explorer)
Let's start by saying that Active X would require the user to change their Internet Explorer Security Settings so we can strike it off immediately.
If a user did change their settings (see: Enable ActiveX controls in Internet Explorer ) and Enable for IE 11, a developer could use active x to access files on a users system.
Also note Active X is deprecated and rumour has it that it may not be around for long.
Java Signed Applets
Java Signed Applets could access the local file system.
However, Applets are no longer supported in firefox and chrome. They do run in Internet Explorer though IE is deprecated as well (since people are moving to Edge).
There's a very well written answer on the topic here: How do I run Java applets? [duplicate] and Why is the Java plugin (JRE) disabled in Chrome?
Adobe Flash (Previously Macromedia)
First off, flash has been removed from most Internet Browsers and is officially considered dead. Additionally, after Flash Player 10 it was possible to load a file but the user had to select it himself through a dialog (see: Can Flash action script read and write local file system? ).
FileSystem and FileWriter APIs
You can read and write using this API. However, it again requires the user to interact with the webpage and to select the files themselves.
References
Is it possible to access local file via javascript?
Sandboxes Explained: How They’re Already Protecting You and How to Sandbox Any Program
Enable ActiveX controls in Internet Explorer , Enable for IE 11, and active x to access files on a users system
Java Signed Applets could access the local file system, How do I run Java applets? [duplicate], Why is the Java plugin (JRE) disabled in Chrome?
Can Flash action script read and write local file system?
As Andrew mentioned this SO is used for Q&A from/to developers. I'll try to give you a general idea what could be done.
Who should do it?
I think you need some freelancer who would create a code for you.
The mechanism you are describing is not possible due to security issues.
Web page should not have access to the HW, as you would like, without user
interaction.
What is then feasible?
I think what is feasible is an application (thick - meaning .exe file) which would be executed by your patients which would search for a CD/DVD drive, pack it and send it via secure channel to your server. They would need to download it and execute it.
If you have elderly patients you need to visually confirm that the data has been send using some clear message.
Something like: Thank you for sending the data to Dr. Jones. All data has been received.
Secure channel can be for example: ftps, sftp, https, etc.
On your side you would a have a daemon which would serve as endpoint for your patient's data. After receiving the data it should be moved immediately outside the uploading folder.
Edit
One more option that came into my mind would be to distribute a tailored USB key to your patients with such application, which would be executed upon insertion.
Can a running nodejs program cryptographically prove that it is the same as a published source code version in a way that could not be tampered with?
Said another way, is there a way to ensure that the commands/code executed by a nodejs program are all and only the commands and code specified in a publicly disclosed repository?
The motivation for this question is the following: In an age of highly sophisticated hackers as well as pressures from government agencies for "backdoors" that allow them to snoop on private transactions and exchanges, can we ensure that an application has been neither been hacked nor had a backdoor added?
As an example, consider an open source-based nodejs application like lesspass (lesspass/lesspass on github) which is used to manage passwords and available for use here (https://lesspass.com/#/).
Or an alternative program for a similar purpose encryptr (SpiderOak/Encryptr on github) with its downloadable version (https://spideroak.com/solutions/encryptr).
Is there a way to ensure that the versions available on their sites to download/use/install are running exactly the same code as is presented in the open source code?
Even if we have 100% faith in the integrity of the the teams behind applications like these, how can we be sure they have not been coerced by anyone to alter the running/downloadable version of their program to create a backdoor for example?
Thank you for your help with this important issue.
sadly no.
simple as that.
the long version:
you are dealing with the outputs of a program, and want to ensure that the output is generated by a specific version of one specific program
lets check a few things:
can an attacker predict the outputs of said program?
if we are talking about open source programs, yes, an attacker can predict what you are expecting to see and even can reproduce all underlying crypto checks against the original source code, or against all internal states of said program
imagine running the program inside a virtual machine with full debugging support like firing up events at certain points in code, directly reading memory to extract cryptographic keys and so on. the attacker does not even have to modify the program, to be able to keep copys of everything you do in plaintext
so ... even if you could cryptographically make sure that the code itself was not tampered with, it would be worth nothing: the environment itself could be designed to do something harmful, and as Maarten Bodewes wrote: in the end you need to trust something.
one could argue that TPM could solve this but i'm afraid of the world that leads to: in the end ... you still have to trust something like a manufacturer or worse a public office signing keys for TPMs ... and as we know those would never... you hear? ... never have other intentions than what's good for you ... so basically you wouldn't win anything with a centralized TPM based infrastructure
You can do this cryptographically by having a runtime that checks signatures before running any code. Of course, you'd have to trust that runtime environment as well. Unless you have such an environment you're out of luck - that is, unless you do a full code review.
Furthermore you can sign the build by placing a signature within the build system. The build system and developer access in turn can be audited. This is usually how secure development environments are build. But in the end you need to trust something.
If you're just afraid that a particular download is corrupted you can test against an official hash published at one or more trusted locations.
I have recently gotten in touch with a small software company that created a piece of software that I would like to modify and resell under their name. The CEO has agreed to collaborate with me on this project. They will provide everything I need to develop and I will develop the software to the liking of a niche market I am close with. The one condition is the code needs to be secured against theft (from me or any outside entities). Anything that will prevent the source code or copies of the source code from leaving.
Is it possible to set up a remote server in their office that will limit all network activity except through ports necessary to run the development environment (db, data-feeds)? Could this be secure enough? Does anyone have any other ideas?
I'm going to build a website for file manipulations. The idea is that the user will manage to upload his files to the website, and click the "manipulate" button, then he will get the resulted file. Also the user will have to pay in accordance with the amount of files he's trying to manipulate.
The code for the file manipulation is already written in JAVA.
The thing is, some of these files will probably be truly sensitive and private, so users will not be delighted to upload to my site over the internet.
I thought about making a local version of the website, and let the user download it (the local version) to his computer (and the only access the internet will be for the payment action).
But there seem to be two problems:
When i'll decide to change anything in my website, it will not affect the local users.
The local site will be very easy to "crack" in order not to pay...
This is my first website,
do you have any suggestions of how to solve one of these 2 problems?
Thanks!
Concerning question
(1) you would have to implement some update mechanism, for example your "local web site" (which might be a .jar file containing a web server) could check over the internet if a new version is available and then download and install it (however, you should generally ask for user's permission to do so, as many users are not delighted with silently auto-updating software). Concerning question
(2) you might use some code obfuscator to make your compiled java classes more difficult to decompile, and use an encrypted SSL connection for the transactions related to payment (while checking for server certificate to avoid man-in-the-middle attacks by the end user); however any software that a user can have on its computer will be eventually cracked by somebody. Therefore, the best solution is possibly to keep all on your server, while securing as much as possible the whole: use encrypted connections with SSL for everything, or even if the files are highly sensitive, provide a public key so users can encrypt their files with GPG (or similar software) before sending them to the site, and encrypt the files to be sent back to the user by using its public key (that he/she has to provide you and that is not critical at all to be transferred over the internet). Also carefully check the security of your web server and all the software running on it, to avoid bugs that might allow somebody to hack into it. Using the encryption with GPG/public keys and only storing encrypted data on your server might be already a good protection (but you have to make sure that it is impossible to get your private key in any way!).
We have this computer code which requires anyone who has access to it pay a license fee. We will pay the fee for our developers but they want our sysadmins to be licensed too as they can see the code archives. But if the code is stored encrypted in the archives then the sysadmins can see the files but not see the contents.
So does any software version control system allow encryption so that only the persons who are checking out the code will require the key and so be able to see the files decrypted.
I was thinking it wouldn't be hard to add this to pserver and cvs but if it is already done elsewhere why reinvent the wheel.
Any insight would be helpful.
There is no way to set up a source control system that can perform server-side diffs in a way that would prevent a sysadmin from at least theoretically accessing the contents. (i.e.: The source control system would not be able to store the decryption key in a place that the sysadmin couldn't access.) Unless your sysadmins habitually browse the source control database contents, such a system should have no practical difference from an unencrypted system from the perspective of your vendor.
The only way to make the source control database illegible to a server admin is to encrypt files on the client before submitting them to the server. For this to meet the desired goal, the decryption keys would need to be inaccessible to the admins, which is unlikely to be practical in most organizations since server admins typically have admin access on all client machines as well. Ignoring this picky detail, it would also mean that all your source control system would ever see is encrypted binaries, which means no server-side diff or blame. It also means potentially horrible bloat of your database size since every file will require complete replacement on each commit. Are you really willing to sacrifice useability of your source control system in order to save licensing fees and/or placate this vendor?
Basically, you want to give all your developers some secret key that they plug into the encryption/decryption routines of git's smudge and clean filters. And you want an encryption scheme that is capable of performing deltas.
First, see Encrypted version control for some examples in git. As written, this can dramatically increase disk usage. However, there are ways to make more "diff-friendly" encryption at the cost of some security. See diph for an example of how you might attack that. Also, any system that uses AES-ECB mode would diff quite well. (You generally shouldn't use AES-ECB mode because of its security flaws... one of those security flaws is that it can diff quite well... hey, that's what you wanted, so this seems a reasonable exception.)