Plaintext storage of TOTP secret key

AnnikaV9 commented 2 years ago

Severity: Low (At the moment)

The Issue

The TOTP secret key generated by the server is stored as plaintext in login/2fa_key. While it is unlikely anyone who doesn't have access to the server can retrieve this key, this may change when new bugs or vulnerabilities surface in future updates.
commands/csh_setup_2fa.py#L16-L19

Patch Status

This issue has not been patched yet.

Symmetric/Asymmetric encryption with key file(s) is pointless, since the encryption key needs to be stored in the same server, and will face the same issue as the plaintext 2fa secret key.
Encrypting the 2fa key with the user password as the encryption passphrase is also not feasible, as the whole point of having an otp system is to keep the server secure even if the password is compromised.

A method to save the key in the operating system's keyring/keychain/secret-service is being worked on at the moment.

Workarounds

Ensure that only trusted user accounts can access the carrotsh directory in your server.
Ensure that no other webserver/fileserver is exposing the carrotsh directory to the internet.

If you do have a proper solution, feel free to make a pull request which references this issue

AnnikaV9 commented 2 years ago

@minasrc I'm not sure of a way to derive the TOTP pin from just the secret key's hash. If there isn't, It would require the user to send the key when connecting, which essentially just makes it another password.

AnnikaV9 commented 2 years ago

@minasrc At the moment, the password is sent over plaintext. This is by design, which is why enabling encryption with self-signed certificates is highly recommended. The password is then hashed on the server side, and the hash is compared with the one stored on the server. If it matches, then the server moves the connection to the next security level (OTP) if it's enabled. The OTP type used is TOTP (Time-Based One Time Password), which mixes a base32 key with the current time to generate a 6 digit pin that lasts a short duration. The user will have the base32 key already registered in their authenticator app, which will display the currently valid OTP. If the sent OTP matches with the one generated by the server (Presumably with the same key), then the user is finally let into the shell.

The user encrypts their password with their private key and sends the result. The server can then look for the public key associated with the user and if it exists decrypts the password. If it matches then all good. Of course the passwords are not stored as plain text either.

We don't want to do encryption manually because any form of encryption through the browser would have to be done through javascript. This is very insecure, since someone performing an MITM attack could intercept the webpage, manipulate the javascript, and send it to the client, who will end up running the bad code which could expose the password to the attacker or something else malicious.

AnnikaV9 / carrotsh