[josm-dev] shocking - unsecure password sending!

[Karl Guggisberg]

> 1) Use the authentication mechanism that JOSM is using now: Sending the
username and password with each request 
> that requires it. This would mean that each and every request would have
to be sent using HTTPS.
> 2) Use OAuth. While that requires a one time redirect to the browser on
first usage it requires HTTPS _only_ when 
> receiveng the Request Token + Token Secret and the Access Token + Token
Secret. Each subsequent request to the API is 
> done by constructing the request, adding the Access Token and _signing_
[1] the whole thing with the Token Secret. As 
> both sides (JOSM and OSM) know the Token Secret but no one else (due to
them being submitted via SSL) both sides can 
> verify the requests authenticity. It does _not matter_ that the Access
Token is send on each request as it alone provides 
> _not enough information_ to make forged requests.
Good summary. I agree with that. 
*If* OSM provided a HTTPS protected login page, JOSM *should* offer OAuth as
possible authorization mechanism (OSM already has it implemented).
Nevertheless, user experience from JOSM will be less seamless as from a web
application using OAuth, JOSM should therefore still support the traditional
Basic Authentication scheme. 

>From a technical point of view it would be wise to migrate the JOSM OSM API
to the Apache http client, for two reasons:
- it would be helpful in order to add proxy authentication (asked for since
ages in trac)
- it would be helpful for implementing the OAuth part in JOSM (using
signpost, for instance) 

-- Karl 


-----Ursprüngliche Nachricht-----
Von: josm-dev-bounces at openstreetmap.org
[mailto:josm-dev-bounces at openstreetmap.org] Im Auftrag von Lars Francke
Gesendet: Mittwoch, 7. Oktober 2009 15:35
An: josm-dev
Betreff: Re: [josm-dev] shocking - unsecure password sending!

> No, I meant the tokens which would be used if authentication is done 
> with https and data transmission without. Somehow these two parts have 
> to be connected, a token transfered with the authentication would be 
> one solution.
>
> This token could be intercepted and used to send unauthenticated map 
> data, but only as long as the session lasts.

I think you misunderstand me or the process. My previous answer was exactly
about the point you state here.

If HTTPS is ever offered we have two options (as we do now):
1) Use the authentication mechanism that JOSM is using now: Sending the
username and password with each request that requires it. This would mean
that each and every request would have to be sent using HTTPS.
2) Use OAuth. While that requires a one time redirect to the browser on
first usage it requires HTTPS _only_ when receiveng the Request Token +
Token Secret and the Access Token + Token Secret. Each subsequent request to
the API is done by constructing the request, adding the Access Token and
_signing_ [1] the whole thing with the Token Secret. As both sides (JOSM and
OSM) know the Token Secret but no one else (due to them being submitted via
SSL) both sides can verify the requests authenticity. It does _not matter_
that the Access Token is send on each request as it alone provides _not
enough information_ to make forged requests.

OAuth in short with a description which steps would have to be secured by
SSL:
HTTPS: JOSM requests a Request Token from OSM and receives a Unauthorized
Request Token and a Token Secret [2]
HTTP: JOSM redirects the user to a page on OSM that asks the user whether
he'd like to allow JOSM access to OSM in the name of that user. JOSM
provides the Unauthorized Request Token for this redirect.[3]
HTTPS: JOSM asks OSM (again using the Unauthorized Request Token) if the
user has authorized the use. If this is the case OSM sends an Access Token
and a Token Secret [3]
HTTP: Every subsequent request is _signed_ using the Token Secret and that
has always been transported securely and does not ever need to be send again

This is quite technical but it works. I assumed a few things:
- OSM switches to OAuth 1.0a, Matt Amos is aware of this and I believe it
will be done eventually. He's done great work so far. I just don't know
enough about Ruby on Rails
- The Consumer Key and Consumer Secret provide no additional security here
as they'd have to be stored in JOSMs source code

And yes OAuth is implemented for OSM[5]. I don't know the specifics for Java
but the whole OAuth process is generally very easy to implement for a
client. A desktop client like JOSM would require some extra steps (redirect
to external browser, ...) but it shouldn't be to hard. But until HTTPS is
offered it doesn't really make sense to switch/implement it.

Lars

[1] http://oauth.net/core/1.0a#signing_process
[2] http://oauth.net/core/1.0a#auth_step1
[3] http://oauth.net/core/1.0a#auth_step2
[4] http://oauth.net/core/1.0a#auth_step3
[5] http://wiki.openstreetmap.org/wiki/OAuth

_______________________________________________
josm-dev mailing list
josm-dev at openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev