The keychain provides a way to securely store sensitive information
such as access credentials or any other data. This pull request
contains a new class called JKeychain that extends JRegistry and
supports encrypting and decrypting data through the use of public and
private keys. It also provides the necessary command-line utility (a
Joomla Platform application itself) to generate the key files.
DOCUMENTATION
Documentation is provided in the pull request. A readable version is
available at:
At eBay, we needed a way to be able to store sensitive credentials
(server/database logins, etc) in our SCM repository in an encrypted
form without the hassle of sharing those credentials over email or
other electronic means. The Keychain package was developed so we could
store encrypted data in the source code repository (the security
issues related to storing clear-text credentials in a semi-public,
albeit internal, source code repository should be obvious). Engineers
and deployment servers only need obtain the the 'shared key' manually,
but only once. Should the credentials change, the encrypted data file
in the repository simply needs to be updated and all engineers and
servers have access to the new information on the next build.
> The keychain provides a way to securely store sensitive information > such as access credentials or any other data. This pull request > contains a new class called JKeychain that extends JRegistry and > supports encrypting and decrypting data through the use of public and > private keys. It also provides the necessary command-line utility (a > Joomla Platform application itself) to generate the key files.
> DOCUMENTATION
> Documentation is provided in the pull request. A readable version is > available at:
> At eBay, we needed a way to be able to store sensitive credentials > (server/database logins, etc) in our SCM repository in an encrypted > form without the hassle of sharing those credentials over email or > other electronic means. The Keychain package was developed so we could > store encrypted data in the source code repository (the security > issues related to storing clear-text credentials in a semi-public, > albeit internal, source code repository should be obvious). Engineers > and deployment servers only need obtain the the 'shared key' manually, > but only once. Should the credentials change, the encrypted data file > in the repository simply needs to be updated and all engineers and > servers have access to the new information on the next build.
Very, very, cool! Is this something that you believe would be suitable for use with the general public? Here is a use case that I was thinking about.
I have many customers who want to use Facebook Connect in conjunction with their websites. The way that Facebook Connect works is to confirm with a website that the current user is logged in to a Facebook session in this browser. The site is then left to its own devices in regards to actually authenticating the end user with Joomla ( or whatever authentication method the platform uses ). Most sites that I have seen (Joomla or not) allow users to register with Facebook Connect and then require the user to enter yet another password, which, to me seems to defeat the whole purpose. People don't want to have to remember another password and they expect Facebook Connect to just work without entering passwords.
So, my question is this: Do you think this keychain system could be used to generate and securely store a token for each user which is then retrieved and used as the password for logging in to Joomla?
alonzo.tur...@subtextproductions.com> wrote:
> Very, very, cool! Is this something that you believe would be suitable for
> use with the general public? Here is a use case that I was thinking about.
> I have many customers who want to use Facebook Connect in conjunction with
> their websites. The way that Facebook Connect works is to confirm with a
> website that the current user is logged in to a Facebook session in this
> browser. The site is then left to its own devices in regards to actually
> authenticating the end user with Joomla ( or whatever authentication method
> the platform uses ). Most sites that I have seen (Joomla or not) allow
> users to register with Facebook Connect and then require the user to enter
> yet another password, which, to me seems to defeat the whole purpose.
> People don't want to have to remember another password and they expect
> Facebook Connect to just work without entering passwords.
> So, my question is this: Do you think this keychain system could be used
> to generate and securely store a token for each user which is then
> retrieved and used as the password for logging in to Joomla?
You'd have to look at the efficiency of the JRegistry object for
storing that information (for example, one data file for all users, or
one data file for each user - though you are talking about
authentication, so it may be ok for that to be a slightly expensive
operation - in fact, that's an attractive proposition in some cases),
but you could use it in such a fashion. You could certainly use it to
store secure tokens to connect to 3rd party API's, etc.
<alonzo.tur...@subtextproductions.com> wrote:
> Very, very, cool! Is this something that you believe would be suitable for
> use with the general public? Here is a use case that I was thinking about.
> I have many customers who want to use Facebook Connect in conjunction with
> their websites. The way that Facebook Connect works is to confirm with a
> website that the current user is logged in to a Facebook session in this
> browser. The site is then left to its own devices in regards to actually
> authenticating the end user with Joomla ( or whatever authentication method
> the platform uses ). Most sites that I have seen (Joomla or not) allow users
> to register with Facebook Connect and then require the user to enter yet
> another password, which, to me seems to defeat the whole purpose. People
> don't want to have to remember another password and they expect Facebook
> Connect to just work without entering passwords.
> So, my question is this: Do you think this keychain system could be used to
> generate and securely store a token for each user which is then retrieved
> and used as the password for logging in to Joomla?
<alonzo.tur...@subtextproductions.com> wrote:
> Very, very, cool! Is this something that you believe would be suitable for
> use with the general public? Here is a use case that I was thinking about.
> I have many customers who want to use Facebook Connect in conjunction with
> their websites. The way that Facebook Connect works is to confirm with a
> website that the current user is logged in to a Facebook session in this
> browser. The site is then left to its own devices in regards to actually
> authenticating the end user with Joomla ( or whatever authentication method
> the platform uses ). Most sites that I have seen (Joomla or not) allow users
> to register with Facebook Connect and then require the user to enter yet
> another password, which, to me seems to defeat the whole purpose. People
> don't want to have to remember another password and they expect Facebook
> Connect to just work without entering passwords.
> So, my question is this: Do you think this keychain system could be used to
> generate and securely store a token for each user which is then retrieved
> and used as the password for logging in to Joomla?
I'd suggest for this work flow you'd just send the user back through
to Facebook to be the IDP and never bother with the password locally.
Create a table or similar that links the Facebook identity back to the
Joomla identity and always use the Facebook Connect IDP to
authenticate the user. I agree that providing a password defeats the
purpose, I'd suggest that just storing the link should be sufficient.
And in that case this work is likely not useful for you. Where it
would be useful is securely storing your Facebook app credentials in
the registry so that they're not necessarily sitting out in the open
so much.
