API Security

From ePrize Developers Wiki

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
-
TODO: organize and explain.
+
== Trusted Communication ==
-
Use SSL with basic auth and the {apikey} from a trusted computer or nothing except the {apikey} from an untrusted computer. The {apikey} only gives them access to a subset of the API that we want to make available to Flash. What's kind of funny is the subset API is the entire API at the moment. This mirrors exactly what TB2 does right now -- {apikey} is like a deploy path.
+
Any computer which you control may establish trusted communication with ePrize. This requires sending all requests via an [http://en.wikipedia.org/wiki/Secure_Sockets_Layer SSL] connection to your assigned hostname and including your assigned account name and password on each request. [http://www.ietf.org/rfc/rfc2617.txt Basic HTTP Authentication] must be used to send the account name and password. This method is secure and can be improved further using mutual certificate authentication.
-
----
+
The benefit of trusted communication is that you can access the full eWS API including portions of the API to create, modify and delete your promotions.
-
anti-botting protection with CAPTCHA.
+
== Untrusted Communication ==
-
----
+
Any computer which you cannot control may only establish untrusted communication with ePrize. This includes all consumer owned devices. If you build an all-Flash promotion for example, communication from it directly to our servers must be untrusted. You may have the all-Flash promotion connect to your computers first, and then establish trusted communication to ePrize. In this configuration, you are responsible for providing adequate security and protection against automated attacks against your computers.
-
The draft I'm pasting below speaks to SSL mutual authentication. We
+
Untrusted communication does not pass any credentials except your assigned API key. Security is based on the fact that most resources are very difficult to guess and will give ePrize time to detect an attack. ePrize PromotionSAFE technology such as CAPTCHA and address verification increases the difficulty of brute force attacks. Other techniques such as IP throttling and black listing may also be used to increase security.
-
probably won't use that outside of large customers with their own
+
-
security teams, so we probably don't want to include any of that,
+
-
although I'd like to leave it as an option eventually.
+
-
The relevant text is below:
+
You may use SSL with untrusted communication, but this only provides limited protection against disclosure of consumer personal information. Most attacks are still possible even with SSL.
-
AUTHENTICATION
+
Many portions of the eWS API are forbidden or restricted when using untrusted communication. The allowed API calls are carefully chosen to maximize the creative options for all-Flash promotions while still providing reasonable safeguards against attack.
-
Many RTI method calls require privileged access to Toybox functionality.
+
Untrusted communication is also useful for limiting access to your account name and password. If you out-source development of an all-Flash promotion for example, you only need to share the API key. The development team will not be able to access any of your promotion information or consumer personal information.
-
Such calls must be authenticated over the HTTPS protocol.
+
-
The recommended authentication technique is mutual authentication, in
+
== Future Support ==
-
which the client application and Toybox promotion site exchange digital
+
-
certificates. Only recognized and trusted client certificates will be
+
-
permitted to complete the request successfully. This technique has the
+
-
advantage over password-based authentication in that it prevents
+
-
disclosure of a secure password to unauthorized parties.
+
-
To implement mutual authentication, you must first request a certificate
+
ePrize would like to adopt mutual authentication over SSL as our primary authentication system. This ensures that both our identity on the server and your identity on the client are securely exchanged using signed digital certificates. Only recognized and trusted certificates will be permitted to complete the request successfully. This technique has the advantage over password-based authentication in that it prevents disclosure of a secure password to unauthorized parties.
-
from a trusted certificate authority, then supply a copy of this
+
-
certificate to your Account Services team. Finally, configure your
+
-
application to include this certificate on outbound HTTPS requests.
+
-
Your Account Services team will notify you when authentication is ready
+
-
for testing.
+
-
For applications that cannot support mutual authentication, Toybox RTI
+
To implement mutual authentication, you must first request a certificate from a trusted certificate authority, then supply a copy of this certificate to your Account Services team. Finally, configure your application to include this certificate on outbound HTTPS requests. If you are interested in this as an option, please let us know via the mailing list.
-
also supports basic authentication over HTTPS. For use of basic
+
 
-
authentication, a secure login/password will be supplied on request.
+
For applications that cannot support mutual authentication, basic authentication over HTTPS will continue to be a supported option.

Revision as of 05:34, 3 March 2009

Trusted Communication

Any computer which you control may establish trusted communication with ePrize. This requires sending all requests via an SSL connection to your assigned hostname and including your assigned account name and password on each request. Basic HTTP Authentication must be used to send the account name and password. This method is secure and can be improved further using mutual certificate authentication.

The benefit of trusted communication is that you can access the full eWS API including portions of the API to create, modify and delete your promotions.

Untrusted Communication

Any computer which you cannot control may only establish untrusted communication with ePrize. This includes all consumer owned devices. If you build an all-Flash promotion for example, communication from it directly to our servers must be untrusted. You may have the all-Flash promotion connect to your computers first, and then establish trusted communication to ePrize. In this configuration, you are responsible for providing adequate security and protection against automated attacks against your computers.

Untrusted communication does not pass any credentials except your assigned API key. Security is based on the fact that most resources are very difficult to guess and will give ePrize time to detect an attack. ePrize PromotionSAFE technology such as CAPTCHA and address verification increases the difficulty of brute force attacks. Other techniques such as IP throttling and black listing may also be used to increase security.

You may use SSL with untrusted communication, but this only provides limited protection against disclosure of consumer personal information. Most attacks are still possible even with SSL.

Many portions of the eWS API are forbidden or restricted when using untrusted communication. The allowed API calls are carefully chosen to maximize the creative options for all-Flash promotions while still providing reasonable safeguards against attack.

Untrusted communication is also useful for limiting access to your account name and password. If you out-source development of an all-Flash promotion for example, you only need to share the API key. The development team will not be able to access any of your promotion information or consumer personal information.

Future Support

ePrize would like to adopt mutual authentication over SSL as our primary authentication system. This ensures that both our identity on the server and your identity on the client are securely exchanged using signed digital certificates. Only recognized and trusted certificates will be permitted to complete the request successfully. This technique has the advantage over password-based authentication in that it prevents disclosure of a secure password to unauthorized parties.

To implement mutual authentication, you must first request a certificate from a trusted certificate authority, then supply a copy of this certificate to your Account Services team. Finally, configure your application to include this certificate on outbound HTTPS requests. If you are interested in this as an option, please let us know via the mailing list.

For applications that cannot support mutual authentication, basic authentication over HTTPS will continue to be a supported option.

Retrieved from "https://code.helloworld.com/wiki/index.php/API_Security"
Personal tools