1

In Securing an API: SSL & HTTP Basic Authentication vs Signature HTTP Basic Authentication is cited as an adequate way to secure REST web service calls if the REST calls are made through SSL.

But it seems this method will still not work for an unsecured client page that uses Ajax to make calls to the REST service that is protected behind SSL & Basic Auth.

I am trying to design an application that performs password reset using the usual way:

  1. user enters username and requests "reset password" email
  2. user receives email with a password reset link that includes a verifiable token
  3. user clicks on the link and (after the token is verified) types in their updated password

By definition these pages do not require login. Can this UI be implemented using Ajax that calls REST services to do things like validate token, send email, etc.? Even if those REST services are protected behind SSL & Basic Auth, the information that you need to call the service (i.e. the application's "username" and password) will be at best in cookies which would be accessible through the browser.

I know I am missing something. I just don't know what :-)

Community
  • 1
  • 1
pastafarian
  • 1,010
  • 3
  • 16
  • 30

2 Answers2

1

As long as 1 - 3 happen under SSL, the data will be safe over the wire to the server (assuming you trust the certificate authority)

During that process, the browser will hold those credentials in memory. You have no choice but to trust that if the user is going to enter the data.

It is the web sites code that determines whether to store info in cookies.

I think you should be OK if 1 - 3 are under SSL.

bryanmac
  • 38,941
  • 11
  • 91
  • 99
  • Thanks. I think the disconnect in my mind is this: if this is to be a 1 page ajax application, the only trips to the server will be to call these REST services. The REST services need authentication information in order to trust the calling application. How can an ajax app have/use the auth info. without exposing it through the browser? Couldn't anyone just go to this page, look at the cookies it has set and lift the REST username / pass. Then build another app that calls the REST services using the username / pass. – pastafarian Sep 01 '11 at 16:16
  • let's say I want to use amazon S3's basic auth scheme as a guideline for calling our REST services over SSL using basic auth: `Authorization: "AWS" + " " + AWSAccessKeyID + ":" + Base64(HMAC-SHA1(UTF-8(Date), UTF-8(AWSSecretAccessKey)))` ... If it's an ajax "1 page" app, how do we avoid exposing "AWSSecretAccessKey" to the world? – pastafarian Sep 01 '11 at 16:23
0

I've no idea what you're protecting so I'l just toss some thoughts out.

SSL and TLS are not meaningful if you (or someone else who gives a hoot) aren't in control of the root list of the relying party. I say this because I expect that if you don't trust the guy with the key to the lock then you won't put your money in his vault. So if the users loading the login pages are in the wild so to speak then user/pass through TLS is a low bar, definitely good enough for protecting my favorite movies list.

Carby praises to the all being FSM

Ram
  • 327
  • 2
  • 20
  • RAmen! Thanks. It is a low bar for resetting password. IIt just seems that Ajax calling REST is not suitable for apps that don't require a login first. – pastafarian Sep 01 '11 at 16:53
  • I don't see a problem with using AJAX to trigger the reset-your-password-token-link email message. Of course when they click the link in an email proggy or browser it will take them to a new page (or load the page anew anyway). I suppose you are concerned about the cookies being sent to the wrong (bad guy) server... you can't avoid that risk without a lot of heavy lifting. AJAX is not the weakness here. – Ram Sep 01 '11 at 22:05
  • Thanks. Yes my concern is mainly about the "second part" of the workflow _after_ they click on the link. If that part of the app makes Ajax calls the app has to authenticate itself against the REST service but how would it get the authentication info (username/password a.k.a. apikey/sharedsecret) without exposing it to whoever is looking at the browser? – pastafarian Sep 02 '11 at 17:38
  • The validation interface for logging in is a place where an anonymous user has access. The API should not require a system user pass which anonymous users don't have the right to *leverage*- it should either be public or opaque. Public is typical for login APIs - consider the right to login to gmail - if it were restricted then how would you log in; if it had an exposed user pass what would that help; if it had an obscured user pass who would they grant use of the secret user pass to? Anonymous users ! – Ram Sep 04 '11 at 20:38