Have you got a time scale for this fix?
The County Council are querying whether Emerge meets their requirements for Dual Factor authentication. The marketing material appears to suggest that it uses dual factor, but i'm not so sure. If the device is found it can be remotely wiped, but in the meantime the data is only a pin entry away. What are our thoughts on this?
If you read up the thread, the remote wipe isn't quite as you'd expect, and even if it was implemented as i have suggested, you'd still have a time to live. The only useful thing that can be done now, is with iOS 5 and the find my iDevice feature which has the same flaws but is one step better.
They do recommend that if you install the software that you ensure the device itself has a passcode for entry, so that's an extra layer. But most people use a pin, and i imagine will set the Emerge pin to be the same, unless it's configured by a tech.
In theory you've got 3 layers - but all of about equal strength.
If you want to try it before then, give me a call in the office and I arrange something for you.
FYI. New version has been heaviliy optimised, is dramatically faster and has a number of minor bug fixes.
SteveB - I've had some clarification which i didn't think of before to be honest. Each device has to be manually added to the Emerge server console as a device that is allowed to access the software, this is then linked to the users / groups that are granted access. So you could in theory have some devices only usable by senior management.
The data is encrypted and is only available to the correct combination of allowed device, and login credentials. The physical device is what provides the second factor of authentication. I found this when i switched iPhones, it wouldn't even copy over from the backup properly, and had to be reinstalled.
In terms of security, if you were to enter the pin code incorrectly 5 times, this would wipe the data, and after the timeout period, you'd need a password too before you get the pin code screen. So, it's only really susceptible to social engineering or over the shoulder peeping attacks.
With regards my idea to have a time to live for the app itself, that is something they will look into, and would eliminate the last risk factor, that of rogue teacher running off to another country with the device.
I'm in the process of testing out a BETA version, which resolves some minor issues, and should make things a little quicker too. So will report back if there's anything new.
Thanks for that @vikpaw. I think the powers that be a still likely to be nervous that if the device is lost, just a pin could unlock the data (as long as device has not been reported lost). We use fobs for SLG here, and if we lose "the something we have" element it is useless without a working login and password. If this "something we have" is lost a 4 digit pin could unlock it. BUT, i would consider 2 pins and 5 attempts is pretty secure.
That's true @SteveB , i would need to get the tech expert to confirm for sure, but the pin is only valid for 15 minutes, before you're looking at an alphanumeric password. So you're talking about losing the device then within 15 minutes somebody going for that app with a chance of 5/9999 . It's not something you can enforce, but i have recommended that the device itself has it's own pin / passcode lock. I've implemented that too. So most likely, they'll have to break your device passcode then the app one.
For any iDevice users - you can change the passcode for iDevices to be alphanumeric and i'd suggest doing that, much harder to guess and a lot harder to see what is being pressed over the shoulder
To be honest we’re really struggling to find a way around this…
The only thing we can thing of now is to limit the number of attendance codes in Emerge to 7 which you will need to choose from your list of 13.
It’s a real limitation with the API that we’re gutted we can’t get around.
Would the proposed solution work for you?
So the limitations with the API mean that schools that use more than 7 attendance codes for Lesson by lesson reg are scuppered.......
Well I arranged for a trial to be setup and the general feedback I have been receiving from staff is that it is a useful tool in addition to what we already have. There are a few things we would like to see changed, but other than minor annoyances it is going down well.
We do get occasional error messages which go away when you dismiss them, but there is a recurrant error that is popping up. Its not a major error as far as I can tell, but its rather annoying that it pops up as it sometimes needs to be dismissed several times before you can continue. The error message that pops up says:
"Unable to connect to the remote server --> No connection could be made because the target machine actively refused it 188.8.131.52:80"
I have no idea where that ip address is located since its not an internal one, and we haven't had the facility to use the app via 3g setup for the trial. I logged a call with Emerge yesterday but they havent got back to me yet, so was maybe someone here has encountered it before and could shed some light on it?
@jonrose - is it a trial with your own data. it could be that is the ip of the demo server? why that or any server is refusing, i don't know, but an over eager firewall could do it.
just tried to look up the ip and it came back with info for livedns.org through fast hosts, somewhere possible in gloucester, so maybe someone is trying to setup external access via a dynamic dns service.
@vikpaw - yes it's a trial with our own data. A quick message appears about trying to update the app before the error message pops up, so it could be that its trying to update itself. Tgough I would have thought any updates would have to be done through the App Store?!
I thought the update was regarding the databases stored on the phone. So it's checking to see if any have expired. I may be wrong though.
It does a check prior to taking a register if the server is available. It could be a server issue.
There are currently 1 users browsing this thread. (0 members and 1 guests)