1. 7
  1.  

  2. 2

    Was encrypted storage of the secrets intentionally foregone?

    1. 3

      Then pass-otp might be better… at least the secrets are stored gpg-encrypted then :)

      1. 1

        The secrets will be saved as a hidden file named .mina.json in the home directory of the current user.

        1. 1

          This doesn’t offer any protection against other users on the same machine. Encrypting the secrets is the way to go, but in the meantime you should do

          import os
          import stat
          os.chmod(JSON_URL, stat.S_IRUSR | stat.S_IWUSR)
          

          to prevent other users from being able to view the file.

          1. 5

            That’s susceptible to race conditions. You have to do a little umask dance before creating the file.

      2. 2

        I’ve been using oathtool for a while. This tools are fun, and especially useful under an architecture like QubesOS where your TOTP VM can be separated by the hypervisor from the network and from the VM in which the login is occurring. Then you can have same-physical-device reasonably secure 2FA, and you only need a fuzzy clock sync between your totp vm and the world.

        1. 1

          I’d have trouble trusting Python for something like this, just due to the chance of someone changing an important line subtly to steal secrets. Am I crazy?

          1. 8

            What language doesn’t allow people changing important lines?

            1. 1

              A reasonable question which might betray my insanity for preferring compiled languages for handling private authentication materials.

              1. 3

                Surely it’s harder to see the suspicious modification in a compiled form. If you’re going to rely on hash checks, say, instead of inspection, I would think that would apply equally well to any executable.