Comments on: Upcoming Security Changes - overview of impact

By: Scott Hemmeter

Scott Hemmeter — Mon, 10 Dec 2007 22:55:15 +0000

This post is not totally accurate. Refer to the Salesforce Help on exactly what happens with this change.

By: Pat

Pat — Tue, 20 Nov 2007 13:22:17 +0000

I believe the tokens are appended to the password - Not replacing the password for the API based login.

Also, the criteria for the validation process appears to be:
1. Is the org using IP Login Restrictions on Profiles?
2. Is the User logging in from an IP on the Trusted Network list?
3. Have we seen this user from this IP address before?
4. Does the User have a cookie placed from Salesforce in this browser?

Yes on any of these = Pass on activation process
No on all of these = Initiates the activation process for user during website login

By: Less

Less — Sun, 18 Nov 2007 18:55:35 +0000

I think that I agree about 50% of the way here… Let me qualify that thrown gauntlet:

SFDC didn’t get “hacked”, meaning remote exploit or etc. They had a social engineering issue. Basically, It looks like they got their ass handed back to ‘em due to media problem and had to push slap on some “InfoSec” right away…

As far as API solutions go, instead of collecting passwords from my clients, I now collect, password-in-the-form-of-a-token that are generated by god knows what RNG algorithm. In essence, they’ve replaced one password with another… I bet phishing for users tokens will be even easier than getting password: “It isn’t a password, so I’ll give ‘em my token…” mentality.

The login procedure stuff might be ok… But the API is such a richer target anyway.

What would be really excellent is if SFDC could finally act as a trusted 3rd party to negotiate access to certain data types for 3rd party vendors without having to have those 3rd party vendors collect logins and password/token info. That, right there, is limiting some of thier growth potential…