Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Security] Password should always show TOTP #872

Open
SimplyCorbett opened this issue Apr 20, 2020 · 13 comments
Open

[Security] Password should always show TOTP #872

SimplyCorbett opened this issue Apr 20, 2020 · 13 comments

Comments

@SimplyCorbett
Copy link

SimplyCorbett commented Apr 20, 2020

When using TOTP the user password should -always- go to the TOTP app, even if wrong.

It should not say "wrong password" prior to the TOTP app for security reasons. This app should not let the attacker know they have the correct password!

Current behavior:

Attempt login - wrong password - error
Attempt login - correct password - totp - error | This lets the attacker know the password is correct!

Expected behavior:

Attempt login - wrong/right password - TOTP login.

Error message:

"Either your password or TOTP code is wrong!"

@ChristophWurst
Copy link
Member

Then you would leak whether a user has 2FA enabled or not and which 2FA options are active, right? See nextcloud/server#5935 for the old discussion.

@SimplyCorbett
Copy link
Author

Then you would leak whether a user has 2FA enabled or not and which 2FA options are active, right? See nextcloud/server#5935 for the old discussion.

This would be preferable over the current setup.

@SimplyCorbett
Copy link
Author

@ChristophWurst From a security perspective by maintaining plausible deniability when it comes to correct passwords it becomes hard for someone with say a password leak to verify the account ownership and therefore prevents a social engineering attack.

Sure, if the username is unique it might be possible. However, if the attacker cannot verify account ownership by either password or email (and email recovery does not list the username on nextcloud, aside from in the actual email) a social engineering attempt becomes rather hard.

For a personal nextcloud instance this is not a concern. For a shared provider (hetzner as an example) this does become a concern.

@ChristophWurst
Copy link
Member

cc @rullzer @nickvergessen

@nickvergessen
Copy link
Member

Hmm i guess the lost of available 2fa providers is leaked already. So it's a question of user experience that we would show all 2fa methods enabled on the server and the user would have to guess which one they configured already?

@ChristophWurst
Copy link
Member

ChristophWurst commented Apr 27, 2020

Hmm i guess the lost of available 2fa providers is leaked already.

where? That is only the case if you know the password.

So it's a question of user experience that we would show all 2fa methods enabled on the server and the user would have to guess which one they configured already?

won't work. like for u2f you need a registration on the server. we can't just pretend there is one unless we go for security by obscurity.

@nickvergessen
Copy link
Member

By available I meant instance wide. They are leaked by available translation and JS files

@ChristophWurst
Copy link
Member

but that does not tell you anything about the 2fa state of user

@rullzer
Copy link
Member

rullzer commented Apr 27, 2020

I don't see the issue here. Sure if your credentials leak they could login. True. But then they still need your second factor.

I also did a quick check. Neither Google nor github do this. And i must say I would also find it very weird UX. Because when you get the error you wouldn't know what is wrong.

And the pointed out mess of what provides to show.

@SimplyCorbett
Copy link
Author

SimplyCorbett commented Apr 27, 2020

Right, I'm more worried about social engineering.

Let's say you know your target uses x username. If x username is a common username then the attacker wouldn't know if it's your account or not unless the password matched.

Since we use 2FA it's impossible for them to gain access to the account... however since they have now identified the account is owned by the target they can use the rest of the details in the leaked database and use social engineering to gain access.

Not a problem for personal nextclouds but definitely a problem for shared hosts. Google and github have this nailed down. Regular hosts might fall for this.

I know this is not a common method or attack vector but it has happened in the past. And it doesn't necessarily have to be a targeted attack. Just search for random accounts in the database until you get a hit.


Since nextcloud is used in personal/private organizations including medical it would be a really good idea to obfuscate that the password is correct to close this attack vector.

@nickvergessen
Copy link
Member

So I don't fully understand what you are worried about.

Someone has the username + password from another hack/leak already. And they can now "verify" that a user on a given nextcloud is the same user as their "target"?

@SimplyCorbett
Copy link
Author

SimplyCorbett commented Apr 28, 2020 via email

@ACJCA
Copy link

ACJCA commented Jul 6, 2020

I agree with the OP.

The big problem is that brute force attackers will know they have a valid username and password by the time they get to the TOTP prompt.

Sure, it would probably take a single attacker a few months to guess the right 2fa code if they were trying them one at a time. But in a botnet this could be done very quickly.

I appreciate that the UX would be potentially confusing to some people, but in the example of Google (and I assume github) these companies have many more sophisticated ways to detect and suppress malicious attacks. Nextcloud 19 with Two Factor TOTP doesn't (I just tested it).

To make MFA meaningful against brute force attacks, a user who enters one or more incorrect credentials at log in must not know which one(s) failed. For this to be achieved, the TOTP input must appear at the same time as the username and password.

An error message might look like: 'Sorry. Either the user does not exist, or the password or TOTP code were incorrect.' It's not ideal but it's clear.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants