I've just read this very interesting article: Principles for Standardized REST Authentication and I'm wondering why one should sign REST queries even when using SSL. In my understanding, signing REST queries lets the server ensure requests come from trusted clients.
Having said that, is signing really necessary considering that SSL also protects against man-in-the-middle attacks?
As stated on the Wikipedia article for HTTPS:
[...] HTTPS provides authentication of the web site and associated web server that one is communicating with, which protects against man-in-the-middle attacks. Additionally, it provides bidirectional encryption of communications between a client and server, which protects against eavesdropping and tampering with and/or forging the contents of the communication. In practice, this provides a reasonable guarantee that one is communicating with precisely the web site that one intended to communicate with (as opposed to an imposter), as well as ensuring that the contents of communications between the user and site cannot be read or forged by any third party. [...]
This is why you need HTTPS, so that the client "is sure" that it's requests are sent to the proper destination. The article you linked also says this:
If you are not validating the SSL certificate of the server, you don't know who is receiving your REST queries.
But HTTPS normally does not authenticate the client unless you configure the server to request a certificate from the client in order to perform mutual authentication. If you read the comments in the post you linked you will see people mentioning this:
If you are going to use https, why not use it fully, and ask for client side certificates too? Then you get a fully RESTful authentication method, because the client and the server are authenticated at the connection layer, and there is no need to bring authentication into the URI level.
But HTTPS with client-side certificates is more expensive and complex so most API providers keep "the normal" HTTPS to identify the server and use a lighter mechanism to identify the clients: the API keys. The API keys basically consist of a name which is public - for example "Johnny" - and a secret key which is private - for example a long string of randomly generated characters.
When you make a request to the server you include the name "Johnny" in the URL so that the server knows who sent the request. But the server doesn't just blindly trust you that you are "Johnny", you have to prove it by signing the request with the secret key which, because it's private, only the real "Johnny" knows.
A digital signature has legal implications such as non-repudiation, which any value transaction should require. It's not just a matter of authentication. A digital signature on an actual transaction is a much stronger piece of evidence in court than 'this conversation was carried out over SSL with mutual authentication so it must have been the defendant Your Honour'.
Related
I have been looking into REST authentication schemes (many discussed on SO), and many of them seem to be overly complex for my purposes. I have formulated a simpler scheme from elements of the more complex ones: but I would like to know if there are any security holes in my approach.
Influencing factors:
TLS everywhere is too slow and resource heavy
I do not require security against eavesdropping as all information is public.
Proposed authentication scheme:
"Sign up" and "Login" are achieved via a TLS connection. On Login, a username and password are supplied and a shared secret key is returned by the server (and then stored in local storage by the client e.g. HTML5 local storage, App storage, etc).
Every other request takes place over cleartext HTTP
Client side algorithm:
Before sending, every request is "salted" with the shared secret key and an SHA hash is taken of the salted request.
This hash is inserted into the request in a custom HTTP header.
The salt is removed from the request.
The request is sent with the custom header.
Server side algorithm:
Server isolates and removes the custom Hash header from the request.
Server salts the request string with the shared secret key.
Server takes the hash of the salted request and compares it to the value of the custom hash header.
If they are the same, we have identified which user sent the request and can proceed with authorisation etc based on this knowledge.
Are there any vulnerabilities in this scheme that I have overlooked?
I would question your assumptions here.
TLS everywhere is too slow and resource heavy
TLS is becoming almost ubiquitous for APIs and one reason is because it is now relatively cheap for both clients and servers to support it. How much overhead? As usual "it depends" but certainly negligible enough for most modern APIs, even mass-consumer APIs like Facebook and Twitter, to be moving towards using it exclusively.
I do not require security against eavesdropping as all information is public.
This is a common myth about TLS. Even for public data, consider the implications:
Any intermediary agent can inject their own requests and responses. It could be junk, malicious, subtly incorrect, whatever. Secure communication is not just to keep the content private, it's also to maintain its integrity. (A common example is telcos and hotels injecting ads into websites.)
The data may be public, but the traffic may still be sensitive. What if you could monitor Apple's Wikipedia requests? Would it be interesting if there was a spike in requests to car-related articles? Without TLS, intermediaries can monitor requests a user is making.
None of which critiques your algorithm. You could ask on Cryptography Stack, but it's considered fairly risky to roll your own authentication and rarely worth it nowadays.
What you are describing is an MAC based authentication scheme. Instead of rolling your own implementation, you should look at Hawk or AWS authentication schemes.
A downside of such an authentication scheme is that the server that needs to validate the request needs to talk to the authentication server to get the secret key. This impacts the scalability of the system in a negative way.
Token based authentication schemes can validate the request without going back to the token issuing authority due to digital signatures.
Finally, I agree with #mahemoff that TLS is becoming ubiquitous and very cheap. Actually, depending on the circumstances, HTTPS may outperform HTTP.
I'm writing REST API in PHP and recently I faced with authorization problem. I read a lot about basic authorization, about using private and public keys to create request signature. It is said that using request signature is more secure. But then I have a question:
-How should user will pass public key and generated signature?
I'm thinking about several options:
1) Create custom http header like X-Key, X-Signature
2) Use authorization header with custom scheme, like
AUTHORIZATION: SIGNATURE key='123' signature='abc'
3) Send this values as parameters. But I don't know if it acceptable for methods DELETE and PUT
What would you advice?
p.s. I don't want to implement oAuth
What are the desired properties of authentication scheme? Is this a publicly accessible or an intranet service? Are user accounts linked to something outside of scope of your API (linked 3rd party accounts etc). How are you going to distribute user credentials?
I would probably stick with plain old basic authorization, but encrypt everything at the transport level, making use of HTTPS mandatory. Rolling out your own cryptographic scheme is generally not a good idea. It's easier to fall victim to timing or replay attack than it seems. If you insist on client using a key pair for authentication, you can use HTTPS client certificates (though this is not widely used and maybe somewhat cumbersome solution).
There are a few security concerns about plain-text authentication over TLS. First, if someone implements MITM with forged certificate using either well known CA (maybe a government agency) or CA the client is forced to trust (big evil corporate proxy), they will get credentials. But you can't protect the client from its own environment anyway. Second, basic authentication can be prone to CSRF because browser knows how to do it and can remember credentials if you presented challenge and user filled the form. That's not a big problem if you adhere to REST principles and never allow state-changing GET requests. Also, if you are using JSON, never return arrays.
I'm building and iPhone App that will make requests to an application of mine running on a server. I'm using REST to build the server's application API. What is the best way for securing the requests from the iPhone to the server and viceversa. Is OAuth a good option? What would you recommend?
Thanks!
If it's a server you control, use a SSL/TLS connection for all communications between the phone and your server. Make sure that the phone app code checks the server's certificate (e.g., to check that it is a cert for your domain name, where your domain name is hardcoded into the source code). This will protect against eavesdropping, man-in-the-middle attacks, message forgery, and other attacks on the data while it is in transit.
There is not really any way to answer the question "what's best" without a lot more information on the security needs of your app.
In general, you should consider authentication, authorization, and transport.
Authentication could be as simple as username/password login. This could be simple authentication, OAuth, kerberos, etc. It is meant to identify the user. Authorization deals with which services are allowed to be accessed by which groups or individuals. You'd need a way to grant and maintain privileges. Finally, securing the transport typically means using encrypted services, such as HTTPS over SSL. This prevent data from being intercepted or altered during transport.
There are many other considerations to think about including how your protecting personally-identifiable information, encryption, etc., but again, there is no one-size-fits-all solution that could be recommended.
The standard should solve the following Authentication challenges like-
Replay attacks
Man in the Middle
Plaintext attacks
Dictionary attacks
Brute force attacks
Spoofing by counterfeit servers
I have already looked at Amazon Web Services and that is one possibility. More importantly there seems to be two most common approaches:
Use apiKey which is encoded in a similar fashion like AWS but is a post parameter to a request
Use Http AuthenticationHeader and use a similar signature like AWS.
Signature is typically obtained by signing a date stamp with an encrypted shared secret. This signature is therefore passed either as an apiKey or in
the Http AuthenticationHeader.
I would like to know weigh both the options from the community, who may have used one or more and would also like to explore other options that I am not
considering. I would also use HTTPS to secure my services.
"authentication" means:
prove me you are who you say you are
"who you are" is the identity of an entity (person, computer user, software, server, etc...)
"identity" is an attribute unique to each entity (a dba would say primary key here)
so you must prove to have that unique attribute in a way or another.
When the entity here is an HTTP client, then HTTP Auth is the standardized way to prove to the server its unique identity (represented by what we call a user name).
It does not bother with the security of the channel, that's what the presentation layer (ie., SSL) is for, and requires a shared secret between the parts. "Shared secret" means that both parts must know it and no one else does. This implies the two parts trust each other on not disclosing the secret or taking appropriate measures if it gets disclosed (changing the secret, for example).
HTTP as a protocol does not include other ways to do authorization and leaves that at other layers. As an example, SSL can prove the identity of the two parties without sharing a secret via the use of a public key infrastructure (certificates and certification authorities).
In the end:
if it's ok for you to share a secret between the parties, you can use HTTP Auth for authentication and SSL to secure the channel. It's up to the parties to securely exchanging and storing the shared secret
if you don't want to share a secret, but the parties can agree on a common trusted third party, you can speak plain HTTP and use SSL for both securing the channel and proving the identity of one or both parties using a PKI (> certificates)
there are many other possibilities but this two are the most standard I can think of and should be compatible with most of the existing HTTP softwares/libraries/whatevers out there
home brew systems, while technically valid, will either break accepted standards or be ad-hoc (hence non standard) systems implemented at the application layer (to solve an issue that should be addressed at another layer, bah)
There are no ways to prove the uniqueness of something without agreeing on a shared secret (and keeping it secret) or agreeing to trust someone else to take care of that uniqueness (PKI). Everything else is just implementation details.
I'm not certain there is one standard. If there is it would likely be HTTP Auth, (Basic or Digest). Both of the aforementioned are pretty poor solutions.
AWS is a good example of how a "roll-your-own" auth solution could work, however, when you're talking about security/authentication, roll-your-own is usually a bad idea unless you're a security/crypto guru.
My preferred choice is actually just using Client Side Certificates. It takes care of the authentication and security process. No need for an API Key because the Cert itself identifies the client user.
Background:
I'm designing the authentication scheme for a REST web service. This doesn't "really" need to be secure (it's more of a personal project) but I want to make it as secure as possible as an exercise/learning experience. I don't want to use SSL since I don't want the hassle and, mostly, the expense of setting it up.
These SO questions were especially useful to get me started:
RESTful Authentication
Best Practices for securing a REST API / web service
Examples of the best SOAP/REST/RPC web APIs? And why do you like them? And what’s wrong with them?
I'm thinking of using a simplified version of Amazon S3's authentication (I like OAuth but it seems too complicated for my needs). I'm adding a randomly generated nonce, supplied by the server, to the request, to prevent replay attacks.
To get to the question:
Both S3 and OAuth rely on signing the request URL along with a few selected headers. Neither of them sign the request body for POST or PUT requests. Isn't this vulnerable to a man-in-the-middle attack, which keeps the url and headers and replaces the request body with any data the attacker wants?
It seems like I can guard against this by including a hash of the request body in the string that gets signed. Is this secure?
A previous answer only mentioned SSL in the context of data transfer and didn't actually cover authentication.
You're really asking about securely authenticating REST API clients. Unless you're using TLS client authentication, SSL alone is NOT a viable authentication mechanism for a REST API. SSL without client authc only authenticates the server, which is irrelevant for most REST APIs because you really want to authenticate the client.
If you don't use TLS client authentication, you'll need to use something like a digest-based authentication scheme (like Amazon Web Service's custom scheme) or OAuth 1.0a or even HTTP Basic authentication (but over SSL only).
These schemes authenticate that the request was sent by someone expected. TLS (SSL) (without client authentication) ensures that the data sent over the wire remains untampered. They are separate - but complementary - concerns.
For those interested, I've expanded on an SO question about HTTP Authentication Schemes and how they work.
REST means working with the standards of the web, and the standard for "secure" transfer on the web is SSL. Anything else is going to be kind of funky and require extra deployment effort for clients, which will have to have encryption libraries available.
Once you commit to SSL, there's really nothing fancy required for authentication in principle. You can again go with web standards and use HTTP Basic auth (username and secret token sent along with each request) as it's much simpler than an elaborate signing protocol, and still effective in the context of a secure connection. You just need to be sure the password never goes over plain text; so if the password is ever received over a plain text connection, you might even disable the password and mail the developer. You should also ensure the credentials aren't logged anywhere upon receipt, just as you wouldn't log a regular password.
HTTP Digest is a safer approach as it prevents the secret token being passed along; instead, it's a hash the server can verify on the other end. Though it may be overkill for less sensitive applications if you've taken the precautions mentioned above. After all, the user's password is already transmitted in plain-text when they log in (unless you're doing some fancy JavaScript encryption in the browser), and likewise their cookies on each request.
Note that with APIs, it's better for the client to be passing tokens - randomly generated strings - instead of the password the developer logs into the website with. So the developer should be able to log into your site and generate new tokens that can be used for API verification.
The main reason to use a token is that it can be replaced if it's compromised, whereas if the password is compromised, the owner could log into the developer's account and do anything they want with it. A further advantage of tokens is you can issue multiple tokens to the same developers. Perhaps because they have multiple apps or because they want tokens with different access levels.
(Updated to cover implications of making the connection SSL-only.)
Or you could use the known solution to this problem and use SSL. Self-signed certs are free and its a personal project right?
If you require the hash of the body as one of the parameters in the URL and that URL is signed via a private key, then a man-in-the-middle attack would only be able to replace the body with content that would generate the same hash. Easy to do with MD5 hash values now at least and when SHA-1 is broken, well, you get the picture.
To secure the body from tampering, you would need to require a signature of the body, which a man-in-the-middle attack would be less likely to be able to break since they wouldn't know the private key that generates the signature.
In fact, the original S3 auth does allow for the content to be signed, albeit with a weak MD5 signature. You can simply enforce their optional practice of including a Content-MD5 header in the HMAC (string to be signed).
http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html
Their new v4 authentication scheme is more secure.
http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html
Remember that your suggestions makes it difficult for clients to communicate with the server. They need to understand your innovative solution and encrypt the data accordingly, this model is not so good for public API (unless you are amazon\yahoo\google..).
Anyways, if you must encrypt the body content I would suggest you to check out existing standards and solutions like:
XML encryption (W3C standard)
XML Security