- 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.
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.
"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.