hashicorp / vault

A tool for secrets management, encryption as a service, and privileged access management
https://www.vaultproject.io/
Other
30.51k stars 4.14k forks source link

Add support for Yubikey as auth backend #131

Open radeksimko opened 9 years ago

radeksimko commented 9 years ago

https://www.vaultproject.io/docs/auth/index.html

https://www.yubico.com/faq/yubikey/

Yubikey is slowly becoming quite popular when it comes to HW solution to 2FA and more importantly it's quite easy to use it.

I'm not sure if the integration should actually be 1FA (generated token from Yubikey only) or extra factor to existing auth backends. Eventually it can be both?

EDIT: Its currently possible with a 3rd party plugin https://github.com/bruj0/vault-plugin-auth-u2f

ketzacoatl commented 9 years ago

++

carldanley commented 9 years ago

:+1:

sherzberg commented 9 years ago

This would be awesome to use as unseal tokens as well. No clue if that would work the the current Shamir keys, but still a neat idea for operator unsealing.

GonZo commented 9 years ago

:+1:

CharlieSu commented 8 years ago

:+1:

nicr9 commented 8 years ago

:+1:

GonZo commented 8 years ago

:+1:

eedgar commented 8 years ago

:+1:

peterloron commented 8 years ago

:+1:

bscott commented 8 years ago

:+1:

klauern commented 8 years ago

I am curious about how this would work. I know that with the recent GitHub support for Yubikeys, this would need to support the U2F protocol, which I can't find any mention of it being supported anywhere other than Google Chrome. Are there libraries that integrate with the USB device so you could get the token?

nicr9 commented 8 years ago

@klauern I started looking into this a while ago. I've been fleshing out a prototype using GeertJohan/yubigo.

I have the verification logic done but I'm looking for a neat way to associate policies with particular yubikeys/users. Each yubikey has a 12 digit identifier that's easy to derive from a OTP but it's not a particularly intuitive way to refer to a user.

klauern commented 8 years ago

I do think I ran across your repo when I was doing research on this earlier, but I think I was more confused about what you would need to write to integrate with Vault.

I was looking into this yesterday, and I think what I am trying to understand is how to interface with the Yubikey itself. This StackOverflow question seemed to ask the right question, but it wasn't until I started reading the comments before I saw that what I was looking for was a Host Client Library, of which Yubico links to two: https://developers.yubico.com/Software_Projects/FIDO_U2F/U2F_Host_Libraries/

So my next thought would be, if you want to add a U2F Yubikey as a backend in Vault, you're assuming that you'll get the token through some other means, most likely Google Chrome. I suppose that's possible, as I do that more-or-less with the Google Cloud SDK, but if you could natively support that from the command-line when you call vault itself, you'd more likely want to integrate with something like the libu2f-host C library.

Now, I'm honestly hoping I'm completely off-base and clueless, but this is all new to me, so I expect I'm not alone in trying to understand how it would work.

JensRantil commented 8 years ago

@klauern There are two different Yubikey modes that could be supported:

The former has a more complex authentication methodology and requires a driver which currently mostly is useful in Chrome. For example, U2F wouldn't be possible to use from curl. The latter (OTP) is much easier to implement, but at the expense that a MITM (say, a keylogger) could collect the password. However, replay attacks aren't possible.

I suggest you start with supporting the OTP before digging into U2F. I assume most Vault users aren't communicating with Vault through Chrome, right?

klauern commented 8 years ago

This is where I think I'm limited a bit. I own a FIDO U2F Security Key, which only supports U2F. I suppose if Vault were to support YubiKeys, OTP would probably be the preference, but would limit those people who own the U2F-only version. Maybe that's why I am having such trouble, as I can't simply press the button to generate a token like you can in an OTP-mode enabled version.

JensRantil commented 8 years ago

@klauern I see. I'm sure you already know this, but you can order an OTP-supported key for $25 from here. If that's too much, you could always try opening up a support ticket and see if they'd be willing to sponsor with a key or maybe @sherzberg @GonZo @CharlieSu @nicr9 @eedgar @peterloron @ketzacoatl @bscott is willing to sponsor you with one?

CharlieSu commented 8 years ago

There is another mode that could also be supported that doesn't require interfacing with any external services.

https://www.yubico.com/products/services-software/personalization-tools/challenge-response/

HMAC-SHA1 secrets for each key could be stored in the vault and used to authenticate a user. You'd send a challenge to the device and know what the expected response would be.

I'd be more than happy to sponsor someone if it speeds things up. Send me your address and promise you'll actively work on it and I'll ship one out.

https://keybase.io/charlessullivan

jefferai commented 8 years ago

To @CharlieSu 's point, it may make sense for someone interested in seeing this through to reality to come up with a design document that can be reviewed. It would be nice to get some kind of community consensus as to what the desired behavior is before implementing something that may not meet those needs.

There seem to be some basic questions that simply aren't answered yet, such as whether Vault should be responsible for implementing the YubiKey protocol and validating tokens, or simply holding a mapping from tokens to policies and passing through the validation process to Yubico's servers. Not to mention UDF vs. OTP vs. HMAC-SHA1.

asemt commented 8 years ago

:+1:

cvle commented 8 years ago

:+1:

jfuechsl commented 8 years ago

:+1:

kitotik commented 8 years ago

👍 Cool to see the discussions on U2F.

We've been experimenting automating yubikey provisioning and authentication with the TLS backend in Vault using pkcs11 with some success.

rdark commented 8 years ago

@kitotik do you have any more info on that? I'm considering using some of the new Yubikeys with PIV support for authenticating users using client certs stored on the key.

skyzyx commented 8 years ago

:+1:

oppegard commented 8 years ago

:+1:

z00m1n commented 8 years ago

:+1:

winpat commented 8 years ago

:+1:

dnascimento commented 7 years ago

What are the disadvantages of implementing the U2F support?

JensRantil commented 7 years ago

U2F essentially requires a webbrowser to authenticate.

fproulx-pbox commented 7 years ago

👍 for unsealing with shamir among multiple Yubikeys!!!

JensRantil commented 7 years ago

This would be awesome to use as unseal tokens as well. No clue if that would work the the current Shamir keys, but still a neat idea for operator unsealing.

I'm pretty sure this is doable even today. Yubikeys supports storing a hardcoded string. Essentially, you could simply store the unseal token on the Yubikey. Note that there's no password to access that unseal token. Someone stealing a Yubikey essentially has plaintext access to the unseal key.

Also, modern Yubikeys has PGP support. Maybe someone else can clarify if the unsealing with PGP can be done using a Yubikey?

jdelic commented 7 years ago

I'm pretty sure this is doable even today. Yubikeys supports storing a hardcoded string.

That's definitely true, but kind of a waste considering the cost of a Yubikey :). Still more secure than a post-it sticky or a text file, but less secure than a good password manager.

I think a better solution is provisioning PGP keys on Yubikeys and then encrypting the Shamir keys for those PGP keys. This gets you full multi platform support with secure passphrases.

For authentication you can use the PIV applet on modern Yubikeys to authenticate against the cert auth backend.

So I don't think that's Vault needs any special support for Yubikeys, it already integrates quite well. It might be worthwhile to look into supporting the YubiHSM for additional security though (storing the encryption keys in a tamper proof module instead of RAM).

JensRantil commented 7 years ago

I propose we stay focused here and focus on Yubikeys as an authentication backend in this issue. AFAIK, using Yubikeys for unsealing I think is/should be a separate issue.

gblmarquez commented 7 years ago

👍

h4m24 commented 7 years ago

👍

markojak commented 7 years ago

We all use Yubikeys for logins and management and using this would be a great MFA and would encourage us to use vault

mjungsbluth commented 6 years ago

For authentication you can use the PIV applet on modern Yubikeys to authenticate against the cert auth backend.

@jdelic could you elaborate on the how? I assume curl with OpenSSL + engine_pkcs11 + p11-kit + opensc? At least on OS X this is not straight forward as the bundled curl as well as Homebrews curl are by default built against darwinssl for good reasons (use the system keychain) which prohibits using the yubikey's piv applet (at least I found no way to reference the key on the yubikey) on macOS Sierra

wiktor-k commented 6 years ago

Homebrews curl are by default built against darwinssl for good reasons (use the system keychain) which prohibits using the yubikey's piv applet (at least I found no way to reference the key on the yubikey) on macOS Sierra

