A Guide to Implementing Multifactor Authentication

Website Design and Implementation

Overview of Multifactor Authentication

1. General Description

Multifactor Authentication increases website security by asking the user to provide two out of three possible authentication credentials:

1. Something the user knows. (Typically this is the password.)
2. Something the user has. (This can be some sort of device, such as a fob or key or a cell phone. Most commonly a cell phone is the designated device and that is what this paper will address.)
3. Something the user is. (This typically means some sort of biometric such as a finger print or retinal scan. Because these are not commonly employed except in very high security settings and because they are expensive to implement, this factor will not be discussed in the present document.)

Multifactor Authentication is commonly referred to as Two Factor Authentication (TFA or 2FA) although Facebook calls it “Login Approvals” while Google refers to it as “2-Step Verification.”

2. User Experience

When TFA is enabled by a website the username and password are initially verified; this is followed by an additional request by the server for a six-digit access code. This code is generated using a shared secret known to both the server and the user. If the user enters the correct code, authentication succeeds and the user is granted access, otherwise the authentication fails and the user is denied access.

Access codes are valid for short time periods, generally 30 seconds. Thus the user needs a way to determine the current access code value for very small time windows. This is typically accomplished by either sending the user the current code via SMS or by using a mobile application. The mobile application approach is considered the best practice.

3. Developer Experience

Developers faced with the task of either implementing a new website or upgrading an existing website with TFA are faced with some additional considerations. First, they must provide for the routes and processing of the TFA user request and response. They must also expand their current persistent data stores to accommodate additional user information needed by TFA. Determination of the current access code for validation purposes is non-trivial and a source for potential error. Finally, an enrollment process needs to be developed that will involve a number of routes and screens; this enrollment permits the user to activate TFA and exchange the secret key required to generate access codes with the server.

All of these tasks can be mitigated by using standard libraries or code examples that are readily available on the Internet.

4. Security Considerations

Some implementations include a feature similar to Google’s “app passwords.” This is because some desktop and mobile applications cannot respond to requests for an access code; an example might be Microsoft Outlook or Mozilla Thunderbird attempting to access a Gmail account. Special passwords are provided for these kinds of applications to permit them to log on successfully. App passwords are a serious breach of security. No viable solution to this problem has yet been presented.

A serious security flaw involves the password recovery process typically implemented by websites that require a login. Since password recovery takes place completely apart from TFA, any additional security protections provided by TFA are completely bypassed providing hackers with an opportunity for successful penetration.

2. Detailed Considerations

1. Framework

This document makes frequent reference to Google’s implementation of TFA. It is assumed that this reflects the intended implementation by the reader. If some other implementation is envisioned, modifications may be required although the general methodology will remain the same. The general basis for this methodology is RFC 6238 ad RFC 3548 that should be used as a guide for any implementations.

2. Logon Flow

The website logon flow is illustrated by the following diagram. It begins when the user contacts the website login page and concludes when access is granted.

User	Webserver
User sends GET request to webserver ➔
	← Webserver responds with login page
User provides username and password and sends POST request to webserver ➔
	← If the user has been set up to receive six-digit codes via SMS, Webserver sends six-digit code to user via SMS. Otherwise this step is skipped.
	← Webserver sends page requesting six-digit code
If the user has been set up to receive six-digit codes via SMS, user retrieves code from SMS message. Otherwise, user determines correct six-digit code by using the Google Authenticator App (or another equivalent third-party app.)
User provides the six-digit code and sends POST to the webserver. ➔
	← Webserver receives the six-digit code. If the code is validated, user is granted access and webserver returns appropriate web page. If the code fails validation, webserver returns the page requesting the six-digit codes decorated with an appropriate error message.
User proceeds with website access or, in the case of an error, retries the six-digit code ➔

3. Password Algorithm

The most common algorithm, used by Google and other major websites, is called Time-based One-time Password Algorithm (TOTP). TOTP is based on another algorithm called HOTP or HMAC-based One-time Password Algorithm. The only difference between the two is that HOTP uses a counter that is incremented and used in the generation of the key while TOTP replaces the counter by referencing the device timestamp. There is a secret key shared by the server and the client (user) that along with the current timestamp and agreed upon parameters is used to generate the six-digit code used for authentication.

