Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

standardize device biometrics / PIN check as a 2nd factor to support web crypto operations #354

Open
prime2358 opened this issue Aug 31, 2023 · 1 comment

Comments

@prime2358
Copy link

The first use case of web crypto, mentioned by the specs is multi factor authentication:
https://www.w3.org/TR/WebCryptoAPI/#multifactor-authentication

Since biometrics / PIN access is used in native apps as a second factor to crypto operations (implemented by web crypto on the web), I think web crypto standard would be the right place to standardize a simple biometrics / PIN check (above different native platform APIs) like (just an inital suggestion):

subtle.crypto.verifyUser(option, timeout = 100_000)

  • where option is an enum: STRONG, ANY (referring to stronger methods like faceid or fingerprint or any methods like drawing something or weaker face unlock)
  • timeout is the timeout in millisec
  • result is a promise with true or false

This would be like a second factor for any (!) crypto operation where it makes sense: like signing challenges or decrypting data.

Example use cases (2):

  • A web app (even operating offline), having been signed in with any methods, may have encrypted sensitive user data in indexed db (with WEB CRYPTO: unextractable decryption key). The web app is capable of decrypting and showing this sensitive data to the device operator, but with biometrics check, we could add a 2nd factor to EXISTING WEB CRYPTO USE CASES, and only for the device owner(!) would it be possible to use the decryption key.

  • A web app that utilizes WEB CRYPTO private keys for device authentication can now make the browser sign a challenge with an (unextractable) private key before doing some sensitive action on server like downloading or deleting sensitive things (the successul signing with the private key practically refreshes an access token before performing sensitive operations). Same here, with a second factor, only the device owner would be able to do these things and not anybody that currently operates the signed in device.

Apple, Google, Microsoft platforms have different classification of "device unlock" security levels, it would be great to achieve a good definition of what is considered STRONG.

@prime2358
Copy link
Author

prime2358 commented Aug 31, 2023

EXTRA info:

I rephrased #351 with better understandable use cases.
I stress that what I propose here is an extension to multiple(!) WEB CRYPTO functionality with a 2nd factor and not a full authentication solution that is webauthn.

Webauthn standard has nothing to do with decryption, for example.

Webauthn cannot be used for simple biometrics checks, it is coupled to creating and getting private keys in a pass manager system.

Web crypto enabled us to use private keys in the browser. What is proposed here, in addition to other use cases like decryption, to ENHANCE the current WEB CRYPTO implementation of BROWSER stored private key signing with a 2nd factor of biometrics check that proves that the device owner executes a command.

Even in this use case, it is not duplicating webauthn functionality. It is providing a biometrics enhancement of browser stored private keys that is usually a part of a different authentication system than the passkey approach.

Netflix has a WEB CRYPTO based approach where email/password is an inital sign in and recovery, access tokens and web crypto keys manage keeping the device signed in. This works with people having a paper based password system and emails, works on all platforms (linux) with or without any pass managers(!), now. For accessing local encrypted data or performing sensitive server side actions with already signed in devices (managed by WEB CRYPTO) it would be a great 2nd factor to provide biometrics check capability, uncoupled to any alternative full scale authentication method that requires pass manager usage.

Another approach is #350 where you couple web crypto operations to biometrics/PIN checks. As of now I do not really see why it is better than just having a biometrics check with yes/no result but it may guide implementors to use biometrics check by crypto operations where it really makes sense like signing or decrypting. As of now, I am supporting a well separated biometrics check as proposed here.

I would really like to keep this suggestion open for at least a year to be discovarable by others and listen to others.

I found it very rude that a single person shuts a discussion down before even getting views from multiple people.

I cannot accept an argument that this is some kind of duplication of webauthn and webauthn should be changed instead. I think the person who states this has no idea what webauthn is and how unrealistic it sounds. I spent a lot of time with webauthn, implemented it successfully, I know webauthn standard, I implemented web crypto encryption/decryption and web crypto ECDSA private keys and access tokens and signing and all of this. I really know what I am talking about.

I am totally open to security arguments from people who are much better in security than I am but it is nonsense that you can use webauthn for above purposes that is clearly a biometric capability extension of the use cases of THIS standard.

It may be a competing approach to passkeys to use browser based private keys and biometrics and keep passwords, but it is a healthy competition and not at all a duplication. I do not see any suggestions to abolish browser based private keys just because we have passkeys now?

As Apple stated, passkeys are a replacement for passwords. I suggest NOT a replacement for passwords but a biometrics enhancement of different web crypto capabilities, one is adding security to signed in browsers via biometrics, where web crypto keeps the browser signed in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant