Upcoming Security Changes – overview of impact

Salesforce.com is making security changes on Monday Nov. 26, 2007. (Note that the rollout was pushed back a week from their original communications. It is now Monday Nov. 26, 2007)

There were a couple of webinars today about the changes. The customer-focused webinar will be available at http://www.salesforce.com/security soon. The partner-focused one will be available in the Partner Portal.

Below is my understanding of what was said and a high-level overview of the main impacts. Please add clarifications in the comments.

API Logins
  • If you connect via a Session ID passed from a web link/tab, none of these restrictions apply as the user is explicitly providing you with login access to his/her active session.
  • To login with a username and password, the IP address you are logging in from needs to be white-listed.
  • Salesforce will pre-populate the org’s whitelist with IPs used in the past 4 months.
  • Each end-user can generate an API token to replace their password for API logins.
  • API logins using the API token do not require their IP to be whitelisted.
  • API tokens do not expire. Only 1 is active at a time. It can be replaced by the user generating a new one. This automatically invalidates the old one.
  • API tokens cannot be used to login at https://www.salesforce.com/login.jsp.
  • Going forward, the best practice would be for end users to provide their API token to any app/service they use other than the main Salesforce.com login page.
Logging in at https://www.salesforce.com/login.jsp
  • Username and password will still be the way to access Salesforce.com from the main login page
  • A new feature will be added requiring you to confirm that your computer is valid to login using that username.
    • The login page will check if you’ve logged in from that computer before (by looking for a browser cookie)
    • If not, the email address on the user record will be sent an email to confirm that you are, in fact, the one trying to login now.
    • You will click a link in that email “activating” your computer for login with that username
    • Unless you delete the cookie or clear your broswer’s cache, you should be good to go for a while without repeating these steps.
  • There are no new IP restrictions affecting logins at the main login page. The profile-based IP restrictions that have been around for a long time are still the way to go there.

If you are a consultant, you may fall victim of the new security measure when you try to login as your client (maybe they couldn’t afford another temporary username just for you). On the call, I was told that you can request a temporary one via the Partner Portal or ask your customer to forward you the email to confirm your PC is okay.

My thoughts

I think it is great to see Salesforce taking a step to tighten up the API, especially. I like to think that my old API Authentication List post had something to do with it, but who knows.

The biggest impact to me will be using client’s logins to get into the system from my PC, but I’ll just have to workaround that one. Security and convenience are generally a trade off and overall I’d rather use/subscribe to a service that is tightened down with my business data. If anyone can handle the inconveniences of logging in, it’s developers since we are used to doing hacks/workarounds in the first place.

3 Comments

  1. Less Said,

    November 18, 2007 @ 11:55 am

    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…

  2. Pat Said,

    November 20, 2007 @ 6:22 am

    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

  3. Scott Hemmeter Said,

    December 10, 2007 @ 3:55 pm

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

RSS feed for comments on this post