This question already has answers here:
Can I really not ship open source with Client ID? [closed]
(2 answers)
Closed last year.
I'm using Google's Perspective API and have an API key. I've restricted this to the specific domain I'm going to be using, but I would like to know if it's safe to release the key in my code? As this would be in the client's browser I don't want to make a backend just for that, but I will if necessary.
Essentially: Is it safe to share a domain restricted API key?
I do not think it is safe. Google does not recommend it. You can check the official article for the best practices.
"Do not embed API keys directly in code: API keys that are embedded in code can be accidentally exposed to the public, for example, if you forget to remove the keys from code that you share. Instead of embedding your API keys in your applications, store them in environment variables or in files outside of your application's source tree."
Related
I am working on a desktop application using GCP Speech-to-Text API to perform streaming recognition. I'm using Python 3 and Google client libraries, google.cloud.speech. I've started off the transcribe streaming infnite Python sample and built around those concepts, and everything works nicely. I'm now trying to get to the end user access question, as I'm currently using a service account file for development purposes, which I'm obviously not willing to distribute to all users.
Basically, how do I give access to my end users to the Speech-to-Text service for streaming recognition in the least intrusive way possible? I have no need for accessing storage or the like, as I don't access buckets contents and stream all audio directly. I actually don't need any user information, I only need GCP to process the STT requests and send me the responses.
I see 2 solutions that should work on paper, out of the three the documentation mentions (I leave out the service account file ones):
API key
OAuth2
API key
API keys sound like my dream option: it's simple, doesn't require user interaction past initial setup, I can manage such keys in GCP's console, and it should be able to grant access to what I need (as I effectively don't need any user info, an account is mostly irrelevant).
However, how to use an API key using the Google Speech client library totally eludes me. I can see a PUB/SUB Go example, but I can't find any mapping to Python. I'm not even 100% sure it can work, as the Go documentation for the option seems to note it only works for JSON-over-HTTP, and I believe the client library for Speech-to-Text is using gRPC.
Yet, at least with a JSON non-streaming recognize request, I can use such an API key, and successfully did so manually using cURL on the command-line. So I still have a little bit of hope, in case the gRPC restriction either isn't true or doesn't concern my use case.
This part's question would summarize as: "how do I specify an API key using the Python SpeechClient?".
OAuth2
This sounds like my second-best option, as it uselessly asks the user for authentication while I don't actually need any personal data. Yet, I still have serious issues I'm struggling to overcome:
How do I reliably store info that prevent me from having to re-ask the user for authorization every single time the app runs? google_auth_oauthlib's InstalledAppFlow doesn't seem to provide such feature, so I'm rolling my own based on google.oauth2.credentials.Credentials.from_authorized_user_file() after having saved them with the to_json() the first time I obtained them with InstalledAppFlow. I'm however confident this will not last, and I'm really not sure how to check whether the credentials are still good before I fail to use an API with them (e.g. I can't seem to be able to rely on Credentials.valid before they actually get used).
There seem to be no specific Speech-to-Text scopes, and the required one is way broader than what I need, leading to an overly complex and frightening authorization request. And no, without this scope I cannot access the Speech-to-Text API, I tried :)
Summary
To summarize: what is my best and least-intrusive option to provide credentials to be able to use GCP Speech-to-Text in my desktop application?
I am writing a desktop app using PyQt5 which uses the Wordnik API to get word definitions. I do not have server-side access, nor do I wish to invest in acquiring it. Is there any way I can reliably hide my key so I can share my program on GitHub?
At the very least you could store your API key in a separate source file (which you would exclude from the repository via .gitignore) and check for exceptions while importing that file (see this), alerting to provide own API key if that fails.
Storing the API key in a non-source configuration file is another option, but then your worries are in storing that file in a way that is not accessible to the end user of your application.
Unfortunately, no, our Wordnik terms of service don't allow for sharing keys where they are accessible by end-users. If your app is noncommercial you can share instructions for users to help them apply for and add their own Wordnik keys to their copy of the application (and this also helps you, in that your key won't hit our API limits based on your users).
If this is a commercial application, please get in touch with us (apiteam#wordnik) with more details about your use case as we are looking into how to make this easier. As a small nonprofit with limited engineering resources we can't promise a quick solution but since our mission is to find & share every English word we're always interested in learning more about how folks are using our API. :)
Thanks for using Wordnik!
Im looking at security threats to my java application when doing updates.
Also looking for ways to update my application. If there is an urgent update needed that it will be forced onto the user. Also what would be the security issues with these ways of updating?
You need to be more specific. What mechanism do you use to update your application?
A way to update your app is, for example, to replace single class files.
In general you have to check the source of the update. A possible attacker could try to fake an Update (class-file) to get into the host. To counter this threat you should sign your updates with a private key and use your public key to check if the signature is valid. (Overall you should sign your applications/jar-files)(Java Code Signing)
Code signing is also usefull if an attacker tries to trick the user to install some manipulated update.
If you use object-serialization you need to be aware of additional points (Object (De-)Serialization Vulnerabilities)
Another question Stackoverflow about updating java applications: How can I write a Java application that can update itself at runtime?
How do you secured a key into your iPhone application?
I have an API key that is used by the client application, and do not want anyone to see it, only the application should be able to read it.
1) how do I safely store this in my application? storing it into a variable? is good enough?
2) What happens if someone decrypts my application? (Is that possible?)
There's a lot of questions here so let me answer one at a time:
How do you secured a key into your iPhone application?
I assume that you are trying to secure it from the user of your application. This is impossible unless you are using a trusted computing platform, ie. a platform that can be trusted to not obey orders from its owner (sometimes called treacherous computing for that reason). iPhone is not such a platform to my knowledge.
I have an API key that is used by the client application, and do not want anyone to see it, only the application should be able to read it.
If your application can read it then the owner of the platform that your application runs on can read it as well. (The exception would be a trusted computing platform - see above.)
how do I safely store this in my application?
You can't.
storing it into a variable?
You might.
is good enough?
No.
What happens if someone decrypts my application?
Then he gets your key.
Is that possible?
Yes.
If you don't want your users to know your key then don't give it to them in the first place. Set up a proxy server that your application would connect to and keep your secrets there.
There's an old saying that every secret has to be treated like a public knowledge unless it's known by no more than two people. This applies to software too.
Consider storing the key in the iPhone's keychain repository. Take a look at the Apple provided keychain sample app here:
http://developer.apple.com/library/ios/#samplecode/GenericKeychain/Introduction/Intro.html
Hope this helped. Good Luck.
I agree with Greg Thompson, Apple recommends the use of the keychain to store secure data such as credentials.
By the other hand there is a couple of articles around the web that says that the keychain is no longer "the safer zone", because some people were able to decode its data (and pretty quick).
With iOs 4.0 and later, some improvements about security where made, that is called Data Protection (you can google it like: iOs data protection).. if you are interested in this topic, you'll find the Session 209 - Securing Application Data from WWDC 2010 Session Videos very interesting ... You can get this video for free via iTunes store - iTunes U
Hope this helps
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
If I had let's say a sensitive report in PDF format and wanted to send it to someone, what is the most secure way?
Does a desktop application make it more secure? Since we are basically doing a client to server communication via private IP address? Then add some kind of standard encryption algorithm to the data as you send it over the wire?
What about a web based solution? In web based, you have a third person in the loop. Sure, it would do the same kind of encryption that I would have on a desktop.. but now instead of client->server directly, you have client->server | server<- client... You also have exposure to the broad internet for any intruders to jump in, making yourself more open to man-in-middle attack... One thing the web has going for it is digitial certificates but I think that is more authentication than authorization.. which the desktop problem doesnt have?
Obviously from a usability point of view - a person wants to just goto a web page and download a report he's expecting. But most secure? Is desktop the answer? Or is it just too hard to do from a usability perspective?
OK there seems to be some confusion. I am a software engineer and am facing a problem where business users have some secure documents that they need to distribute - I am just wondering if using the web and SSL/CA is the standard solution to this, or maybe a desktop application could be the answer??
The method that comes to mind as being very easy (as in it has been done a lot and is proven) is just distributing via a web site that is secured with SSL. It's trivial to set up (doesn't matter if you're running Windows, *nix, etc) and is a familiar pattern to the user.
Setting up a thick client is likely more work because you have to do the encryption yourself (not difficult these days, but there is more to know in terms of following best practices). I don't think that you'll gain much (any?) security from having to maintain a significantly larger set of code.
Most secure would be print it, give it to a courier in a locked briefcase, and have the courier hand deliver it. I think that'd be going overboard, though :)
In real world terms, unless you're talking national security (in which case, see courier option above), or Trade Secrets Which Could Doom Your Company (again, see courier option above), having a well encrypted file downloaded from the web is secure enough. Use PGP encryption (or similar), and I recommend the Encrypt and Sign option, make the original website a secure one as well, and you're probably fine.
The other thing about a desktop application is: how is it getting the report? If it's not generating the report locally, it's really doing just as many steps as a web page: app requests report, report generated, server notifies client, client downloads.
A third option, though, is to use something other than the website to download the reports. For instance, you could allow the user to request the report through the web, but provide a secure FTP (SFTP or FTPS) site or AS2 (or AS3) connection for the actual download.
Using a secure file transfer (or managed file transfer) is definitely the best option for securely transferring electronic data. There are smaller, more personal-use solutions out there like Dropbox or Enterprise solutions like BiscomDeliveryServer.com
Print it off, seal it in an envelope, hire some armed guards for protection and hand deliver it to them.
You may think its a silly answer, but unless you can identify what your threat vectors are any answer is pretty meaningless, since there is no guarantee it will address those threats.
Any system is only as secure as it's weakest link. If you sent the document securely and the user downloaded / saved it to their desktop then you'd be no better off than an unsecure system. Even worse they could get the docuemnt and then send it onto loads of people that shouldn't see it, etc. That leads on to a question whether you have an actual requirement that they can only view and not download the document? If not, why go to all this effort?
But if they are able to down load it, then the most secure method may be to send them an email telling them that the document is available. They then connect to a system (web / ftp?) using credentials sent separately to authenticate their access.
I'm surprised no one has mentioned a PK-encryption over email solution. Everyone in the "enterprise" gets a copy of everyone else's public key and their own private key. Lots of tools exist to do the heavy-lifting. Start with PGP and work from there.