- From: mattimac via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Jun 2020 10:27:47 +0000
- To: public-webauthn@w3.org
> > > The original approach (https://www.w3.org/TR/webauthn/#sctn-simple-txauth-extension): > a) allowed the RP to provide any transactionText (having the expectation it would include something like "Transfer $1000 from account 987654321 to account 123456789". > b) expected the authenticator to display that transactionText and > c) only generate the resulting signed assertion (including the hash of the transactionText) if the user (i) agreed to the transaction and (ii) could provide the gesture (e.g. use correct finger to touch the sensor). The hash of the transactionText is included in an extension that is added/controlled by the authenticator. > > The new idea, would also allow some privileged software to display the transactionText - expecting that the the assertion would allow the RP (=verifier) to understand whether the Authenticator displayed it (hash of transactionText included in extension) or the privileged software did (e.g. add hash of transaction Text to collectedClientData or to the same extension but setting a specific flag that privileged software displayed it). > > With this approach we would extend the reach as FIDO authenticators without a display could be used as well. > The use of authenticators with display is still possible and even allows scalable security (e.g. using TrustedUI as it is done by Android Protected confirmation). > However, on today's mobile devices, malicious apps cannot easily "infect" other apps or the browser. > Both approaches protect against JS code injection, e.g. through infected ads or ad providers or otherwise altered contents that was loaded via one of the typically many external script sources that are included in web pages. What about threats: - that would manipulate memory to alter the transactionText presented to the user ? - that would try to manipulate which prompt containing transcationText is on top (if opening multiple is possible) - other means on OS api level security mechanisms preventing tricking the user to authorize different transaction that he thinks he authorizes The above explanation is not enough, i have no knowledge of any security considerations, tests (if any of those have been performed and documentations is available - please let me know). IMHO this is a minimum for financial market to consider this when we speak about authorization of transactions. -- GitHub Notification of comment by mattimac Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1396#issuecomment-641910858 using your GitHub account
Received on Wednesday, 10 June 2020 10:27:49 UTC