The parameters are generally the following. If the implementation elects to use an application such as Google Authenticator to determine the correct codes, then both the server and the client (user) must implement the same values for authentication to succeed.

• Secret Key
• Epoch (Default is Unix epoch)
• Time Interval that is the length of time a particular code remains valid. When the time interval expires the code becomes invalid and a new code is generated. (Default value is 30 seconds.)
• Cryptographic Hash Method. This is used during code generation. (Default is SHA-1.)
• Token Length (Default is six.)

A special note for Google implementation is that Google does not support parameters that are not defaults. Further, Google expects the secret key to be entered in base-32 encoding.

Since the six-digit code is determined by the agreed-upon parameters and the secret key, anyone can generate a currently correct code by using these parameters and assuming they know the correct time. Thus it becomes important for users who elect to use Google Authenticator or any similar app to ensure their phone has the correct time. Normally, this is handled transparently by the phone operating system. The server will likewise have access to an NTP server and know the correct time.

Regardless of the method used to receive six-digit codes (SMS or Google Authenticator) there is the possibility that a code will expire prior to the user’s ability to enter and return it. There is also a possibility for some time variance. For these reasons, most servers are programmed to accept the current value, the previous two time-period values, and the next two time period values, for a span of five time periods. Greater spans are possible with a corresponding reduction in security.

4. Setup

The setup for a user enrolling in TFA is similar to the Logon Flow above. However, the process begins with the user requesting enrollment by enabling TFA at the website. If the user indicates that he wishes to use the Google Authenticator app, the website presents a QR code that can be read by the app to complete the exchange of the secret key and establish an entry in the Google Authenticator database on the user’s cell phone. If the user has elected to receive codes via SMS the Authenticator steps are bypassed. The website requests that the user enter a current six-digit code in order to test the setup. (An incorrect setup can lock a user out of the system, so it is important to test the setup prior to actual activation.) The correct code is either sent to the user via SMS (if SMS has been elected) or the user launches the Authenticator application to obtain the currently correct access code. If the user returns the correct code the enrollment process is completed and further logons will be performed using TFA. An error in the test validation will result in additional opportunities for the user to correctly enroll.

5. Enforcement

Enforcement of TFA is a function of website programming. If TFA is being implemented by a website where the source code is under the control of your developers, then suitable design will ensure that users must always employ TFA or be denied access.

Google users must enroll themselves in TFA. Google recommends a two to four week period to give all users time to enroll themselves in TFA. By using the administrator setting Turn on enforcement from date, Google will remind users they need to enroll each time they log in and they will receive periodic reminder emails. On the ending date specified, users who are not enrolled will be denied access until they enroll.

It is also possible to place users in groups so that some G Suite users are required to enroll while others may not be. Google presents a comprehensive guide to setting up 2-Step Verification at https://support.google.com/a/answer/175197?hl=en&ref_topic=2759193.

6. Google Exceptions

Desktop and mobile applications that access G Suite resources are not able to enter six-digit codes. A primary example of this might be Outlook attempting to access a Gmail account. To accommodate this circumstance, users can set up special App Passwords to be used in place of their regular passwords on the impacted desktop or mobile application.

In some cases Google may determine that the application is not secure enough and may block login attempts from the Mail app on iPhone or iPad with iOS 6 or below. Also some instances of Microsoft Outlook and Mozilla Thunderbird.

Google presents a more complete discussion of this topic at https://support.google.com/accounts/answer/185833.

Note: Application Specific Passwords (ASP) severely compromise the security of G Suite since they completely bypass TFA. ASP in fact do not provide application limited access (since Google has no idea which desktop or mobile app you may be using for access.) In fact, ASP provide access to nearly all G Suite functionality.

7. Salesforce

Salesforce also implements TFA. The details of the Salesforce implementation are different from Google. Salesforce also has its own Salesforce Authenticator. Details of the Salesforce approach can be found at https://trust.salesforce.com/en/security/2fa/. There are also three Trailheads (Salesforce tutorials) listed that provide training for Administrators in User Authentication, Security Basics and Identity Basics.

8. Two Factor Authentication on User Developed Websites

