5 ms·

Ask HN: Any ways to make Gitea safer for my private projects?

4 points by dev_0 4y ago

Having hard coded database password is insane. If my linode is hacked, then the password will be seen

joshxyz 4y ago
Is it stored in plain text? If it uses scrypt / argon2 / pbkdf2 it is enough. Also, you may simply use a randomly generated password so your other accounts wont be hacked if someone hacks your linode server.
stop50 4y ago
You can only limit the access. For example: limit access for other users than gitea to the config including sshd. Limiting the data that can be accessed with the databasepassword. Gitea doesn't need access to your wordpress. using an sso can also help: in this case gitea doesn't even have the password.
- dev_0 4y ago
  If someone hack my linode, they can be gitea user?
  - stop50 4y ago
    yes they can, but the risk is relative low. SSH-Auth should be only over keypairs,2fa should be on for your account and then most attacks should be unsuccessful.
    - dev_0 4y ago
      I bought Yubikey recently. Should be usable
    - dev_0 4y ago
      I will be doomed if there is RCE?
      - stop50 4y ago
        Golang is relative save in case of rces. The only problem is git with its hooks, but you need authentication to do harm. Gitea would rather crash than giving access to the attacker. git server are not really in danger.
      - stop50 4y ago
        Unless you have very private data in your private repos: no if you have your bankaccount password, your ssn or similar important data in your git repos: yes, but its your fault
  - halfdan 4y ago
    I'm not sure I understand the concern. If they have shell access to your linode they already have access to everything - even if your db password were encrypted gitea can communicate with the db and so can any attacker coming from that system.
detaro 4y ago
If your linode is hacked, the attacker doesn't need your database password anymore...
hardwaresofton 4y ago
Have you filed an issue with gitea about this? Accepting a bcrypt/scrypt/etc hashed password via ENV is likely a like… <4 hour pull request for the project
- detaro 4y ago
  for the database password?
  - dev_0 4y ago
    Yes the database password
    - detaro 4y ago
      Giving an application a hash of a database password to protect against compromise doesn't make any sense
- marcc 4y ago
  While there are solutions here, generally an app needs to have the actual database password or the ability to create one. A bcrypt of the password just won’t let the gitea server connect.
howlett 4y ago
If I'm not mistaken gitea stores codebases/projects on the filesystem, so having a hardcoded database password makes no difference. If someone gets into the server they can simply copy the files without touching the database. As others have indicated, a VPN server of your choosing (openvpn/wireguard) can solve your issues. Even if at some point there's an "unauthenticated RCE" exploit for gitea, having it behind a VPN will mitigate that.
- dev_0 4y ago
  They can get my username and tokens from the db
g_p 4y ago
The database password is irrelevant unless your database is exposed to an attacker - if it is, you've not set your system up correctly. Your first line of security should be the perimeter - preventing access to services which aren't needing exposed (like databases). Then you should consider your exposed attack surfaces you can't avoid - the SSH interface for git over SSH, and the HTTPS interface for web access. You could protect the HTTPS interface by requiring a client certificate before allowing a connection, by using a reverse proxy like nginx or caddy. If you do this, make sure your underlying gitea web server isn't accessible from outside of the server (e.g. via another port). For the SSH interface, look at whether you are using the system SSH instance, or another one - if you run gitea via docker, you can have an isolated SSH instance running on a separate IP (or port) from your underlying system, and limit the risk of a compromise. But don't overlook the simplest issues - using weak or re-used user passwords, not using MFA, using passwords for SSH. At a certain point, your VPS is probably more vulnerable to attack through your regular management SSH access, or the customer portal of your VPS provider.
- dev_0 4y ago
  I am using SQLite. Is this unsafe?
navjack27 4y ago
Now here is something I'm wondering. Why not just install Gitea locally? I run it on my Mac Mini and I can access it from any computer in my local network. And maybe also consider rethinking what you're using git itself for. Gitea might not be the whole problem here. I personally would never put a gitea on the world wide web just for personal private projects. That would mean that it would be completely up to me to manage that security and I'm not really sure of any upsides on that. Also a quick Google brought this up https://book.hacktricks.xyz/cloud-security/gitea-security https://book.hacktricks.xyz/cloud-security/gitea-security

