passwords Archives - IDPro https://idpro.org/tag/passwords/ The Professional Organization for Digital Identity Management Wed, 26 Jan 2022 18:04:58 +0000 en-US hourly 1 https://idpro.org/wp-content/uploads/2023/07/cropped-idpro_stickerA-circle-100-32x32.jpg passwords Archives - IDPro https://idpro.org/tag/passwords/ 32 32 The Password Isn’t Dead…But It’s Quite Ill https://idpro.org/the-password-isnt-dead-but-its-quite-ill/ Wed, 26 Jan 2022 18:04:56 +0000 https://idpro.org/?p=1489 by Simon Moffatt Well, as we enter 2022 – and a good way into 60 years of using commercial computer […]

The post The Password Isn’t Dead…But It’s Quite Ill appeared first on IDPro.

]]>
by Simon Moffatt

Well, as we enter 2022 – and a good way into 60 years of using commercial computer technology of some sort – the password is very much alive and kicking. For example:

  • This article is being written in Google Docs, which requires my username, password + MFA.  
  • It will be promoted on Twitter: Username, password + MFA.
  • Shared on LinkedIn. Username, password + MFA.  

Note the pattern?  Yes MFA is absolutely in the mix for me personally, but a) that doesn’t necessarily equate for all users and b) the underlying requirement for a shared secret still exists.

The “cost” to a service provider or application developer to reach out for the username and password pattern is very low.  Libraries exist and many password storage approaches now rely heavily on techniques using salts and hashes.  Making a choice for something different has some pretty big impacts – namely changes to usability and hoops to skip through regarding security change management if some new and funky passwordless approach is selected.

Drivers Towards Passwordless

However, there are emerging shoots of hope for those who wish to see a password-free world. A quick Crunchbase search reveals a tasty $700+ million has been poured into startups with the word “passwordless” in their description in the last 36 months.  A chunk of change (admittedly heavily influenced by Transmit Security’s $543 million last summer) that is empowering new techniques to the age-old problem of authentication.

The interesting aspect is that authentication is the main pinch-point of both B2E and B2C interactions.  B2E identity is having to contend with distributed working, migrations to zero trust and secure service edges and data security, whilst the continued drive for B2C consumer identity sees a need for secure yet usable user verification driven by retail and financial services and the increasing need for secure PII sharing.

All in all, user interruptions during the authentication process are increasing hugely.  The volume increases and the context surrounding the transaction is becoming more complex and subtle, too.  Usernames and passwords just won’t cut it, even with a decent MFA overlay leveraging one time passwords (generated client side of course not sent via SMS or email…) or Push Notifications.

Passwordless Requirements

Passwordless adoption requirements for both B2C and B2E will be subtly different.  It can be quite interesting to analyze requirements of passwordless just as you would any other credential – via a life cycle model.

A basic example would see steps such as enroll, use, add, migrate, reset, and remove.

Each step in the life cycle can then be broken down into the capabilities needed.  A consistent theme would seem to be a need for increased end user self-sufficiency – especially around enrollment and reset, where the dreaded call to the helpdesk instantly increases cost and reduces end user happiness.  (Obligatory sales nudge, I worked on a buyer guide for passwordless in 2021…)

B2E

From a B2E perspective, concerns for a passwordless model seem to focus upon replacing existing MFA components.  Many organisations often have numerous disconnected modals perhaps focused on specific user communities or applications.  Any consolidated passwordless approach must provide a range of application integration options from SDK’s, standards integration, or out of the box native integrations.  It would also be worth considering orthogonal authentication use cases for PAM and even physical building access.  Can that be integrated into a mobile centric passwordless approach?  The buzz words of zero trust and contextual and

adaptive access need to be shoe-horned into this landscape too, likely with a decoupled

approach to authentication away from the identity provider and network infrastructure plumbing.

B2C

Consumers are a different beast.  The focus is often upon rapid user onboarding with transparency and usability being important.  Can KYC and identity proofing be augmented into the credential issuance process?  Can those processes also be used during any reset

