[flurp]

Maybe sites like IFTTT are doing it because it's much easier to remember a username/password (assuming you don't use generated passwords) than an API token. A global third-party api token barely provides much more safety than giving up a random password to said third-parties. If you want to prevent one third-party app from continued access you have to go around to all the others and update the token (just like with a password).

Don't get me wrong, I'm in favor of removing user's passwords from third-parties (and blocking those who won't update). I'm just wondering why Pinboard hasn't built a proper OAuth system which would remedy all the above problems. It even mentions OAuth on the api docs: "This token is intended as a stopgap measure to prevent third-party sites from having to store Pinboard credentials while the site moves to full Oauth support."

[idlewords]

The advantage of an API token is that it protects people who re-use passwords. It also allows, in principle, for finer-grained control over what apps can do on the site.

I've really soured on OAuth since writing those docs. It adds a lot of complexity, and from the user's perspective is hard to distinguish from phishing. Initially I figured API tokens would be a stopgap, but have come to believe they're a good solution. I'll make sure to update the API docs accordingly.

[hanley]

The line from the docs that flurp quoted might be exactly why people didn't transition to using the API - it suggested that Pinboard was developing Oauth and no one wants to update their code twice.

[flurp]

Maybe allowing users to have multiple API tokens, that way you have one for IFTTT and another for each service you set up. Gmail does something similar to this btw.

Although I agree with you, there's a good chance that people who reuse passwords do so because they don't want to remember usernames/passwords everywhere and by forcing the user to go get their API-token it's just making things harder for them again. But, maybe this just isn't a problem for Pinboard users.

Too bad about OAuth, it does solve both problems above. :)

[tptacek]

Plus the added win of keeping everyone on their toes about open redirects!

[patio11]

If I can translate Thomas for the benefit of non-security professionals in the room, several researchers (most prominently, Egor Homakov) have repeatedly demonstrated the combination of a) using OAuth in certain configurations and b) having an open redirect on the OAuth consumer site allows an interested attacker to achieve privileges from the OAuth provider site to the limit of a trusted consumer site.

What does that mean? Alice uses Bob's site, which she trusts, and authorizes it to operate her Twitter account for some limited purpose. Bob's site includes an open redirect. Mallory carefully crafts a URL that theoretically exists on Bob's domain but redirects to a server Mallory controls (which displays a cute cat photo and exfiltrates the OAuth token) and then posts it, as one does with cat photos, somewhere where Alice can see it. If Alice sees that cat photo, Mallory can now manipulate Alice's Twitter account to the maximum extent permitted Bob.

[ceejayoz]

> The advantage of an API token is that it protects people who re-use passwords.

As well as the other end of the spectrum, people who don't and change theirs regularly. Having access survive password changes is great (but should robably come with a "Are you doing this because you got hacked?" question on the change form to invalidate API tokens).