Amazon is also in beta. I'm not sure if being in beta is any excuss
for poor security policies. Do they do this for their traditional
hosting plans?
reuven
Shane,
Thank you for pointing this out. I will be sure that our support team
knows not to give out this type of information, or if it is given out,
it is done in a secure manner.
Security is of utmost importance to us. If you have any other
suggestion on how we can increase your comfort level (e.g., with
password hints, temporary password resets, etc.) please let me know.
Do note that our entire GoGrid portal is run with SSL-encryption,
INCLUDING the chat session so while I agree with you that the password
should not have been delivered in that manner, the chat session was
encrypted with RC4 128 bit encryption.
There is no compelling reason for designing a system that allows a customer password to be recovered. The security risk from somebody gaining access to the password database goes from almost zero to huge, for no operational benefit
OpenID (www.openid.net) ?
On 9/5/08, Dan Kearns <d...@thekearns.org> wrote:It's actually unavoidable to store real passwords in cloud apps, as there is no trust or delegation model between services (that matter) which is usable or widespread enough to "just work". It doesn't seem to be for lack of effort though, as uncountably many companies and standards have been involved.
We can do that with OpenID and OAuth. Actually we can do it with better granularity.
Cheers
<k/>
It's probably too low-tech to suit most folks, but I'd like to see a cloud service created which does the following:
- stores my ids/passwords in a way where I have a reasonable expectation it won't be compromised
- provides an id/password on demand to anyone who a) asks for it, and b) I have approved for access to it and c) which the service provider has contractually obligated not to persist it locally under penalty of a monetary value known to me
>
> >
> > It's probably too low-tech to suit most folks, but I'd like to see a
> > cloud service created which does the following:
> >
> > * stores my ids/passwords in a way where I have a reasonable
> > expectation it won't be compromised
> > * provides an id/password on demand to anyone who a) asks for it,
> > and b) I have approved for access to it and c) which the service
> > provider has contractually obligated not to persist it locally
> > under penalty of a monetary value known to me
> >
>
> The grid community solved this with GSI
> <http://www.globus.org/security/overview.html> and delegated credentials.
That link is pretty out of date, in particular:
"Note that the GSI and software based on it (notably the Globus Toolkit,
GSI-SSH, and GridFTP) is currently the only software which supports the
delegation extensions to TLS (a.k.a. SSL). The Globus Project is actively
working with the Grid Forum and the IETF to establish proxies as a
standard extension to TLS so that GSI proxies may be used with other TLS
software."
See: http://www.ietf.org/rfc/rfc3820.txt
OpenSSL has support for this since 2005 I believe.
>
> /The primary motivations behind the GSI are:
>
> * The need for secure communication (authenticated and perhaps
> confidential) between elements of a computational Grid.
> * The need to support security across organizational boundaries,
> thus prohibiting a centrally-managed security system.
> * The need to support "single sign-on" for users of the Grid,
> including delegation of credentials for computations that involve
> multiple resources and/or sites. /
>
> There is almost certainly some stuff there worth considering for use in
> clouds.
We use it with Nimbus for client -> management interactions:
As for what happens on VMs, the Nimbus automatic configuration technology can
take you from no secrets to a bootstrapped security context using just about any
technology (including remote access policies as well as SSH host key
distribution/authentication across your launched VMs):
http://workspace.globus.org/clouds/clusters.html#features
This "overlay" technology is good in my opinion because only a small amount of
"cooperation" is necessary from the various VM-as-resource providers (namely,
help to get a seed secret on to the VM).
We've spoken with AWS evangelists etc. about some kind of delegation for EC2
operations -- it is a natural fit for the ecosystem of businesses running
things on clients' behalf (many companies are getting into this, it would be
good for our users that run via a Nimbus backend to EC2 as well).
Uploading your raw credentials to a remote management application is
unnecessary and risky...
Tim
>
> rw2
>
>
> >
OpenID doesn’t do anything like what is being suggested. Several OpenID providers are building identity services that do support the single sign-on password management.
But we aren’t really even talking about single sign-on here. We’re talking about delegation. OAuth, SAML, and I think GSI have solutions for this, but OpenID? Not what is was designed for.
From: cloud-c...@googlegroups.com
[mailto:cloud-c...@googlegroups.com] On Behalf Of Adwait Ullal
Sent: Friday, September 05, 2008 12:19 PM
To: cloud-c...@googlegroups.com
Subject: Re: GoGrid Needs to Rethink Security
OpenID (www.openid.net) ?
<br
> We can do that with OpenID and OAuth. Actually we can do it with better
> granularity.
Here is a slightly old, but I think still relevant, discussion of OpenID cons:
http://idcorner.org/2007/08/22/the-problems-with-openid/
Tim
>
> Cheers
>
> <k/>
>
>
>
> From: cloud-c...@googlegroups.com
> [mailto:cloud-c...@googlegroups.com] On Behalf Of Dan Kearns
> Sent: Friday, September 05, 2008 12:04 PM
> To: cloud-c...@googlegroups.com
> Subject: Re: GoGrid Needs to Rethink Security
>
>
>
> On Fri, Sep 5, 2008 at 11:40 AM, Brendon Whateley
> <bre...@darkindigo.com> wrote:
>
> There is no compelling reason for designing a system that allows
> a customer password to be recovered. The security risk from somebody
> gaining access to the password database goes from almost zero to huge,
> for no operational benefit
>
>
> Sidestepping the horror that hashing even needs to be explained to a web
> based service provider....
>
> It's actually unavoidable to store real passwords in cloud apps, as
> there is no trust or delegation model between services (that matter)
> which is usable or widespread enough to "just work". It doesn't seem to
> be for lack of effort though, as uncountably many companies and
> standards have been involved.
>
> It's probably too low-tech to suit most folks, but I'd like to see a
> cloud service created which does the following:
>
> * stores my ids/passwords in a way where I have a reasonable
> expectation it won't be compromised
> * provides an id/password on demand to anyone who a) asks for it,
I'd like to note that if the one-way encryption of the password is MD5,
then I can be patient or look it up on a database by people who have
been patient for me. To me, that's not a security advertisement worth
noting. The security mechanisms and procedures you expose should be a
base line example.
Another weakness is the procedure of the password retrieval or reset
procedure. Telling the right stuff provides new keys to the kingdom.
Working with certificates might be a lot of extra hassle but could add a
new level of trust. If you're not up to the task to work the certificate
CA jazz yourself, then you can leave that to existing commercial CAs. If
the CAs do their job (except just collect $200 and sign a certificate
request by comparing bank transfer info or credit card info) then they
have a very well known identity relationship established between them
(the CA) and your customer. Other options, like GSI, might then also
become possible.
my 2 cts,
Oscar
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "Cloud Computing" group.
> To post to this group, send email to cloud-c...@googlegroups.com
> To unsubscribe from this group, send email to
> cloud-computi...@googlegroups.com
> To post job listing, send email to jo...@cloudjobs.net (position title, employer and location in subject, description in message body) or visit http://www.cloudjobs.net
> For more options, visit this group at
> http://groups.google.ca/group/cloud-computing?hl=en?hl=en
> Posting guidelines:
> http://groups.google.ca/group/cloud-computing/web/frequently-asked-questions
> To collaborate in group's Wiki (http://sites.google.com/site/cloudcomputingwiki/) send request to cloudmo...@gmail.com
> -~----------~----~----~----~------~----~------~--~---
Shibboleth will give you federated identity-based authentication and
authorization infrastructure based on SAML. You still have the issue of
hosting an IdP and vetting the identities. This is to get the
credentials of the users into the SAML statements.
The technology is irrelevant for the procedures that should be done to
get identity handling deployed in a trustworthy and secured way.
The other thing is the federated 'thingy' about the technology. Usually
LDAP might be used for simple user base authenticated behind the IdP.
Employing the federated trust between the IdPs (= between domains) is
the thing that this technology is for.
IMHO: This doesn't seem to be the technology your looking for here...
cheers,
Oscar
One of the advantages of federated security (ala shib, gsi or if you
combine them gridshib) is that the rules for vetting identities can be
managed locally.
So, in the example that started this thread, GoGrid wouldn't have had
access to the users authentication data.
rw2
That's correct. I think the sysadmin department doesn't want to link
their user account database to a federated identity system just yet.
Some might do it though. Especially when there is a mutual benefit
between domains to start work on the federation. I wouldn't rule it out,
but in the given use case not very likely and useful.
Oscar
Rich Wellner wrote:Oscar Koeroo wrote:Hi, Shibboleth will give you federated identity-based authentication and authorization infrastructure based on SAML. You still have the issue of hosting an IdP and vetting the identities. This is to get the credentials of the users into the SAML statements.One of the advantages of federated security (ala shib, gsi or if you combine them gridshib) is that the rules for vetting identities can be managed locally. So, in the example that started this thread, GoGrid wouldn't have had access to the users authentication data. rw2That's correct. I think the sysadmin department doesn't want to link their user account database to a federated identity system just yet. Some might do it though. Especially when there is a mutual benefit between domains to start work on the federation. I wouldn't rule it out, but in the given use case not very likely and useful.