4 points by dev_0 4y ago

Having hard coded database password is insane. If my linode is hacked, then the password will be seen

Is it stored in plain text? If it uses scrypt / argon2 / pbkdf2 it is enough. Also, you may simply use a randomly generated password so your other accounts wont be hacked if someone hacks your linode server.

stop50 4y ago

You can only limit the access. For example: limit access for other users than gitea to the config including sshd. Limiting the data that can be accessed with the databasepassword. Gitea doesn't need access to your wordpress. using an sso can also help: in this case gitea doesn't even have the password.

dev_0 4y ago
If someone hack my linode, they can be gitea user?
- stop50 4y ago
  yes they can, but the risk is relative low. SSH-Auth should be only over keypairs,2fa should be on for your account and then most attacks should be unsuccessful.
  - dev_0 4y ago
    I bought Yubikey recently. Should be usable
  - dev_0 4y ago
    I will be doomed if there is RCE?
    - stop50 4y ago
      Golang is relative save in case of rces. The only problem is git with its hooks, but you need authentication to do harm. Gitea would rather crash than giving access to the attacker. git server are not really in danger.
    - stop50 4y ago
      Unless you have very private data in your private repos: no if you have your bankaccount password, your ssn or similar important data in your git repos: yes, but its your fault
- halfdan 4y ago
  I'm not sure I understand the concern. If they have shell access to your linode they already have access to everything - even if your db password were encrypted gitea can communicate with the db and so can any attacker coming from that system.

detaro 4y ago

If your linode is hacked, the attacker doesn't need your database password anymore...

hardwaresofton 4y ago

Have you filed an issue with gitea about this? Accepting a bcrypt/scrypt/etc hashed password via ENV is likely a like… <4 hour pull request for the project

detaro 4y ago
for the database password?
- dev_0 4y ago
  Yes the database password
  - detaro 4y ago
    Giving an application a hash of a database password to protect against compromise doesn't make any sense
marcc 4y ago
While there are solutions here, generally an app needs to have the actual database password or the ability to create one. A bcrypt of the password just won’t let the gitea server connect.

howlett 4y ago

If I'm not mistaken gitea stores codebases/projects on the filesystem, so having a hardcoded database password makes no difference. If someone gets into the server they can simply copy the files without touching the database. As others have indicated, a VPN server of your choosing (openvpn/wireguard) can solve your issues. Even if at some point there's an "unauthenticated RCE" exploit for gitea, having it behind a VPN will mitigate that.

dev_0 4y ago
They can get my username and tokens from the db

g_p 4y ago

The database password is irrelevant unless your database is exposed to an attacker - if it is, you've not set your system up correctly. Your first line of security should be the perimeter - preventing access to services which aren't needing exposed (like databases). Then you should consider your exposed attack surfaces you can't avoid - the SSH interface for git over SSH, and the HTTPS interface for web access. You could protect the HTTPS interface by requiring a client certificate before allowing a connection, by using a reverse proxy like nginx or caddy. If you do this, make sure your underlying gitea web server isn't accessible from outside of the server (e.g. via another port). For the SSH interface, look at whether you are using the system SSH instance, or another one - if you run gitea via docker, you can have an isolated SSH instance running on a separate IP (or port) from your underlying system, and limit the risk of a compromise. But don't overlook the simplest issues - using weak or re-used user passwords, not using MFA, using passwords for SSH. At a certain point, your VPS is probably more vulnerable to attack through your regular management SSH access, or the customer portal of your VPS provider.

dev_0 4y ago
I am using SQLite. Is this unsafe?

navjack27 4y ago

Now here is something I'm wondering. Why not just install Gitea locally? I run it on my Mac Mini and I can access it from any computer in my local network. And maybe also consider rethinking what you're using git itself for. Gitea might not be the whole problem here. I personally would never put a gitea on the world wide web just for personal private projects. That would mean that it would be completely up to me to manage that security and I'm not really sure of any upsides on that. Also a quick Google brought this up https://book.hacktricks.xyz/cloud-security/gitea-security https://book.hacktricks.xyz/cloud-security/gitea-security