element-hq / element-meta

Shared/meta documentation and project artefacts for Element clients
66 stars 11 forks source link

2FA for logins #345

Closed ara4n closed 7 months ago

ara4n commented 7 years ago

When I log in (using a username/password or 3PID/password combo), we should give users the option to also require a two factor authentication (or multi-factor authentication) via other channels. Options are:

ara4n commented 7 years ago

To do a sensible job of this we should probably have a seperate 3PID verification service, as proposed in https://github.com/matrix-org/synapse/issues/1710.

Dasoren commented 7 years ago

Is there any update on the work for this or anything? Just wondering, because I would like 2FA for my account v.s just a username/password.

spacekitteh commented 7 years ago

Another crucial option would be via X.509, which would allow a large array of existing authentication methods to be used transparently.

spacekitteh commented 7 years ago

Relevant: https://github.com/matrix-org/olm/issues/5

lpar commented 7 years ago

RFC6238. Then people can use Google Authenticator, Authy, LastPass Authenticator, or pretty much any other standard 2FA app.

vsund commented 7 years ago

I'd really like to see Fido U2F like it's implemented by Yubico etc.

lrvick commented 6 years ago

I strongly second U2F. It is well tested, standard, built to withstand phishing attacks, and never exposes any secrets to system memory.

RyanSquared commented 6 years ago

Correct me if I'm wrong but wouldn't this require it to be implemented in a Matrix implementation rather than Riot? Matrix would have to support U2F, with Riot just passing on the authentication request.

lrvick commented 6 years ago

@RyanSquared It would need to be implemented in a both the UI and the authentication server IIRC.

RyanSquared commented 6 years ago

So if it needs to be implemented on a backend server as well, is there a relevant issue for U2F or other 2FA methods on a backend server (or for the protocol)?

singlerider commented 6 years ago

+1 for U2F

ara4n commented 6 years ago

this is starting to get more urgent with the advent of cryptocommunities and other security-focused communities embracing Matrix. need to check out U2F and how it compares to TOTP and friends.

pafcu commented 6 years ago

FYI, Firefox does not support U2F out of the box currently, but it was added to nightly last week, so should hopefully land at some point in the not too distant future.

RyanSquared commented 6 years ago

I'd say it's not "last week", based on this article: https://www.yubico.com/2017/09/firefox-nightly-enables-support-fido-u2f-security-keys/

vsund commented 6 years ago

