rust-u2f
OpenSK
Our great sponsors
rust-u2f | OpenSK | |
---|---|---|
8 | 12 | |
285 | 2,897 | |
- | 2.5% | |
5.4 | 6.3 | |
3 months ago | 22 days ago | |
Rust | Rust | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
rust-u2f
-
Software U2F with Fingerprint (On Linux)
This project aims to support U2F / FIDO2 using fingerprint reader on Linux (via libfprint). The goal is to have the same user experience with 2FA using Windows Hello.
This project is based on https://github.com/danstiner/rust-u2f with minor modification (see my fork: https://github.com/ngxson/rust-u2f-pkexec)
Link to the project: https://github.com/ngxson/softu2f-fprintd-docker
- The mechanics of a sophisticated phishing scam and how we stopped it
-
Apple, Google, and Microsoft commit to expanded support for FIDO standard
I've considered adding FIDO2 support to the software-only U2F token I wrote ( https://github.com/danstiner/rust-u2f). It's a fair bit of work though, and I am not sure how comfortable I am with passwordless login unless the keys are kept purely in hardware such as a TPM.
That said, my reading of this post is that FIDO2 support will get built into Chromium directly, which is itself open source. Or if you do want a hardware key but running open software, I'd definitely recommend https://solokeys.com/, I've been following them for a long time.
Also there was some related discussion on this same article last week: https://news.ycombinator.com/item?id=31274677
- Apple/Google/Microsoft to accelerate rollout of passwordless sign‑in standard
- Howdy – Windows Hello style facial authentication for Linux
-
Google is going to ban “less secure sign in method”
On a Workspace account you only need U2F token emulator (https://github.com/danstiner/rust-u2f woks fine) and thenn you can setup u2f first and add normal TOTP in second step. But u2f must stay there. I don't have a personal account to try if it works the same.
-
Ask HN: Is Google phasing out Authenticator/TOTP?
As it becomes easier to emulate hardware tokens[1], Google may start limiting which ones it accepts. I believe they can use attestation keys to do that.
This is just a softer layer of security to slow down less sophisticated mass signup attempts.
They may very well eventually phase out TOTP, under the justification that it is not as secure, but I would be shocked if they ever retire the highly insecure SMS verification.
TOTP is really easy to implement, and adds a ton of value. I have a oneliner that takes a screenshot, extracts the QR code with zbarimg, and adds it to my pass[2] password database, which then hooks back into my browser. I use it whenever it is available because it is so low effort.
[1]: https://github.com/danstiner/rust-u2f
-
Does 2FA actually prevent phishing?
GitHub has a couple of others listed, but I have not tested them personally: Example https://github.com/danstiner/rust-u2f
OpenSK
- OpenSK – open-source implementation for security keys written in Rust
-
Yubico is merging with ACQ Bure and intends to go public
https://github.com/google/OpenSK works, it runs on something like this $15 board. Could do with a case though.
https://www.nordicsemi.com/About-us/BuyOnline?search_token=n...
- How to Yubikey: A Configuration Cheatsheet
- Make Custom Yubikey
-
WebAuthn, and Only WebAuthn
There are a huge number of other vendors supporting Webauthn apart from Yubikey. (From the top of my head Nitrokey, Solo, Tomu, Mooltipass, Ledger, Trezor, Google Titan, OnlyKey, Token2).
You could also use the system TPM (https://github.com/psanford/tpm-fido).
A brief search didn't yield any FIDO2 software-only solutions for Linux, but I see no reason why in principle you couldn't implement it (perhaps interfacing https://github.com/google/OpenSK through hidg - similar projects do exist for U2F).
-
Apple, Google, and Microsoft commit to expanded support for FIDO standard
Cloudflare does, using a security key not found in the FIDO Metadata Service will unfortunately not work. This precludes the use of any hacker-friendly solution (making your own).
> Supported: All security keys found in the FIDO Metadata Service 3.0, unless they have been revoked for security reasons.
https://support.cloudflare.com/hc/en-us/articles/44068890480...
Attestation keys, as they're currently used, aren't very "privacy friendly" and it's much worse for those who wish to create their own key.
> Usually, the attestation private key is shared between a batch of at least 100,000 security keys of the same model. If you build your own OpenSK, your private key is unique to you. This makes you identifiable across registrations: Two websites could collaborate to track if registrations were attested with the same key material. If you use OpenSK beyond experimentation, please consider carefully if you want to take this privacy risk.
https://github.com/google/OpenSK/blob/f2496a8e6d71a4e8388849...
-
Phone May Soon Replace Many of Your Passwords
There are a number of FOSS solutions.
- https://github.com/google/OpenSK <- DIY solution
- https://solokeys.com/
- https://www.nitrokey.com/
The issue with any FOSS solution is that FIDO requires an attestation private key which is shared between a batch of at least 100,000 security keys. Using a DIY or cli app (application running on the host) solution will likely mean you'll be generating that private key yourself, this makes you identifiable across registrations.
- Apple/Google/Microsoft to accelerate rollout of passwordless sign‑in standard
-
Login with a Public Ed25519 Key
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.
- I read the federal government’s Zero-Trust Memo so you don’t have to
What are some alternatives?
secretive - Store SSH keys in the Secure Enclave
nrf52-u2f - An Open-Source FIDO U2F implementation on nRF52 SoC
Coze - Coze is a cryptographic JSON messaging specification.
keyberon - A rust crate to create a pure rust keyboard firmware.
wasmer - 🚀 The leading Wasm Runtime supporting WASIX, WASI and Emscripten
solo1 - Solo 1 firmware in C
libfido2 - Provides library functionality for FIDO2, including communication with a device over USB or NFC.
CozeJS - Coze Javascript - cryptographic JSON messaging specification
smoltcp - a smol tcp/ip stack
tokei - Count your code, quickly.
python-fido2 - Provides library functionality for FIDO 2.0, including communication with a device over USB.