activities?  Clearly fraud – I’m thinking ATO, phishing, credential stuffing and basic brute force attacks – are all a huge issue with an Internet facing service, so any passwordless service needs to be immune.  Compliance initiatives such as the Strong Customer Authentication aspect of PSD2 is also driving a need for an authentication method that is secure yet can be operated at high scale by the end user.

What Are The Options?

So we all hate passwords. Service providers are getting hacked daily – the HaveIBeenPwned site is nearly at 12 billion breached accounts – and end users pick easy to break passwords that they re-use.  But, numerous startups are coming to the rescue – typically with a local mobile focused biometric (aka FaceID/fingerprint) that unlocks a private key on a device in order to respond to a challenge being set by a service that requires an authentication result.  Many do this in a proprietary way and many now leverage the W3C WebAuthn approach as a standards-based model.

A few other subtleties start to emerge.  How is the private key stored?  If on device, does it

leverage the trusted execution environment or secure enclave?  If off-device, is it stored in a

distributed manner, so no single point of failure exists?  If on device, what happens if the device is lost or stolen?  Does the end user have to re-enroll? Questions that all emerge once roll out starts to hit big numbers.

Another aspect to consider, away from just the technicalities, are things like end user training

and awareness.  Whilst many service providers aim for “frictionless” experiences and

transparency, a user journey that is too seamless, may actually make the end user suspicious – they want to see some aspect of security.  The classic “security theatre” scenario.  As with any mass rollout approach, not all users are the same. Behaviour, geographical differences, device preferences and the like will result in the need for a broad array of usage options and coverage. Can the new passwordless models cope with this?

Summary

Passwords aren’t dead, but they’re definitely quite ill.  The options for moving to something new are starting to become broad and numerous.  However, authentication doesn’t exist in a silo and on its own carries little use.  It would seem that before authentication (think proofing) and after authentication (think session integration coverage) use cases would likely emerge as the biggest competitive battlegrounds in the next 24 months.  Those suppliers that can create authentication ecosystems that integrate into a range of different devices, users, and systems

would likely see success.


Simon Moffatt

Founder & Industry Analyst, The Cyber Hut

Simon Moffatt is Founder & Industry Analyst at The Cyber Hut. He is a published author with over 20 years experience within the cyber and identity and access management sectors. His most recent book, “Consumer Identity & Access Management: Design Fundamentals”, is available on Amazon. He is a CISSP, CCSP, CEH and CISA. He is also a part-time postgraduate on the GCHQ certified MSc. Information Security at Royal Holloway University, UK. His 2022 research diary focuses upon “How To Kill The Password”, “Next Generation Authorization Technology” and “Identity for Hybrid Cloud”.

The post The Password Isn’t Dead…But It’s Quite Ill appeared first on IDPro.

]]>
My Phone Is My Password https://idpro.org/my-phone-is-my-password/ https://idpro.org/my-phone-is-my-password/#respond Sun, 10 Nov 2019 20:37:00 +0000 https://www.idpro.org/?p=646 Everyone has a smartphone (in fact, many have more than one). Nobody wants to remember yet another password. Surely the […]

The post My Phone Is My Password appeared first on IDPro.

]]>
Everyone has a smartphone (in fact, many have more than one). Nobody wants to remember yet another password. Surely the combination of these two means that the smartphone app is the logical solution to securing authentication and delivering a truly passwordless experience for both employees and customers? Unfortunately, it’s not always as simple as that, though. In the ongoing war between convenience and user experience on the one side, and strong security and privacy on the other, we need to ensure that we do not unwittingly create new risks and attack surfaces in our rush to remove passwords.

The Trouble with Passwords

It’s probably not all that controversial to say that we, as an industry, are not doing knowledge- based authentication (and passwords in particular) at all well. Knowledge is fallible and unreliable – just because somebody knows a particular random string of characters at one point in time is unfortunately no guarantee that they’ll remember that same thing days, months oryears later. Bad password hygiene thus abounds, as individuals would rather use weak passwords to eliminate complexity and improve their own user experience. Companies often counter by enforcing impossible password policies that only make the user experience worse.

Smartphones are commonly used today as a secure yet convenient second factor, for a number of good reasons. Phones offer built-in private keystores protected with a biometric and a built- in way to deliver secure authentication challenges via push messaging. Smartphone apps often double as a soft token, and organizations can stay in control of the user experience and branding of the app. They are also cheaper and more convenient than hard-token based solutions

