Loading ...
Sorry, an error occurred while loading the content.

Re: encrypt/decrypt functions for a session

Expand Messages
  • Matt Wozniski
    ... That s a very good point (and I hadn t thought of core files) but you also point out two important considerations: first, that even laying aside the fact
    Message 1 of 33 , Dec 3, 2007
    • 0 Attachment
      On Dec 3, 2007 1:17 PM, Erik Falor wrote:
      >
      > On 03/12/2007, Matt Wozniski wrote:
      > >
      > > 3. This entire discussion seems to basically be a moot point since
      > > any cracker worth his salt would just be sniffing the network...
      > > FTP transmits passwords in plaintext; security in how netrw handles
      > > the passwords seems to be a rather moot point to me.
      >
      > netrw doesn't only handle FTP transfers. Better types of traffic are
      > supported.
      >
      > I just don't like the idea that my password is sitting in a global vim
      > variable for all to see. If I walk away from my keyboard, someone
      > could walk by and type :echo netrw_passwd
      >
      > Plus, if/when I dump core, my password is there, in cleartext, in the
      > dumpfile. Again, something I don't want to leave to filesystem perms
      > to protect me from. Especially if I happen to be using an OS that
      > FTPs dumpfiles back to the mothership for you.

      That's a very good point (and I hadn't thought of core files) but you


      also point out two important considerations: first, that even laying


      aside the fact that this encryption idea only provides security
      through
      obscurity, you could achieve a similar amount of security by having
      netrw store the password in a script-local variable, rather than a


      global variable (global variables are particularly awful, since a


      malicious user at your keyboard, or anyone who convinces you to
      install
      their vim script, can just scan through the output of :let searching for
      /pass/). Fixing that to use a script-local variable would definitely be
      a worthwhile change that should be made ASAP, though it still wouldn't
      protect you from plaintext passwords being in your core files.

      The second important point you make is that netrw supports other
      protocols for which this isn't an issue. If a user is sufficiently
      worried about security to not want a plaintext ftp password stored in
      vim's memory, he can always use ssh key-based authentication and make it
      a moot point.

      While we're at it, what is a reasonable use-case for why someone would
      need a getpid() function? Why would we need to know our PID?

      ~Matt

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Tony Mechelynck
      ... by making the check a part of whatever routine you use to supply the stored password. ... You could add additional checks, e.g. in CursorHold, CursorHoldI
      Message 33 of 33 , Dec 5, 2007
      • 0 Attachment
        thomas wrote:
        > On Dec 6, 5:06 am, Tony Mechelynck <antoine.mechely...@...>
        > wrote:
        >> thomas wrote:
        >> Vim can store the current time -- see ":help reltime()". Store it when the
        >> user types in the master password, compare it with the time when a password is
        >> needed, and ask the master password again if the time interval is "too long".
        >
        > Yes, but how do you make sure the interval is ever checked?

        by making the check a part of whatever routine you use to supply the stored
        password.

        > IIRC
        > CursorHold[I] events don't get triggered when vim doesn't have the
        > focus. And you don't know which value 'updatetime' has. If you check
        > only when the password is accessed, somebody could use the :debug
        > trick
        > even hours/days after you last used the password.

        You could add additional checks, e.g. in CursorHold, CursorHoldI and/or
        FocusGained autocommands.

        >
        > BTW I would really like to see timer events that get triggered even
        > when
        > vim is in the background. I started writing a kind of PIM plugin but
        > stopped at about 80% because I didn't have the time to find a way to
        > reliably show alarms in a cross-platform manner. But this is a
        > different subject of course.
        >
        > thomas.

        Maybe you could use some external program (such as Unix's "at" or "cron", but
        possibly handcrafted to use shorter timespans) to periodically trigger
        something in your Vim instance via the |clientserver| feature? IIUC, it could
        even be a Vim script running on the "client" Vim, looping forever with a
        ":sleep" command in the loop, and periodically triggering some effect in the
        "server" Vim.


        Best regards,
        Tony.
        --
        Paul's Law:
        You can't fall off the floor.

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      Your message has been successfully submitted and would be delivered to recipients shortly.