Open SimplyCorbett opened 4 years ago
Then you would leak whether a user has 2FA enabled or not and which 2FA options are active, right? See https://github.com/nextcloud/server/issues/5935 for the old discussion.
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.
@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.
cc @rullzer @nickvergessen
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?
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.
By available I meant instance wide. They are leaked by available translation and JS files
but that does not tell you anything about the 2fa state of user
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.
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.
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"?
Yes.
Let's say I run a nextcloud instance and my username is Betty. Betty is a common name and the attacker doesn't know for sure if it's their target.
By verifying the password matches they now know Betty is their target and can launch a social engineering attempt to gain access.
On the other hand if they can't verify the password matches then they can't take the risk of attempting such an attack because if they're wrong it will give the admin a heads up and security policies will change.
I know this is all hypothetical and 99.99% of your users won't be in such a situation but if I can think this up so can an attacker.
On Apr 28, 2020, 12:43 AM, at 12:43 AM, Joas Schilling notifications@github.com wrote:
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"?
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: http://url8123.irex.me/ls/click?upn=yKxo4UA1HGjGV1MPu3-2B6c50oP4lZOClzo9aUfGYERUEJ7d448rj-2FtrfHyZrJUl7tmv9UryxjpT4MituFBtW6iKhRskZywkO1rJpVsJufiJi0GIHSrmRLgQXf-2FN7B4dffbG_2_U31jt5HgHBh7k3Grc5s4l2dWDDUTzzgFxUbv6yG-2F10V3RPrxMLREk7q5tt8NIE7xhAiYwWRPnQ59l2CharuWw3r0fYI31XZrW-2B1Wm3BKEz481bTn21iJjOkXisYH88PxfWDmY49YAYCT8BUuccH-2BhtWz7YbWc1AThHNecltkCpfu5F8qdOCFEnk7DhFQ6LhpFmCDnuWxWf9-2B9KKwHiDA1AsU1mRTahFlG-2BSfvAfSrpjFU9nZiNFlTdHc2Lur2KOr2SNP7lMglGAAgLrHY4TVYzkCpxp7rjiowPBd2ePw8gc-3D
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.
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!"