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.  They are an implementation of the Fast Identity Online (FIDO) standard defined by the FIDO Alliance.  

The private key is stored on a user side device, usually in an high security module (HSM) or trusted platform module (TPM)  and is used to sign a challenge (random value sent from the application side.)  The corresponding public key is stored on the application side and is used to verify the signed challenge.  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, something one knows, required to open the device 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.  

Note that Passkeys rely for their security in part on the device on which the private key is stored.  Thus they are often seen as limited to a single device.  However, a number of mechanisms are available to enable their safe use across devices.  These include storing the key in a "password manager" (e.g., Bitwarden) or using the network or the cloud (Apple's implementation.)

Limitations of Biometrics

It is Blackhat/Defcon time so it should not surprise anyone that the media is full of hacks. While the hackers pretend to demonstrate that the security mechanism is useless, most of the attacks are so expensive as to be impractical.  What they really demonstrate is the limitations of the mechanism.  Regular readers of this blog know that all security mechanisms have limitations; understanding those limitations are part of our stock in trade and I write about them often.   

A recent demonstration spoofed Apple's FaceID in only "120 seconds," as though that were the only cost of attack.  They omitted the special knowledge and access.  A recent article in BankInfoSecurityNews raised alarms over the discovery of a database of fingerprint images for sale.  

First, keep in mind that biometrics are really about convenience, not security. That is why they are best used as one factor in multi-factor systems. 

Second, they do not rely upon the secrecy of the reference but upon their resistance, at least in context, to counterfeiting. Your visage is an authenticator for your drivers license. It is public information. While a photograph of you might be able to fool a computer, no other person would be likely to confuse the photo with you.  There is too little information in the photo for it to be mistaken for you.  The more information that the implementation uses, the lower the risk of false positives but the higher that of false negatives and the more power and time required for a check.  

Finally, as this article suggests, just like passwords, biometrics are fundamentally vulnerable to spoofing and replay attacks; implementations must resist them. For example, Apple's FaceID uses tests of "liveness" to distinguish between a real person and a photo of the person or a replay of an earlier submission.  Perhaps they are better used on mobiles, where possesion of the mobile is one factor and where the instant data is compared to the reference locally and does not go across a network where it could be captured for replay.  

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.

The Desktop, our Achilles Heel

During the last three or four years the number and rate of enterpirse wide breaches have increased dramatically.  Successful attacks have relied upon duping users into clicking on bait malicious objects in e-mail messages and web pages.  The malicious objects capture user credentials and then use them to attack peer systems in the enterprise network, spreading the compromise laterally.  These attacks exploit user gullibility, re-usable credentials, the default desktop access control rule of ”read/write,”  and flat enterprise networks.  Therefore, many security practitioners recommend user training, multi-factor user authentication, and structured networks.  Resistance to all three of these measures is high and their effectiveness limited.  Moreover, they do not address the vulnerability of the desktops to have their procedures modified by their data.   We are left with a high level of risk.

E-mail and browsing are the Achilles Heel of the desktop and the desktop is the Achilles Heel of the enterprise.  One of these two applications are involved in a large percentage of all breaches.  Note that while Achilles was vulnerable on only one heel, small attack surface, the enterprise may be vulnerable on many desktops.                                                            

One obvious defense would be to isolate these two applications from the system on which they run and those systems from the other applications and systems of the enterprise.  Neither of those applications should have the capability to make persistent changes to the procedures of the systems on which they run.  

In a world of cheap hardware, one way to do this would be to run these two applications on sacrifical hardware dedicated to these two applications.  In a world of reliable process-to-process isolation, another would be to use that isolation to protect the system on which the applications run from any changes originating in those porous applications.  The first solution is resisted because IT culture sees hardware as expensive, this in spite of the fact that its cost halves every two years.  The second is resisted because user culture prefers convenience, generality, flexiblity, and ”dancing pigs” to security.  As a consequence, most desktops are configured to offer read-write access to most objects and  few provide reliable protective isolation.  

It does not have to be this way.  Ten years ago Steve Jobs and Apple introduced us to iOS, with very limited capabilities but with very strong process-to-process isolation and strong protection from anything done at the user interface.  As it has matured its capabilities have increased.  Controlled application-to-application communication has been introduced while maintaining strong isolation and protection.  Some generality and flexibility have been sacrificed to usability and security but less than the defenders of the status quo predicted.  Nonetheless, resistance to iOS was so strong that it provoked Android, a more traditional system.  

However, iOS has been adopted by a large population of users that enjoy ”most, but not all, of the benefits offered by the traditional general purpose system.” (Fred Cohen)  At the user application interface, it appears as a single user single application-only machine.  While it can maintain application state, iOS is resistant to any persistent change to itself from the application or the user.  

Said another way, iOS protects itself from its data, its user, and its user’s data.  While the application may be vulnerable to a ”bait” attack, the system is not.  Therefore, it is a preferred environment in which to run vulnerable applications like e-mail and browsing, and sensitive applications like banking and healthcare.   

Personal computers can be configured with hypervisors to provide strong process to process isolation.  They can be configured with the ”least privilege” access control rule to resist contamination of procedures by their data.  Said another way, they can be configured such that simply clicking on a bait object is not sufficient to compromise the system.  Indeed they can even be configured in such a way that, as in iOS, nothing done with the keyboard and mouse is sufficient to compromise the system. 

This brings us to the ”flat enterprise network.”  Traditionally, enterprise networks have been configured for any-to-any connectivity; any node in the network could send a message to any other node.  The latency and bandwidth between any two nodes was roughly the same as the average across all nodes.  Often, and at least by default, they have been operated at a single level of trust.  That is to say, all nodes in the network were assumed to be benign, orderly, and well behaved. Nodes were not expected to have to protect themselves from traffic that originated on the network or question the origin address.  It is this configuration that leaves the enterprise vulnerable to lateral compromise with little more than one compromised system or user credentials.  

The alternative and safer network is referred to as ”zero trust.”  All nodes are assumed to be mutually hostile.  Traffic may flow only between specified pairs, e.g., user to application or client to server. Origin addresses are not trusted but must be authenticated.  Some cost in latency or bandwidth is tolerated for authorization of the connection and mutual authentication of the nodes. This kind of network is resistant to lateral compromise; a compromised node can attack only the nodes to which it is allowed to send traffic.  Even those nodes will treat it with suspicion and may require evidence as to its identity.  

There are a number of ways to restrict the flow of traffic to accord to this policy.  The first and most obvious is to provide only links between authhorized nodes; easy for two nodes, illustrative, but it does not scale even to a small enterprise.   However, the others simulate this illustration, usually through the use of encryption, e.g.,virtual local area networks, VLANs. virtual private networks, VPNs, and software defined networks, SDNs.  Note that in SDNs, users are included as ”nodes.”  Note also that to be most resistant to attack, connections should be at the application layer.  Applications are the nodes of interest and, contrasted to, for example, operating systems, have the smallest attack surface, i.e., the user interface.  

So, to summarize, the traditional use and configuration of desktops leave the enterprise vulnerable.  While awareness and strong authentication, remain essential practices they are limited in their effectiveness.  E-mail and browsing should be isolated from mission critical or otherwise sensitive applications.  The environment should be resistant to persistent changes to programs or procedures from application data; least privilege access control.  Network traffic should be encrypted end-to-end at the application layer; prefer software defined networks to VPNs to VLANs.