Security Concerns

I have never been one for much security when it comes to my technology. I like to keep my network secure, but I’m not one to necessarily have a lot of different passwords or use things like virus scanners or firewalls (outside of a firewall router). This makes me a not very good person for doing things like figuring out how the access rights side of GITI will operate when considering external uses of data via the SecretKey system. At this time there is exactly one SecretKey application, and it isn’t even really part of GITI, it is an adjacent application under the pcfire.net domain that just happens to have the same users as GITI, and therefore can use the SecretKey system without using the whole GITI login routine. In addition, I wanted the application to be something that could be accessed without having to be greeted with a credentials prompt every time it is accessed. I’m told that allowing a page to be accessed with a plain text password is bad, as it compromises everything, so I’m using the keys.

My concern now turns to the aspect of key security. Is one key good enough? Basically the way things work now is that each user is issued a key and with that key they can theoretically access limited GITI resources. The key is supposed to be used in a condition where the data is not sensitive and where things are read-only. For the current implantation there is a non-sensitive use where the data is pretty much one-way. There is only an input, not a modify, and thus no records to corrupt. Of course I log the IP addresses used for access so in the event of a problem it is possible to drop rows from the database made from any IP address not owned by the owner of the account. This being said, if the key is compromised, it is easy enough to have GITI to reset (“roll”) the key, but then all other services that use the key must be updated. I find myself wondering if each service should be able to be assigned a GITI key independently. Currently Google assigns a unique API key to each service that it “authorizes”, but it is a standard OpenID implementation, so I’m not sure how much stock I put in that process. It does seem rational though, to be able to use multiple keys and cancel them at will. I have considered using a different key for each service, allowing the user to issue however many keys they want or just leaving it as is, with each user having one key.  Oh so much to consider.