22 Dec
2008
22 Dec
'08
3:21 p.m.
On Mon, Dec 22, 2008 at 2:50 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
+1 for this...
and even HTTPS can be attacked :)
Pascal Voitot wrote:
I was joking :)
Basic auth will be good enough :)
On Mon, Dec 22, 2008 at 12:14 PM, Eduard Moraru
<eduard.moraru(a)xwiki.com
wrote:
> Yes, but in both cases the security issue would be for someone to sniff
> the network.
> In this situation, both methods fail to provide security:
> HTTP Auth:
> - sniffer decodes username:password from the Base64 "Authorization:
> Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==" header and can authenticate whenever
> he pleases.
> Token:
> - sniffer grabs the token and uses it himself to pose as the user.
> + user can call log out and the sniffer's access will be blocked out
> but the damage can already be done.
> - the sniffer can catch the initial log-in which sends the GET
> command with user name and password parameters which are in plain text.
> + If the authentication process involves more than one step (at
> least public/private keys or something stronger), the sniffer would not
> be able to find the user/pass and authenticate whenever he pleases.
>
Any HTTP authentication method is either not generic enough, or not safe
enough. The only solution is to use HTTPS.
- Digest auth requires that we store passwords in plaintext
- Basic auth and URL auth have no protection at all
- Cookie auth requires that the user/pass are sent at least once to the
server
- Client side encryption requires the use of a graphical browser, and
enabled javascript
HTTPS is safe enough to make any of the above methods also safe.
For sure, but it enforces the hacker to be just a
bit more clever...
But you're right!!!
Basic and Digest authentication is a bit light :)
We should do as Amazon S3 and define our own Authentication digest called
AWS ;););)
How do we make clients understand this? Javascript-powered browsers can
emulate this authentication method, but what about lynx and wget?
> If we want good security, we need it done by an application on the
> client side.
>
> Another idea would be to use HTTP:// for anonymous access and HTTPS://
> for authenticated access. Having HTTPS to secure the communication, the
> authentication approach could be a relatively simple one(please correct
> me), even token-based or basic auth. (seems curl handles HTTPS
> http://curl.netmirror.org/docs/manual.html)
>
> We should provide a standard way accessible both to a browser and a
> command-line tool like curl.
>
> WDYT?
+1 for Basic auth over HTTPS, or cookies over HTTPS. Basic auth should
be used by non-interactive clients (command line tools), since in a
browser it is hard to "logout". Cookies should be used for interactive
tools, which can keep an internal state.
Don't know if this is really needed... Currently, without REST, XWiki
doesn't use HTTPS and has the same authentication risk, am I right?
But if we want a strong security layer, HTTPS could be a solution...
No web application has safe authentication without HTTPS.
> Pascal Voitot wrote:
>> On Mon, Dec 22, 2008 at 10:56 AM, Eduard Moraru <
eduard.moraru(a)xwiki.com
>> wrote:
>>
>>
>>> Vincent Massol wrote:
>>>
>>>> On Dec 19, 2008, at 6:27 PM, Fabio Mancinelli wrote:
>>>>
>>>>
>>>>
>>>>> Vincent Massol wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Does this mean I cannot open my browser and call the REST URL
without
>>>>>> specifying a user?
>>>>>>
>>>>>>
>>>>>>
>>>>> It should open up the authentication dialog where you type your
>>>>> username
>>>>> and password (or guest) the first time you request a resource.
>>>>>
>>>>>
>>>> Is that right? It sounds cumbersome and bad for easy automation when
>>>> you want guest access.
>>>>
>>>> Cannot we default to guest when no username/account is specified?
>>>>
>>>>
>>> +1
>>>
>>>
>> User as a resource seems quite logical... this is the same point of
view
> as
>> OpenID...
>>
>>
>>
>>> I think it would be easier and more natural to have the default to
guest
>>> or anonymous user.
>>> When an anonymous user tries to access restricted content -> 403
>>> If he wants to log-in, he just does:
>>> http://user:password@xwikihost.xxx/space/X/page/Y
>>>
>>>
>> for security issues, passing the user/password for each request is
really
>> not very good... I really prefer the
authentication token approach...
>>
>>
>>
>>> We should mimic the basic auth and skip the pop`ul window that
requires
>>> user/pass in the browser.
>>>
>>> That is: Imply that the current user is exactly who he says he is and
do
>>> not assume he could be a user with
rights to a resource until he
>>> explicitly says so.
GET (or POST) /authToken?user=..&pass=.. -> sets a cookie (deleting all
previous values set)
DELETE /authToken -> deletes the cookie
The semantics seem correct IMO. You GET a token, this has the most
correct meaning. But since GET is defined as a simple resource
retrieval, and here we do a lot of processing behind the scenes, a POST
might be better suited (you send some parameters and expect a result
from the server).
DELETE also is meaningful. We don't delete a resource with the same
value as a document or object. The difference is that this resource is
not stored on the server, but on the client. However, it is used on the
server, thus it is a correct computational resource that the server
sees, and which it can also DELETE.
Now, since DELETE is not easy to access from all clients, to delete a
token without using a DELETE request, a client can simply POST or GET
the authToken without specifying user/pass, or using empty values for
them. By the mechanics of cookies, if the server sends an expired cookie
(i.e. an invalid token, or an invalidating token), it will be deleted
from the client.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs