A few months ago, Salesforce implemented a security feature that while I agree with on principle (and therefore don’t want to take steps to completely disable), it has been driving me crazy.
In short, when you log in to your Salesforce account, the system looks at your IP and recognizes whether or not you have logged in from that IP before or if your IP is already cleared by the system administrator. If it’s a new IP in your account, you have to click an activation link which sends an email to the account you’re trying to log in under. You click the link in the email which activates the IP and you’re good to log in and get work done.
Businesses that have static IPs (or even dynamic IPs that don’t move around that much) aren’t bothered by this. However, someone like me whose office usually consists of a laptop and any power outlet she can find is finding this security feature challenging to say the least.
Even when I’m home, Verizon is changing my IP at least 2-3x a day. It’s annoying to have to dance over to my email so often to authorize yet another IP address. Thankfully, that email arrives in fractions of a second after I click the link so I’m not delayed that much. Otherwise, I would just authorize entire IP blocks that Verizon DSL uses, which I’m not sure I want to do.
However, yesterday I found out what happens when I can’t get to my email: Not fun.
I did a little presentation/demo at the New York City Nonprofit Salesforce Usergroup. The meeting was hosted at Wells Fargo Insurance services in midtown Manhattan. When I attempted to log in to Salesforce, of course I got the “Activation Needed” box. Okay, so I fire up a browser window to check my email. Now that we are fully migrated to Google Apps, I no longer use a separate mail client. A window pops up that mail.google.com is blocked by the corporate firewall. The little note on the message says that all external email applications are blocked. Uh oh.
So what did we do so I could use my Salesforce account during the demo?
Another attendee (thanks again, Marc!) found that he could use my computer to log in to his webmail (SquirrelMail). I guess they let that one get away, likely since it was webmail.domain.com and not a known mail application. So I clicked the link to activate, retrieved the message on my Blackberry, forwarded to his email where he could open the message in a window on my computer and activate. Phew!
I completely agree with the extra security measure of making sure that the account holder is the person logging in to Salesforce. I agree with the notion that if there’s a doubt, notify the user via the email address on their account. But I wish Salesforce wouldn’t base this decision solely on IP/physical location. Guess what? That’s the point of Salesforce. We can log in from anywhere and move around.There has to be a better way of verifying that I’m me.
What about a software token (Mac compatible, of course) that one could install on a computer in a secure way that Salesforce could check for if it doesn’t recognize the IP address? That way, every time my computer is used to log on, Salesforce knows it’s me. I don’t know.
Judi Sohn 
8 responses to “Salesforce IP checking is a royal PITA”
Hey Judi,
That sounds like a presentation nightmare scenario. I’m glad that you solved the problem ingeniously, but I can see how that might have been a *little* awkward.
The IP check (which I’m sure you know is optional and is settable on a per profile basis) is a very useful security device. But it’s definitely better suited to some working styles than others. If you have an idea on how we can make this better for your working requirements, I’d encourage you to post it to the IdeaExchange (http://ideas.salesforce.com), where it can be seen and voted on by other customers. If you do post an idea, please update this post to link to it so your readers can vote on it too.
Thanks, Kingsley. As I said, I don’t want to disable it. I like that Salesforce has that additional layer security and I want it to make sure I’m me. I just want it to do it in another way than checking my IP address.
Judi. I think it would be ideal for SalesForce to offer a SecurID key or some other hardware/multi-layer password system instead of brute-force IP checking, which is more or less useless from a security standpoint. What you’ve stumbled on is only a minor roadblock for a knowledgeable hacker to get around, as you’ve seen by “hacking” your own account.
Way late on this, but there’s also a security token inside of salesforce (I believe it’s listed under Security Controls in Setup). If you add this token to the end of your password then it doesn’t matter which IP address you are trying to access it from, you should be able to gain access.
I can’t stand this thing – like the majority of features that Salesforce has implemented, it’s completely half-assed. Internally, we call it the ‘Aggravation Link’ 😀
Is there anything new on this? Having this issue and it’s driving us crazy.
HI i am sumanta.I work in Softtrends Software Pvt, Ltd. in Bangalore(India). We have developed one mobileCRM client to access data from Saleforce CRM server. But the problem we are facing is alwyas during login we have supply the security token when calling the Salesforce WebService. So can anyone help me out to give some idea of how to implement the same ip validation based login in device like salesforce does in web browser. I mean what is the technicall proces or what are the WebServcies availbale to do this in device client?
When users log in to Salesforce, either via the user interface, the API, or a desktop client such as Connect for Outlook, Salesforce for Outlook, Connect Offline, Connect for Office, Connect for Lotus Notes, or the Data Loader, Salesforce confirms that the login is authorized as follows:
(1) Salesforce checks whether the user’s profile has login hour restrictions. If login hour restrictions are specified for the user’s profile, any login outside the specified hours is denied.
(2) Salesforce then checks whether the user’s profile has IP address restrictions. If IP address restrictions are defined for the user’s profile, any login from an undesignated IP address is denied, and any login from a specified IP address is allowed.
(3) If profile-based IP address restrictions are not set, Salesforce checks whether the user is logging in from an IP address they have not used to access Salesforce before:
(3A) If the user’s login is from a browser that includes a Salesforce cookie, the login is allowed. The browser will have the Salesforce cookie if the user has previously used that browser to log in to Salesforce, and has not cleared the browser cookies.
3A SOLVES THE PROBLEM YOU ARE DESCRIBING
(3B) If the user’s login is from an IP address in your organization’s trusted IP address list, the login is allowed.
(3C) If the user’s login is from neither a trusted IP address nor a browser with a Salesforce cookie, the login is blocked.
Whenever a login is blocked or returns an API login fault, Salesforce must verify the user’s identity: For access via the user interface, the user is prompted to click a Send Activation Link button to send an activation email to the address specified on the user’s Salesforce record. The email instructs the user to copy and paste an activation link into their browser to activate their computer for logging in to Salesforce. The activation link included in the email is valid for up to 24 hours from the time the user clicked the Send Activation Link button. After 24 hours, the activation link expires, and users must repeat the activation process to log in.