Showing posts with label multi-factor authentication. Show all posts
Showing posts with label multi-factor authentication. Show all posts

Wednesday, January 13, 2021

What I tell my family about protecting their identity.

 Recently a family member asked me how to respond to a solicitation for "identity protection."  The ad appealed to fear and some of the benefits were ambiguous. 


Every time we open an account or do business, we expose ourselves to fraud.  About three percent of us will be the victims of transaction (e.g., payment card) fraud but almost one percent of us will be victims of fraud so serious as to cause serious financial loss or crippling  damage to our reputations.  Therefore, I offer the following advice in the order of its importance.  

  • Use strong (e.g., multi-factor) authentication wherever it is offered.  (Prefer Passkeys for a good balance of security and convenience.)
  • Avoid doing business with those who do not offer it.
  • Prefer purpose-built applications for financial activity.  Avoid the use of browsers.
  • Prefer mobile computers to personal computers for financial activity.
  • Review all account balances and activity on a timely basis (for large and active accounts, "review" equates to online and "timely" may equate to daily.)
  • Sign up for "paperless" options.  (For good security these should be the default option but for reasons of "backwards compatibility," one must usually opt in.)
  • Allow notifications.  (Again, this should be the default.)*
  • Freeze your identity on all three credit bureaus.  (Locking and unlocking is now easy and free but all three bureaus will take every opportunity to try and sell you "identity protection" for a relatively high annual fee.  All three have had major compromises of personal data and are not reliable.)
  • Use complimentary credit monitoring from AAA, American Express, or, as offered, by your bank or credit union.
  • Most card issuers now permit you to "lock" your cards, using a mobile app.  Balance this with the convenience of using the card but be sure to lock the card if it is misplaced, lost, or stolen.  
  • When buying online, prefer to pay with such checkout proxies as PayPal, Apple Pay, or Click to Pay.  Avoid using debit or credit cards.  However, prefer credit cards to debit cards.  
  • When paying at the point of sale, prefer "contactless."  This resists the leakage of the Primary Account Number on the magnetic stripe.  Most banks now offer such cards and both Apple and Google Pay offer.
  • Do not use the option permitting the merchant to retain debit or credit card information.  Checkout as a guest; avoid signing up for accounts.  
  • When using debit or credit cards for the convenience of frequent purchases from a merchant (e.g., Amazon) consider the use of a one-time or one merchant token number from Privacy.com.  
  • Consider insurance against financial loss and/or expenses related to identity theft.  Such insurance is not a substitute for any of the measures above, may be redundant of protections that you already enjoy (from homeowners insurance, fiduciaries, e.g., https://www.fidelity.com/security/customer-protection-guarantee ), may be expensive, and is best purchased from insurance sources (e.g. as an optional endorsement  to one's homeowners insurance).  https://tinyurl.com/FTCreportidenttiyfraud

* While I have been writing this I have received notices of three legitimate transactions.  This assures me that I will get timely notification of fraudulent ones.  

Thursday, July 11, 2019

Control of Privileged Insiders

On April 23, 2019 the FBI published a Private Industry Notification (20190423-001).  The document was distributed as a pdf only by e-mail.  While marked “TLP-White,” “may be distributed without restriction," I could not find it on the web.

The summary read:

The FBI continues to observe U.S. businesses’ reporting significant losses caused by cyber insider threat actors.  These cases often involve former or disgruntled employees exploiting their enhanced privileges—such as unfettered access to company networks and software, remote login credentials, and administrative permissions— to harm companies. Cyber insider threat actors most often are motivated by revenge, but they also conduct attacks to profit financially from stolen information, gain a competitive edge at a new company, engage in extortion, or commit fraud through unauthorized sales and purchases.

I recommend it to the reader.  (Since I cannot find it on the web, here is a link to a private copy.)

There are two kinds of insider risk, accidental and intentional, and three threat sources, benign, dishonest, and disgruntled employees.  Note that insider threat rate is much lower than the outsider threat but the consequences, and therefore risk, may be much greater.  Outsiders damage the brand while insiders may bring down the business.

Not only is employee error by otherwise well motivated and intended employees perhaps the biggest source of losses ("The dummies have it, hands down, now and forever."  --Robert H. Courtney)  but it contributes to the success of attacks by outsiders. (Think “phishing” and other forms of duping.)  Undetected errors may result in employee temptation and fraud.  The employee makes an error and no one notices.  She repeats and still no one notices.  She finally concludes that she could do it in her own favor and still no one would notice.   We distinguish between dishonest employees, who want to keep their activities secret, and disgruntled employees who want you to know that you have been injured.  

Management supervision is the most effective of all insider controls.  Effective supervision usually requires that the supervisor could do, or at least appreciate, the job being supervised.  This control often breaks down for privileged IT jobs.  The more sensitive or unique the task to be supervised, the more narrow should be the span of control.  While one might be able to supervise a dozen tellers or coders, one might supervise no more than five or six loan officers, system designers, or privileged administrators.  

The limitation of supervision is cost; while it is effective, it is also expensive.  Therefore, other more efficient and complimentary controls are often substituted for all or part supervision.  These might include background checks, training, division of responsibility and privileges (so-called multi-party controls), cross training, job rotation, measurement, mandatory vacations, audit trails and audits, recognition, compensation, and complete and timely separation.  

I had been writing and talking on this subject for a few years before I added “please and thank you” to my list of controls.  While equitable compensation is a powerful control, no amount of it can compensate for inadequate recognition.  Many dishonest and most disgruntled employees feel that their contribution to the enterprise has not been appreciated.  Please and thank you go a long way toward maintaining necessary morale.  

The FBI notification gives special attention to IT personnel and, especially, privileged users such as system administrators.  Management often focuses on lower level employees, like tellers or clerks, doing routine tasks.  Where these engage in fraud they get little and are caught early.  It is professionals, managers, and executives who bring down the business.

It is ironic that these highly privileged actors are often inadequately supervised, under paid, and unaccountable.  We caution against the sharing of user IDs and passwords, but it is privileged IDs and passwords that are most likely to be shared.  Many administrators have so much privilege that they cannot be held accountable, can escalate their privileges, and the privileges, once granted, cannot be effectively withdrawn.  Think about the privileges that Edward Snowden had to have accumulated to gain access to all the information that he exfiltrated.  

One should not grant privileges that one cannot withdraw.  Therefore, privileged users should be required to use hardware token based strong authentication.  One should not grant privileges without accountability for their use.  Therefore, when there is more than one privileged user, i.e., in most large enterprises, Privileged Access Management (PAM) controls should be in place.  These controls will be covered in a later post.



Friday, February 1, 2019

Limitations of Two Factor Authentication

In an opinion piece in the New York Times, Professor Josephine Wolff of Rochester Institute of Technology describes a “phishing” attack in which two factor authentication might not protect you.  The bait asks you to click on it to go to an application that you are authorized to use.  Clicking on the link takes you to a site that mimics the application.  It mimics the prompts for the user ID, the password, and the one-time password, all three of which it uses to logon to the real application in your name.  Unfortunately, to some readers this may read like a general limitation of two factor authentication rather than a special case.  Some users might conclude that two factor authentication is not worth the inconvenience.  

Consider some of the conditions for the success of this attack.  First the bait must be for an application to which you actually have an account.  Second, the bait must be sufficiently well crafted to convince you that you want to respond.  Third, you must respond, not by going to the application the way you usually do but by clicking on the bait.  Of course, this is very bad practice.  

While if this man-in-the-middle attack is sufficiently well designed as to fool you, it has only stolen a session that you started. Unlike simple passwords it cannot be use to initiate a session on its own.  It has not exposed you to fraudulent reuse of your credentials.  It cannot be used to compromise other systems “laterally” within the enterprise.  

Well designed applications will not permit the attacker to turn off the two factor authentication without requiring a second one time password and will confirm any such change out of band.    

This is not the only possible successful attack against two factor, depending upon the implementation.  Consider Google’s implementation.   It offers the user five different choices of how to get the one-time password (OTP), in an SMS text message, in an e-mail message, in spoken language over the phone, from a software generator, or from a hardware token (Google Titan).  All of these must ensure that the OTP come from and get to the right place.

For example, SMS text and voice over the phone rely upon legitimate user’s control of the phone number.  E-mail requires that the OTP be sent to the legitimate user’s address.  Attackers have been successful in duping the carrier support personnel into pointing the the number to a new SIM or phone that they control.  They have also been successful in duping the application support personnel to change the number, or e-mail address to which they send the one time password.  Good practice requires that the change be confirmed out of band.  After compromise the user will not get one time passwords, or perhaps even phone calls, that they are expecting.   

Even software and hardware tokens rely upon the right token being associated with the legitimate user.  In order to compensate for lost or broken tokens, most applications provide for enrolling new tokens.  An attacker might succeed in duping support personnel into enrolling their token in place of the one heldby the legitimate user.  

Note that all of these attacks require work and special knowledge.  None of them guarantees success, none of them scales well.  Those that permit fraudulent reuse, also deny the legitimate user access and should be obvious.  

Two factor authentication using one time passwords is a special case of “strong authentication,” defined as multiple forms of evidence at least one of which (e.g., one time passwords) is resistant to replay.  Note that security can be increased by using more forms of evidence.  This at the expense of convenience.  

Strong authentication should be preferred for most applications.  Simple passwords must be used only for trivial applications.  All security mechanisms have limitations that we must understand and compensate for but that does not make them unuseable.  We must not permit the perfect to become the enemy of the good.  

Friday, August 17, 2018

Limitations of One Time Passwords

Recently a man sued AT&T because his one time password was sent to the wrong phone, causing him to lose $24M in “cryptocurrency.”  To punish them, he asked for $200M in punitive damages.  This led to headlines talking about the “dangers” of relying upon SMS to deliver one time passwords.

These are not so much ”dangers” as they are ”limitations.” ”Nothing useful can be said about the security of a mechanism except in the context of a specific application and environment.” All security measures have limitations. Perfect security has infinite cost; we must not let it become the enemy of good security.

While one time passwords, whether sent from the server or generated at the client, are orders of magnitude more secure than reusable passwords, they still have limitations.  They must be properly associated with the user or his account.   Like most security measures, and as in this case, this association is vulnerable to social engineering attacks.

Some of you may have tried to register a new SIM or move an existing phone number from one device to another.  You can testify that it can be a pain; the carriers have stringent security procedures in place to resist fraudulent changes to your account. However, they have hundreds of agents handling provisioning requests and they are trained to be customer friendly. In pursuit of this, they can be expected to make mistakes. That is a limitation of using your phone and its number as part of your authentication scheme.

Note that if you do not get a one time password, or a phone call, or even a paper bank statement that you are expecting, you may have been compromised. Note also that the carriers are not the only targets of these ”social engineering” attacks. The attackers may try to get your account holder to change the phone number, e-mail or street address in your account record from your number to theirs. That is why responsible account holders will send you an out-of-band confirmation of all changes to your account record to both the old and the new address. Even hard tokens may be vulnerable to these attacks because the account holder must be able to respond to lost tokens by allowing you to register a new token. Again, not so much a danger as a limitation. Keep in mind that just twenty years ago, the scam was to request a postal address change.

While I use SMS for Google, Dropbox, PayPal, Amazon, my credit union, and my banks, I use a token for my brokerage and retrirement accounts. Note all of these offer me choice of SMS or tokens. ”Horses for courses.” Rest assured that I would not use SMS for $24M. In fact, I would never put all that in one account.

Even as users, we need to know the limitations of the things that we depend upon for security.  As security professionals, responsible for choosing, applying, and operating these mechanisms, it is mandatory.

Thursday, March 8, 2018

The Use of SMS for Strong Authentication

NIST and others have discouraged the use of SMS for strong authentication.  This is another case of the perfect as the enemy of the good. 

First, strong authentication using a one time password sent via SMS is dramatically more secure than a replayable password. Second, if you get a one-time password when you ask for it, you are safe.

The problem is not so much with SMS but with the (cell) phone number. There is a risk that an attacker can either change the number in your account, to which the one time password will be sent, to a number other than yours, or get the phone company to associate, re-assign, your number with their phone. In either case, you will not get the one time password when you ask for it. In the latter case, you will not even get phone calls. Whenever the cell phone number in your profile is changed, you will get an e-mail message asking you if you really did it.

Carriers have controls in place to resist fraudulent reassignment of numbers to new phones.  However, the large number of agents and their desire to be accommodating, makes them vulnerable to ”social engineering” attacks. 

The difference in risk between a one-time password sent to your phone and one generated on board is small, particularly when compared to the difference in risk between either and a reuseable password.

In certain circumstances, the difference in convenience may be great. I have ten different accounts associated with my cell phone number. If I get a new phone, all my accounts continue to work as they did on the old phone. The number has moved to the new phone. If I used an on-board password generator, not portable to the new phone, I would have to register the new password generator with each of the ten accounts. I have to do that by calling support, authenticating myself, and registering the new generator. Until I have done that, I cannot logon to or use the account.

If you think about it, the real risk is in provisioning of the phone number or the registering of the on board generator (e.g., VIP Access, Google Authenticator, RSA SecurID Software Token).