Before Firefox 57 you can use an addon for Firefox to use U2F. I currently use U2F without any addons in Firefox 57 Beta. According to their release schedules, they release Firefox 57 on 2017-10-14 (https://wiki.mozilla.org/RapidRelease/Calendar). I had to enable it manually though.

alduder commented 6 years ago

U2F would be great, although it is so far supported by Firefox, Chrome and Opera only. A note on Firefox 57: Users must turn on the U2F switch (security.webauth.u2f) manually in the "about:config" settings.

jaekwon commented 6 years ago

We'll pay for this to be implemented by the end of January, just send us a service contract. On our end, we'll be requiring employees to use U2F. What's important is not that everyone has all the options for 2-factor available, but rather that at least we can tell our employees to adopt 1 trusted solution (like U2F).

ghost commented 6 years ago

Any updates on this?

brainbug89 commented 6 years ago

Still no 2FA? 🙄

jtl999 commented 6 years ago

In my mind, the authentication in Synapse should be easily "pluggable" so I could for example easily replace the standard username+password authentication with a custom plugin that takes a username+password+OTP as input.

I'm unsure of how such a thing should be supported on the client side, maybe the server should be able to say "Need a username+password+OTP" to the client and Riot should add such fields to the login form?

stevenaldinger commented 5 years ago

bump just to see if vector im took up @jaekwon on offering to sponsor if nothing else.

2 factor isn't optional at this point imo but I really like the potential of this project so hate to bail on the thing. will contribute myself eventually but reinventing-the-wheel with my personal time is too much for a project I'm just now considering adopting.

my software engineering company would take the contract work to implement it for sure though 😄

lrvick commented 5 years ago

@stevenaldinger I for one would gladly vote with my wallet towards such an effort if the matrix team lacks the resources to pursue this right now.

Can we get a bounty going for this somehow?

All the end to end encryption in the world is pointless if you can just phish someones login. This is still a major adoption blocker for any serious use cases.

stevenaldinger commented 5 years ago

let me scope it out a little bit and see what it really takes to make it a reality and I'll update. client is js which I'm really comfortable with and have worked with this sort of thing before, synapse/matrix server is python and I might make a mess lol (but with test coverage! 🤣), haven't looked into if they're both needing updates at this point or what the deal is. I'll try to lead the hunt this week though, I'm interested.

ronmckown commented 5 years ago

Not having 2FA with fido(2) on a security platform is plainly ridiculous. At least throw in TOTP or even Google oauth.

ptman commented 5 years ago

An important thing to remember when implementing 2FA: allow for multiple second factors. IIRC AWS didn't. Allow any number (?) of U2F tokens and TOTP app tokens, preferably individually named. And recovery codes.

jtl999 commented 5 years ago

An important thing to remember when implementing 2FA: allow for multiple second factors. IIRC AWS didn't. Allow any number (?) of U2F tokens and TOTP app tokens, preferably individually named. And recovery codes.

Agreed. And the method of 2FA shouldn't be forced on HS operators, i.e I should be able to choose TOTP or U2F depending on my use case by using a certain plugin (if possible).

sandys commented 5 years ago

I would also like to add that this feature be combined with auth using Google Auth/Identity - https://cloud.google.com/identity/ since that is the most popular and compliant (with necessary certifications) auth platform in general.

friedger commented 5 years ago

While planning this feature, you should also take into account webauthn (https://www.w3.org/TR/webauthn/)

jtagcat commented 5 years ago

I reached out to yubico, they politely rejected investing time, sending me this, what they already advertise on their web.

Braintelligence commented 4 years ago

I'm trying to decide on a communication platform and absolutely require 2fa. Is Matrix/Synapse/Riot capable of at least TOTP by now? If not, how does the roadmap look after all those announced commitments of time and money currently?

jtagcat commented 4 years ago

I'm trying to decide on a communication platform and absolutely require 2fa. Is Matrix/Synapse/Riot capable of at least TOTP by now? If not, how does the roadmap look after all those announced commitments of time and money currently?

Not yet implemented, though considering how fast security features are added, it's very likely that we will get multiple methods for 2fa. This is probably slower, since the feature does need to be supported on multiple platforms (client(s), server) and as a result in the matrix protocol.

ptman commented 4 years ago

One thing that is possible to do today is to use SAML and have your SAML IDP require 2FA

Braintelligence commented 4 years ago

@ptman So using Gluu with Matrix would be possible?

dngray commented 4 years ago

While planning this feature, you should also take into account webauthn (https://www.w3.org/TR/webauthn/)

One of the things I like about WebAuthn is:

The public key is not secret, because it is effectively useless without the corresponding private key. The fact that the server receives no secret has far-reaching implications for the security of users and organizations. Databases are no longer as attractive to hackers, because the public keys aren’t useful to them.

It seems WebAuthn is a even more secure option than even TOTP so I hope it doesn't overlooked just because everyone is already used to TOTP.

WebAuthn will have clear support in all browsers and that much is apparent being a part of the W3.

RyanSquared commented 4 years ago

It seems WebAuthn is a even more secure option than even TOTP so I hope it doesn't overlooked just because everyone is already used to TOTP.

TOTP carries it's own set of issues with it; my Yubikey, for example, has a system similar to TOTP which I have sent to IRC channels quite often by mistake. I don't use it because of this reason.

It's less easy to phish a WebAuthn challenge given IIRC it's attached to the domain name of the source of authentication - however, I do recall an issue with web access to the USB interface where the challenge can be spoofed. Assuming the only way to access the "device" (as some systems such as Chromebooks and Apple hardware have it builtin) is through an interface provided by the web browser, it then becomes a lot harder, I believe impossible, situation to phish the WebAuthn "device" with a valid challenge.

lpar commented 4 years ago

It doesn't matter if a TOTP code gets disclosed publicly, unless someone knows what account it corresponds to, has cracked your password for that account, and is ready to try logging in during the appropriate 1 minute window.

958826 is the current TOTP code for my Google account. That doesn't even let you deduce what the next one is, even assuming you could work out exactly when a given key was generated.

lrvick commented 4 years ago

There seem to be some misconceptions in this thread that tend to pop up every time 2FA comes up on many tickets I track...

The point of 2FA is to make account compromise harder.

The most common way accounts are compromised are:

  1. phishing
  2. password cracking via database dumps
  3. brute force cracking via a web interface

Working in security and infrastructure teams for most of my career I have seen a lot of vector-im/element-web#1, much less of vector-im/element-web#2, and almost never vector-im/element-web#3 anymore unless the target is a complete idiot that does not lock out an account for too many attempts from a given IP.

Why SMS sucks

You can do a SIM Port attack or simply use a cheap SDR and a 2TB set of A/51 rainbow tables to dump codes out of the air in the US where carriers are forced to honor 2G retransmission requests.

It fails at reliably closing attack surfaces vector-im/element-web#1 and vector-im/element-web#2

Why Yubico OTP sucks

Yubico-OTP is just AES challenge/response against a central Yubico-owned server which must share the secret, which I can tell you does -not- have 100% uptime and results in global account lockouts when it is down.

You can opt to host that server yourself, but then you end up with the AES secret exposed in the same application you are hoping does not get databse dumped.

Worse the Yubico OTP codes are -not- time based like TOTP and are in fact just a counter. This means you can capture one and use it hours later as long as a user has not logged in with a fresh one since.

It fails at vector-im/element-web#1 and vector-im/element-web#2 as well.

Yubikeys are a -solid- tool I document the use of extensively, but this is a feature that should be deprecated universally.

Why TOTP sucks

TOTP fails at vector-im/element-web#1 because a phishing system prepared to automatically make immediate use of a password can simply do the same with a TOTP secret within a 30 second window without much fuss, and I have seen this happen in the wild.

TOTP normally fails at vector-im/element-web#2 because it relies on a shared secret that is combined with the current time, and the secret must be stored server side and be readily accessible in plain text. Unless someone happens to implement TOTP validation server-side in an HSM, which almost no one does, then an attacker with datbase access likely has access to the TOTP secrets as well.

TOTP is simply an awful design for 2FA that fails at the two most common forms of account compromise.

As an aside, Google Authenticator, the most popular implementation, just sores the TOTP secret in plain text in an sqlite database on both iOS and Android. I audited the code of both myself.

TOTP ALSO fails at vector-im/element-web#1 and vector-im/element-web#2 (Does no one actually do threat profiling before they design these stupid protocols?!)

Why WebAuthn is awesome

It succeeds at threat vector-im/element-web#1 because the browser supplies the current domain name in your URL bar to your personal HSM (yubikey or otherwise) as part of the challenge/response flow. A malicious actor can't override this without the ability to manipulate core browser functionality not reachable by javascript (and if they can you have bigger problems).

It succeeds at vector-im/element-web#2 because the only thing the server needs to track is a public key, not unlike an authorized_keys file if you are familiar with ssh.

Conclusion

WebAuthn is the only responsible form of 2FA worth implementing today, and we should be forcing users to use it on every service we can. I for one am working very hard to get SMS/TOTP/yubico-otp all deprecated and replaced with webauthn based solutions at every company I support.

Even if someone does not have a personal HSM like a Yubikey there are software implementations available which still account for the most common forms of account compromise better than any alternatives like TOTP.

The lack of native WebAuthn support on Matrix is perhaps the biggest remaining black eye on the platform next to cross-signing which is already in progress.

Hopefully that argument was coherent but I am happy to answer any questions :)

richvdh commented 4 years ago

cf https://github.com/matrix-org/matrix-doc/pull/1998

jean-io commented 4 years ago

@lrvick there is a flaw in your use case: password cracking via database dumps should be spited in two:

  1. password cracking from your database dumps
  2. password cracking from other website database dumps

In case 1, you are totally right since shared secret for OTP is compromised.

In case 2, since your OTP shared secret is (by definition) not compromised, people who has a unique password for all theirs accounts are safe.

I do agree that WebAuthn is better but cost are higher on setup.

joepie91 commented 4 years ago

@irvick

TOTP normally fails at vector-im/element-web#2 because it relies on a shared secret that is combined with the current time, and the secret must be stored server side and be readily accessible in plain text. Unless someone happens to implement TOTP validation server-side in an HSM, which almost no one does, then an attacker with datbase access likely has access to the TOTP secrets as well.

Nitpick: TOTP secrets are normally site-specific, no? So they don't affect the threat model of "someone cracks a password from your database to use on another site" - which is why we hash passwords, because your database has already been compromised anyway and so for that the attacker doesn't need to crack any passwords... the value is just in reusing the password elsewhere.

I do agree with your conclusion that WebAuthn is the way forward.

RyanSquared commented 4 years ago

Nitpick: TOTP secrets are normally site-specific, no?

That should be correct. Section 3.R5 of RFC 6238 specifies that "there MUST be a unique secret (key) for each prover," where I believe a "prover" in this case is equivalent to a "site".

So they don't affect the threat model of "someone cracks a password from your database to use on another site"

But that's not what this was referencing. This referenced the following section:

an attacker with datbase access likely has access to the TOTP secrets as well.

lrvick's rule 2 states the following:

password cracking via database dumps

This does not specify that it has to be a third party. I believe this was intended to be referencing the same database you'll be accessing with your next connection. This is solved by WebAuthn by having the secret key stored by only yourself rather than by the server.

If you have both a database leak of the system you're attacking, and know the password you're trying to use, it then becomes trivial. The only way to prevent against this, if you're using TOTP and are aware of the attack, is to then invalidate every TOTP secret and use some other kind of mechanism to reset them.

esackbauer commented 4 years ago

Well I am using the LDAP proxy of Duo.com for 2FA. Works great.

caglar1 commented 4 years ago

has anyone tried to implement verifykit https://verifykit.com/en/ it is free for 10.000 monthly verification I think, it is the cheapest and convenient solution for 2fa

esackbauer commented 4 years ago

has anyone tried to implement verifykit https://verifykit.com/en/ it is free for 10.000 monthly verification I think, it is the cheapest and convenient solution for 2fa

Verification only via telegram or whatsapp... And only 1 app. Duo is free for up to 10 users, and you can have multiple apps protected. Verification via Duo app, which also replaces Google Authenticator.

caglar1 commented 4 years ago

has anyone tried to implement verifykit https://verifykit.com/en/ it is free for 10.000 monthly verification I think, it is the cheapest and convenient solution for 2fa

Verification only via telegram or whatsapp... And only 1 app. Duo is free for up to 10 users, and you can have multiple apps protected. Verification via Duo app, which also replaces Google Authenticator.

Yes you right, But 10 free user is too limited, There will be about 1000 users on my matrix server, so Duo would be so expensive for me

ptman commented 4 years ago

To repeat myself: Use synapse SAML support with a SAML IdP that can require 2FA, like Keycloak (free).

thibaultmol commented 4 years ago

Added a 30$ bounty on Bountysource for this feature request to be solved! Bountysource

epicfacethe3rd commented 4 years ago

might give this a shot. commenting to bookmark it for myself

rugk commented 3 years ago

Wtf, Matrix, what happened to you? People would have paid you for this feature?

We'll pay for this to be implemented by the end of January, just send us a service contract.

https://github.com/vector-im/riot-web/issues/2772#issuecomment-352947462

Also the French goverment is a client of yours that may very much appreciate such a feature…

ptman commented 3 years ago

Also the French goverment is a client of yours that may very much appreciate such a feature…

They most likely use some kind of SSO (SAML? CAS? OpenID Connect?) that handles 2FA on another layer. Like keycloak. But I would not recommend SAML as you can now use OpenIDC.