I have 2 google adsense accounts. I plan to create one more. I want to be safe and login to every account from different IP's. I don't want to use public proxies because they can have bad history. What could be solution?
You can access every account from diff IPs by using TOR. Check it out: https://www.torproject.org/
Related
Google API Server To Server service account key is a simple json or p12 file which can be compromised in some scenarios. Is there a way to limit its use to specific IPs or domains from Google Developer Console? The support topics there are not helpful at all.
No service accounts cant be restricted to IPs or Domains. Currently if you have the correct credentials then you can use them.
This is why you need to keep them safe. However that being said i think its a good idea. I am going to see if i can find someplace to add it as a feature request.
Note for openid signin
Signin returns an id token this id token can be verified verify the hd claim matches your domain name. Again this only works if you are authenticating with the openid scope.
Response from Google
I contacted one of the developers on Google identity this was his response.
IP restrictions had some value many years ago. Now, most of the apps are hosted in the cloud and traffic can move around the world thus making the IP restriction not very useful. If service account credentials are compromised, it is time to get a new credential or they were used in an incorrect way.
We have an application that uses a couple different Google APIs (Login, Classroom). We originally wrote end-to-end tests to make sure that these integrations worked on a very basic level. Unfortunately, it looks like our end-to-end tests have started failing because Google is detecting "suspicious" login activity from the Google accounts we created to do the integration testing and is presenting Captcha's etc..
Is there anyway to get Google to whitelist an account so that they don't run it through all their security checks? We literally only use these accounts for automated testing.
As much as Email whitelisting goes this is what I found from the docs
Email whitelist:
An email whitelist is a list of IP addresses from which your users
expect to receive legitimate mail. When you add an IP address to your
email whitelist, mails sent from this IP address will generally not be
marked spam. To instead approve specific senders based on their email
address or domain name, create an approved sender list using the Spam
setting.
Please note that email whitelist is not exclusive. If you create a
whitelist for your G Suite account, it will affect your entire domain.
There's currently no functionality in place for you or your users to
only receive mail from a self-defined list of senders.
After you configure an advanced Gmail setting, it may take up to one
hour for that configuration to propagate to individual user accounts.
You can track prior changes under Admin console audit log.
To add IP addresses to your email whitelist:
Sign in to the Google Admin console. From the dashboard, go to Apps >
G Suite > Gmail > Advanced settings. In the Organizations section,
highlight your domain. In the Email whitelist section, enter the IP
addresses of your contact's domain host to make sure any mail
originating from these IP addresses are not labeled spam. If you would
like to add more than one IP address, enter an IP range in CIDR
notation or separate each IP address with a comma. Click Save changes.
I am using Backendless.com as a BAAS for my application. I have some custom logic running on their servers which need to make an HTTP request to the Google Places API.
I'm trying to generate an API key for the Backendless.com server to run this request but i'm not sure what API key I need to generate. The Google developer console gives me 4 options. Server Key, Browser Key, Android Key, & iOS Key.
Server key seems to be the one I want to use... but I need to provide it with some IP addresses... I don't know where or how to find those! The console states that they are optional, but it seems insecure to not add the server IP address. What are the risks? Where can I find Backendless.com app server IP's?
Server key is what you want. Restricting access is a good additional security step to take, it is not however required. They basically make it so that if someone manages to steal your API Key, they can't use it from IPs that are not whitelisted. You will have to ask backendless.com if they have a finite list of IPs they can gurentee your requests will come from.
Using a server application with C#, how is it supposed to work when accessing users in the same domain if the authentication is only possible using:
OAuth2Authenticator interface?
I'm able to access the admin of the domain's Drive, but I'm missing the 3 legged OAuth in 2.0.
Looking at this description found at this link: https://developers.google.com/drive/delegation
Since this is not executed as a Service, and is not using Google Apps and cannot then
access: https://www.google.com/a/cpanel/mydomain
Also the IP is not known from where the machine running the server-application.
Currently I'm using: "Client ID for installed applications", and it works. But what I need is to also store files in other users in the same domain.
A other solution that works temporarily is to first store them at the admin domain account and then move them to the user domain account. But this removes the possibility to direct it to a parent/folder at the end user's drive. It will always be stored in root for that end user.
Basically what I want is following:
A Server application is running on a local machine (admin domain account can be used)
The application upload files to different users that are in the same domain, but with their own email address and also then have their own Drive.
Yes, you can do that through 2 legged oauth, which can provide domain-wide authorization.
Here are some links for your reference:
https://developers.google.com/gdata/docs/auth/oauth#2LeggedOAuth
http://support.google.com/a/bin/answer.py?hl=en&answer=2538798
I have a site i am working on that i would like to display only to a few others for now. Is there anything wrong with setting up windows user names and using windows auth to prompt the user before getting into the development site?
There are several ways, with varying degrees of security:
Don't put it on the internet - put it on a private network, and use a VPN to access it
Restrict access with HTTP authentication (as you suggest). The downside to this is it can interfere with the actual site, if you are using HTTP auth, or some other type of authentication as part of the application.
Restrict access based on remote IP. Just allow the IPs of users you want to be able to access it.
Use a custom hostname. Have it on a public IP, but don't publish the hostname. This means make an entry in your HOSTS file (or configure your own DNS server, if possible) so that "blah.mysite.com" goes to the site, but that is not available on the internet. Obviously you'd only make the site accessible when using that hostname (and not the IP).
That depends on what you mean by "best": for example, do you mean "easiest" or "most secure"?
The best way might be to have it on a private network, which you attach to via VPN.
I do this frequently. I use Hamachi to allow them to access my dev box so they can see whats going on. they have access to it when they want , and/or when I allow. When they are done I evict them from my Hamachi network and change the password.
Hamachi is a software VPN. Heres a link to Hamachi - AKA LogMeIn
Hamachi
They have a free version which works quite well.
Of course, there's nothing wrong with Windows auth. There are couple of (not too big) drawbacks, though:
your website auth scheme is different from the final product.
you are giving them more access to the box they really need.
you automatically reimaging the machine and redeploying the website is more complex, as you have to automate the windows account creation.
I would suggest two alternatives:
to do whatever auth you plan on doing in the final website and make sure all pager require auth
do a token cookie based auth - send them a link that sets a particular token in a cookie and in your website code add quick check for that token before you even go to the regular user auth
If you aren't married to IIS, and you need developers to be able to change the content, I would consider Apache + SSL + WebDav (aka Web Folders). This will allow you to offer a secure sandbox where developers can change and view the content without having user accounts on the server.
This setup requires some knowledge of Apache so it only makes sense if you are already using Apache or if you frequently need to provide outsiders access to your web server.
First useful link I found on the topic: http://pascal.thivent.name/2007/08/howto-setup-apache-224-webdav-under.html
Why don't you just set up an NTFS user and assign it to the website (and remove anonymous access)