Any website can implement TFA. From the preceding discussion it can be seen that this is a nontrivial task. The website will have to implement authentication routines that require a username and password at bare minimum. These will have to be stored persistently (e.g. in a database) to be useful. Adding TFA entails the initialization functions of enrollment, the exchange of a secret key, preferably by QR code (if an app like Google Authenticator is planned) or provision for the automatic transmission of the access code by SMS if that is chosen. Also the persistent store will require expansion to accommodate these additional items. Finally, the second level of authentication must be implemented to request and process the six-digit code from the user.

Details of this kind of implementation are beyond the scope of this present discussion, however the following comments can be made:

• Developers should avoid “reinventing the wheel.” The code required to generate six-digit keys is complex and error-prone. If a package is available that is already proven and that supports the site stack in use, then that should be chosen.
• For websites developed using PHP, visit https://phppackages.org and search for TFA, 2TF or Two Factor Authentication. Over fifty entries are available.
• For websites developed using node.JS, visit https://github.com/speakeasyjs/speakeasy and examine the README.md file. The package is a very comprehensive library for implementing two factor authentication as well as generating both HOTP and TOTP passcodes.
• The vendor website https://www.twilio.com/docs/tutorials has examples of code required for C#, Java, Node.js, PHP, Python, Ruby (Rails), and Ruby (Sinatra). Another set of examples covers similar material for using SMS authentication rather than a local app.

9. Security Issues

Several general comments can be made about the efficacy of TFA.

• While TFA improves security it is not perfect. Google “Two Factor Authentication Hacks.” This query recently returned nearly two million results.
• Using SMS as a method to transmit authorization keys to users is definitely not a best practice. Using the Google Authenticator is far safer. Authenticator is available in both Android and iPhone versions.
• No technology, no matter how sophisticated, can withstand clever social engineering attacks. One of the more famous attacks seems to be http://tech.firstpost.com/news-analysis/hackers-using-social-engineering-to-bypass-two-factor-authentication-321121.html. This kind of attack, by the way, can be mitigated by simply not using SMS to transmit authorization keys.
• Password recovery is a gaping hole in TFA. This is because password recovery completely bypasses TFA, allowing hackers to gain control of the user’s account.
• An educated, vigilant user is always an asset when trying to improve security. Spending some time educating users about common threats and how to avoid them can pay handsome dividends.

Write It Using Word, Post It to Blogger: A quick way to get your Word document posted to Blogger

Genesis

I had a Word document that I spent some time preparing and suddenly decided that it would make a good blog post. Problem: How to get the document into Blogger without actually re-keying it or spending lots of time fixing formatting errors after using some form of cut and paste.

Here's how I finally resolved my problem. 

Prepare and Import the Word Document

1. Prepare your Word document in the normal way. I usually save the Word document as a .docx file so it can be easily reedited.
2. I also typically prepare a .pdf of the final document to make sharing the document easier and also to make it difficult to change or plagiarize it.
3. To use the document for a Blogger post, save the document as a .odt file (Open Document Text). This seems to be the only format that Google Docs and Blogger will handle easily.
4. Open Google Docs and import your .odt document into Google Docs. Open it.
5. Use Ctrl-A to select all of your document text. (If you have headers and footers, it will not include them.)
6. Use Ctrl-C to copy the selected text.
7. Switch to Blogger and create a new, empty blog.
8. Paste the copied text into the empty blog. It will likely be formatted quite well and require no further manipulation.

Caution

If you feel the need to start tweaking various items of your blog, you'll probably end up with a mess. I'm not sure why, but this technique results in HTML that is not easily controlled by the Blogger editor functions.

Go ahead and fiddle with things if you must, but don't say I didn't warn you.

When Your Blog Passes Muster

Publish it!

Salesforce Macros: A Quick Guide to Enablement and Implementation

Salesforce Macros

A Quick Guide to Enablement and Implementation

1. Preamble

I normally blog about Delphi, however this is an exception. I was recently asked to examine Salesforce macros and discovered a world of difficulty in getting my arms around the conceptual framework and obscure documentation. In order to preserve and share that hard-won experience, I decided to prepare this blog. Any errors are mine and please feel free to share corrections and improvements in the comments.

