Stateless incremental dialog implemetation

Hello all.
I want to implement a stateless incremental payment dialog in a RESTfull
manner like this one:
Client — Server

  1. Post Order —> Return Order Details + Payment Method Form
  2. Post Order + Payment Method —> Return Order Details + Payment
    Method +
    Sender Details Form
  3. Post Order + Payment Method + Sender Details —> Return Payment
    Result

However is the any way how i can be sure that Order was not changed
during
this client server dialog and still be stateless?

  • Best regards, Nikolay P… <<<-----------------------------------
    ======================================================================

On Fri, Sep 28, 2007 at 04:12:42PM +0300, Nikolay P. wrote:

However is the any way how i can be sure that Order was not changed during
this client server dialog and still be stateless?

Include and require a digitally signed hash key in a hidden field and
verify on that.

  • Best regards, Nikolay P… <<<-----------------------------------
    –Greg

On Friday 28 September 2007 16:16:18 Gregory S. wrote:

Include and require a digitally signed hash key in a hidden field and
verify on that.

Thanks Gregory. I have come to the same conclusion. I just want to be
sure
that there is know other known way for such things.
Thanks again.

On Friday 28 September 2007 16:16:18 Gregory S. wrote:

However is the any way how i can be sure that Order was not changed
during this client server dialog and still be stateless?

Include and require a digitally signed hash key in a hidden field and
verify on that.

I forget to ask. Is there any plug-in for that?

On Fri, 28 Sep 2007 09:16:18 -0400, Gregory S. wrote:

However is the any way how i can be sure that Order was not changed during
this client server dialog and still be stateless?

Include and require a digitally signed hash key in a hidden field and
verify on that.

I absolutely don’t mean to spread FUD here, but isn’t that what Rails
2.0
cookie-based sessions do, and isn’t there some way (not obvious to my
sleep-addled brain) to exploit that?

Again: The answer may very well be “no”! There was a really really long
discussion on rails-core about this when cookie-based sessions first
landed
and I just don’t remember the conclusions. I’m hoping someone who
remembers that discussion can jump in.


Jay L. |
Boston, MA | My character doesn’t like it when they
Faster: jay at jay dot fm | cry or shout or hit.
http://www.jay.fm | - Kristoffer

On 9/28/07, Jay L. [email protected] wrote:

Again: The answer may very well be “no”! There was a really really long
discussion on rails-core about this when cookie-based sessions first landed
and I just don’t remember the conclusions. I’m hoping someone who
remembers that discussion can jump in.

You can’t create, modify, or otherwise forge a message, but you can
grab a valid message and ‘replay’ it later. To avoid a replay attack,
you need to include, say, a nonce in the message and check it against
a list of used nonces. Already used the nonce? Replay attack! Reject
message.

jeremy

On Fri, 28 Sep 2007 14:38:47 -0400, Gregory S. wrote:

I absolutely don’t mean to spread FUD here, but isn’t that what Rails 2.0
cookie-based sessions do, and isn’t there some way (not obvious to my
sleep-addled brain) to exploit that?

You missed the “stateless” requirement.

No, I saw it - but I also saw the “how can I be sure” requirement, and I
wasn’t sure that cookie-based solutions met both.

From what Jeremy says about using the nonce - and yes, that’s exactly
what
I was thinking of - it really depends on the application; if a replay
attack could cause something bad to happen, then you simply can’t be
totally stateless.

Looking at the OP’s requirements:

  1. Post Order —> Return Order Details + Payment Method Form
  2. Post Order + Payment Method —> Return Order Details + Payment Method +
    Sender Details Form
  3. Post Order + Payment Method + Sender Details —> Return Payment Result

a replay at (2) could result in someone sending along a digitally
signed
key that says “Order 1 large-screen TV, my American Express is XXXX” and
getting back a nice “Sure thing, we’ve verified that digital signature,
what address shall we ship to?” dialog.

So it’s something to consider in the design.


Jay L. |
Boston, MA | My character doesn’t like it when they
Faster: jay at jay dot fm | cry or shout or hit.
http://www.jay.fm | - Kristoffer

On Saturday 29 September 2007 04:10:48 Jay L. wrote:

signature, what address shall we ship to?" dialog.

So it’s something to consider in the design.

Well I was not totally clear. “Sender Details” here means Sender billing
information. So every time you are replaying (2) you are getting (3) and
every time you are replaying (3), you are getting the bill or
redirection
to some payment gateway. Of course i could be wrong…

On Fri, Sep 28, 2007 at 02:11:58PM -0400, Jay L. wrote:

cookie-based sessions do, and isn’t there some way (not obvious to my
sleep-addled brain) to exploit that?

Again: The answer may very well be “no”! There was a really really long
discussion on rails-core about this when cookie-based sessions first landed
and I just don’t remember the conclusions. I’m hoping someone who
remembers that discussion can jump in.

You missed the “stateless” requirement.

Jay L. |
–Greg

On Saturday 29 September 2007 11:34:40 Nikolay P. wrote:

XXXX" and getting back a nice “Sure thing, we’ve verified that digital
signature, what address shall we ship to?” dialog.

So it’s something to consider in the design.

Well I was not totally clear. “Sender Details” here means Sender billing
information. So every time you are replaying (2) you are getting (3) and
every time you are replaying (3), you are getting the bill or
redirection to some payment gateway. Of course i could be wrong…

By the way on (2) we could include one of those fancy images with zapped
digits in a response and a signature of (order + digits_on_image). Than
on
(3) we could compare received signature and resigned (order +
received_digits). Also we could invalidate the replay in time by adding
something like Time.now.strftime("%Y%m%d%H").to_i to signature. And
still
be stateless.

On Sat, 29 Sep 2007 14:09:53 +0300, Nikolay P. wrote:

By the way on (2) we could include one of those fancy images with zapped
digits in a response and a signature of (order + digits_on_image). Than on
(3) we could compare received signature and resigned (order +
received_digits).

You’re talking about CAPTCHAs… they can be helpful in some cases, but
there are a few drawbacks, including:

  • They’re not accessible, so you need to provide some alternative for
    the
    visually-impaired
  • They’re getting easier and easier to OCR
  • If someone really wants to break your CAPTCHAs, all they have to do is
    redisplay them somewhere else (porn sites, Amazon Mechanical Turk) and
    get
    THEIR humans to solve them

Google for CAPTCHAs before you go that route, just so you understand the
issues.

Also we could invalidate the replay in time by adding
something like Time.now.strftime("%Y%m%d%H").to_i to signature. And still
be stateless.

Not a bad idea at all.


Jay L. |
Boston, MA | My character doesn’t like it when they
Faster: jay at jay dot fm | cry or shout or hit.
http://www.jay.fm | - Kristoffer

On Sat, 29 Sep 2007 11:34:40 +0300, Nikolay P. wrote:

So it’s something to consider in the design.

Well I was not totally clear. “Sender Details” here means Sender billing
information. So every time you are replaying (2) you are getting (3) and
every time you are replaying (3), you are getting the bill or redirection
to some payment gateway. Of course i could be wrong…

Cool, sounds like you’ve already taken replays into account. That’s all
I
was suggesting!


Jay L. |
Boston, MA | My character doesn’t like it when they
Faster: jay at jay dot fm | cry or shout or hit.
http://www.jay.fm | - Kristoffer

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs