gistfile1.txt

The token system is ridiculous because it makes security weaker, by offering a
larger surface area for attack.

If I had to guess, Salesforce is concerned that users are embedding their
passwords into scripts which could be stolen and used outside the company for
other purposes. Why are users putting their passwords in scripts? I imagine
it's because of the web-centric oauth flow coupled with short oauth token
expiration intervals but THATS a different story.

So *within* an authorized set of IP addresses, the regular password works.
Outside that IP range, you concatenate a decent-sized random string (the token)
to the password. If leaked, this concatenated string is *worse* than either the
password *or* the token separately, because it reveals *bolth*. Because the web
interface does *not* enforce the token restriction, an attacker can use your
password to log into the web interface and, say, *extend the authorized IP
range to include the attacker's machine*. Or just steal/destroy your data
through the web interface directly.

Moreover, the token *by itself* has sufficient entropy to authenticate a user;
the inclusion of the password doesn't add any real security. Salesforce still
has to store bolth the password and token, only now they need to do string
munging (and depending on their hashing strategy, could leak information about
either the password or token internally) to authenticate requests. So they
could just use the token in place of the password+token.

tl;dr I can't think of a good reason to do things this way, and there are
several reasons not to. :-/