• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

E-mail link entry to webapp

 
Ranch Hand
Posts: 270
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a web application ( order system ) which is going to send an e-mail to a confirmer each time an order is going to be approved/rejected.

To avoid that the confirmer has to login into the system each time, I want to make a direct link in the e-mail from where you can approve or reject the order...

My question is:
How can authenticate the confirmer, if I don�t use the username and password of the confirmer in the link?

Can I use the digest (hash) of his password? What if someone gets this digest, then they have access to the confirmers account through this direct link "backdoor"?

Below I show an example of how another network solve the problem. They use a loginid and smid? How does this works?

http://www.domain.do?loginid=F6UQ7B12gregewre98985&smid=10786785_100_KkyA04Aic0IzlulkuiVI-454876488
[ August 02, 2006: Message edited by: Jeppe Fjord ]
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If someones email is compromised then there are probably bigger problems than orders getting approved/rejected.

I wouldn't include even a hash of the password. You could use some kind of ID which is good for doing just this one transaction (approval/rejection). From there, the user should not be allowed to do anything else, in particular not be able to get at details of the user account. This ID should only be usable once, and only for a limited time (say for an hour or a day).
 
Jeppe Sommer
Ranch Hand
Posts: 270
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your reply.

I understand the solution you propose.
 
Greenhorn
Posts: 22
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You could encrypt the e-mail using the user's public key (assuming they have a public key). Then _only_ the user who has the private key (which would be assumed to be the one you thought you were sending the message to) would be able to open the message and reply. Then you could use a one-time token embedded in the message to allow approval, and be completely secure.

Ultimately, if you are sending your message over e-mail, and it's not encrypted - it isn't secure. If your system has any requirement for "real" authentication, you can't do it without encryption. Keep in mind that you are getting an "approval" for a reason - you want to link the approver to the transaction, and guarantee that the approver can't repudiate the transaction (e.g. "I didn't approve that!"). If you send the approval in clear text via e-mail, you are guaranteeing that any approver _can_ repudiate the transaction, because any number of people could intercept the e-mail and approve the transaction. (And even prevent the "real" approver from seeing the e-mail.)
 
Robin Wilson
Greenhorn
Posts: 22
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One other thing, you would want to encrypt the response - using the public key of the web application (server), so that the response can't be intercepted and modified along the way...
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic