We are currently looking at the possibility of a jquery mobile app for company employees. But, we don't have a ton of experience and would like suggestions on how to do security?
Background:
Salesmen with Android phones or Iphones
most of the time on foreign wireless or 3g/4g, sometimes on intranet/internal wireless.
Would like app to show customer info, current orders, pricing, etc
Windows 2008 Active Directory environment.
Obviously because of the sensitive customer data, security would be fairly important.
Just barely researching jquery mobile, and wondering what the ideas for security are out there?
Also, all the phones are company provided, and we have access to the full phone, would using something hardware/os related on the phone provide extra security? A hash of the imei, phone number, mac address, etc?
Thanks
Run the company portal on HTTPS - assuming you are just building a regular site. If you are planning on wrapping it in a e.g. a PhoneGap layer, be sure to communicate securely.
Make the backend API stateless (no sessions) and provide the full authentication credentials in the AJAX headers. You'll want to transmit username, password, and device ID over SSL on each call that way you can authenticate the device in addition to the user.
You can manage the equivalent of a session timeout on the app itself using setInterval() in javascript. When the timeout expires just clear the user credentials in javascript and have the app go back to the signin screen. You can also add a check on the beforepagechange event in JQM to see if the user is authenticated and, if not, redirect them back to your signin screen.
Related
I have a problem that I need to solve for my client. The situation is that they have a lot of users on one platform (platform_1). In order to use the platform a user must be signed in, therefore these users (credentials) are given out to clients for them to use the platform. The problem is that one user (one set of credentials) may be given out to a few clients, therefore we cannot know which of the clients did what (in this case - bought something) on the platform.
Figured I would just create a new system where the client can be created and a set of credentials would be attached to that account, then I would just display an iframe of that platform (platform_1) with the attached credentials on the newly build platform and then I would be able to track what the user is doing in the platform.
But turns out iframe cannot handle credentials and also it would not be safe to use this method..
Also thought about scraping the whole platfrom (platform_1), which would work, but then I believe it would be extremely hard to do live auctions, for example scrape the live auction and display it on my system and let the user click on some buttons and the script would do the same on the platform_1, but the delays and overall usage could make it very hard.
I would like to kindly ask you to share your thoughts on ways this problem could be solved or whether it aint possible.
I am currently working on my final year project, and one of the tasks I am struggling with is integrating biometrics in the authentication system of a web app. I have gone through many readings, questions and blog posts, but none of them seems to deal with the exact same issue.
The problem: I have an external fingerprint sensor (GT21F32 https://www.sparkfun.com/products/14518). Is there any way I could use this sensor in order to get a user to authenticate on my web app?
My thinking process:
have the user input username/password in the login fields;
once they hit login button the server creates a SESSION (call it x) in which they are prompted to put their finger on the sensor;
if everything goes well (data check aganist internal sensor store returns a valid match), user is signed in (mix this with jwt auth?);
similar flow for registering
Regarding SESSION x:
I was considering during that time my authentication API could communicate with an API that wraps the functionality of my sensor
e.g: call a readFingerprint() or searchForFingerprint() function that I implement, which in turn communicates locally with the hardware using it's SDK protocols
I was considering writing this fingerprint API as a node package so that I can use node with Javascript
Please offer me some guidance, since my project supervisor does not really provide much help, and I feel I have exhausted all the possible sources of information.
Thanks a lot!
I have cors installed and only my website is whitelisted, how reliable is this? Can bad actors still call my api if they are not calling it from my website?
Next I want to rate limit each user on my website, (the users are not registered or signed in),
I want to restrict each user to make no more than 1 request per second.
How can each user be identified? and then how can each user be limited?
Too many separate questions packaged together here. I'll tackle the ones I can:
I have cors installed and only my website is whitelisted, how reliable is this? Can bad actors still call my api if they are not calling it from my website?
CORS only works with cooperating clients. That means browsers. Your API can be used by anybody else with a scripting tool or any programming language or even a tool like CURL. So, CORS does not prevent bad actors at all. The only thing it prevents is people embedding calls to your API in their own web page Javascript. It doesn't prevent anyone from accessing your API programmatically from whatever tool they want. And, they could even use your API in their own web-site via a proxy. It's not much protection.
How can each user be identified? and then how can each user be limited?
Rate limiting works best when there's an authentication credential with each request because that allows you to uniquely identify each request and/or ban or delay credentials
that misbehave. If there are no credentials, you can try to cookie them to track a given user, but cookies can be blocked or thrown away even in browsers to defeat that. So, without any sort of auth credential, you're stuck with just the requesting IP address. For some users (like home users), that's probably sufficient. But, for corporate users, many, many users may present as the same corporate IP address (due to how their NAT or proxy works), thus you can't tell one user at a major company from another purely by IP address. If you had a lot of users from one company simultaneously using the site, you could falsely trigger rate limiting.
I'm thinking about a sign-up-with-mobile number system whereby someone can register with a mobile number and get a SMS to verify that they exist... at which point I'd like to have them automatically logged in without a password... (the SMS is basically a password)
This is patterned on the Lyft app sign-up, which doesn't ask for a username/password/etc.
But for the life of me, I can't figure out how to do this.
I'm totally fine with a server only Meteor.method which responds with something "secure" but I don't know what that would be now.
The only thing I can think of would be to set the password on the User and then transmit it to the client and run a login (which seems insecure to me).
I have read through this great article
https://meteorhacks.com/extending-meteor-accounts.html
and it's a good option, but I don't know of a strategy for that which wouldn't bypass security too
(at some point the server has to communicate securely back to the client...)
Recommendations?
I made a package that might help you, Meteor accounts phone, which do login based on sms mobile number verification https://github.com/okland/accounts-phone/ Enjoy!
I'm in the process of using the facebook javascript sdk to provide user login functionality for a website.
What I'd like to do is simply take the logged in user's unique facebook id and then put/fetch data to/from a mysql database using the id to determine what data is available to said user.
However I don't really feel like this is very secure. Whilst I'm not storing anything sensitive like credit-card details etc, I'd obviously prefer it to be as secure as practically possible.
My fear is that with javascript being what is it, someone could fake the facebook id and just pull whatever they wanted.
I'm aware that the php sdk would provide a solid solution to this problem, but i like the javascript one mainly because it's easy to use and I have the basis of it set up (I admit it, I'm lazy).
So, my questions are:
Would this set up be as insecure as I feel it might be?
Is there anything I can do to improve the security of such a system, other than switching to the php sdk?
Thanks!
Facebook Ids are pretty hard to make up (at most a user will only know their own). Depending on what you store in the database (which will not be anything that the user cannot get on their own, unless you ask for extended permissions)
If you are worried about a user trying to get information from the database, add an access token or signed request to each row and us that and facebook id to get data. That will greatly increase security.
EDIT
There are few occasions where you get a signed request from a user:
* A signed_request is passed to Apps on Facebook.com when they are loaded into the Facebook environment
* A signed_request is passed to any app that has registered an Deauthorized Callback in the Developer App whenever a given user removes the app using the App Dashboard
* A signed_request is passed to apps that use the Registration Plugin whenever a user successfully registers with their app
Signed requests will contain a user id only if the use has accepted permissions though, and are not passed again if the user enters the application, and accepts permissions (meaning that the signed request would not contain the ID). Because of this saving an access token may be a better idea. Here is more on the signed request
Also the signed request is in the url (param = "signed_request"). I always parse it through c# but I am sure you can at least get one through javascript
It's pretty easy to spoof the origin using curl. I'd imagine Facebook has another mecanism in place to make this possible. If you inspect their code, it appears that they generate an iframe and pass requests through. If I had to guess, they have setup the requests to only be made from the Facebook domain, and ensure that the iframe can only be embedded in a page that has a white listed domain.