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 Pavlov. <<<----------------------------------- ====================================================================== --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Fri, Sep 28, 2007 at 04:12:42PM +0300, Nikolay Pavlov wrote:> > 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?Include and require a digitally signed hash key in a hidden field and verify on that.> - Best regards, Nikolay Pavlov. <<<-------------------------------------Greg --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Friday 28 September 2007 16:16:18 Gregory Seidman 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. -- ====================================================================== - Best regards, Nikolay Pavlov. <<<----------------------------------- ======================================================================
On Friday 28 September 2007 16:16:18 Gregory Seidman wrote:> On Fri, Sep 28, 2007 at 04:12:42PM +0300, Nikolay Pavlov wrote: > > 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? > > 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? -- ====================================================================== - Best regards, Nikolay Pavlov. <<<----------------------------------- ======================================================================
On Fri, 28 Sep 2007 09:16:18 -0400, Gregory Seidman 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 Levitt | 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 9/28/07, Jay Levitt <jay+news-WxwZQdyI2t0@public.gmane.org> wrote:> On Fri, 28 Sep 2007 09:16:18 -0400, Gregory Seidman 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.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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Fri, Sep 28, 2007 at 02:11:58PM -0400, Jay Levitt wrote:> > On Fri, 28 Sep 2007 09:16:18 -0400, Gregory Seidman 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.You missed the "stateless" requirement.> Jay Levitt |--Greg --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Fri, 28 Sep 2007 14:38:47 -0400, Gregory Seidman wrote:> On Fri, Sep 28, 2007 at 02:11:58PM -0400, Jay Levitt wrote: >> >> On Fri, 28 Sep 2007 09:16:18 -0400, Gregory Seidman 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? > > 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 Resulta 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 Levitt | 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Saturday 29 September 2007 04:10:48 Jay Levitt wrote:> 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.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... -- ====================================================================== - Best regards, Nikolay Pavlov. <<<----------------------------------- ======================================================================
On Saturday 29 September 2007 11:34:40 Nikolay Pavlov wrote:> On Saturday 29 September 2007 04:10:48 Jay Levitt wrote: > > 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. > > 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. -- ====================================================================== - Best regards, Nikolay Pavlov. <<<----------------------------------- ======================================================================
On Sat, 29 Sep 2007 11:34:40 +0300, Nikolay Pavlov 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 Levitt | 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Sat, 29 Sep 2007 14:09:53 +0300, Nikolay Pavlov 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 Levitt | 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---