Check Fraud?

 I recently saw a great video https://www.bankinfosecurity.com/how-to-fight-check-fraud-look-beyond-technology-a-21299?rf=2023-02-27_ENEWS_SUB_BIS__Slot1_ART21299&mkt_tok=MDUxLVpYSS0yMzcAAAGKMqJfI2i87GCnqQPTeoRoYMCf1EEHC1AJ4qh708AIYOhT0Q8JFA_5fWC2pELiMEUqWwUPXl7I0l13QQJQKJapHyHw3oF_eWabtx5ta8nuZ8aR4A by Karen Boyer, Sr. VP of M&T Bank on how to fight check fraud, a topic that I recently addressed.   However, the problem that she addressed was not so much "check fraud" as frauds involving checks.  

I see two different problems here, and faster reversibility is not addressing either. First is stolen legitimate checks deposited to fraudulent accounts. This is a classic "know your customer" problem. This problem is aggravated by the banks' desire for new accounts and initial deposits. One can set up an account, deposit a stolen check to it, and transfer or withdraw the funds, all without ever having gotten close to a bank officer or even a human, non-automated, decision.

The second is alteration, amount or payee, of an otherwise legitimate check before deposit to a fraudulent account. "Know your customer," positive pay, and online banking all apply here. (I no longer have to wait for a statement in the mail to recognize fraudulent activity to my account, as I did seventy years ago when I first began to write checks. I can see it daily.)

All that said, these powerful controls no longer appear to be sufficient. The demand deposit system used to have, and relied upon, controls to ensure that banks only did business with people and institutions from whom they knew they could recover. In the name of popular banking and fast availability of funds, many of those controls have been watered down.  

Ms. Boyer cautions banks to "monitor accounts."  I encourage depositors to use online banking to do the same.  While the depositor is not responsible for fraud, someone has to recognize it, the earlier the better.

When I think up a solution, I will get back to you.

Apologia

 As of March 15, 2023 I will no longer be associated with InfraGard.  The FBI has set conditions for continued association that I am not willing to meet.  It behooves me to explain my position.  

The InfraGard web site was recently compromised.  The FBI has been less than forthcoming about the compromise but they have admitted that personal data of their constituents, including e-mail addresses and employment, have been compromised.  They have not offered any compensation or remedies to said constituents.

As a matter of policy I do not do business with management in which I have lost confidence.  Specifically I do not continue to use web sites that have proven unable to protect my personal data.  The FBI has made it a condition of continued InfraGard membership that members must routinely use the compromised web site and that they do so no later than March 15, 2023.  I will not meet that condition.

More over the FBI requires that members provide additional personal data to the web site so that they can reverify one's identity and conduct a criminal background check.  There can be only two reasons for such procedures.  First Colonel Blimp is once more covering his derriere.  Second, he has lost confidence in the database, believes it to be contaminated with fraudulent entries. If they do not trust it, I certainly do not.  

They have announced that they intend to turn personal information over to a third party for authentication.  Not only do they expect me to trust the management that has already demonstrated that they cannot protect my data, they expect me to trust an additional unnamed party, a party that is already in the data collection and exploitation business. I have no interest in improving the quality of their data.  

Most of you are far too young to remember the House UnAmerican Activities Committee and their actions.  Careers were destroyed.  One of the things that we learned from their proceedings was that mere friendship, association, was sufficient to create a presumption of guilt and to place the burden of proof on the accused.  If the InfraGard database disclosed nothing else, it disclosed associations.  (I would not want my e-mail used to query a (just for example, the NSA) database.  None of us is  more than six degrees of separation from a foreigner, terrorist, or criminal.  The three degrees of association that the authorities will admit to might implicate hundreds of thousands.)   

It is clear that we, the FBI and I, no longer enjoy mutual trust.  However they expect me to reestablish my bona fides before they have demonstrated theirs.  It was not I that failed and created this situation.  Given the rather one-sided relationship between the FBI and their InfraGard constituency, it does not surprise me that they want the constituents to bear the cost of remediating their database.

I am late into my ninth decade.  My continued association with InfraGard is limited at best.  Moreover, I enjoy mutual trust with a large number of colleagues, trust that preceded the founding of InfraGard.  I do not expect others to follow my example but I did think it useful for me  to give warning and share my reasoning.  

On Resisting Check Fraud

 When I first began to bank in the 50s, we did not have pre-printed personal checks or account numbers.  The only identification on a personal check was the signature.  The operators who processed the checks, identified the account from the signature.  While this was an error prone process, they were very good at it.

At the time, most checks were written by businesses.  We printed the checks on special paper, in multiple steps and fonts.  The amounts and signature facsimiles were often mechanically pressed into the paper rather than simply printed.  All of this was intended to make checks, particularly business checks for relatively large amounts, difficult to forge.  

Much has changed since then.  The introduction of MICR was the impetus for account numbers and pre-printed personal checks.  This not only reduced errors but also fraud. In the modern world, we use direct deposit for routine payments to those parties whose banks and account numbers are known to us.  While we still think of these as "checks," i.e., payments from demand deposit accounts, most are electronic and are never reduced to paper.  Even individuals may use "online banking," rather than writing checks, to make payments.  While some of these payments may result in the preparation of a paper check, it will not contain a signature for authentication.

Today, paper checks, when used, are often printed on plain paper in one step including the facsimile of the signature.  The bank does not rely on the paper to know that the transaction is authorized but on an out of band confirmation known as "positive pay."  In this system the check is sent to the payee and a message noting the amount and check number is sent to the bank on which it is drawn.  When the check is presented to the bank for collection it must reconcile to the message.  Actually, the paper is never presented to paying bank but is converted to an electronic facsimile by the bank of first deposit.  

 In the seventy years since I wrote my first check, I have only had one transaction turn on the authenticity of the signature.  This was last year on the pre-printed check to pay my real estate tax.  Admittedly, it really was a bad example of my signature.  I was impressed that someone was watching and checking.  