2. Overview

As with any macro, Salesforce macros encapsulate a series of operations so that when the macro is invoked, the operations specified take place more or less automatically, thus resulting in fewer errors and greater efficiency. Salesforce is notorious for some of the worst documentation on the planet; it is generally 100% accurate and in many cases, nearly 100% useless for learning and solving problems. Macros are no exception, and the Salesforce documentation may actually be 110% useless. This guide will attempt to anticipate those deficiencies and offer the reader a quick way to navigate the false starts and poorly documented settings needed to actually get Salesforce macros to work.

This guide was developed used a Salesforce Developer Sandbox in December, 2016. The Sandbox was created sometime in November, 2016. Salesforce is a moving target, constantly rearranging, redefining and often making seemingly arbitrary changes to nomenclature and the interface. If you’re reading this a year or so after I post it, don’t be afraid to “reinterpret” my approaches and explanations to fit the current Salesforce paradigms, interfaces and idiosyncrasies.

3. Development Technique

Your workflow when developing macros is likely to alternate frequently between a Setup page and your running console app. Don’t hesitate to switch back and forth a lot. Work on something in the Setup and then immediately try it in your app. To minimize the keystrokes it takes to switch back and forth, note the following:

• If you are displaying a console, click the gear in the upper right corner of the window to switch immediately to the Setup display.
• From a non-console view, click the Setup item next to your name.
• Use the Quick Find / Search box at the top of the Setup menu tree. It makes finding some setup items much faster than trying to open the reveal triangles to navigate.
• When you are displaying a non-console page, a quick navigation is provided at the top of the page, on the left side of the window. This will typically say something like “Back to xyz-app.” You’re one click away from your app using this navigation aid.

4. Prerequisites

It is assumed that the reader knows how to find the Setup button and further that the reader has full administrative authority. You may want to work in a sandbox or developer edition but for even a beginning administrator, you probably won’t be able to do much harm to your organization if you are the least bit careful. Hence you can dive right in on your organization’s production system with some degree of confidence. Even if your macros are a dismal failure, you won’t preclude the organization’s functioning.

• Macros are only available in: Professional, Enterprise, Performance, Unlimited, and Developer editions.

Click Setup➔Administer to display the edition at the top of the page. Click Setup➔Company Profile➔Company Information to display lots of useful stuff about your organization. Of particular interest are the licenses assigned to the particular instance of Salesforce you are using.

• Macros are supported only on the Accounts, Cases, Contacts, and Leads objects. (Salesforce objects are nothing more than a relational entity to use standard E/R jargon.)
• Macros are only available on console applications. The documentation says only on “Service Console” but that is misleading. At one time, there may have been a Service Console, but now you can designate any app to be a console app. This simply means that the user will have access to multiple records in tabs rather than the nearly unusable standard presentation Salesforce uses.
• Feed Tracking must be enabled for objects (remember, only four are supported—see above) you intend to target a macro to.

Go to Setup➔Feed Tracking. Click on the object needed (remember, only four are supported for macros) and then click the Enable Feed Tracking check box at the top of the display. Remember to click Save to save the setting.

• Use a feed-based page layout for objects that are targets for your macros. (Remember, only four objects are supported for macros.) This one is tougher. You must either use a feed-based layout or if none exists, create one.

Click Setup➔Customize➔the desired object, i.e. CASES➔Page Layouts. This will display all page layouts for that object. At the far right is a check-box that says "Feed-based Layout." You cannot change this setting, it is read-only. If you need to create a feed-based layout, click the New button. You will be given a chance to clone an existing layout under a new name. Be sure to check the “Feed-Based Layout” check box for your new layout! Cloning is probably the easiest way to get a feed-based layout but if you’re really ambitious, you can create your own from scratch.

After you clone or create your page layout, press the Save button to save it. You will be redirected back to the list of Page Layouts for the object you’re working on.

Click Page Layout Assignment. Click Edit Assignment. Make sure your new page is assigned to the user profiles for users who will be using macros. At the very least, if you have an Administrator profile, make sure you assign the Page Layout to System Administrator.

