[CALL] Shorter device registration process

[Andy Buckingham]

Since the last significant work on the RadioTAG specification, a number of other prominent organisation have developed methods to associate devices with online accounts without the use of inputting credentials, such as Facebook:

  https://developers.facebook.com/docs/facebook-login/using-login-with-devices/

and Google (YouTube):

  https://support.google.com/youtube/answer/2523964?rd=3

Both processes only require a code be copied one way from device screen to web interface, rather than both ways like we have in the most recent RadioTAG specification. Though intentional in TAG for greater security, it is more complicated for the user. Considering organisations such as Facebook and Google have adopted the simpler methodology on very prominent projects, it might be worthwhile considering relaxing our own implementation.

I would appreciate other peoples thoughts on this, though we may ultimately end up parking this as an objective depending on the outcome of a wider discussion on which auth model to use. If we can capture thoughts here it can guide our desire to have a simplified device registration mechanic in whichever auth model we adopt in the future.

[Robin Cooksey]

Hi Andy,

 

From what I remember, the reasoning behind requiring the user to enter a code on the receiver was to prevent hijacking of the registration by someone reading the displayed registration key from the receiver screen, and using it to register the receiver to their own account.

I.e., it was effectively confirming that the person performing the registration on the web site still has physical access to the receiver (by entering a code into it), before allowing the registration to complete.

 

However, I think I agree that this is probably a fairly low risk – both in terms of the probability of it occurring, and of the consequences.

If the receiver polls, waiting for registration to be complete, and then displays the user name with which the receiver token is now registered, then it should be obvious to the real user that it’s been registered against a different account.  Also, they should find that their own attempt to register will fail – again alerting them to a problem.

One case would be that the registration is started on the receiver, the registration key read, but registration then cancelled on the radio – so that it no longer polls for completion.  In this case, someone could later use the copied registration key to register against a different account – and it would not be immediately obvious to the receiver’s user.

 

It still doesn’t seem like a very likely scenario, and as long as it’s always possible on a receiver to find out whether it has been registered, and with which account – then it sounds like it’s probably OK, and the simpler user experience would be good.

 

Best regards,

Robin

 

 

--
You received this message because you are subscribed to the Google Groups "RadioTAG developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to radiotag-develo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Andy Buckingham]

One case would be that the registration is started on the receiver, the registration key read, but registration then cancelled on the radio – so that it no longer polls for completion.  In this case, someone could later use the copied registration key to register against a different account – and it would not be immediately obvious to the receiver’s user.

One way we could overcome this is suggest that a Service Provider invalidates the registration attempt if they do not see a poll request come back within a sensible amount of time (supplied interval + 60 seconds for example). This way if the device fails to poll, we should abort the registration attempt.

For clarity we may also want an explicit method that allows the device to tell the Service Provider the attempt has been cancelled on the device, to invalidate the attempt faster.

A

To unsubscribe from this group and stop receiving emails from it, send an email to radiotag-developers+unsub...@googlegroups.com.

[Ben Husmann]

I think keeping the user experience as simple as possible is a good goal. The "hijacking" scenario seems like an edge case to me and shouldn't require us to make user authentication twice as time consuming/confusing.

[Chris Lowis]

Hi,

On the point of a shorter device registration process, I'd just like to issue a note of caution. The design of the existing protocol was quite a lengthy process involving several weeks of Sean's and my time on just this aspect. It revealed quite a lot of subtle opportunities for different types of attacks and failure modes. I know that Andy and Robin also spent a lot of time going through what we'd come up with to verify it. None of us are security experts, but I think what we have is pretty robust. A mistake here, and the subsequent loss of user data, could be very damaging to the fledgling service - remember we (RadioTAG) don't necessarily have the traction of a Google or Apple.

If you'd like to change the protocol to something similar, you should be prepared to put in quite a lot of work until you're happy with the security aspects of it. Remember Google have a huge pool of talent, and considerable data to draw on when it comes to their authentication systems - by copying the surface form of what they do, we may be missing the subtleties.

At the time of designing the PIN system, we discussed using a more basic "username and password" authentication system on devices that can support more sophisticated text entry. The listener would enter their BBC, say, username and password into the radio and it would exchange those credentials for a password. I think this is quite a common mode of authentication, and I'd be interested to see it explored and added to the RadioTAG spec. It has the advantage of being common, and fairly secure.

I think the simplicity of the authentication is a bit of a red-herring. If you're the kind of listener to buy an internet-enabled radio and want to view your tags on a website, I think you're likely to be quite tech-savvy. Secondly this procedure is a one-off which for the average listener takes very little time in the scheme of things - although I know when you're testing it multiple times a day, like I did, it doesn't feel like it!