Interesting because on windows curl built with WinSSL (Secure Channel) automatically uses certs in Certificate Store and Windows adds Yubikey PIV certs when the key is inserted in the USB port. So curl with WinSSL is all that's needed to use e.g. client certificates.

Are you sure MacOS does not add Yubikey PIV certs to Keychain?

OH, now I see Yubico documentation mentions OpenSC so you're right, curl with darwinssl would not work: https://developers.yubico.com/PIV/Guides/Mac_code_signing.html

mjungsbluth commented 6 years ago

I had a look at curl's sources and everything seemed to support keys on a smart card, so I dug deeper and alas, it actually seems to work (at least curl is able to load the certificate + key). It seems the default "Yubikey PIV Authentication" key doesn't work (maybe because it ECDSA and not RSA).

curl selects the identity based on the certificate's subject's commonName.

To list the usable identities you can use macOS Sierra's security tool (if it is listed but not valid, there most likely is a missing trust)

> security find-identity -p ssl-client

> curl -E "<commonName>" https://targeturl

rm-rf-etc commented 5 years ago

Seems like Yubikey is important. Vault is advertised as better than Dropbox for storing secrets but Dropbox supports Yubikey.

limnick commented 5 years ago

Throwing in my +1 for this now 3 year old request!

martin-sucha commented 5 years ago

@gfraetis a possible workaround how you can use yubikeys with vault is to setup an OpenID Connect auth provider instead that allows to enforce 2FA with yubikey via U2F/Webauthn and let the yubikey be checked as part of login to that provider in web browser. https://www.vaultproject.io/docs/auth/jwt_oidc_providers.html

gfraetis commented 5 years ago

@gfraetis a possible workaround how you can use yubikeys with vault is to setup an OpenID Connect auth provider instead that allows to enforce 2FA with yubikey via U2F/Webauthn and let the yubikey be checked as part of login to that provider in web browser. https://www.vaultproject.io/docs/auth/jwt_oidc_providers.html

Awesome thank you. My google-fu let me down on this one :) Thanks!

viralpoetry commented 4 years ago

You can authenticate to Vault by leveraging pkcs11 support in curl with Vault's TLS certificates auth method. Step by step guide: https://www.malgregator.com/post/vault-authentication-with-yubikey/

aphorise commented 3 years ago

Unfortunately I've not yet got my Yubikey - however I wondering if support for this may already be in place via HSM?

Aside from TLS / Certificate based authentication with Vault involving Yubikey that's well covered in the article above (by Arthur Rainwater) - I'm wondering if anyone has actually tried something like:

seal "pkcs11" {
        lib             = "/usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so"
        slot            = "1969300112"
        pin             = "1234"
        key_label       = "hsm:v1:vault-yubi"
        hmac_key_label  = "hsm:v1:vault-yubi-hmac"
        generate_key    = "true"
        #mechanism      = "0x1087"  # // correct value may be needed
        #hmac_mechanism = "0x0251"  # // correct value may be needed
}

Any other pre-Vault / OS configuration and initialisation would be via CLI pkcs11-tool, p11tool, ykman, yubico-piv-tool or any other manufacture specific utility that's provided when dealing with HSM devices typically.

Is this issue still applicable?

bruj0 commented 3 years ago

I finished the implementation of such an auth backend and you can test it at https://github.com/bruj0/vault-plugin-auth-u2f

Ramblurr commented 3 years ago

I'm wondering if anyone has actually tried something like:

Using a OpenPGP smartcard (such as a yubikey) as a way to auto-unseal vault would be great indeed!

viralpoetry commented 3 years ago

@Ramblurr as the most smartcards those days are based on pkcs11 and are basically small HSMs, I believe it's already possible, but only with an enterprise offering.

anoncam commented 3 years ago

I am using Vault Enterprise 1.6.1 and I would like to use Yubikey as an auth backend. It would be sweet to do this without having to use a pkcs11 seal

bruj0 commented 3 years ago

I am using Vault Enterprise 1.6.1 and I would like to use Yubikey as an auth backend. It would be sweet to do this without having to use a pkcs11 seal

You can do it: https://github.com/bruj0/vault-plugin-auth-u2f