On Thu, 2015-08-20 at 12:01 -0700, Josh Andler wrote:

I think a simple system like that could be beneficial. Given the info about it and my lack of knowledge of OSUOSL's systems, is our web hosting on an encrypted filesystem?

Not as far as I know. But an encrpyted sqlite3 db should be possible with an fs mount If I remember how ubuntu used to do home directory encryption.

Martin,

On Thu, Aug 20, 2015 at 03:04:32PM -0400, Martin Owens wrote:

On Thu, 2015-08-20 at 12:01 -0700, Josh Andler wrote:

...

I think a simple system like that could be beneficial. Given the info about it and my lack of knowledge of OSUOSL's systems, is our web hosting on an encrypted filesystem?

Not as far as I know. But an encrpyted sqlite3 db should be possible with an fs mount If I remember how ubuntu used to do home directory encryption.

Martin,

I'll point out we already have a gpg/git-based password management system. I'll be happy to add anyone to it that needs access, and while I know gpg can be kind of technically complicated, I did attempt to document it well enough that most steps should be pretty paint-by-numbers.

Given that, I'd only want to consider switching the system if the new one is a) properly open source, b) at least as secure as our current system, and c) *technically* better in some way (apart from usability). Bonus points for being user friendly.

With that said, and not having actually played with Rattic, (a) seems to be covered since it's GPL licensed. (b) it is essentially sidestepping by leaving it to the webserver and filesystem to handle (which actually is probably a smart approach); however it feels like I'm comparing apples to oranges so I'd want to hear the evaluation of an actual security expert (e.g. Kees Cook) before deciding this one. As to (c), it looks like it'll handle everything our current approach does, and adds Auditing which our current system does *not* do, and which I do think would be useful. Unfortunately they don't post screenshots of the app itself, but presumably nearly anything would be more user friendly than command line gpg so I'll concede that point.

Given A and C, I see no reason not to go ahead and set up something we can try out. I'd want B settled before we migrate to it though.

In terms of priority, since we do have a system for handling passwords right now, I don't see this as urgent, myself, but if Martin is gung ho to experiment with it, I don't see a reason not to.

I *would* like to see a listing of what passwords we'd put in it, and who should have access.*

Bryce

* - Mostly because if there's anything our current system is missing, then I should make a priority to fix that ASAP.

On Thu, Aug 20, 2015 at 03:24:02PM -0700, Bryce Harrington wrote:

On Thu, Aug 20, 2015 at 03:04:32PM -0400, Martin Owens wrote:

...

On Thu, 2015-08-20 at 12:01 -0700, Josh Andler wrote:

...

I think a simple system like that could be beneficial. Given the info about it and my lack of knowledge of OSUOSL's systems, is our web hosting on an encrypted filesystem?

Not as far as I know. But an encrpyted sqlite3 db should be possible with an fs mount If I remember how ubuntu used to do home directory encryption.

I'll point out we already have a gpg/git-based password management system. I'll be happy to add anyone to it that needs access, and while I know gpg can be kind of technically complicated, I did attempt to document it well enough that most steps should be pretty paint-by-numbers.

Given that, I'd only want to consider switching the system if the new one is a) properly open source, b) at least as secure as our current system, and c) *technically* better in some way (apart from usability). Bonus points for being user friendly.

I would add d) "is more or equally simple in implementation".

With that said, and not having actually played with Rattic, (a) seems to be covered since it's GPL licensed. (b) it is essentially sidestepping by leaving it to the webserver and filesystem to handle (which actually is probably a smart approach); however it feels like I'm comparing apples to oranges so I'd want to hear the evaluation of an actual security expert (e.g. Kees Cook) before deciding this one. As to (c), it looks like it'll handle everything our current approach does, and adds Auditing which our current system does *not* do, and which I do think would be useful. Unfortunately they don't post screenshots of the app itself, but presumably nearly anything would be more user friendly than command line gpg so I'll concede that point.

Given A and C, I see no reason not to go ahead and set up something we can try out. I'd want B settled before we migrate to it though.

In terms of priority, since we do have a system for handling passwords right now, I don't see this as urgent, myself, but if Martin is gung ho to experiment with it, I don't see a reason not to.

I *would* like to see a listing of what passwords we'd put in it, and who should have access.*

Bryce

• • Mostly because if there's anything our current system is missing,

then I should make a priority to fix that ASAP.

If this is for shared password management, I would actually argue for eliminating the need for shared passwords entirely. How does revocation currently work? Right now, I imagine you're sharing credentials instead of having a credential for each person, which then has authorizations tied to that credential. For example, give each admin an account (separate credentials), and access to a sudo group (authorization tied to their credential).

I suspect my lack of context here means something about your requirements make this suggestion unworkable, though. :)

-Kees

On Fri, Aug 21, 2015 at 04:53:50PM -0700, Josh Andler wrote:

On Fri, Aug 21, 2015 at 4:10 PM, Kees Cook <kees@...20...> wrote:

...

If this is for shared password management, I would actually argue for eliminating the need for shared passwords entirely. How does revocation currently work? Right now, I imagine you're sharing credentials instead of having a credential for each person, which then has authorizations tied to that credential. For example, give each admin an account (separate credentials), and access to a sudo group (authorization tied to their credential).

For certain things where there is a single user (e.g. Twitter), we need to be able to share a single password.

Gotcha. Do you change all the shared passwords each time someone is removed from the list people with access?

-Kees