More secure storage of credentials

[jflournoy]

I think it would be more secure for the credentials function to write these to a separate file, and try to control the read/write permissions if the OS supports it, rather than writing this to the .Renviron file (which is by default loaded on each session). Ideally the use could specify the file location to ensure it's secure.

This may be me being overly anxious about this, but since it's basically a stored login and password, there could be security implications in terms of leakage of identifiable data.

[juliasilge]

One idea would be to use the keyring package. I've used that in the context of Active Directory passwords and an internal R package for accessing SQL Server data; it worked well.

[dsen6644]

@juliasilge are you aware of any packages (ropensci or other) that use keyring to store api credentials?

[juliasilge]

I looked at the reverse imports/suggests for keyring and it looks like there are some packages that use it for that purpose.

[asadow]

+1 for interest in using keyring after reading this page by Hadley on secrets.

(Would using keyring instead of .Renviron mean that the computer must be logged in for an automatic script to access the password?)

[juliasilge]

Would using keyring instead of .Renviron mean that the computer must be logged in for an automatic script to access the password?

I don't know the details of how this works, actually. I have only used it directly in a previous job, in the context of Active Directory passwords and accessing SQL Server databases; this was interactive work. I do remember that it would re-ask for my password, depending on whether the OS credential store thought it was time (???).

If we pursue this, we'll probably need to support both keyring and the environment variables, because env vars work better when, say, deploying to an automated system like Posit Connect.

[chrisumphlett]

I used keyring for several years. I have switched away from it to azure key vault, primarily because then when I deploy content to Posit Connect I don't need to create and maintain all the environment variables on connect.

Using keyring requires you to pass in the keyring unlock credential (at least as far as I could tell it did). So I had that in .Renviron. That was better than storing the credentials there because it was only useful on my local machine.

It requires creating a "ring". You could create a new ring but i'm not sure if that's ideal if the user has an existing one.

All of that said I would not have cared that much when I was using Keyring to have this, but I had more flexibility in my org of what to use and ultimately some other options (azure key vault). I'm interested in working on this but perhaps after refining the idea a bit more