I'd encourage more user-testing of this if you have concerns about the user experience - we did some originally, which was positive, and I remember James C saying that he thought the process on Robin's prototype radio compared very favourably to other devices' attempts at authentication on the market.

Cheers,

Chris





From: radiotag-...@googlegroups.com [radiotag-...@googlegroups.com] on behalf of Ben Husmann [bhus...@emmis.com]

Sent: 02 July 2013 22:02

To: radiotag-...@googlegroups.com

Subject: Re: [CALL] Shorter device registration process

I think keeping the user experience as simple as possible is a good goal. The "hijacking" scenario seems like an edge case to me and shouldn't require us to make user authentication twice as time consuming/confusing.

--

You received this message because you are subscribed to the Google Groups "RadioTAG developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to radiotag-develo...@googlegroups.com.

For more options, visit
https://groups.google.com/groups/opt_out.

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

[Andy Buckingham]

Thanks for this Chris. As you say, it's really crucial that any changes are extremely carefully considered and explored.

If you'd like to change the protocol to something similar, you should be prepared to put in quite a lot of work until you're happy with the security aspects of it. Remember Google have a huge pool of talent, and considerable data to draw on when it comes to their authentication systems - by copying the surface form of what they do, we may be missing the subtleties. 

The reason we are investigating this area further is because of what others are doing in the same area, which is likely to set user expectations more so than RadioTAG alone. The method employed by Google and Facebook is identical and comparable to Bluetooth pairing and methods used by devices such as the "Fitbit" health tracker, which involve a single code exchange to complete. There has been detailed consideration of this exchange and in FB and Google's case, it appears to be based upon earlier OAuth2 drafts: http://tools.ietf.org/html/draft-ietf-oauth-v2-06#section-2.7

 

At the time of designing the PIN system, we discussed using a more basic "username and password" authentication system on devices that can support more sophisticated text entry.

I'd like to focus our attention on the minimum implementation at this stage. We've previously agreed that we have a baseline requirement to make this work on 2-line displays and car radios, where UIs are basic and/or extremely difficult to input lengthy strings.

I'd encourage more user-testing of this if you have concerns about the user experience - we did some originally, which was positive

This is a really important point. We have not conducted a trial with multiple Service Providers, therefore not exposing users to multiple registration attempts. I don't think we can rely on the user feedback of the curent auth model if they've not had the ability to use it across multiple Service Providers.

On Wednesday, 3 July 2013 08:08:18 UTC+1, Chris Lowis wrote:

Hi,

On the point of a shorter device registration process, I'd just like to issue a note of caution. The design of the existing protocol was quite a lengthy process involving several weeks of Sean's and my time on just this aspect. It revealed quite a lot of subtle opportunities for different types of attacks and failure modes. I know that Andy and Robin also spent a lot of time going through what we'd come up with to verify it. None of us are security experts, but I think what we have is pretty robust. A mistake here, and the subsequent loss of user data, could be very damaging to the fledgling service - remember we (RadioTAG) don't necessarily have the traction of a Google or Apple.

If you'd like to change the protocol to something similar, you should be prepared to put in quite a lot of work until you're happy with the security aspects of it. Remember Google have a huge pool of talent, and considerable data to draw on when it comes to their authentication systems - by copying the surface form of what they do, we may be missing the subtleties.

At the time of designing the PIN system, we discussed using a more basic "username and password" authentication system on devices that can support more sophisticated text entry. The listener would enter their BBC, say, username and password into the radio and it would exchange those credentials for a password. I think this is quite a common mode of authentication, and I'd be interested to see it explored and added to the RadioTAG spec. It has the advantage of being common, and fairly secure.

I think the simplicity of the authentication is a bit of a red-herring. If you're the kind of listener to buy an internet-enabled radio and want to view your tags on a website, I think you're likely to be quite tech-savvy. Secondly this procedure is a one-off which for the average listener takes very little time in the scheme of things - although I know when you're testing it multiple times a day, like I did, it doesn't feel like it!

I'd encourage more user-testing of this if you have concerns about the user experience - we did some originally, which was positive, and I remember James C saying that he thought the process on Robin's prototype radio compared very favourably to other devices' attempts at authentication on the market.

Cheers,

Chris





From: radiotag-...@googlegroups.com [radiotag-...@googlegroups.com] on behalf of Ben Husmann [bhus...@emmis.com]

Sent: 02 July 2013 22:02

To: radiotag-...@googlegroups.com

Subject: Re: [CALL] Shorter device registration process







I think keeping the user experience as simple as possible is a good goal. The "hijacking" scenario seems like an edge case to me and shouldn't require us to make user authentication twice as time consuming/confusing.

--

You received this message because you are subscribed to the Google Groups "RadioTAG developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to radiotag-developers+unsub...@googlegroups.com.