[josm-dev] shocking - unsecure password sending!

[Lars Francke]

>> The request token can be saved in the JOSM-profile (agreed, that this avoids having userid/password
>> unencrypted in the profile) and it will be used to get another access token the next time JOSM
>> is started, but using OAuth doesn't protect us from sending uid/password in cleartext over the net.
>
> The difference is that since the token is valid forever, the unencrypted
> transfer of username and password will take place only once, and not
> with every request. (Requests would still contain the unencrypted token
> which would allow others to make edits in your name though.)

I'd like to mention two things:
1) The client recieves a token seceret and an access token. Every
request has to be signed with the secret. So although the token has to
be sent each time third-parties could not use it to make edits without
the secret [1]
2) OSM implements OAuth 1.0 which has known security problems[2].
Until we upgrade to 1.0A it makes no sense to discard one insecure
method in favor of another.

[1] http://oauth.net/core/1.0a#signing_process
[2] http://blog.oauth.net/2009/04/22/acknowledgement-of-the-oauth-security-issue/

> But as I said before, I don't currently consider OSM accounts to be a
> valuable asset. I have many of them and should one be compromised then
> I'll create another. Any account created anonymously from the web page
> has the same privileges as my account so why should a hacker bother to
> hijack my account when he can just sign up for one?

With the implementation of OAuth this very much becomes a valuable
asset in my opinion. Granted, until now no one really uses OAuth but
it might be used for various purposes later on. I implemented it in
OSMdoc as a "Login with OSM"-feature. Other sites (perhaps pay-sites
later) might implement the same. And then the security very much
becomes a concern.

> This would however change if OSM accounts had special privileges. If my
> account could to things that yours cannot then that might make a difference.

As I said above. With the introduction of OAuth OSM accounts this is
_kind of_ the case.

Cheers,
Lars