I want to create a backend for my android app with Tapestry5 and this http://code.google.com/p/t5-restful-webservices/ plugin.
The app will communicate with the server by calling REST methods both for registered users (that would be easy to secure I guess) as well as unregistered users.
Now of course I don't want people to just call that webservice from a browser.
How can I make sure that only my app can make calls to this backend?
I can think of 2 approaches:
Use SSL to secure the connection. SSL can do a handshake checking the credentials.
To authenticate the user you can use a certificate or a PSK.
Or you can simply create a Hash (SHA or MD5) of your data and include a key. This is called hmac. A reverse engineer may get the Key cause you have to hardcode it in your code.
checking for the users UA could help...
Related
Please inform what security measures need to be implemented before I can deploy an android app (which will collect personal information) for public usage in google play store. I am a newbie and dont have much experience with security procedures.
Already implemented SSL to establish encrypted secure data link between client and server by converting http to https. Is this good enough for data communication between client and server link?
Will be implementing sending email from app securely using OAuth2. Is this a valid approach? Should more be done. I plan to write this code at the server side and not from the client side? Is this ok?
3) I just do a simple retrieval of username and password and check if they match but password retrieval is done using https (SSL). Is this enough?
4) Should I encrypt the passwords in the database? If yes, how should it be done like should I store them encrypted in the database and which retrieval decrypt them? Please inform.
5) Will be composing a privacy policy as per guidelines of google play as the app will be requesting personal information and displaying on the app menu and while first sign up before entering the app?
6) Also using google API's etc...Just requesting, getting JSON, parsing the json and displaying in the app good enough or something needs to be done. This is all done using api key as per the provided guidelines. Anything more needs to be done to secure it?
7) What else am I missing to make the app absolutely secure?
Your inputs will be greatly helpful.
Thank you!!!
I have a Java Spring driven REST API server connecting with PostgreSQL database and a Spring Web Server in Java that is serving content from the REST API to the client using JavaScript (now browsers, but in the future also mobile apps).
I've read a number of articles and topics how one can secure a REST API, but I haven't been able to make a final decision yet. I don't want to have Basic Authorization, because it doesn't make sense as I would need to store credentials in JavaScript that can be easily accessed and read by anyone entering the webpage and developer console. I'd like not to show any credentials to the end user so I can't keep them on the client's side.
I've read a lot about JWT and almost decided to implement it, but I've heard it has some drawbacks and haven't been so sure since then if it's the option I would like to choose. I know there is also oAuth 1.0 or oAuth 2.0 but I don't know if I want to have something this complicated. I would also like to store hashed user credentials in my own database in order not to be depended to any other credential providers like social media or Google.
Now I'm making another layer on my web server as a proxy hoping that it will allow me to authenticate user on this proxy level using Spring Security and having some kind or cookies or something to authenticate, but I'm not so sure if its doable this way and it increases the respond time, adds complexity and needs me to write controller methods for these endpoints. My architecture now is of the following:
Client (browser) -> Webserver -> REST API server -> db
I've also denied all external connections and allowed only localhost access to REST API on tomcat level so that I'd have to implement the security level only on the web server allowing free information transit between the webserver and REST API as it is not reachable anyway.
Web server and REST API are on the same server running as Tomcat instances.
I'm also not so sure if this kind of architecture will allow me to authenticate mobile app clients through the web server.
I would be very grateful for any piece of advice you would have for me in this matter. I'm not so experienced in security, so I'm a bit lost what I should do. Does this kind of architecture any sense or should I simply ask REST API directly from any type of clients, be it a webpage or a mobile app from different IPs and secure Rest API only? And if I want to secure some subpages of my webpage or parts of mobile app should that be an completely other layer?
Thank you for your help.
You have already gone through OAuth, JWT tokens etc. If you don't want to use them,then you can create your own token based authentication system.(say 'TokenHandler').
How this TokenHandler will work ?
TokenHandler will be like a gateway server i.e your every REST API request will route through this server application. So you will address your confusion of mobile and web application call with a authToken in header. Main responsibility of this server applciation is to accept the token and validate against the database where all token details are maintain. This DB will have information regarding timestamp when token was last used to validate, to decide your validation rule .
How Token will get generated ?
Token can be any random 64 digit alphanumeric string and will be generated and updated in DB during every single login activity. Login webservice returns this token in response body.
What can be rules for validation ?
It can be depending on your business logic. I preferred to keep active session window of 15 mins. Means if you access the webservice you will get active window of 15 more minutes. If you didn't access any service for 15 consecutive minutes then from 16th Minute you will need to login again to access further calls. This part can change according to requirements.
How client side will handle this ?
Client side will store this token and pass this token with every request call. Token Handler will validate and redirects it's request to the application server . So your one token handler can be used to server authentication of multiple applcation servers. This you can achieve by application end point identifer.
I will like to discuss further if you have any questions or suggestions .
Use API Gateway Architecture Pattern for your use case -
http://microservices.io/patterns/apigateway.html .
The API Gateway (The webserver in your question) can act as single entry point for all desktop/mobile clients. You can use either session cookies or jwts to authenticate clients at gateway.
With respect to authentication between gateway and micro services, and between micro services, i would suggest mutual ssl - https://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication. If you are using spring boot, this might help - http://www.opencodez.com/java/implement-2-way-authentication-using-ssl.htm
The problem with IP white-listing approach is that - it's not well suitable for cloud architecture as the IPs might change with every server reboot. Even if you are using dedicated IPs, you should be careful to secure the communication with SSL/TLS, else attackers can easily sniff your traffic.
I googled and I only found documents on how to create a sign in button on your android application, or how to create a sign in button on your web application.
My scenario is that the android application retrieves information from my website using get/post http requests and getting json data.
I have a working android sign in button on my android application.
the question is that when i want to retrieve information from my website using get/post request, what information should I send in order for the website to know which user is retrieving that information and that the user is logged in ?
I know that I can't just send the google user id because that's not secured and easly hacked. I'm guessing I need to send some kind of access token and on the web site to parse that access token in order to know which user it is. but what exactly do I need to do?
My client side is PHP with ZendFramework 2 and ZfcUser with scn-social-auth for google login.
any information regarding the issue would be greatly appreciated.
thanks
In my previous staff project, i've implemented our Api modules for Zend Framework (it was version 1 but it is the same for version 2).
Basically, i've implemented the OAuth protocol 1.0 ( rfc at https://www.rfc-editor.org/rfc/rfc5849 ), that is a really strong way to improve the connection security between a generic client ( Android, iOS, Mac OSX, Windows Phone ,... ) and web service.
Shortly it consits into enforce the https protocol ( i hope you are working in httpS ) signing all the client get/post requests with the base OAuth parameters ( such as oauth_version,oauth_token,... all explained in rfc) in order to avoid MITM and proxy to alter the request. Using this method i've make a specific table into which store Request and Access Tokens.
So:
Client has consumer key and consumer secret
Server has same consumer key and consumer secret
OAuth will use that keypair to authenticate the connection
Client obtain "Request Token" from server
Client perform common username and password login through OAuth workflow to the server
Client obtain Access Token ( if login with success ) that will be stored on the token db table, and wil be used to check if that user on that device is logged in and so authorized to use the service (so you'll probably need a device guid also )
You can find good guidelines and good github projects on how implement your own OAuth protocol ( see also service like Dropbox or Twitter developer sections, about how they use OAuth for their service ). Consider that you can obviously customize your OAuth protocol once implemented, with additional controls and tokens ( i've used AES-256 encryption and RSA 2048 bit for some custom tokens, and also to encrypt username and password for the login with a received key combination in the previous step expected by OAuth workflow ).
In the end, you can connect the clients to your web service with your custom tokens so, once authenticated, you make you web service to interact with google service and return information to client always through your website
Hope it helps
If the user login server is the same with the one that you want to retrieve information,you can use the sessionId as the token.
1.After authentication,server store userId in the session
2.Server use session_id() to get sessionId ,return it to android client
3.add ?PHPSESSID=sessionId param to the android client http request.
4.Server get userId from the session
session_start() creates a session or resumes the current one based on a session identifier passed via a GET or POST request, or passed via a cookie.
You can add GET parameter PHPSESSID to any requested url.
$manager = \Zend\Session\Container::getDefaultManager();
//$manager = new \Zend\Session\SessionManager();
$PHPSESSID = $manager->getId();
I am trying to secure my REST API developed using Spring MVC.
On google search I came across this link.
Is this the best approach ? Does it uses Digital Certificates ? Or Digital Certificates used only for SOAP based Web services?
Please also point me if there are better alternatives for REST authentication.
Is this the best approach?
What is "best" depends on your requiremements. The benefits of this approach are
Fairly easy to implement
No obvious vulnerabilities as long as the Secret Access Key stays secret.
Not so nice:
Both sides have to know the Secret Access Key, so you as a user must trust the provider of the REST service keeping your Secret Access Key secret. In most cases this is probably not a big limitation, but still ...
Does it uses Digital Certificates?
Nope. No certificates involved. With the exception of the SSL connection that is probably used to give the Secret Access Key to you.
Or Digital Certificates used only for SOAP based Web services?
Not true. You can use https (SSL) for REST, which typically involves the presentation of a certificate by the server to authenticate itself. You can also configure it so that the client has to authenticate itself with a certificate using SSL. This would be a nice solution, but is rather tricky to implement on the client side. It's not rocket science, but reading and understanding the handling of Certificates and private and public keys can be tricky. You'd also need some trusted Root CA, which is either a lot of work to setup or rather expensive to use if you use one of the established ones. I'd consider this approach when I'm working on internal services of a large company. They often already have this kind of infrastructure.
Please also point me if there are better alternatives for REST authentication.
As said above: This is a pretty good approach for most services. Using a PKI with client certificates would be an alternative, better in some settings.
You can simulate public/private key authentication like this
You need two basic things!
UserId / Application Id ( To check this application is allowed to access this application) (Private Key)
A random key for the API ( to check this method is allowed for the then authenticated application)
The Rest service (Server Side) will have a record of all the allowed application through "Application ID"
Now you can use these two keys in ur own algorithm . For example, you can create a simple HASH out of it.
The scenario would be, you are encrypting your API with a public key ( You API random key).
The client who is calling the method, is decrypting with his private key (Application ID)
When the client sends, his Application Id, you can , generate the HASH out of his Application Id and the API random key and make sure that, this application is allowed to call this method.
The Advantages here are:
1. The Server side can change the encryption algorithm, which client need not to be worried about
The server can change the method encryption (The public key), which the client need not worry about
The Client CANNOT change the private key(Application ID). If he changes, the server will reject it. In other way, a non-registered application cannot access the Rest Service
I'm not a security guy so any help on this would be greatly appreciated.
I have a large number of third-party field devices that have remote methods that can be called across xml-rpc using ssl. For each method call, a username and password must be transmitted in plain text as parameters along with any other method parameters. I have no control over the devices or their implementation.
I'm currently writing a web application that a user would log into and then have access to some number of those field devices. The user doesn't need to know what devices they are connecting to, they just need the data. As such, I need to persist the username and password for each device in a database where they can be retrieved when an rpc call needs to be made.
How do I encrypt my device service passwords so that they can be decrypted when a call needs to be made? How do I decrypt the password when a call needs to be made?
I'm using Java and Spring for the application.
Note, I am not asking how to persist the user's login password.
If I have this right, there is only one username/pswd per field device (though each is different and there are many field devices).
Build a secure proxy service with access to all device passwords. The device passwords can be stored encrypted with proxy service's public key. Your web app presents user key to proxy service which (assuming satisfied) talks to field devices on their behalf. CryptoApi or one of its wrappers should be all you need.
You don't comment on numbers, but given proxy would be stateless, it should scale ok.
We solved similar problems with this code.
You would use the password the users log into your web application with as key when encrypting the usernames and passwords for the other services.