• Now create your console application. You must do this because macros are only available on console applications, so you must either create a new console application or modify an existing one to use macros.

Go to Setup➔Apps. You can either edit an existing console app or create a new one. You cannot change a non-console app to a console app or vice versa. If you create a new app be sure to check the “Console” radio button on the first step. After the Label, Name and Description on the second step, the app logo on the third step, you arrive at the fourth step, selecting the tabs to appear. Choose the tabs you want your app to display. Remember that only Accounts, Cases, Contacts and Leads support macros so you’ll want to include at least one of those. Move on to step 5 and organize your app’s tabs. Remember that this screen controls the way records are displayed when selected outside of primary tabs or subtabs. Move to step six and choose the profiles for which your app will be visible. If you’re the Administrator, don’t forget to check “System Administrator.” Click Finish and your app is created, but it still won’t display macros. You’ll be on the App list screen. Click the Edit action for your new app. You can now make lots of changes to your console app, but the important ones are Choose List Placement: Pinned to Left is popular with about a 30% width. But choose whatever arrangement you think is best. Choose Console Components is critical. Move “Macro Browser” to the Selected Items list box to enable the Macro Browser for the app. Be sure to click Save to save all of your changes.

5. Writing Macros

This is the exciting part where you actually get to write and run Salesforce Macros.

• Now run your app. The Macros widget should appear in the extreme lower right corner of the browser window. If it doesn’t you probably have forgotten to add the Macro Browser to the app. Go back and fix that. From the list dropdown (on the left if you followed the previous app configuration suggestion) choose Cases. Then click on a Case from the list. (This assumes you have some.)  The primary and subtabs (on the right if you followed the previous app configuration suggestion) will populate with the appropriate records for the selected Case. Click on a subtab to display that record. To change views between Detail and Feed, use the icons on the right near the top of the record’s display. Now you can write a macro.

Click on the Macro Browser widget in the far lower right corner of the Salesforce browser window. The widget opens. Click on + Create Macro at the very bottom left of the widget. A new primary tab opens to edit your new macro. Fill in the name and description, then click + Add Instruction. The currently available instruction selector appears. The very first thing you’ll want to do is select the appropriate record tab. If your macro updates a Case, you’ll want to choose Select Active Case Tab, etc. Click Done to move to the next instruction. Next, choose the action you’d like to perform, for example, Update Case Action. Click Done once more. Continue in the manner until you have entered all of your instructions.

To run your macro first select the tab or subtab of a record type the macro targets. I.e, if your macro targets a Case record, select a Case record tab. Now click the Macros widget and then click on the name of the macro you’d like to run. Finally, click the run triangle that appears in the macro text box. You’ll get either a success message or error messages that will help you debug your macro.

6. More Prerequisites

Unfortunately, you may finally get around to writing a macro only to discover that you still lack some of the required resources. The two common deficiencies are Publisher Resources and Email. An explanation of these items follows.

• Next come publisher actions. These are even more obtuse and the source of much confusion. The documentation says that publisher actions that you want to use in macros must be available on the page layout, a pretty ambiguous statement. If you are attempting to write a macro and a needed publisher action is not available in the macro editor instruction dropdown, you should check the page layout. When you are writing or editing a macro, available actions are displayed in the instruction editor dropdown list, so there is no ambiguity about an action; you either have it available or you don’t.

Go back and click Edit for the page-layout you’re using for your object. Click Quick Actions in the source pallet. This will provide a list of quick actions available to include in the section of the layout entitled “Quick Actions in the Salesforce Classic Publisher.” You may be able to simply drag the desired quick action down to the Quick Actions section and that will add the action to the macro’s dropdown list. An example of this is the “Log a Call” quick action. However, there are two instances of this quick action in the source pallet. If you hover each, you’ll discover that only one has the attribute “Create Feed Item: Yes.” This is the one to choose. The other will not appear in the macro editor.

If there are no Quick Actions available to solve your problem, you need to define your own action. After you define a new Quick Action, it will appear in the Page Layout pallet and you can drag it to the Quick Actions section of the layout. See the next bullet point for a discussion on creating quick action items.

Send an Email can be especially gnarly. This is handled in the second bullet point following. Be sure to read it if you intend to use macros to send email.

