- The suggestion of signing the timestamp means that any web site you log into with this can log in as you to any other web site you log in to
- Given that there's no namespacing of the signed messages, users can be easily phished into providing a response to a challenge posed by a different web site
- It's not obvious what advantages this has over using client cert authentication with TLS, and it has many downsides.
> Given that there's no namespacing of the signed messages, users can be easily phished into providing a response to a challenge posed by a different web site
This is key. The whole benefit of hardware token-based authentication is that it is resistant against phishing (because SMS 2-factor and TOTP, e.g. Google Authenticator, are NOT phishing resistant).
So this approach is more complicated than those other 2 2FA approaches but with no additional security benefit.
As the other commenter said, this has nothing to do with hardware tokens. This has to do with the user agent (the browser) passing the (browser-verified) origin to the authenticator (which can be hardware or software). But, critically, the signatures are also origin-scoped—the message that your user-agent correctly passes to google.com cannot be used by google to sign into microsoft.com.
What’s broken here is not that user agents are or aren’t validating the origin (or relying party)—it’s that the same key+challenge is used for every origin. (As a result, there’s nothing for the user agent to validate, because the same signature is used for all origins!)
It’s like using the same password for every website you log into. As severe understatement, this is a very, very bad protocol design, and nobody should use it.
>The whole benefit of hardware token-based authentication [...]
Technically it's not something limited to hardware tokens. You can conceivably do something similar with username/password authentication, as long as the credentials are sent to the browser and not the site.
Signatures are only valid for about 30 - 60 seconds (depending on the server config) and may not be re-used after a successful login. Try to create a key pair and log into the test website. Then try to use the same signature to do so again.
The demo website and the github repo contain this information. It would be helpful, if people actually created a key pair and tried to use it and misuse it before being critical.
It's not meant for federation, single-sign on (which is single compromise IMPO) or anything that is commonly discussed in the security community. It's foreign to most (I understand that), and I just wanted to share it and start a discussion.
Because it was in reply to my earlier comment saying this is not SSO. People seem to think these signatures can be used on multiple websites (sign in with Google like functionality). That's not the case.
These signatures are meant to be used to authenticate to a website. If multiple websites implement this idea, then end users should have multiple key pairs (one for each site). So there would be no way a signature for one site could be misused or abused on another.
I believe the github site and the demo website do describe the problem and goals. Webauthn is too complex. Passwords are bad. Hashes are dumped from databases and cracked. Passwords are stuffed, etc. The complexity of webauthn is not the answer.
In this scheme, the website only knows its users' public Ed25519 keys. These keys are harmless and it does not matter if they are stolen (they cannot be used to cause any harm).
The users are in full control of the keys. There is no CA signing TLS certs, etc. The web service and its users are in full control of the process and they are using open-source software. Full transparency that is easily understood by all parties.
Also, there is no identifying information in an Ed25519 key. One goal I have is user anonymity. This scheme allows for that too. No email, phone, etc. Just a public Ed25519 key fully controlled by its end user.
Are you the author? If so I would love to talk with you more about your vision and goals.
I personally would like reusable keys, and I agree namespace or some other mechanism is needed.
I generally prefer to link my identity among websites and I'm generally not concerned about anonymity or privacy. "A key for each website" is nearly worthless to me.
The ability of others to spoof my identity because a website uses passwords, and most websites provide little to no logging, let alone a standardization, infuriates me. That is a outsized use case I see little attention given to.
If I tweet, users are forced to trust Twitter's authentication system that I tweeted. I don't trust Twitter's authentication systems.
Public key authentication permits third parties to verify my actions without the need to trust system authentication systems.
I too am interested in the small slice of the problem that is replacing passwords with something asymmetric. The rest is kinda out of scope IMO. OPAKE is cool but definitely not less complicated than WebAuthn and doesn't do anything related to solving phishing and tracking etc. either. Keys seem like a natural solution. WebAuthn is actually really good but browsers don’t yield enough control for people to use it in a portable identity style, which I also agree isn't the devil.
WebAuthn is "too complex" the way a catalytic convert is "too complex." If you don't know what it's for, it certainly seems like you can remove it with no downsides. ;)
> Because it was in reply to my earlier comment saying this is not SSO.
The person you were replying to was also not talking about SSO, which makes me think you don't understand that (valid, and fundamental) criticism of your proposal. :-/
> Webauthn is too complex.
Which functionality would you remove, and what tradeoffs does that get you?
> Passwords are bad. Hashes are dumped from databases and cracked.
Surely it's easier for an IdP to use scrypt with some meaningful salt than to implement this fully novel and unsupported scheme.
> Passwords are stuffed, etc.
These seem like problems that affect password reuse. According to your design, users should just know better than to reuse keys, so...why not just know better than to reuse passwords?
> There is no CA signing TLS certs, etc.
So why not use self-signed X509 client certs instead? This is actually a thing browsers actually support.
> The web service and its users are in full control of the process and they are using open-source software.
This is a category error. We were discussing a protocol. If you think your specific implementation of that protocol is better than all the open source implementations of FIDO+WebAuthn, X509 client certs, PAKE, etc...well, you're probably wrong. :)
> One goal I have is user anonymity.
You have not explained how your system is more anonymous than the existing, well-defined, standards-compliant alternatives.
Edit: Just to be clear about the tone of my feedback: my intention is to help you understand the context in which you are making your proposal and, ideally, understand the design tradeoffs existing systems have made. I know it's easy to become attached to an idea and take criticism like a personal attack. I hope you can take this constructively.
Your tone is overly dismissive. If you want to be constructive then have a constructive conversation and not a dismissive knee jerk reaction. Your comment reads like “I haven’t read a standard for this or bothered to really take a look and it’s new therefore it’s fundamentally bad and insecure and not worth my time”. This repo is simply proposing using signed timestamps for auth. It would be nice to keep the discussion on that topic and it’s merits. Personally I think webauthn is not too complex and just needs to not be locked up in browser land so we can have a real softkey impl so we probably actually agree on our general outlook. You’re just kind a being a security diva about the whole thing and it’s not really fair to the author.
Which part was knee jerk? I read everything on the (minimal) webpage. It doesn’t explain anything of substance, nor does it anticipate the (obvious) issues other commenters here noted. It’s like the author just proposed to remove everything they didn’t understand from Webauthn and was left with this.
And what’s left is essentially wireguard for logins. People love wireguard for its simplicity because it doesn’t use certs and PAKEs and whatnot. Yeah there are valid criticisms and I’ve critiqued the work as well in other comments. But the “this is utter shit how could anyone imagine this is a valid idea” is not productive.
> Honestly, this discussion isn’t worth the time.
That’s my point. If it’s not worth your time then let others who are interested discuss rather than just pissing all over the author’s project.
> - Softkeys are available—in fact, iOS, Android, MacOS, and Windows 11 all do webauthn by default, without the need for a hardware token.
That’s not soft keys it’s “platform authenticator”.
When I say softkeys I mean keys managed by a user agent such that they can be portable, like is common with ssh. SSH is popular because it’s gives users the freedom to easily elect their security posture: do they want a user key that can be deployed to different devices or are they super paranoid and want a device key. Do they want a software agent to manage soft keys for them and it can handle the device security and hardware crypto engine support. Not your concern, not the protocols concern, not the services concern: it’s the user’s concern.
Wireguard has soft keys, too.
WebAuthn’s crowd and browser implementers on the other hand seem fixated on making sure users never have the option to deploy the protocol in such a way. That’s the problem.
> People love wireguard for its simplicity because it doesn’t use certs and PAKEs and whatnot.
I don't know of a VPN that uses PAKE, so I don't get this comparison, but whatever.
My point about certs was that OP was effectively proposing self-signed X509 client certs. It's unclear to me in what way those are harder to use than the proposal here, except that they actually are a widely accepted standard with user agent support.
> WebAuthn’s crowd and browser implementers on the other hand seem fixated on making sure users never have the option to deploy the protocol in such a way. That’s the problem.
It kinda feels like you’re deliberately talking around my point. I’m not saying existing VPNs use PAKEs and it makes them bad. I’m saying you don't need a PAKE to have “modern” authentication. And look at wireguard which is loved for being a dead simple protocol that uses raw keypairs. Therefor it’s not absurd to imagine a very simple protocol like this.
You are correct that client certs have user agent support. Honestly it’s a pretty poor UX though. Have you actually tried building a consumer application that uses client certs in the browser? Good luck getting users to install client certs. Client certs work fine everywhere else where you can run bespoke client software (native apps) except for the part where they authenticate the connection and not the request, but that’s not the point either.
Anyway it’s great that other implementations of webauthn exist. But like I just said for client certs: outside of the browser anyone can do anything so webauthn is not a game changer there (not to downplay it). Where WebAuthn matters is for client authentication in the browser and in that arena it is locked down to platform auth and hardware device auth mechanisms. There is no way users could benefit from webauthn right now without the browser-supplied UX.
All I’m saying is that WebAuthn would be way more viable in the way people are asking for in this thread if for example browsers/platforms allowed extensions to participate as a soft WebAuthn agent so that users could choose their preferred WebAuthn backend and UX instead of the browser supplied options. The browser client cert UX sucks and so does browser vendor WebAuthn and I think their adoption story is all the proof you need.
FIDO keys are also unlinkable across origins (or identities!), but unlike in this scheme, that property doesn't rely on the user knowing to not reuse keys.
Anyway, unclear to me how this is better than x509 client certs, except that the author probably doesn't know about them.
I'm not sure what you're replying to--this scheme is much closer to self-signed X509 client certs, not FIDO. But regarding FIDO, it does not prevent user-controlled hardware; it's up to RPs to choose if they require specific device manufacturers or not.
In my experience, the vast majority of (consumer) RPs do not require specific batch attestation, which is why you can make your own FIDO key: https://github.com/google/OpenSK.
I am under the impression support for attestation was controversial in FIDO--it's clearly useful for enterprise scenarios (e.g. where an enterprise requires some silly certification like FIPS: https://support.yubico.com/hc/en-us/articles/360016614760-Ac...), but there's always the risk that consumer-facing RPs require it for no good reason.
My employer requires FIPS certification due to FedRAMP; I'd be interested in how you would propose to change FIDO such that--as now--I can use a single key for work and for all my consumer needs while eliminating attestation. (One obvious option is for my employer to issue already-enrolled keys and disallow self-enrollment, but that has other headaches...)
The WebAuthn spec. explicitly tells RPs not to do this (attestation) unless they're sure they really need it.
Even Microsoft's half-arsed explanation of how this works inside Azure AD says you should probably not use it.
And I tell Firefox "No" when it asks me during enrollment if the site is allowed attestation from my devices, there are no public sites I've used where this was rejected as unacceptable, that includes GitHub, Google's sites, Facebook, and Login.gov.
Because for consumer auth we just go back to the CA oligarchy and client certs nobody uses if we rely on trusting vendor attestation.
I understand for a corporate setup employees are threat vectors. But that depressing outlook isn't how most people view the consumer space. We want: consumer x signed this auth challenge. We do not want: authority Y said consumer X signed this auth challenge. That’s just CA SSO style oligarchy repeated.
Why wouldn't you trust the consumer and their preferred authentication agent to participate in an authentication challenge? Consumer apps don’t need to ensure that consumers are using a hardware token device they just need to arrange an authentication dance that doesn't involve a shared secret.
It depends a lot on the situation. I think it’s reasonable, for example, for banks who have different liability standards depending on how transactions are authenticated to require batch attestation.
But like I said, most consumer IdPs aren’t doing attestation checks, and it’s discouraged, so I think you’re making a big deal of it. :)
I had a Bank of America token-card (the one with the LCD display and button) until they discontinued it. Those things are fine. It was no larger or heavier than their ATM card, and in fact some banks combined the two into a single card. There was no need for any FIDO-like standardization or certification authorities there because the same entity (the bank) had provided both ends of the authentication conversation (the token card and the bank's website).
If a bank feels the need to control the hardware I use, they must provide that hardware. Their needs absolutely do not entitle them to impose codesigning/bootloader-locking requirements on my other devices, such as my phone or my laptop.
> aren’t doing attestation checks, and it’s discouraged
That will change. If it weren't, they wouldn't have bothered putting it into the spec. Or they could have used symmetric cryptography for attestation, like the bank-issued token cards and the chip in your chip-and-PIN card do.
The nice thing about FIDO is that I can use the same USB key for a bunch of different websites. I have a single key on my keyring, and I use it for Github, for my brokerage, for Gmail, for my work, etc.
And the reason I can do that is because my work cares that I use a FIPS compliant key, but nobody else does—because consumer RPs don’t do this.
Have you encountered any consumer RP enforcing attestation? Or is this concern of yours totally speculative?
I don’t know what this Bank of America card you refer to is, but presumably it was phishable auth, since it had an LCD key? Without a standard supported by user-agents, I don’t know how someone would enforce an out-of-band/unphishable auth mechanism like FIDO+Webauthn on their own, but I’m curious to hear you explain it!
"Much simpler than webauthn" Is it? Trying out https://webauthn.io/, I can log in using a security key without hitting the command line and copy & pasting some base64 string.
"Private keys never leave end users' devices" How does it guarantee that, considering it saves the private key in the file system? It can be trivially copied off device from there.
The examples also appear to encourage key reuse, and since the challenge is the current time, the signed auth message can be replayed against any other site where the user set up using the same key.
Users can have a different key pair for each website. Also, signatures may not be re-used and are only valid for a few seconds. Try to create a key pair and login to the test website.
"Simpler" is a weasel word that can either mean "easier" or "more primitive", and in this case it's the latter.
Webauthn doesn't require separate keys per site and user vigilance to stay secure, because it has a-not-so-simple challenge-response protocol that is site-specific. For end users Webauthn is easier to use: just press a foolproof button.
I don't want to sound too negative. ed25519 keys are neat, and have fun implementing software using them. Let's just be realistic that a practical cryptographic system needs many more features, and Webauthn has them for a reason.
Users demonstrably reuse credentials across systems. If you are relying on users to always create a new key pair for each service, they simply won’t do that.
A few seconds is plenty of time for an automated system to cause harm.
This is very likely insecure. A malicious web site could replay your Auth flow to another website where you have an account that uses the same keypair.
right, would be better for the site to encrypt a one-time-use password with the public key you've, then all you have to do is decrypt it and log in, proving you possess the private key
does this have a name? always seemed like the obvious way to do it but I've never implemented auth
edit: I guess this is similar to a challenge/sign/verify signature scheme like webauthen, but is it inferior in some way?
Yep, what you've described is pretty close to the scheme in WebAuthn. The main additions in WebAuthn are for protocol level security: there's an attestation nonce, a shared counter, and some other fiddly bits to make it harder/impossible to misuse.
This is exactly what I use for an emailless password reset. Instead of sending a reset token via email, it's just encrypted with public key and user can decrypt token for reset password. There for I don't require to collect email address for account. Of course this could also be used as login method. On the downside, for UX purposes decryption can run in browser by passing private key. I have mixed feelings about pasting PKs into browser.
Yeah, there's no verification of a server's pubkey like ssh (which mostly is trust-on-first use), or a cert chain like tls.
This seems like a cool proof-of-concept. There are also a bunch of security properties that it fails in.
It's an okay-ish alternative to a password, but if we're going to use cryptographic secrets for auth, I'd hope to see more of a handshake and challenge-response involved.
As it stands, anyone who has access to a private key momentarily can generate any number of tokens for use, practically indefinitely (just sign a timestamp for every second for the next N years). This system is open to replay attacks as well.
It also glosses over the entire problem of trust establishment, cert revocation, etc.
I take an even dimmer view of this. First, the author is wrong on the premise let alone the implementation. This is not logging in with a public key but by using a keypair. This scheme actually moves from something you know to something you have. For that reason alone it can weaken or break two factor auth schemes.
Since it is akin to device not user authentication, the keypair may be copied between machines and suffer the intricacies of the details used to do so, weakening the keypair FOR ITS ENTIRE FUTURE LIFETIME. Replay attacks are trivial to perform.
It's a nice idea that is well explored elsewhere, but this should not even be considered an implementation of how to login into a system. This is not user authentication, even ignoring its flaws. This is auth for the device on which the keypair resides. Crypto is easy to get wrong even for experts.
The web service stores used signatures. They cannot be re-used and are only good for about 30 seconds. Try to register on the demo site and see if you can actually replay a signature.
Which is a naive way to implement reuse mitigation because you have have a db that grows endlessly. Send a nonce and have the user sign it. Make sure the nonce is only valid for one use (burn it after it’s used). Then you only have to remember active nonces and you can expire them after a short interval.
Used signatures are purged from the DB after they are no longer valid (too much time has passed). I realize this is a naive, toy implementation (in general). I wrote it to have a broader discussion.
You've got the problem that a lot of people have tried to create a lot of novel cryptographic protocols, and they are almost always lacking and insecure. It becomes useful to be able to quickly dismiss things that seem uninformed, as nobody has time to read every such thing.
The inclusion of a nonce/challenge (and other chosen-text and offline-attack mitigations) helps with a lot of security flaws, and that you've omitted them for no clear reason undermines your position as creator of a novel protocol.
As a trivial example, imagine that someone else comes up with a protocol that uses a signed current-date to authorise a bank transfer; as it's not distinguishable from your protocol, there would be many avenues for tricking a user into providing you with the ability to steal their money.
In responses elsewhere in the thread, you say that users should have a public key per website, but in your readme, you repeatedly imply that users have a single key-pair. "Register your base64 encoded public Ed25519 key with the website." "Use your private Ed25519 key to sign the current Unix Epoch Time" "Websites store the users' public keys."
Requiring users to keep generating keys and manage them manually introduces insecurity through non-compliance. It's not simple if you've got to manage something that behaves entirely like a local password database.
You say elsewhere "The demo website and the github repo contain this information" - but the demo website has no descriptive text (can you perhaps provide a link?) and the readme barely mentions threat models or goals. How do you prevent MitM attacks? Can your design support multi-party authentication or delegation of any kind?
I have no experience with WebAuthn, but it's likely that a lot of its features are to improve security in many ways, and omitting these features might make things easier at request-protocol level, but perhaps just simplistic overall.
You say you're trying to facilitate a conversation, but the proposal is so basic that you're effectively asking people to create a useful protocol for you.
You might want to look at webauthn since you say you’re unfamiliar. It’s not much more than a signed nonce with relying party domain name. It actually isn't that complicated. I don’t feel like the author is asking people to implement a protocol for them. They just maybe could have done some research into why WebAuthn has the complexities it does and presented a compelling argument in the readme for why they think they’re overkill or not necessary.
Time is just icky. I have a personal requirement/standard that I never depend on wall clocks in software I design. Timestamps can be used as an optimization, sure. But never as a fundamental component in the protocol or system.
I love the effort. Using a password for so much stuff these days just seems insane forcing me to remember a lot of passwords or be bogged down with a password manager.
Relying on google auth is too risky as google can just pull the carpet on any user. I do like a key management type solution with a backup factor like maybe emails and phones (2
of N kinda thing) if keys get lost. Google Authenticator (ironically!) would be a cool way to do it and keep sites siloed while using the same mechanism to log into each of them.
For many things a “scan this qr on your phone to log in” type mechanism linked to a key management app that calls an endpoint would be ideal - we tend to keep our phones working, charged and functioning in these post pandemic days. In Australia you can have your vax, covid check in, driving license, credit card of course, and various government vouchers all on the phone.
As much as I hate that for various 1984ish reasons, Im glad iPhone exists and is privacy centric, fairly robust and secure and with something like GA I feel quite safe logging into most sites that kind of way. Guess I am spoilt that an iPhone isn’t financially a stretch, i hope key chain type devices can be sold for $1 and stuck on your keyring with 12 words in a safe place for those
who cant afford this luxury. I have’t looked into it.
I could then share authentication for certain things like say amazon prime with trusted people. There is this middle ground between individual and corporate (families/startups/friendship groups) that would be catered for here.
As far as I can tell, there's no nonce (for replays) or counter (for stolen keys) in this scheme, both of which are fundamental to the security model that WebAuthn provides. There's also no formal sliding window for server times or key timeliness constraints.
In many regards, this scheme is no better than a strong password in terms of guarantees provided. In terms of UX, it's strictly worse than a password (and those are already pretty bad!) It's not a second factor at all, and thus isn't really an "alternative" to WebAuthn.
The idea may be, but then users will need to manage a key pair per site - and there’s less support for safely managing key pairs than there’s for passwords. How many people will actually do that, if the system doesn’t enforce it and how can the system enforce such a constraint?
I think if I'm being generous, the proposal is to eventually have a credential management ecosystem (with cross-device key syncing, and keys per origin) similar to WebAuthn.
However, if you do this, you rapidly start to discover some of the reasons behind WebAuthn's design choices. For example, to prevent phishing/replay/linkage, the "authenticator" (the thing managing the keys) has to know the origin/RP. And to allow hardware and software authenticators, you need some protocol like CTAP to abstract that out. And because some RPs want to require hardware-backed or biometric authenticators, you need an authenticator type. Etc, etc, etc.
If WebAuthn is hard to use, it's because we haven't build the right libraries and abstractions yet, and that indeed sucks. (Though I think we mostly have, and it's not that hard to use.)
But the criticism here of complexity--contrasted with the simplicity of a trivially broken, horribly unusable "proof of concept"--is a bit like someone who says "I can make a working demo of a car without power steering, antilock breaks, an entertainment unit, an ECU, a catalytic converter, or headlights--just four wheels and a two-stroke engine! Clearly all that complexity isn't needed!"
Having recently had to upgrade from u2f to webauthn, the complexity involved in getting webauthn right cannot be understated, especially when comparing it to something like OTP.
This flow seems simpler but more annoying for the end-user, right? They would have to generate the signed message themselves and then paste it into the browser. Whereas with webauthn you just touch your security key.
Ideally, we make WebAuthn easier to use (via libraries, identity providers, etc), rather than, you know, replacing it with something less secure than passwords.
As many have noted, this scheme is simple only because its only goal is to replace passwords, while seemingly ignoring even common security threats. Reminds me of TripleSec: https://news.ycombinator.com/item?id=9655245
I agree that the proposed solution has many flaws, and that PAKE is much more promising than any plain password-based scheme. As another commenter pointed out, OPAQUE is very interesting.
I just wish browsers natively supported that authentication scheme to further defend against phishing and other attacks where the javascript implementation can be replaced.
I feel like this demo is just a conversation starter and not a serious attempt at a login scheme. Like, signing and verifying using ed25519 is not hard and adding a CLI to do some crypto operations is not novel. If someone was implementing this they wouldn't shell out anyway since there is very good library support in <insert your language of choice>. The only thing WebAuthn needs to figure out is soft keys. Users don't want to enroll devices they want to log in with face/touch ID. The webauthn UX is broken and needs to be revamped so that users can choose a not technically perfect but still effective and better than passwords security posture where they reuse a soft webauthn key across devices. If whatever agent handling the soft key encrypts it at rest using device keys you’re effectively isomorphic to “key never leaves the device”.
It would be nice if hardware devices supported a non-resident key mode where you could give it an encrypted key and it would decrypt the key on device memory using an on-device key and then use the decrypted key for a crypto operation (encryption or signing). Then you could get a pretty much perfectly isomorphic experience with a non-resident key.
> Users don't want to enroll devices they want to log in with face/touch ID. The webauthn UX is broken and needs to be revamped so that users can choose a not technically perfect but still effective and better than passwords security posture where they reuse a soft webauthn key across devices.
I'm not sure I understand the problem here. WebAuthn is entirely agnostic about the physical factor: it can be a hardware key, a software implementation, TouchID/FaceID, or anything else. You can already use TouchID and FaceID on sites that use WebAuthn, and the UX is perfectly fine. You still have to enroll the device, but that's no different from the Face/TouchID UX in any other authentication context.
The problem is device enrollment. I am saying users want to use FaceID to log in like they currently use a password. They don't want to enroll devices with a service. Browsers don’t support software webauthn so the fact that it can happen is kinda moot. The existing browser-controlled implementation of the UX is what I’m complaining about. There’s this assumption in the security community that users need hardware backed crypto and soft keys with an agent in-between aren’t acceptable. I’m saying for most all users a soft-key setup backed by hardware primitives works just fine and is better than password auth but lamenting that it’s unlikely we’ll see support it because of platform control under the guise of better security.
Think of it this way, users would be better off with ssh style login instead of passwords but the “industry” seems to have skipped that step for consumers and gone straight to hardware keys.
- Make it effortless by using the FileSystem api to permanently point to a specific file on the device (until they move it)
- Use webcrypto to do the signing in-browser
- You can store a master private key that certifies new devices and can revoke old keys on the user's behalf or have them agree to generate one and store it off like (usb,etc... pw encrypted)
- what makes this better than using mutual TLS auth?
I've had similar ideas, too. But I just ended up using randomly generated email address and password per website, which does two things for me: resistance against password resets (noone knows what email to put into a password reset form) and credential stuffing.
Author's solution adds some auth re-play protection, compared to what I use. But that's very little additional protection against threats that would be hardly a problem in practice for me. I just use TLS to protect the auth interaction (so who's going to capture the credentials?).
Most importantly, passwords actually work almost everywhere.
- The suggestion of signing the timestamp means that any web site you log into with this can log in as you to any other web site you log in to
- Given that there's no namespacing of the signed messages, users can be easily phished into providing a response to a challenge posed by a different web site
- It's not obvious what advantages this has over using client cert authentication with TLS, and it has many downsides.