Are we ready, though, to abandon passwords entirely and rely solely on the smartphone as a way to authenticate users? I believe that we certainly can do this now.

The Boy who Logged In using (only) his Phone – with apologies to JK Rowling.

A number of techniques and patterns exist today for enabling authentication using only a smartphone. There are, of course, pros and cons to each of them.

Identifier + Push is one technique that I’ve seen. This is where the password is dropped entirely, with the user instead only providing a username (which can, of course, be cached in a browser cookie). Once the user has been identified, a push notification is sent to the smartphone app in order to authenticate the user through the possession factor. In order to implement this model securely (and not reduce security to single-factor, possession only authentication), it is strongly advised to ensure that a biometric login or approval is required on the mobile in order to accept the authentication request.

Claiming an authentication session through scanning a QR code is another popular approach – one that has the added usability bonus of removing the username entirely. In this model, the user opens a trusted app that is strongly linked with her identity, uses a biometric to unlock her private key, and then scans a code that is presented by the website she wishes to access. It’s agreat and novel approach to the problem but can lead to something of a proliferation of different authentication apps on the phone. Some level of user retraining may well be required, too.

Native app auto-login is a good approach for passwordless authentication when the user’s journey starts on the smartphone itself. Once again, the combination of possession (a private key within the app) and inherence through a biometric can be used to enable login without requiring users to type in usernames and passwords each time they launch an app.

Across the industry, we continue to evolve and develop new standards to improve authentication and two newer options for passwordless authentication have emerged from the identity standards community – each aiming to tackle the problem in different ways.

Client-Initiated Back-channel Authentication, or CIBA, is a new standard from the OpenID Foundation that complements the existing redirect-based OpenID Connect flows with a decoupled option that uses a push to a smartphone app as the primary means of user authentication. CIBA is still emerging but offers a solution to a wide variety of use cases, moving beyond authentication towards transaction approval as well.

The new WebAuthN standard developed under the auspices of the W3C provides an end-to-end secure flow for user authentication with a high level of resistance to phishing and man-in-the- middle attacks. Central to the approach is the Client-to-Authenticator Protocol (CTAP) that enables a user agent to communicate with any authenticator device that implements thestandard. Google’s latest phones incorporate a built-in CTAP authenticator, allowing the native biometric capability of the device to be used as an authentication factor.

With Great Power comes Great Responsibility

I do need to end with a few caveats, though. While the approaches outlined above all offer a far better user experience than anything based on passwords, we do need to take some key points into consideration. It’s a pretty small leap from “My Phone is my Password” to “My Phone is my Identity” and it thus becomes very important to include a strong process of identity proofing in any enrollment process that allows enablement of a smartphone app as a primary authentication factor. As the smartphone becomes the primary authenticator, it is equally important to ensure that possession of the smartphone alone is not sufficient to allow access; a biometric or knowledge step must always be added to the authentication process.

Some of these approaches are reliant on standards that are not yet implemented consistently across mobile operating systems and/or browser ecosystems; others rely on the user installing ‘yet another’ authentication application on their device, which can mar the user
experience. Both of these situations will improve with time, but for now, take care to pick solutions which are appropriate for your target user base.

Finally, we need to be realistic about the risks and vulnerabilities of a smartphone-app-based approach to identity and security and ensure we are implementing the necessary countermeasures to protect our users against the threat of compromise of their mobile keystores. This starts with detection of rooted or jailbroken devices but should also encompass an appropriate level of malware detection and anti-tampering counter measures.

(For additional background, check out Rob’s Identiverse presentation on this topic)

page5image2018689040

Rob Otto Office of the CTO Ping Identity

The post My Phone Is My Password appeared first on IDPro.

]]>
https://idpro.org/my-phone-is-my-password/feed/ 0
Why WebAuthn and FlDO2 have a good chance to replace passwords https://idpro.org/why-webauthn-and-fldo2-have-a-good-chance-to-replace-passwords/ https://idpro.org/why-webauthn-and-fldo2-have-a-good-chance-to-replace-passwords/#respond Thu, 30 May 2019 22:46:00 +0000 https://www.idpro.org/?p=670 Nobody likes passwords. Users don’t like passwords because they are hard to remember and every system seems to have a […]

