7

I edited this question to clarify why I asked this question again (I had weak Google-Fu and found these rather old 1 2 3 pretty-much-duplicates only after posting).

Approaches to accessing a password-protected resources that I've seen in the wild.

  1. Plaintext storage in script (might often end up being shared, or in a Dropbox)
  2. Plaintext storage in a config script
  3. You can do password = readline("Password: ") but of course the password ends up in plaintext in the console (and thus in console logs etc.), so might as well store it in a plaintext config file.
  4. I found this little trick to avoid displaying the password in the Terminal, but running system("stty -echo") on OS X Mavericks leads to the error stty: stdin isn't a terminal, so I guess it wouldn't be particularly portable.
  5. Using tcltk. Has the unfortunate effect of making Rstudio crash and being difficult to install.
  6. keychain. It's not on CRAN, so I don't think I can use this as a first-line approach, I'd also like a bit more detail about where and how passwords are stored on various systems (i.e. will it end up in plaintext on Windows?).
  7. Access tokens, OAuth etc. seem to have similar problems.

I don't know any R packages which use PGP for connections? Probably also a bit difficult for newbie users.

I'm not asking for myself mainly, but I want to provide somewhat sensible defaults for nontechnical users who might store plaintext passwords enabling access to sensitive data in their Dropbox.

Unlike others who asked similar questions, I could also change the server-side of things if I had a better approach.

Are there best-practice approaches that I'm currently missing? My focus on interactive sessions is because I assume that's how most nontechnical types use R, but of course it would be nice if it worked during e.g. knitr report generation too.

Ruben
  • 3,452
  • 31
  • 47
  • See http://stackoverflow.com/q/2917202/602276 – Andrie Mar 21 '14 at 16:00
  • @Andrie Thanks! This doesn't work in Rstudio though, owing to tcltk (and it doesn't break nicely either, crashes). And I can still remember the time I had to install tcltk for the first time vividly enough, that I'd prefer not to use it either... – Ruben Mar 21 '14 at 16:05
  • Don't use `R` ? Embed a line in your function/script to redirect all output to somewhere other than `stdout` ? – Carl Witthoft Mar 21 '14 at 16:13
  • @Carl I found one method not to echo anything in `stdin`, that didn't work for me, so `stdout` would be secondary to that? Or what do you mean by don't use R? – Ruben Mar 21 '14 at 16:15
  • I'm sorta suggesting that `R` is not a tool for handling secure data transfer. BTW, **lots** of allegedly secure interfaces store the plaintext password you type, if only in RAM (which then gets written to the virtual RAM file during swaps...). Ultimately, unless you can guarantee that your password is encrypted the moment you enter it, it'll be somewhere on your local machine. – Carl Witthoft Mar 21 '14 at 16:18
  • @Carl I edited my question a little. I'm pretty sure that there is a large security difference between entering my password in my browser on OS X and putting it in a plaintext config file for R. I also have the feeling that R/its IDEs are not perfectly suited for secure data transfer, but I thought there might be newer ways (questions are 2-4 years old), considering that there are a number of packages which support OAuth, `httr` and so on. – Ruben Mar 21 '14 at 16:25
  • the question is "what is the final intention?"! to realize the security-relevant technology in R is OF COURSE stupid. but the demand of secure communication with an R scripted process as an end point does still make sense. but then you either use a REST-API via TLS (https) or you use a tool like OpenSSL. but this is exactly why I voted to close this question because it is too broad and has nothing to do with R itself. – Raffael Mar 21 '14 at 16:28
  • @Яaffael My package is interfacing with a REST-API via TLS, but obviously users are going to store passwords in source files if I don't provide a sane alternative to that. Your comment that this has nothing to do with R itself is true but misleading: It's about using R. I'm pretty sure every R user has at some point used a suboptimal approach to this. Who to ask but R users? – Ruben Mar 21 '14 at 16:33
  • @Яaffael And if you're going to say that I should simply "force" users to download data via a different channel, I would have to counter that scripting access to a website using `httr` is so trivially easy that soon enough somebody would do that so as not to inconveniently have to download the data repeatedly (again, storing passwords in plaintext). – Ruben Mar 21 '14 at 16:38
  • offer a web page where they can request a token which times out after a while - and for that request they just have to enter a password. (f.x.) – Raffael Mar 21 '14 at 16:46
  • I actually considered this, but has the downside of being inconvenient. I still have to provide access to the data via the browser, so e.g. httr could still be used to circumvent this. I read the httr news on better support for OAuth 2.0 and @hadley seems to have put some thought into users inadvertently storing tokens in version control software, but Dropbox, the market leader (not every scientist uses proper version control), does not even offer ignoring specific files. – Ruben Mar 21 '14 at 17:08
  • On Windows you can do something like http://stackoverflow.com/a/36218700/3827849. Maybe the solution can be adapted to use Keychain? – Josh Gilfillan Apr 20 '16 at 22:53

1 Answers1

1

Some suggestions to solve your problem securely. These solutions match all programming languages.

  1. Establish a secure connection to your resource without R, like a SSL tunnel.
  2. If you need a secure password in R to establish a secure connection, then you can read this from a secure config file and remove this password variable if you don't use the password anymore. A secure config file is a config file that is not part of your code repository (Git, SVN, ...). You have to manage your secret independent of your code. This mean separate your code and your secrets. One simple way is to put your private and secure secret in your private and secure user home directory. Then you have delegated your security problem to your operating system. Your secret is now save as your OS and your home directory. Pleas check the rights of your home directory and enable the file system encryption if they are off. Notice, this is the way like Maven handle passwords.
  3. You get more security if you encrypt your password/secret config file. Then you have second line of defense.

For most applications is point 2 enough.

Notice, be sure that your secret is not deployed with your code. You need a second way to manage and deploy your secret to production systems.

Notice, be sure that if your programs jams, that your secret is not in memory anymore.

Notice, use always strong algorithms for encryption. Don't implement your own security algorithm, is a high complexity task. Better use standard implementations of strong encryption algorithms.

Mirko Ebert
  • 1,349
  • 1
  • 18
  • 36