Q1. What is the problem that you are trying to solve?
Some organizations requires users to use multiple factor authentication to log in in systems with restricted level of information.
Q2 - Who is impacted?
Everybody.
Q3 - Why is it important and/or urgent?
Security will be improved. It is considered a good practice and therefore passbolt should support it.
Q4 - What is your proposed solution? (optional)
Support FIDO U2F token such as Ubikeys.
Hi, i really like that idea,for Q2 2018 there´s a 2nd factor auth by sending additional code on the roadmap. maybe you know i, but maybe not… there´s a product called privacyidea (https://www.privacyidea.org/) which offers a lot of 2nd factor tokens. HOTP, TOTP, U2F, Yubikey… sending a bunch of Codes on Paper, using “FreeOTP” (on Android) additionally and if configured by the admin… the user itself can take some of the second factors. e.g. a yubikey is allowed an a user has one… he can just add that on his own to his account. the admin gives some basic settings for that, e.g. lenght of the OTP-Code, but rest if basicly allowed is up to the user. if he likes paper, just take paper as a factor, if he likes e-mail, lets take e-mail. But one thing is maybe really interessting for you… a 4-eyes token. So maybe thats an idea to have some actions for the admin but secured by 4 eyes - e.g. “user has 1 shared password, but is sole owner”
There are already several plugins for other PHP applications like Wordpress, TYPO3, ownCloud, dokuwiki…
If you can point me to your authentication process and if it provides some kind of plugin mechanism adding 2FA via privacyIDEA will be fairly simple.
So instead of adding U2F explicitly I would recommend to add an API for different 2FA scenarios, one of them being U2F.
Not really. The backend server can still refuse access, even if the the user presents a valid passphrase.
The /validate/check endpoint is for validating One Time Passwords only; U2F is a cryptographic challenge-response. Furthermore, U2F tokens don’t have serial numbers so you first have to identify the user from username/password, then send the challenge.
PrivacyIDEA says it supports U2F, although it has only minimal documentation, My suspicion is that it only works if you are using privacyIDEA as an identity provider: that is, you use U2F to identify yourself to privacyIDEA, and then it gives you a SAML or OpenID Connect token to identify you to the end application.
Enabling passbolt to use third-party identity providers would be a very big change.
I’m not saying that’s a bad thing, quite the opposite: for example, it would allow passbolt to authenticate directly against an identity provider like Google, Github or Office365. To do this today, I put passbolt behind an Apache reverse proxy running mod_auth_openidc (details posted in another thread).
It’s just think that this is a rather bigger change than you expect.
Integrating U2F authentication directly into passbolt would probably be simpler, both to code and for sites to deploy, as passbolt would remain self-contained and standalone. But it wouldn’t give you the benefit of using third-party identity providers like those I listed.
In fact the /validate/check endpoint is for validating not only OTP but also Challenge Response tokens like SMS, EMail and U2F.
The thing is, you have to trigger the challenge first. Usually you do this like: User sents his username and static password to this API and privacyIDEA starts the challenge response process. The U2F token is also a challenge response token, just like you said: ask for username/password and then send the challenge. This is what privacyIDEA exactly does in the /validate/check API.
No. You can use U2F with privacyIDEA simply with the privacyIDEA REST API.
See the documentation mentioned above. There is an example implementation:
and the privacyIDEA owncloud App uses the u2f implementation only with the privacyIDEA server:
The documentation of privacyIDEA does not explain U2F in detail. Imho this is out of scope for the privacyIDEA docs to do so. So one needs to dig through the u2f docs to get an understanding, anyways.
And one thing is right, too. You can not add u2f to an application without doing some more changes to the application. It is more complicated than adding OTP. E.g. you need to add javascript stuff and so on.
Managing U2F tokens in privacyIDEA lets you:
enroll u2f tokens within privacyIDEA, so you do not need to implement this in your own application
combine u2f tokens, emails, sms, apps and push button tokens in one place.
Integrating directly into passbolt would be more effort to implement, as I pointed out.
But you are right: It would be simply to deploy, but not that flexible
Well, after all it is just some pointers I am providing.
User sents his username and static password to this API and privacyIDEA starts the challenge response process. The U2F token is also a challenge response token, just like you said: ask for username/password and then send the challenge. This is what privacyIDEA exactly does in the /validate/check API.
It’s unclear to me why the username needs to be supplied in the second request, if the two are linked by a transaction_id. What stops me putting “username=myboss” in the second POST? Is it the PrivacyIDEA client’s responsibility to preserve the username securely between requests? These details matter.
The documentation of privacyIDEA does not explain U2F in detail. Imho this is out of scope for the privacyIDEA docs to do so. So one needs to dig through the u2f docs to get an understanding, anyways.
I’ve got a reasonable understanding of U2F - I’ve gone so far as to get it working with PAM over ssh. (Aside: it’s a pain, because you need need to paste the challenge into a client app and paste the response back into the ssh login; but it does actually work!)
In PAM you’re doing authentication within the context of an authentication session, so the semantics are clear. With a pair of stateless REST operations, not so much.
And one thing is right, too. You can not add u2f to an application without doing some more changes to the application. It is more complicated than adding OTP. E.g. you need to add javascript stuff and so on.
Sure. A couple of other thoughts:
From the doc, it looks like you are forced to use a token PIN with PrivacyIDEA, even though that would not be necessary for passbolt since the user has already securely logged in using their PGP key. That’s a layer of user inconvenience.
You would have a separate python app to install. I did a quick search and it looks like there are existing PHP libraries for U2F which could be embedded directly.
You always need to add a username. privacyIDEA will only work with the tokens for this user.
So if you enter “myboss” in the second request, it will not find the tokens of myboss and it will see, that there is no matching transaction_id for these tokens.
You need a PIN to be able to trigger the challenge. Otherwise you could spam a user with challenges.
With python App you mean privacyIDEA server? That is right.
Besides you do not need any python module.
The privacyIDEA server could run as a central server in you network and passbolt like the VPN, like SSH and so an are authenticating against privacyIDEA.
But for a single instance this of course is far more effort! (But who only runs one service?
If passbolt_api didn’t challenge the user until they have performed the PGP-authenticated login, then the user’s PGP private key + passphrase performs the role of the PIN. Having another PIN wouldn’t add any security, and would be an annoyance.
I’ve personally purchased yubikeys for u2f. These things are amazing and a must have for anyone serious about security. I’m just a personal user and I don’t have any need for this in a business sense, but I do have a lot of gear and places I login to and it gets difficult to remember all the passwords. I refuse to use lastpass. I want something self hosted. this looks ideal and very promising. UI is excellent very familiar (Very gmail/google drive) I’d love to have U2F compat!
Must have: this is critical for me to have this
Should have: this is important for me to have this
Could have: this could be nice to have
Won’t have: we should not schedule this (explain why)
