if i use the android managed configuration with all the app restrictions and so on... and the admin should set the credentials (example for a mail server) what is with security? All the values you define in the restrictions.xml file are set in plain text in the emm system. How can that be safe? and also if i understand everything right: the date also will send via google to the device... also in plaintext?
is there any different approach? or will all the restrictions send over the internet just always in plaintext?
thx
When sending data to and from Android devices, Android uses Transport Layer Security to provide communication security over the network. All data transferred to and from the server are encrypted. However, it’s bad practice to store passwords in plaintext, so we would advise not including a field for passwords in your app restrictions. Gmail, for example, includes app restrictions for use with Exchange accounts; it allows the admin to specify a certificate alias for logging in, but it does not allow the admin to share the user’s password via app restrictions (the user must login on the device).
Related
I have a react web application with a flask api (I used to use express). The product of this app is the data that it displays. I don't want other people to be able to take that data easily from calling the api.
I want to secure the api such that it can only be accessed by my react app and nothing else. How can I do that?
The only way to truly secure your API is by authenticating your app's user with something like Oauth2 and verify that credential on server-side with something like passport, and make the authorization expire with sessions. AND use SSL so none of that is easily visible through a protocol analyzer.
Sure, you can hard-code some sort of "secret key" with the app, but anyone who want it bad enough will read it off your app or sniff the packets through a packet logger until they find the key.
EDIT: Oh, and as a part of the authorization upon login, provide them with a uniquely generated "API-KEY" as part of identity, so you can validate them upon submission, and if they violate your trust, mark their API key invalid in the server so they can't use them any more.
First, if your client code and API server are running on different domains or ports, configure CORS on your API server to only honor requests that originate from the client code's domain. Second, authenticate legitimate users so that only authorized requests for data are honored. There are lots of 3rd-party libraries to help with authentication.
I have a google business apps account.
My requirement is to scan all emails of my support email and process them.
This has to be done on the server side without any manual interaction.
I am able to make this work with IMAP, but i am looking at making this work with Google API.
This doesn't work with the Google API unless i do manual client consent.
Or i need to use the service account, in which case i have to get a domain wide access although my requirement is only for one email id. This is against my company's information security policy hence cannot use this option.
Require help on how i can use Google API to do the integration between my server and gmail server at a individual email account level. Any suggestions?
I am the admin of a Google domain and I need to he able to read users emails in my php app. How is this possible? I have tried to use IMAP but it won't even connect. Is there something special that apps have to do?
Here is a list of all the ways to read a user's Gmail mailbox, outside of App Engine :
IMAP, as you said. Provided it is enabled on your domain. Most of our customers disable it for security reasons (no audit trace of the connections).
Apps Script, but it requires the user's consent, even if you're an admin
The Email Audit API, but an Email extraction takes approximately 2 weeks (no kidding)
If IMAP is enabled on your domain, then it's the best choice. However, by default GAE does not allow outgoing connections apart from HTTP requests. The workaround for this limitation is the Sockets API, currently in preview. You can check it out here.
Note that you will also need to use an OAuth2 service account (domain-wide delegation) and IMAP-XOAuth2 to authenticate with the IMAP protocol.
This question has come up a lot but I haven't discovered the answer. I've read the OAUTH 2 spec and the separate security "considerations" document but I'm still fuzzy on something.
The circumstance is: RESTful based web services being accessed by mobile applications. I am both the server resource (creator and host of the RESTful services) and the authorization authority (I store the user's IDs and passwords and validate identity). Third party companies create the mobile applications that consume my services. I am using OAuth 2.0 to validate the user's UserID and Password and issue a token. TLS via https is used.
A nonce with a singed message is commonly used to prevent against replay attacks but as I understand it, that won't work in a mobile application because in order to sign a message, you need a shared secret. Any secret stored on a mobile app (that would allow you to sign messages) is no longer a secret. So a nonce can't be used.
So we have session tokens, which expire after some configurable period of time, and can be refreshed with a "refresh token".
My question is: If TLS is defeated (example: user is dumb enough to connect their mobile phone to a proxy server and install a certificate of the proxy, which then allows the proxy-server owner to read the unencrypted traffic), what prevents a hacker from replaying a request with a valid session token (while it's still alive), or worse, persisting the session for hours at a time using the refresh token to continuously obtain new session tokens?
The situation you suggest is one where the security is defeated and there is no security. The proxy can do things like steal the user's password during authentication or divert the access token to another application (either local or remote). You must just accept this scenario as a loss.
Also, it is typical for mobile apps to have a shared secret. As you point out, the secret loses some security being on the client, but it is still better than nothing. The secret is typically encrypted while at rest to prevent it from easily being stolen. Of course, the decryption key can be stolen from the app even when obfuscation techniques are applied to it but it provides some security.
Be sure to restrict the access rights of the secret on the client. Make sure that it is not configured for 2-legged auth. That should be saved for servers and only when needed.
How can I make my desktop application into an OpenID relying party?
Have a look at this question, it looks to me that OAuth can do this for you.
Since OpenID has a specified protocol, it will either work all the time (assuming providers are conforming) or not at all. Additionally, since the OpenID protocol (at least the authentication bits, see the specification) consists of simple HTTP requests, you could implement the protocol in a desktop application assuming you know how to make such requests.
It is generally considered a bad idea though, since there are better technologies (OAuth) and it disrupts the user experience (being different from OpenID in a browser — see OpenID For Desktop Applications: How? When?).
Further reading: OpenID for Desktop Clients
Don't do it.
Even an attempt to do so shows a fundamental lack of understanding in the security model that OpenID offers. You have to ask yourself what the password that you would otherwise use for your desktop app is protecting. Is it protecting assets on the local machine itself? If so, OpenID is useless because it would be a simple matter to spoof the network such that I could hack my way into the desktop app without owning the OpenID. You're wide open to user identify spoofing. Are you trying to protect network assets? OpenID fails again, since it doesn't authorize your desktop app to access those network assets, suggesting that some other authentication is going on behind OpenID so once again you're not adding any value.
OAuth is the protocol suited to allow your desktop app to access and protect network resources. If you're protecting local assets on the desktop computer, local encryption is the only way to go.
It seems to me that you should present a small web browser window for the authentication to be completed. The interaction would not be going through your code.
I would not suggest using web scrapers to do this. In doing so, you place your code in between the user's server and the user, which is a breach of the covenant that the user's password is not seen by the relying party.
OAuth is the right technology to use for a desktop application, but it doesn't use the existing password ecosystem that OpenID has, which was not a part of the OP's question.