[josm-dev] shocking - unsecure password sending!

[Stefan Aschenbach]

>
> 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.

Seems discarded as of CPU usage and pointlessness of encrypting map  
data.

> 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.

I was familiar with this process, at least to that detail. But thanks  
for the nice recap nevertheless.

I just would like to point out, that:

- signing and checking a signature is essentally encrypting and  
decrypting (CPU?), but with less data
- even OAuth relies on certificates for authentication of peers  
(once, in the request process), but it's optional
- it's protecting data which doesn't need to be protected (map data)

Also a last question remains, at least for me: If the Access Token is  
valid for a long time, and also the Token secret doesn't change and
only the Token is signed and not the data, what prevents replay  
attacks with changed data?

Regards,

Stefan

PS: Yes I admit, doing a selective HTTPS with unencrypted data and a  
new form of token is more like a non-standard OAuth
than a true HTTPS. So it's probably better to fiddle with OAuth,  
especially if it's partly implemented already.