I wrote an application that stores several things in the registry. When I first started, I added them to HKEY_LOCAL_MACHINE, but kept getting permission errors writing to the. So, it was suggested that I use HKEY_CURRENT_USER, that worked until I realized that I am not able to access them from another account. How can I write to the registry but allow all accounts to access read and write to it?
I used the Python module _winreg.
HKEY_LOCAL_MACHINE/Software/YourSoftware, needs Admin permissions and is for install-time data, or HKEY_CURRENT_USER/Software/YourSoftware, which is for data pertinent to this environment only (this user, this profile etc.)
EDIT: An alternative would be storing a config file and setting the right permissions at install time.
2nd EDIT: I've read in another comment that you want to be sure only your application modified some file, so you store the modification times. Workarounds:
encrypt the file-not-to-be-modified, best is with a user-generated key
make a service, install with a special user under which it runs, and make the permissions so, that only this service can access the file
My gut feeling says your requirement to modify a file only by your app, but under any account is very wrong but the more or less correct solutions have to impose additional complexity. Your decision: review your requirements and possibly your design, or add a layer of complexity and possibly cruft.
3rd EDIT: Split your app, have an admin application, which can with admin rights write to HKLM and set the settings. Normal user rights should suffice to read HKLM
You'll either need admin permissions to write to HKLM, or settle for non-global reg keys. Behavior is going to vary somewhat between different versions of windows.
If you want to write to the registry so that all users can read it, you will need to run your program with administrator privileges.
You might be happier storing your information in a file instead, which will be easier to manage.
One other possibility would be changing the security on your HKLM keys to R/W for anyone. Although the idea that this is somehow security against modification seems a bit of a stretch.
Regedt32 has the ability to set the keys, so the underlying API must have it too.
All that said, this is a screwed up way to run an application and shows a sever lack of understanding of security and security models. (In other words, typical windows development.)
How did I get so cynical.....
Related
I am building an application that uses two legged authentication. I got an API key and API Secret, but now I am confused.
I am currently storing my api keys and secrets in a .yml file. But I would like to distribute the .app code, which will end up having the .yml file.
But the .app file will contain the .yml, file, which is bad since everyone will be able to see the API key and Secret.
How can I store the API key and Secret such that my application can access the key and secret without the users seeing it?
The answer depends on a few variables:
Is your source included?
Is it possible to use a server to call the API for you? If so, can you also apply restrictions to the call that the server makes?
Is using compiled code for where you store the key an option? If so, is it possible to obfuscate it?
Here are my suggestions for different scenarios from experience:
The source is not included and using a server is an option, and restrictions can be applied, however using compiled code is not an argument
Then use a server to make requests. Let's say you need to make a call to example.com/api/v1, and you want to call a specific function with a specific set of arguments, then you can only allow requests to that specific API, with that specific set of arguments, and that specific function. This way, it means nothing to a potential attacker since it only calls to one function and nothing else.
The source is not included, using a server is not an option, and compiled code is not an option either
Well, there's not much you can do, obfuscation is your best shot. The best way to do something like this is to hide it deep within your code, and make it obscure, etc., etc., etc.,
The source is included, using a server is not an option, but you can use compiled code
Use really obfuscated assembly and don't share the source for that if you can. For instance, you can have red herring instructions, and just like before, you should hide it deep in your code.
The source is not included, using a server is not an option, but you can use compiled code
For this it's the same as above, since the source for the assembly wouldn't be included
If I didn't list your scenario here, then feel free to comment and I'll edit my answer
While I consider the existing answer technically correct, it may be wroth pointing out that there are some security issues with hardcoding api keys in distributed software.
The nature of an API key is volatile, it is not designed to last forever.
What would happen if the API key is invalidated? Wouldn't that render all distributed software useless then?
And what would happen if the API key has write privileges and is compromised? How could you distinguish between legit and malicious writes?
Even though I understand the overhead, a scenario were the end user can set dedicated keys, obtained by the end user itself, and a way to replace that initial key, would help with above two questions.
One of the API Key features is to be used by a machine that acts on behalf of a user, but if all the users are the same, this feature becomes meaningless.
I'm not that expert in that server-side stuff, but I am wondering why I can't just leave the secret key in the setting.py file.
I mean when somebody could see the settings.py I would have been already hacked, right?
So couldn't I just leave the secret key where it is right now?
There are a few reasons, why it is good right from the very beggining to keep all of your secret keys in environment variables. But two come to mind:
You might not always be the only dev working on your site...
Suppose you start with a small site where you are the sole developer. You store all of your secret keys etc. in settings.py which is under version control.
The site is a success and you start hiring some other developers to work on your site with you. Eventually, there will be some things that you really don't want everyone to see, and just maybe you and another person.
Now, you could remove them from settings.py and move them to environment variables at this point. But anything that has ever been in your settings.py will be available through git history. This will be a major security hole.
It stops a bad security problem, becoming a really bad one...
Even if somehow someone is able to see your settings.py, that is pretty bad. But it is a thousand times more bad if they can see all your secret keys.
If they can see your stripe secret key, they can now not only see your settings.py but also really really easily empty your bank account.
If they can see your amazon s3 credentials, now now only can they see your settings.py they can also access all of the confidential documents your users have uploaded (and you can end up with major legal issues). It also means they can use it for free, and you end up landed with a massive bill.
If they can see your general secret key, they can now intercept any of the messages that get sent to and from your server more easily. If you are using pickle to serialize session data, they could even run arbitrary code on your server, and wipe your database (see here for further details).
Imagine you're not very sensible and you re-use a password, you get a notification from 'company X' who let you know your credentials have been compromised. Now someone can get onto your github and see your code. Instead of having to just change your password on github, you have to go round every service you use on every site you have stored there, and update all of those secret keys (assuming the damage hasn't already been done).
Let's also imagine that you are sensible, and you use 1password and have 2 factor authentication set up, so this can't happen to you. All it requires is one person on your team to not be sensible to make this a possibility again, and quite a realistic probability.
You definitely want to store all secret keys as environment variables.
Having said all of the above, yes, if your system has been compromised by someone who knows what they're doing, it won't make any difference and you are probably in a really bad place regardless. But storing secrets in environment variables will stop some attacks, so you should always do it anyway.
Also...
This is useful for non-security reasons as well. You probably want different credentials for your development, staging, production environments, and storing things in environment variables makes this a lot easier. Sure, you could have different settings.py files, but storing things in environment variables means you can update them really quickly without having to do a release.
Let's say I am creating a python-based CMS on GAE (similar to Squarespace/Shopify) which allows users to create a website.
The platform will (automatically?) create a subdomain for each new user and duplicates the application.
Now there are two options:
1) Create a new Database for the new user, WITHIN the master GAE project. (I'm worried that if one user gets a lot of traffic it might slow down ALL websites.)
2) Duplicate the entire project. (This method seems difficult to accomplish because either I have to manually create an instance of the application for each user, or I have to figure out how to hijack gcloud.py (or appcfg.py) somehow and store my login credentials in the code.)
Which choice will most likely provide the most performance for the price? Is choice 2 allowed by Google (or even possible)?
Edit:
I've done some more research about this, and it's not documented very much. I found this in the docs https://cloud.google.com/sdk/docs/scripting-gcloud which talks about running gcloud from scripts, although I don't think that means from python. I am looking into appengine-jenkins to see if it will work for my purpose. Let me know if you have any additional information about this.
Also, it seems like gcloud is adding a create command within the projects command which might be useful for me if I can figure out how to run gcloud from my script. https://cloud.google.com/sdk/gcloud/reference/alpha/projects/create
This question is a bit far fetched (i don't even know if the way i'm going about doing this is correct).
I have a script that gathers some information on a computer. The intent is to have that script ftp/sftp/any-transfer etc some data to a remote server. This script is intended to be distributed among many people also.
Is it possible to hide the password/user of remote server in the script (or perhaps even the implementation details?). I was thinking of encoding it in some way. Any suggestions?
Also, in compiled languages like java or C, is it safe to just distribute around a compiled version of the code?
Thanks.
The answer is no. You can't put the authentication details into the program and make it impossible for users to get those same authentication details. You can try to obfuscate them, but it is not possible to ensure that they cannot be read.
Compiling the code will not even obfuscate them very much.
One approach to the problem would be to implement a REST web interface and supply each distribution of the program with an API key of some sort. Then set up the program to connect to the interface over SSL using its key and put whatever information it needs there. Then you could track which version is connecting from where and limit each distribution of the program to updating a restricted set of resources on the server. Furthermore you could use server heuristics to guess if an api key has leaked and block an account if that occurs.
Another way would be if all of the hosts/users of the program are trusted, then you could set up user accounts on a server node and each script could authenticate with its own username and password or SSH key. Your server node would then have to restrict access based on what each user is allowed to update. Using SSH key based authentication allows you to avoid leaving the passwords around while still allowing authenticated access to your server.
Just set the name to "username" and password to "password", and then when you give it to your friends, provision an account/credential that's only for them, and tell them to change the script and be done with it. That's the best/easiest way to do this.
to add onto jmh's comments and answer another part of your question, it is possible to decompile the java from the .class byte code and get almost exactly what the .java file contains so that won't help you. C is more difficult to piece back together but again, its certainly possible.
I sometimes compress credentials with zlib and compile to pyo file.
It protect from "open in editor and press ctrl+f" and from not-programmers only.
Sometimes I used PGP cryptography.)
I'm trying to write a script which will monitor packets (using pypcap) and redirect certain URLs/IPs to something I choose. I know I could just edit the hosts file, but that won't work because I'm not an admin.
I'm thinking that CGI might be useful, but this one has really got me confused.
EDIT:
sorry if it sounded malicious or like a MITM attack. The reason I need this is because I have an (old) application which grabs a page from a site, but the domain has changed recently causing it to not function anymore. I didn't write the application, so I can't just change the domain it accesses.
I basically need to accomplish what can be done by editing the hosts file without having access to it.
pypcap needs administrative rights, so this is not an option.
And you don't have access to the pcs internals, to the source code or to the webserver.
There are a few options left:
Modify the host name in the applications files with a hexeditor and disassembler.
Modify the loaded application in memory with Cheat Engine and other memory tools.
Start the application in a virtual environment which can modify os api calls. A modified wine might be able to do this.
Modify the request between the pc and the webserver with a (transparent)proxy / modified router.
If the application supports the usage of proxies, it might be the easiest solution to set up a local squid with a redirector.