The post Why WebAuthn and FlDO2 have a good chance to replace passwords appeared first on IDPro.

]]>
Nobody likes passwords. Users don’t like passwords because they are hard to remember and every system seems to have a unique password policy. Companies do not like passwords because they drive up support costs and reduce productivity. IT security does not like passwords because they are easily compromised. The news is filled with stories about stolen credentials, mega breaches, and reputation damage. Yet passwords remain. For years, new techniques for replacing passwords have come and gone with different levels of success. 

Now there is a new standard that has a real chance to replace passwords. I know some of you are thinking that you have heard this before. A shiny new approach, but will it really work? Will it work in the real world? Will users actually adopt the new technology? Can it be implemented without requiring a massive project, expensive new infrastructure, and/or an army of consultants? This article will walk through the basics of WebAuthn and FIDO2 and how its ease of use, strong security, and industry support will accelerate the implementation of passwordless authentication and reduce the difficulty of use. 

Background
WebAuthn is a W3C specification, ratified in March of this year, that evolved out of the FIDO Alliance’s Universal Second Factor (U2F) standard. It paves the way for common deployments across browsers, operating systems and applications. 

If you have heard of WebAuthn, you have probably also heard of FIDO2. FIDO2 is a term that encapsulates the WebAuthn standard and the FIDO Alliance’s Client to Authenticator Protocol version 2 (CTAP2). WebAuthn and CTAP2 work in concert to eliminate passwords.

These standards work together and establish a method for asymmetric (public-key) cryptography and origin-bound key validation to verify the authenticity of the user to the relying party. The standards also provide protection against phishing attacks as only the relying party that initially performed the registration with the FIDO-compatible security key will receive a valid response. Each registered application has its own unique public / private key pair providing an additional level of security and privacy. 

WebAuthn requests that a credential be created by the authenticator for a particular RP.  The authenticator provides key management and cryptographic signatures. The authenticator generates the credentials. This eliminates the need for a company to implement and manage a public key infrastructure (PKI) for end-user authentication.  This streamlined approach will make implementations and adoption easier for companies. The authenticator also provides an attestation certificate that provides basic information about the authenticator that the relying party can use accordingly. Attestation proves to the relying party that the keys generated originate from a genuine device.

WebAuthn and CTAP2 take the U2F authentication model and extend it for primary login as opposed to only enabling a second factor. The specifications include user verification (biometric and/or PIN) for added security. User verification (UV) provides a multi-factor authentication and ensures if someone gets ahold of the authenticator they cannot use it without PIN or biometric information. The PIN and biometric information never leaves the authenticator, and they serve only to unlock the authenticator for use. WebAuthn can be used as a second factor and is backwards compatible with U2F-based authenticators. Users have become accustomed to logging in using fingerprint readers and PINS so this form of interaction should be readily accepted.The specification also includes the concept of user presence (UP) which requires the user to perform an action, like touching a security key, to ensure a person is involved in the event.  

Putting it all together
Strong, modern authentication requires a number of systems to work together. One of the challenges with mass adoption of U2F was that not all browsers support it. That brought the FIDO Alliance and the W3C together to work on standard ways to ensure implementations work across browsers and platforms. Now, all major browsers are actively working to implement support for WebAuthn and have some form of FIDO2 functionality working today with full functionality and browser parity coming in the not-too-distant future. Having WebAuthn and CTAP2 built into browsers and platforms reduces the need to deploy client software, making implementation much easier for services, relying parties, organizations and companies. 

In order to integrate WebAuthn with their applications, relying parties will need a lightweight WebAuthn server. WebAuthn capabilities are being built into Identity Provider solutions or companies can build their own using open source projects. One such project can be found at https://github.com/Yubico/java-webauthn-server

