Different behaviors while directly visit project URLs

[nevercodecorrect]

Hello, An attacker could know what are the projects exist by simply brute-force checking localhost:8080/testproject. If the returned page is authenticator then he knows the project exist as if the project does not exist, the returned page will be create project page. It also applies to the user/bill index. The returned page are different and the index is easy to guess. All those trials does need any login/priveledge at all.

[almet]

You're correct, thanks for bringing this up. I believe it's a tradeoff we're doing right now, to ease the life of the users.

Some more context:

• the id of the project is not secret, and is not shared with other services, so for instance a leak of a database wouldn't be usable with other leaked databases (like we see for usernames/emails)

Mitigations:

• We have a protection in place for logins, but only used for /admin, so I wonder if we should also protect other resources, and if that would be enough to mitigate this.
• Always present the authenticator page, even when the project doesn't exist.
• Never present the authenticator page, even when the project exists, and always redirect to the front page.

What do you think?

[almet]

We want to display the authentication page in all cases, and ideally merge the project creation form with the one from the homepage.

[nevercodecorrect]

Sorry for the late reply, that would be better in term of security,