New options for securing administrative interfaces - the new device based approach

I originally intended for this to be a community post - but it's length, to properly discuss the subject warranted a blog post.

Dan - wrote in our community:

I've noticed that when I go back to my iPad or iPhone browser (to see if there are any new orders in Zoovy for example) after having been logged in to Zoovy from one or two different PC's during the day (and after many hours or sometimes days) since I used the the iPad or iPhone to check Zoovy, I am immediately logged in and the screen refreshes with the latest data. While this is really nice in my case, it is different than the single session security the system used to have an could be a problem if we were to use someone else's iPad, phone or PC. They would have the ability to login (or refresh essentially) under my login. Again, this is by just going to the tab that already has the super long URL in it, not by going to zoovy.com - I guess one thing we could do is make a habit of logging out?

Security models are always evolving. 

First - yes Dan, what you suggest is timeless advice -- you should ALWAYS click the exit button if there is a reasonable expectation that somebody you don't want to have access to your store that could have access to your device.
We call it "exit" because it's an app, but it has the same effect as logout, it severs the connection (assuming your Internet is still working)

But I would like to address/defend the long session timeout issue.  I think it's fine.
In today's threat model - we are trusting that the end user or organizational security administrator can purchase, and reasonably secure a device.  And that any security administrator will be able to remotely brick the device. (Brick is a cute way of saying "disable" or "render unusable").

I became very aware of this capability a few years ago when my daughter Kimberly had her iphone stolen at the mall. Once she realized it had been stolen she used her friends phone to login and disable the phone, then she put a message on the phone to the person who took it saying to call her at her phone number so she could get her device back and informing them if they did not that she would report it to the police. She tracked the device to it's last gps location and then called Dad (me) and asked me to go get it.
Now I wasn't sure what type of hardened criminal I would encounter I decided it would be best to call the local constabulary and asked them to have an officer meet me there. The phone had been turned off for a few hours, but we knew it's last location. Ultimately I ended up meeting the officer at a Starbucks down the street and he, and two other officer went over to and retrieved the phone. The officer was able to identify the device because of the message on the phone.
The home-owner was cooperative and did not have the phone, but knew who had it and went to get it for the officer in exchange for us declining to press charges. The officer was able to identify it was the correct phone because of the message on the screen. The phone was returned to us by the officer without incident.
Even if the phone had been lost, all photos, music, etc. was all backed up to the cloud - no data would have been lost. This was my first-hand experience in the evolution of threat models.

We are tracking device authentication now (new feature of the app framework) and while we don't *currently* make anybody go through a complicated "new device authentication" process - it is absolutely something that we will be adding, as well as the ability for the security administrator to remotely terminate authentication for a device (and be notified at "wire speed" when new devices attempts authentication).

I feel compelled to say that features like the one I'm about to describe require a very fast internal event messaging system to connect messages from one webserver to another. (Yep -- it's that same messaging system that's giving us all the grief in supply chain these past few weeks)

 Here is an example device authentication message exchange - (messages are necessary because different devices may be connected to different servers).
Anyway here goes:

• A New device requests permission => message to security system 
• A Notification broadcast via event system to all security adminstrators via all available channels - sms,push to native phone app, or popup on screen
• One or more security administrators receives "user xyz is requesting permission to login from device abc named 'Bobs Home' the device appears to be an ipad/browser/unknown - shall i approve?" 
• Security administrator responds via sms response, touch approve, or click approve in browser.
• If no security administrator responds within timeout (ex: 10 minutes) then default allow/deny protocol is followed. 
• A return message is sent to authentication system and accepted/rejected. 
• Then the remote session is allowed to proceed/fails and remote user is notified via another event message.
• 
  

Now our original event system which could take 2-3 minutes per message (each trip) would make that process take 10-15+ minutes - which would be a horrible user experience, the new messaging system (again -- the same one that is causing all your supply chain orders issues) is the one that allows us to deliver that new behavior. 

I think we can make that whole experience described above take less than a minute then I think it would be a welcome amount of security.  Of course security administrators who don't want that level of security can leave "allow any new devices to authenticate" open and never be notified. 

Now - In today's threat model - for the most part once a device is authenticated we *should* assume we can trust it. People don't share phones, or pads (as a rule) - hence the long session timeouts.  Trade a daily password, with a strong device setup. 

There should be a configuration setting IN AN APP (not server based) to idle itself out based on user preferences if that's something you need.

But ultimately that's not the real threat these days, it's stolen/lost equipment.
When you're purchasing a new device consider the security -- new devices have really diverse and highly configurable security models (pin pad, pattern, facial recognition, voice, screen saver/passwords) and so the trend in software/services is "don't re-invent the wheel".  Facial recognition can be fooled by devices with 2d cameras, but not devices with 3d cameras.  Future devices will have different authentication / locking protocols based on the location of the device.  (Ex: in a mall, lock fast, at home, lock slow)  -- this will just get easier and easier as the devices continue to get smarter and more aware of their surroundings.

For that reason it really doesn't make sense for each app to re-create it's own security.  Ultimately if the device isn't secure - I can't defend against that.   For example even if a hostile attacker can't use the application - BUT they have physical access to the device they can just as easily install a keystroke logger, etc. and get in that way -- which is why the device authentication is way more important. 

If you lend your laptop/phone/tablet etc. to anybody you should expect to do a full system wipe when it returns. You should not be processing orders on public internet terminals or libraries, or computers in kinkos -- EVER, seriously, it's about the same chance something bad happening as having vigorous unprotected sex with a Bangkok prostitute. 

Once a "clean" device is authenticated - it should be safe to trust at least for most commercial needs (maybe not industrial or military). If the device trust is broken - it's simply a failure of the security protocols that were on the device before it was ever authenticated.   Passwords suck, they don't work and I for one look forward to a day when we don't need them anymore. 

Because of our app based framework I'm excited by the new things we can do -- it will allow us to define the security administrator role even further.

The security administrator should be able to see activity by device, be notified of suspicious activity on a device and be able to remote terminate that session.

A great example of that is if an employee who was fired but had been logged in on his phone/tablet at home.

In addition we are excited because our app framework lets us better describe the roles of employees/access so that a compromised device (token) can't be dropped into a hostile application and use the API rip the business a new a**hole.

I hope you enjoyed reading this as much as I enjoyed writing it.