Relying parties should plan for account holders to have multiple authenticators registered. Each public-private key pair is bound to an authenticator and cannot be copied or shared by design. Since multiple security keys can be tied to an account, a relying party should allow users to name authenticators for easier tracking and management. Authenticators come in a number of form factors that provide convenient options for users to authenticate.  They can be built into the computer (Windows 10 provides this capability now), into a mobile phone (Android 7+ phones can be used for FIDO 2FA at this time), or be on a keychain like the YubiKey (FIDO2 ready) . The FIDO Alliance maintains a list of authenticators that are U2F and FIDO2 certified at https://fidoalliance.org/certification/fido-certified-products/ 

Traditionally, a password is used for the initial authentication since it is not bound to the device. To remove passwords, the initial login scenario needs to be resolved. One way to resolve this is to use security keys to help bootstrap new devices and support a passwordless option for initial login to an RP.  A new device that can be used as a FIDO2 authenticator cannot be used until it is registered with the RP. A security key that is already registered to the RP can be used to perform the initial login. After initial login, the new device can then be registered and be used as a FIDO2 authenticator.   

With the confluence of secure hardware at the user’s fingertips (in the form of security keys and secure elements within devices), WebAuthn ratification, and industry adoption, there is a viable solution to replace and or dramatically reduce the use of passwords. WebAuthn will attract users with its strong security, convenience, and ease of use. Even though the user will authenticate with different authenticator form factors, with unique credentials, the process will appear seamless. The work is not done but users can count on fully viable solutions very soon. 

What now?
As an identity professional, what can I do to prepare for a WebAuthn deployment?  Within your company, there are a number of things that can be done to prepare for leveraging FIDO2.

Review and update policies and procedures

We have been living with passwords for a long time and have built processes with that model in mind. Processes need to be revisited if passwords are not used or significantly reduced.  How will onboarding be affected? How should recovery processes be altered? What type of authenticators make sense for the company? PINs are not considered passwords and should have their own policy.

Additionally, passwords have a one-to-one relationship with an account. With FIDO2, an account can have many credentials across different devices. This subtle shift can have some dramatic impacts to a company. As an example, access policies could be written based on which authenticator or authenticator family type is being used.    

Work with your IDPs and RPs to support the standard 

WebAuthn is gaining a lot of traction but unless the majority of identity providers and web applications implement the technology, it will take a long time to eliminate passwords.  Vendors really listen to their customers to prioritize feature requests. The more they hear from IDPros, the sooner WebAuthn will be implemented into their authentication flows.

Upgrade to the latest browsers and platforms

Though the infrastructure footprint can be minimal, the technology is highly reliant on the latest browsers and platforms. Work with your counterparts within your company to ensure that browsers and platforms are being updated. 

Start planning for a pilot

WebAuthn/FIDO2 can be used today with certain websites and more will be coming online soon. A pilot will help work through all the processes that need to be updated for a successful deployment.

Going Deeper

This article provides a high level overview of WebAuthn/FIDO2 but there are a number of details that can be explored in more detail, especially if you plan to implement WebAuthn for your own services.

If you will be attending the Identiverse conference in June, go to one of the many WebAuthn/FIDO sessions.  Here is a short list of relevant sessions (details and additional sessions can be found online

Tuesday, June 25th

  • Google Masterclass: Democratizing phishing-resistant FIDO technology
  • SecureAuth Masterclass: What passwordless technology can learn from American Prohibition
  • Federating FIDO through a Blockchain

Wednesday, June 26th

  • Ping Identity Masterclass: Implementing Passwordless Authentication with FIDO-based, Intelligent MFA
  • The state of FIDO
  • Netflix’s Journey with WebAuthn

Thursday, June 27th

  • Standards: The Bedrock of Identity
  • The next wave of Identity standards
  • Ping Identity Presents: The Intelligent Future of Multi-factor Authentication
  • Envisioning Authentication Beyond FIDO

Friday, June 28th

  • SecureAuth Masterclass: What passwordless technology can learn from American Prohibition
  • MFA for Real – reports from the field

Additionally here is a list of great resources to learn more about Webauthn and FIDO2 as well as public announcements of support:

David Treece is a senior solutions architect at Yubico and an individual member of IDPro.

The post Why WebAuthn and FlDO2 have a good chance to replace passwords appeared first on IDPro.

]]>
https://idpro.org/why-webauthn-and-fldo2-have-a-good-chance-to-replace-passwords/feed/ 0