I need your help please.
I developed some REST services with .NET Web API.
These sevices must authenticate the clients with username and password.
The solution I find out in Internet is "Basic Authentication".
The BIG problem is that I can't use SSL for secure the comunication. I don't have HTTPS.
Using basic authentication without SSL is not a good solution.
I'm not able searching on Internet to find out a solution that can authenticate the clients over http using username and password.
Please can you help me?
Summarizing I need to authenticate the user in a Web.API using username and password. I can't use SSL. My comunication is on HTTP.
Thanks!!!
You could use the ASP.NET membership provider:
http://msdn.microsoft.com/en-us/library/yh26yfzy(v=vs.100).aspx
Basically - you can't do that.
Sure there are scheme that don't transfer credentials in clear text over the wire - but it is not only about the credentials. All the data is going over the wire in the clear as well, you have no authentication of the server, no confidentiality, no integrity protection, no replay protection etc…
If you don't care about all these features - why bother with (secure) authentication at all?
The only other common approach for username + password authentication I am aware of is digest access authentication. There is a blog here showing an example for WebApi.
This will give you some protection without SSL as it uses hashes; however, I wouldn't really advocate it until all the disadvantages of this approach a fully read and understood.
Without SSL, basic is not secure but digest is also not secure due to man-on-the-middle attacks. I would recommend you to use some public/private key based approaches like HMAC or encrypting as paul said with hash + salt.
Related
I'd like to allow untrusted clients to subscribe to MQTT and AMQP queues on ably.io.
Can I use one of the token authentication schemes described in https://www.ably.io/documentation/core-features/authentication#token-authentication somehow, or do I have to set up a separate API key for each client?
If the latter, can API keys be provisioned dynamically?
I went through the docs & help desk articles, but couldn't find anything regarding this combination. Is this just a missing feature or generally a bad idea on my part?
Thanks in advance
Short answer: Yes
Long answer: Token authentication can be used for authenticating all kinds of Ably clients. As an example, have a look at the MQTT docs on Ably's website and you'll find the authentication section that explains how to implement Token Auth with MQTT. As you just said, using Token Authentication is not only more secure but also gives you a way as an admin of the app to set up your own authentication server to carry out your custom authentication strategy.
Hope that helps!
P.S. I'm a Developer Advocate for Ably Realtime.
What is the best way to authenticate clients that uses my private REST API? I will not be opening this to outside public. Is there a easy and secure way to do this?
Note: I'm running SSL already. I've looked at HTTP Basic Auth over SSL, but I don't want to ask the user to send the password every time, and it seems not good practice to store the user/pass in the client to be send automatically.
Any ideas or best practices?
You can use the most adopted authentication approach which is OAuth
You select the best suited one between OAuth 1.0a and OAuth 2.0
Here is a comparison between the above two ways : How is OAuth 2 different from OAuth 1?
There are several levels to implement security / authentication in RESTful services:
Basic authentication. Username and password are sent for each call within the Authentication header encoded with based 64.
Token-based authentication. This implies a dedicated authentication resource that will provide temporary token based on credentials. Once received there is no need to use again credentials since this resource also gives a refresh token to a new authentication token when the previous expired.
OAuth2. It provides different flows according to the use cases. It allows to let the end user to authenticate through a third-part provider (google, facebook, ...). The application doesn't manage username / password (and even know the password). The drawback of this technology is that it provides high-level hints and it's not so simple to implement.
Here are some links that could provide you some additional hints:
Implementing authentication with tokens for RESTful applications - https://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/
OAuth2 flows - http://www.bubblecode.net/en/2013/03/10/understanding-oauth2/
Hope it helps you,
Thierry
We are in the process of planning an iOS application in which users will need to be authenticated and authorized before they can interact with data provided by a Symfony2 web service.
Authorization will be implemented with ACLs, it's the authentication I'm not sure about.
From what I found in my research, there are a few ways to achieve the authentication part, but since there won't be any third parties accessing the data it sounds like basic HTTP authentication paired with a SSL certificate is the way to go. Is this correct?
Additionally, is a simple username and password secure enough, or is it better to add some sort of API key for identification?
If a key is needed and considering our users will be part of a group, should a key be bound to every user individually or to the group as a whole?
Finally, and slightly off topic, Symfony2 has FOSRestBundle, is there a defacto REST library for iOS?
For securing REST applications in symfony the FOSOAuthServerBundle is very useful. With it you can implement easy OAuth authentication for your app. OAuth is de facto standard for securing REST web services.
As https/ssl is pretty secure you can go for basic http authentication and/or the api key solution.
Wether to use a key and/or username/password is your personal choice.
If somehow requests can be catched in cleartext either one is compromised.
Keys in addition to username/password auth can have the advantage of seperating i.e. user contingents.
Basic http authentication is mostly used, therefore the chance of your client having already available methods to integrate it from his side are high.
You should always give out unique keys or username/passwords to every user in order to be able to log who did exactly what.
I'm not that much into iOS, sorry.
I am currently working on a API site based on Zend Framework. As ZF doesn't have sufficient support for Digest Authentication and it is too late to shift to another framework now, I am thinking of implementing Basic Authentication.
Basic and Digest are not actually the ideal way to perform authentication, while Digest is better but unfortunately not quite supported by Zend (implementing it properly will take too much work, need the project done asap). One of the big problem with Basic auth is that password is sent in cleartext form. I am thinking instead of sending the password in cleartext form, can I somehow hash it using one-way-hashing algorithm / bcrypt to avoid sending password in cleartext form? But it is still suffering from man-in-the-middle attack though.
But if comparing the basic authentication with current form-based authentication used by most web-apps, are they both sharing the same security problem while transferring the request to the server?
Your best option for keeping the request secure is to use SSL for your authentication requests to ensure that the information isn't sent in plaintext.
If you try to do some kind of hashing or encryption on the client before sending the authentication request, you immediately expose your hashing algorithm and any salts you might be using to malicious users. This makes it possible for them to use dictionary attacks against your server.
But if comparing the basic
authentication with current form-based
authentication used by most web-apps,
are they both sharing the same
security problem while transferring
the request to the server?
Absolutely they are. Again with forms based authentication your best bet is to use SSL.
Alternatively, you might consider using an external authentication service like OAuth.
Hum, Zend Framework has an Digest Adapter for Authentication?
Manual: Zend Digest Authentication
You could always write your own Zend_Auth_Adapter for HTTP authentication. I implemented Zend_Auth_Adapter_Http_Resolver_Interface to have different passwords each day in the format of default password + day + month. Works like a charm!
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