1

My application implements LTI which receives signed requests with OAuth HMAC-SHA1. They look like:

oauth_version:1.0
oauth_nonce:0aaa53c5d8518ahh56203f5eac773023
oauth_timestamp:1497069755
oauth_consumer_key:foo-test
oauth_callback:about:blank
user_id:99
lti_version:LTI-1p0
lti_message_type:basic-lti-launch-request
oauth_signature_method:HMAC-SHA1
oauth_signature:qe5puCiqcU7UjIe/0NZ0oy4M/8c=

The request can ONLY happen over SSL (we implement no other connection options). So I'm trying to determine if there is any purpose in verifying the oauth_nonce. I believe that the purpose of the nonce is entirely to prevent replay attacks which is already a feature of SSL.

Storing the nonce values will cost money and waste time for each user so I only want to do it if it has some value.

Is there value in storing nonces and rejecting any duplicate requests when the request is made over SSL?

jww
  • 83,594
  • 69
  • 338
  • 732
jrjohnson
  • 2,003
  • 14
  • 22
  • It depends. Does your threat model include replay attacks? If not, then you probably don't need the nonce because the threat of a bad guy replaying a previous message is not present. Also see [What is the use of a client nonce?](https://security.stackexchange.com/q/3001/29925) on the InfoSec.SE. Don't laugh at removing threats you don't like or want to deal with. The web and browser security model do it a lot. Removing inconvenient threats is why phishing is such a problem in browsers and other user agents. The user and some attacks against him/her were removed from the model. – jww Jun 10 '17 at 05:14
  • However, according to [this answer](https://security.stackexchange.com/a/5139/29925) on the InfoSec.SE question: *"According to RFC 2617, the cnonce and nc parameters protect against chosen plaintext attacks."* So it sounds like you need to verify it. – jww Jun 10 '17 at 05:23
  • I absolutely do was to prevent a replay attack, but I believe that is a feature of SSL and so would be unnecessary here. I do recognize the value of preventing this attack here and my first instinct is to validate the nonce, however since storing that WILL cost money and take user time I don't want to do it for no reason. – jrjohnson Jun 10 '17 at 05:31
  • 2
    I'm voting to close this question as off-topic because it is less about a specific programming problem but more about the security properties of a specific protocol. Therefore it should better be asked at security.stackexchange.com. – Steffen Ullrich Jun 10 '17 at 05:45
  • The RFC you reference (2617) is for authenticating over plain http and doesn't apply (other than very very generally) to this question. – jrjohnson Jun 10 '17 at 05:46
  • I understand your concern about appropriateness. I wanted to ensure I had as wide and audience for my question as possible. Since it is about the implementation of good application security over a specific protocol I thought this was the best place for it. As i've posted links to the question in other places to generate feedback I would like to keep it open, but will understand if that isn't possible. – jrjohnson Jun 10 '17 at 05:48

2 Answers2

1

Yes and no,

The SSL/TLS channel itself is protected against replay attacks using the MAC, computed using the MAC secret and the sequence number. (The MAC mechanism is what ensures the TLS communication integrity). See TLS 1.1 specification Appendix F.2

However, this protecting is only against a third party eavesdropper from seeing that application request, and thus from replaying it with their own separate SSL/TLS connection.

However, SSL/TLS on its own doesn't necessarily prevent the legitimate initial user from replaying a request. Protocols and applications that require this additional level of protection tend to have nonce-based mechanisms (as the LTI OAuth signature does) at the application level to address this problem.

pfranza
  • 3,066
  • 2
  • 19
  • 32
  • This is a great way to break this down thanks. It isn't a problem in this case for users to replay their own traffic many times since they cannot change anything - only view what is there. If users *were* able to modify something or if viewing twice was an issue then we would want to verify the nonce on each request. – jrjohnson Oct 18 '17 at 18:50
  • Agreeing - whether this is in SSL or not is irrelevant. In the normal flow these values pass through a browser in an auto-submitted form. The vector to do a replay attack is to infect the browser grab the data as it passes by and then send it again. The SSL will be the same in both the requests. – drchuck Apr 27 '18 at 00:40
1

I will observe that it is very common for LTI applications to protect the launches by insuring the timestamp is within 300 seconds and not worrying too much about the nonce. A lot of the sample code implements this.

The problem is that to handle the nonce you need a database to store nonces for at least as long as the "timestamp window".

There are one of two general approaches to implementing LTI providers. The first, verifies launch validity and then puts all the data into a session and logs the user in. A more sophisticated application implementation gathers all of the launch data including the nonce and absorbs it into a set of tables.

It turns out that most of the LTI implementations are rush jobs so they are happy with the "put it in session" approach. There are a lot of benefits to building a more sophisticated application - and checking nonces is just one of the benefits. But it is non trivial.

I built a framework to handle the heavy lifting for an application that wanted to handle a very rich set of use cases called "Tsugi". You can take a look at the Tsugi data model at:

https://github.com/tsugiproject/tsugi/blob/master/admin/lti/database.php

You can look at how Tsugi handles launches (including nonces) in this code:

https://github.com/tsugiproject/tsugi-php/blob/master/src/Core/LTIX.php

Look for methods called extractPost, loadAllData and adjustData. They are non-trivial - but in a single JOIN the code does secret lookup, data absorbing, and nonce checking (your original question).

I am going to guess that you will will go with the "TL;DR;" version and just keep a 5-minute window - but if you take a quick look a the LTIX class in Tsugi, you can see that there is a good bit that can be done with LTI beyond single sign on.

drchuck
  • 3,485
  • 3
  • 19
  • 25