should I authenticate with every call to RESTHeart? - java

I want to write a messenger app on Swift, iOS and as a database I chose MongoDB and turned ON authentication on it. And for the bridge I chose RESTHeart(GitHub). But for input something to database from RESTHeart I use the next line:
http PUT 127.0.0.1:8080/myfirstdb desc='this is my first db created with restheart' -a username:password
So, I use authentication for each connection. So my question is:
Is it OK, log in for each insert to database for the messenger app or there are another, better, solution? I think that I need to make this process as faster as possible

Quoting the RESTHeart documentation:
If a request is successfully authenticated, an authentication token is generated and included in every subsequent responses. Following requests can either use the password or the auth token.
http://restheart.org/docs/security.html
You have to enable the auth token with the auth-token-enabled: true configuration

You should also make sure to use https.
Quoting the RESTHeart documentation:
With stateless basic authentication, user credentials must be sent over the network on each request. It is mandatory to use only the https listener; with the http listener credentials can be sniffed by a man-in-the-middle attack. Use the http listener only at development time and on trusted environments.

Related

Authenticate server to server communication

I am new in authentication/authorization. I need to expose some authenticated apis to be consumed by third parties (server to server). I read how I can do this and figured out that a good option is to use oauth2.
I want to implement this using java with spring boot. My first problem is how to generate client id and client secret. Can you help me with some advice/materials to implement this?
Thanks
For generating the Client-Id and Secret, this guide might be useful.
In all cryptographic affairs, try to find solid / well tested libraries, as mentioned in the article.
Client id and client secret is just a simple login / password pair. Usual constraint apply, just ensure that your secret is not too simple.
As there is only two party implied, the oauth flow is very simple (client credentials).
One server (the client) will consume resources on the other one (the resource server #EnableWebSecurity, #EnableResourceServer) using an access token acquired against the authorizations server beforehand. The resource server may also act as the authorization server (#EnableAuthorizationServer). The client is annotated using #EnableOAuth2Client.
If communication is bidirectionnal, both "server" must be resource server and client (and so have its own client id / secret pair), the authorization server may be independent or hosted by one or both server.

How can I create a secure auto-login system for my client-server program?

I want to create a auto login system for my client-server program.
I have an idea but I think it is very insecure. So.. can anyone explain to me how to do this in a secure way so nobody can get into my account with "just copying files".
My idea:
As the Client registered at the server he get an identifier and a securitytoken from the server. The client and server are saving these in a sqlite database. When the client starts the program he checks if he has a database. If he has he sends the data inside the database to the server. In case the server has got the data the client is signed in.
There are multiple ways to achieve this authentication.
Exchanging a Token is a good idea. The token must be unique for every client in the application, and the server, in a authentication phase (middleware) verifies if the token exist on the database.
If it does, then the request is processed normally. If it fails, then you return a 401 error code.
There are multiple types of tokens. It can be a random token that you might need to check on a DB if that token is valid, or a cryptographically signed token with a private key of the server. This approach adds the advantage that you don't need to check on DB if that token is valid as it can be validated using the server's public key. An example of these are Json Web Tokens https://jwt.io
You must also think on a method to revoke the tokens if you wish that a client no longer connects into your system.
Finally, it's necessary to mention that the security of this system is valid as long as the communication between client and server is encrypted using SSL/TLS or any other method. If you're using plain text communications, anyone in the middle of the network can get your token and send requests on the client's behalf.

Are idToken's safe to send over non-secure URL for API?

So I'm all very new to Java and developing for Android, but I somehow managed to get a successful idToken when logging into my app via Google.
I read on the Android dev site that just ID's are not safe as a modified client could send a fake one and result in impersonation of another user, so I followed their steps to get the user's idToken.
Anyway, is this safe to send over a URL to my server at home? For example, like so (pretend the long string of random text is the idToken of the user):
http://130.155.122.8/api_test/h78e568e7g6589gjkdfhjghdjfkghjkdfhgjkdfhk7hg9867458g74598hg6745896gh49/command
Also, is the idToken even required? Could I just as easily use the user's email address to identify the user (again, it would be sent over an insecure URL, no HTTPS)?
Thanks!
You should use encryption, if someone gets the token from a user they can impersonate that user, in my case, since i can't aford ssl (for now) i encrypt the token using asymetric encryption, and i send it to the server, but ssl is the best way
Generally speaking - No.
A token that identifies you should never be transmitted over an insecure connection (e.g. http). Since on such connections no encryption is used, a third party can very easily monitor the connection and get your token (leading to the impersonation issue).
IANAE, but any security-relevant data (e.g. idToken or password) should only ever be transmitted over a secure (encrypted) connection (e.g. https).
And using the e-mail address does not solve the issue. You simply replaced one identifier for another one. And if anyone ever were to know a user's e-mail address, he could impersonate said user. Stick to the "documented" authentication techniques. If done right they should be safe.

WWW-Authentication / NTLM Negotiate using HttpClient with current user credentials

Looking for a pointer on how to get HttpClient (httpclient 4.3.6) to Authenticate the current user to IIS REST service.
I can connect no problem using UrlConnection as it seems to handle the WWW-Authentication protocol out of the box.
I have moved to HttpClient to leverage the multi-part POST/PUT (FileEntity) and I have discovered that the HttpClient does not handle the WWW-Authentication, it simply fails with a 401 which is the first part of the process.
I have found some examples out there that present NTLM credentials etc... but I don't want to capture credentials, I want to execute the request using the current windows identity.
Is there some code or an API out there that I can use to manage this on my behalf? I don't want to capture user name and password, I just want to present the current user credentials. Do I need to use a 3rd party library like SPNEGO?
Many thanks in advance
You might want to try out HttpClient 4.4 (to be released as GA soon). It supports native Windows Negotiate, Kerberos and NTLM via SSPI through JNA when running on Windows OS. Please note this feature is still considered experimental. Your mileage may vary.
http://hc.apache.org/httpcomponents-client-4.4.x/httpclient-win/examples/org/apache/http/examples/client/win/ClientWinAuth.java

How to send app data securely to a recipient/server

I'm currently developing an android app where the user has to fill out and successfully send the data of a few text fields to a recipient/server, to enable a feature.
The big issue is how to do that in a secure way to be protected against e.g. decompiling. My concern is not the security during the transport but rather the security of the transport medium.
What I've thought/read so far:
I could send the data via mail with the Java Mail API.
First of all, I don't want require that the user has to enter his mail credentials and SMTP server.
That would mean that I have to include the credentials to a mail account in the app, though.
To avoid the situation that somebody decompiles the app and takes over my mail account, I thought of encrypting methods, but even if I would save the aes encrypted version of the password, the attacker could decompile the app and could add a syso to output the decrypted password.
The same applies to OAuth authentication because I have to store an authentication token.
In addition to the mail version, I read something about getting the password with a POST request from a web service, which doesn't seem safer at all.
I could search for free smtp server without the need of credentials, but I want something I can rely on instead of waking up each day and looking if the service still works.
Send the data to a web service.
Okay that would require more work for me, but I would accept that, if there would be a solution without saving the credentials in the app or having a web service which accepts data from everybody.
Have I overlooked something? Or is there no safe method without asking the user for his mail credentials or google account etc. ?
OAuth would probably work. The nice thing about OAuth is that if a token is compromised it can be revoked on the server side.
You could create a web service that accepts TCP connections on some port. You could have some authentication mechanism for example Digest authentication that would be carried out before accepting data.
Another option would be to use an API such as Golgi. Golgi requires a developer key, app key and app instance id to connect to the servers and send data. In the event these credentials somehow get compromised you can simply change the app key and push a new version of the app through the Play Store.

Categories

Resources