Reconciling signatures must be a very scarce skill these days.  That said, in addition to knowing their customers, banks are responsible for ensuring that transactions, e.g., checks, are properly authorized.  For business accounts, we now use "positive pay;" we do not rely on anything on the paper.  However, for individuals we take the risk, rely on the signature, return any questionable items, i.e., reversibility, or confirm out of band.  All of these involve cost.  Therefore, we use them in combination to minimize cost and risk.

On Over Classification

In the US government, we have a pervasive problem of over classification. https://www.cnn.com/videos/tv/2023/01/27/exp-gps-0129-fareeds-take-us-classification-system.cnn This results from a number of factors.  First, almost any author or officer can Classify data, that is specify, among other things, how much is to be spent to protect the data.  Said another way, he specifies how much others must spend to protect the data but may not incur the cost of protection himself.  

Second, the authority to classify, does not include the authority to change the classification.  Once the data has been labeled, often with a rubber stamp, it is too late to change it.  The implicit assumption is that the decision, once made, is irrevocable.  The decision is reviewable, even by a higher authority, but following a procedure specified for the class.  

 

Third, and as already noted, the classification includes a specification about the procedure that must be followed to lower the classification.  The higher the classification, the more rigorous and expensive the process.  Since the cost of declassifying may be equal to or even greater than the cost of declassifying, declassifying is rare.  

In enterprise things are a little different.  The authority to classify includes the authority to re-classify or declassify.  The classifier's authority comes from his role, it is not arbitrary.  Classification is normally limited in time.  Because sensitivity decreases with age, because we are normally protecting plans and rarely sources, by default classification ends automatically, usually in no more than three years, unless renewed.  

On "Sensitive but unclassified."

 In government "Classified," with a capital C, is a term of art.  It refers to data which the classifier believes requires some level of protection, rather than to the decision about the data.  This results in this strange expression.  To say that something is "sensitive but unclassified" is to classify it the sense of the literal English meaning of the word but not in the meaning of the term of art.  It is an attempt to get around the fact that the government has coopted the word Classified for its own use.

Can anybody tell me?

 Was there a written contingency plan for the failure of the NOTAM application?  Did it really say "shut down the industry?"  Had that plan been shared with the owners and users of the system?  Did they concur in it?  Obviously the flying public did not know.  What other remedies were considered and rejected in arriving at this plan?   Did the plan contain an estimate or an assumption as to the failure rate of the system?  Did the plan enumerate the failure modes.  Was operator error one of the enumerated modes or was it simply accounted for under "other."  Can anybody tell me? 

Can anybody tell me how much the shutdown cost?  How does that cost relate to the cost of the system?

One report suggested that there are roughly 30,000 records in the system but that perhaps as many as 5,000 are no longer current.  Can anybody tell me how many changes are made to this database in a day?  How many changes occurred during the shutdown?  

Another report suggested that the flight plan for an international flight might contain as many as 100 pages of NOTAMs.  Can anyone tell me what the signal to noise ratio is in the database?  

Please tell me that there was a plan and that it worked as intended rather than that this was a massive failure of management and governance.  Can anyone help me here?  These questions seem to deserve, not to say demand, an answer.   

Passkeys

By now you have probably heard about the "death of passwords," or at least alternatives to them.  Passkeys are one such alternative.  Apple, Google, and Microsoft  are rolling them out.  https://tinyurl.com/PasskeySupporters  They are intended for use in remote login to web based applications.  (While apps can use passkey, many are already passwordless.) PayPal, Kayak, Best Buy, eBay, GoDaddy, and Google are among those that are offering Passkeys as a preferred alternative means of user authentication. 

Passkeys resist the security problems with passwords.   They eliminate both the choice of password requirement and the forgotten password problem.  They resist brute force and replay attacks.  Social engineering (e.g., so called "phishing") attacks no longer work.  While the user may still be duped into logging on, the process that that uses does not leak reusable information. 

(However, Passkeys may still leave one vulnerable to session stealing (MitM) attacks. This is a limitation that they shares with most remote authentication methods.  Note that unlike the reuse of passwords, MitM attacks do not include the ability to initiate sessions, only takeover sessions initiated by the legitimate user.  They also require the ability, usually by duping the user, to insert a process between the user and his target application.)

Passkeys are an application of asymmetric key cryptography.  The private key is stored on a user side device and is used to sign a challenge (random value sent from the application side.)   Every time one chooses to sign on to an app or a web application with a passkey, one must authenticate to the device by biometric or PIN.  

Thus Passkeys offer strong authentication.  One must possess the device holding the  private key, something that one has, and the biometric, something that one is, or PIN required to open the device and again at time of use.  The exchange of the challenge and response resists replay.  

Most often, and at least in the short run, apps that implement Passkeys will  leave their use at the option of the user.  It will be offered as an option, either at enrollment time or when signing on.   If one accesses an account from multiple devices, one  may create a passkey for the account on multiple devices.  Apple plans to store keys in the cloud, as does now with passwords, so that one key can be used across multiple Apple devices sharing access to one Apple account.  

When attempting to logon to an account that expects a passkey from a device that does not already have access to a key, one may be offered a QR code to sync to a device that does have access to a (or the) key.  Both the security and the convenience are maintained.  

Indeed security and convenience are what Passkeys are about.  They make it easier to do the right thing than the wrong thing.  Smart enterprise applications will offer them as an option and smart users will choose them.  Some enterprises will mandate them.  They offer us one more opportunity to increase the cost of attack against our networks, systems, applications, and data while improving convenience.  

What are your questions?