My context here is a check-in system for use in classes I conduct, but this applies similarly for any sort of web-based checkin where the device used is not under your physical control (i.e. not those airline or cinema touchscreens). I include the geolocation tag as it may (or may not) be relevant.
Problem Definition
How can a website verify that the user checking in is physically present in a particular venue, given that no control is assumed over both the user's device (laptop/smartphone/tablet) and internet connection (users will be using their own 3G/4G connections)?
Foolproof security isn't possible here (I believe) due to the restrictions above, so the aim is to maximise security by increasing the complexity of fooling the system (by checking in without being physically present), while minimising process complexity for those who are physically present.
What strategies are possible here, given that I have control of the venue itself and the web service.
Possible strategies
A password which is only provided in the venue without which sign in cannot occur.
A QR code displayed on a screen in the venue which must be scanned.
Either of the above, but the authorisation element refreshes every N seconds to prevent relaying of the element to external parties.
Analysis of current strategies
This is very simple to use. However passwords are easily obtained by external parties assuming they have contact with at least one internal party (being just text).
This is actually not too different from number 1, as a QR code, once scanned, is just text. Complexity is increased as each user needs some form of QR code scanning on their phone, and external parties can still easily obtain the QR code content as it can be forwarded as text.
This seems to increase security by preventing the utility of forwarding passwords as passwords will expire after N seconds. As long as N is short enough, the inherent lag of scanning a QR code and/or the lag associated with message delivery and receipt means it would be fairly difficult for external parties to reliably obtain a current password from an internal user. This can be circumvented using a live video stream of the venue though.
Additional ideas
Some sort of client geolocation (HTML5 supports it, but may not be trivial to add to my web service).
Require that a certain wifi ESSID or bluetooth device be present (must be a client-level check, may not be possible depending on device).
Related
I'm developing an iOS app that sends notifications to individual groups of users. Number of users per group will most likely be in the order of 1-7, but can exceed that and while the app generally doesn't set a limit, I hardly see it exceeding 20.
Currently I've set it up with the topics approach and it works like it should. I understand this approach is optimized for throughput rather than latency, as opposed to device groups.
Nearing completion of my app, I'm considering to change to device groups. However, I don't see many advantages, especially considering the substantial complexity that comes along with it.
Notifications at the moment is fast enough. As long as delivery time doesn't suddenly increase by a lot, it's perfectly fine at the moment.
How secure are topics compared with device groups?
The app does allow the user to use more than one device, but I don't see that happening often - realistically quite seldom. However if that were to happen, device groups would handle it better. Still, I think it's an acceptable compromise to stick with topics.
For device groups to work, I have to create a new collection server-side to manage device registration tokens and their updates, pairing with my existing data structure and implementing several http requests. I also need to query for the notification_key every time I want to send a notification, instead of sending it to the more obvious id I now use for topics.
I've read through other questions on SO, but wanted to get some fresh thoughts on this. My opinion is to stay with topics unless convinced otherwise
I'm using both of these delivery methods and yes, topics are far easier to manage but that comes at a cost of security. If your groups are public in nature then you should be fine with topics. If they're meant to handle more sensitive/private information you should probably go with device groups / individual tokens. Reason being, topics are more public facing and anyone can listen in on them, even devices not on your app.
I am so happy that I get an ID per device, so I can keep data per user anonymously with firebase! The only thing that could be better is if I could get an id per user's iCloud storage for the app.
I understand that how the authentication token is maintained per app, at least on the web, is that it is stored in local storage. It implies that a similar approach is being used per app in iOS in something like UserDefaults. I'm hoping there's an easy way to keep it instead in NSUbiquitousKeyValueStore.
edit with use case:
I have an app that is (with permission) capturing and anonymously collecting location data. I would like to have that data stored per user rather than per device, and I essentially can't use signed logins.
(actually, the reality is that I am not capturing that in firestore, I am capturing accompanying metric data from other apps designed to work with this one)
So "why anonymous?", right? I am collecting time series data for third party apps - this presents risk of "use" to the user, and loss of control for that same data for the subscriber apps using the service I am writing.
Honestly, at a later point in time this might be converted to a library that allows apps to swarm their information together instead. But there are overhead concerns, and difficulty in trust for sharing data, with that approach and for my research project that approach is further from topic.
This is for a visualisation project on what data gets recorded about us from our phones.
The idea would be to log as much detail as is reasonable to an internal location (probably) on the phone for later analysis, e.g. HTTP requests. It doesn’t need to be secret at all – the subject will be aware they are participating – and it doesn’t have to be 100% automatic; if the phone owner needs to perform some action regularly that’s okay too, although they need to be able to use their phone approximately normally throughout the day.
I can’t find any Apple APIs that look suitable, but that’s hardly surprising. I can find some approaches that would potentially work on OSX (tcpdump, netstat), so perhaps a jailbroken iOS device would support one of those?
Alternatively, running a custom proxy server would open up a bunch more options, but is there any way to get a mobile device to reliably route through a proxy server?
It appears this question provides a viable proxy-server-based approach:
https://apple.stackexchange.com/questions/81102/proxy-settings-for-iphone-3g-connection
Basically, it seems it is possible to route all requests through a proxy server, even over cellular.
Background
My client's iOS application makes use of a third party library for advertising. About once a week we'll find that enormous numbers of our users are experiencing a crash because of some specific advert the API is presenting. When this happens our current reaction is to turn off all adverts until it is resolved.
We'd like to have some kind of per advert control.
Doing it properly
Ideally the third party library would provide an ID for the advert it's about to display and give the App an opportunity to block that particular advert. We'd log this ID and if it correlates with crashes (which is usually very obvious), block it.
However, getting the ID tracking in will require negotiation between my client's departments, and the the advert provider's departments, which will take some time, if it happens at all.
The work around
As an alternative, I'm wondering if there is a way that our app could intercept (and then potentially block) the network traffic of the third party library? Essentially run a transparent proxy that vets network traffic for our whole process (within which the library is running).
Are there hooks in iOS that would support this?
Just knowing the url requests would be a good start, this could at least be logged to help us isolate the advert and request it's not sent any more.
I'm not after a complete solution: pointers to useful areas in the API would be fantastic.
Any example code of something similar?
Other ideas for other ways to achieve the same result?
Valence allows to do this, but I wondered if there's limitations to trying to automate user account setup and enrollment in this way. We're a relatively small institution with hundreds of enrollments perhaps in a given term scattered over several weeks, so I don't think there'd be a problem with realtime events. But I wondered what the implication might be for a larger university that might have thousands of enrollments updating all the time. There'd be spikes of activity certainly as a term reached official start.
The issue of performance is a complex one, with many inter-dependant factors. I can't comment on the impact of hardware hosting your back-end LMS, but obviously, higher-performance hardware and network deployment will result in higher performance interaction between clients and the LMS.
If your needs are "hundreds of creations scattered over several weeks", that is certainly within comfortable expected performance of a back-end service.
At the moment, each user-creation request must be done separately, and if you want to pre-provide a password for a user, then it takes two calls (you can, in one call, nudge the LMS to send a "password set" email to the new user, but if you want to manually set the password for the user, you have to do that in a separate call after the user record gets created). The individual calls are pretty light-weight, being a simple HTTP POST with response back to provide the created user record's details.
There are roadmapped plans to expand support for batch operations, and batched user-creation is certainly a logical possibility for improvement.