If you edit your page layout, but sure to click Save before leaving the page.

• Define your own Quick Actions, if you need them. Then go back and include the new Quick Action in your Page Layout. Notice the almost labyrinthian path we are now following:
1. Switch to the Button, Links and Actions items for the object you are working on;
2. Define a quick action for the object;
3. Switch to edit the page layout you are using for the object and its macros;
4. Drag the new quick action object from the quick action pallet to the Quick Actions in the Salesforce Classic Publisher section of the layout and be sure to save the layout;
5. Switch to the console view that will contain the desired macro;
6. Edit or create the macro. The desired action should now appear in the macro instruction dropdown list.

Go to Setup➔Customize➔the desired object, i.e. CASES➔Buttons, Links and Actions. Click New Action. For this example, choose Update a Record as the Action Type. Choose Change Status for the Standard Label Type. Enter Case_Status_Close for the Name. (Note the use of the snake-case underscore. This is an API name.) Enter “Close the target Case.” In the Description. Finally, enter “Case successfully modified.” In the Success Message. Finally click Save and again on the layout for the Quick Action that appears.

You will now be presented with the Action Detail page. At the top you will see the information entered when you created the Action. The next section is Predefined Field Values. Click New. On the next screen in the Field Name dropdown, choose Status. This will display a second dropdown with allowable specific values. Chose “Closed.” Click Save.

You have now created an Action that Close a case. Remember, that closing a case involves simply changing its status to “Closed,” which is what this Action does.

Go to the Page Layout you are using for the object. Click Quick Actions in the Pallet. Drag the Change Status item from the pallet to the Quick Actions section of the layout. If you have more than one Change Status item, hover over the items and choose the item that displays “Name: Case.Case_Status_Close.” This matches the name you gave the Action Item when you defined it. Click Save.

Now switch to your console app and click Macros and create a new macro. Your new action will appear in the instruction dropdown list (after first selecting the target record.) Create a macro that has the following: 1) Select Active Case Tab; 2) Select Change Status Action (this matches the name of the action); 3) Submit Action. Name and save the macro.

Test your macro on an appropriate record. This macro will change the status of a Case to Closed. (Note that this is a trivial example, as there is a Close button on the Case listing in the console. However, in complex macros, you may want to update several fields in the Case record. This can be accomplished by adding additional predefined field values in the Action item. You might also want to send email to the contact for the Case. You can include more than one action in a macro.

• We arrive, finally, at sending email. This involves even more mystifying settings, especially if you’re working in a fresh Sandbox. Here’s how to make Email (actually “Select Email Action”) appear in the macro instruction dropdown list.

Go to Setup➔Email Administration➔Deliverability and make sure that “Access level” is set to “All email.” In a fresh sandbox, this may not be the value. Click Save.

Go to Setup➔Customize➔Cases➔Email to Case and make sure that “Enable Email-to-Case is checked. Click Save.

Go to Setup➔Customize➔Cases➔Page Layouts. Check to be sure Send Email appears in the Quick Actions section of the page layout you are using. If it is not, drag it in from the Quick Actions section of the pallet.

The item “Select Email Action” should now appear in your macro instruction dropdown. After you include the Email Quick Action item the next level of instructions will permit you to modify one or more message attributes, such as template, addressees, subject and so forth. Finish up with Submit Action to send your email.

You may now include other quick actions in your macro, such as closing the case. Macro design can be as simple or complex as you choose and limited only by your needs, resources and imagination.

7. Conclusion

Using Salesforce macros is unfortunately excessively complex and frustrating. I recommend using an iterative approach, first establishing all of the known prerequisites and then, when you have a console app running, trying to actually write a macro. When you discover a deficiency, back up and resolve the deficiency by adjusting the Page Layout, creating an Action Item, Enabling Email or some combination of all three. Try your macro again and repeat the process until you have all deficiencies resolved and your macro functions as desired.

I have obviously left out some significant parts of the administrative burden associated with macros. For example, I haven’t dwelled at all on user permissions, but take note that there are three:

• Create Macros
• Run Macros
• Run Irreversible Macros

I leave these and other details to you, assuming you are a competent administrator and capable of addressing these issues.