Let me start by saying that I like GoGrid. I think they are a viable
player in the cloud computing space, and I hope they do well. I'm
starting this discussion so they and all of us can learn together to
build credibility for cloud computing in general.
We all know that security is only as strong as your weakest link and
you never get a second change to make a first impression. With so
many people already skeptical of cloud computing, we need to make sure
that people's first experience with cloud computing is a positive one.
GoGrid has failed to secure the most basic component of IT security -
customers' passwords. When you try to login to GoGrid's control
panel, the screen doesn't provide any way to retrieve your username
and password. If you lose it, you have to contact customer support to
retrieve it. In and of itself, this is a big oversite.
I contacted customer support through their online live chat support.
My expectation was that they would either point me to a page where I
could go through a process of requesting a password reset or that they
would have to reset my password and the system would automatically
send it to my email address.
The support rep asked for my name, email address, and billing address
for the credit card on file. What happened next, was a complete shock
to me...in the chat window, there was my password in plain text. Not
only did the rep have access to my password (which is completely
unacceptable), but they actually gave it to me without any real
assurance that I was who I said I was.
Getting someone's name, email address, and billing address is about as
easy as it gets - especially in the corporate world.
Bill Gates, bi...@microsoft.com, One Microsoft Way, Redmond, WA 98052
I'm sure Bill isn't a GoGrid customer, but you get the point. As an
industry, we have to be a lot better than this if we expect to earn
the trust of enterprise customers. I know that the GoGrid team is
strong and they'll correct this problem very quickly, but it should be
an eye opener for all of us.
> Let me start by saying that I like GoGrid. I think they are a viable > player in the cloud computing space, and I hope they do well. I'm > starting this discussion so they and all of us can learn together to > build credibility for cloud computing in general.
> We all know that security is only as strong as your weakest link and > you never get a second change to make a first impression. With so > many people already skeptical of cloud computing, we need to make sure > that people's first experience with cloud computing is a positive one.
> GoGrid has failed to secure the most basic component of IT security - > customers' passwords. When you try to login to GoGrid's control > panel, the screen doesn't provide any way to retrieve your username > and password. If you lose it, you have to contact customer support to > retrieve it. In and of itself, this is a big oversite.
> I contacted customer support through their online live chat support. > My expectation was that they would either point me to a page where I > could go through a process of requesting a password reset or that they > would have to reset my password and the system would automatically > send it to my email address.
> The support rep asked for my name, email address, and billing address > for the credit card on file. What happened next, was a complete shock > to me...in the chat window, there was my password in plain text. Not > only did the rep have access to my password (which is completely > unacceptable), but they actually gave it to me without any real > assurance that I was who I said I was.
> Getting someone's name, email address, and billing address is about as > easy as it gets - especially in the corporate world.
> Bill Gates, bi...@microsoft.com, One Microsoft Way, Redmond, WA 98052
> I'm sure Bill isn't a GoGrid customer, but you get the point. As an > industry, we have to be a lot better than this if we expect to earn > the trust of enterprise customers. I know that the GoGrid team is > strong and they'll correct this problem very quickly, but it should be > an eye opener for all of us.
<sudhi.seshach...@gmail.com> wrote: > I noticed this too. I guess, they are still in beta, so hopefully they will > get better in this area.
> thanks > Sudhi
> On 9/5/08, Shane Jones <shanedjo...@gmail.com> wrote:
>> Let me start by saying that I like GoGrid. I think they are a viable >> player in the cloud computing space, and I hope they do well. I'm >> starting this discussion so they and all of us can learn together to >> build credibility for cloud computing in general.
>> We all know that security is only as strong as your weakest link and >> you never get a second change to make a first impression. With so >> many people already skeptical of cloud computing, we need to make sure >> that people's first experience with cloud computing is a positive one.
>> GoGrid has failed to secure the most basic component of IT security - >> customers' passwords. When you try to login to GoGrid's control >> panel, the screen doesn't provide any way to retrieve your username >> and password. If you lose it, you have to contact customer support to >> retrieve it. In and of itself, this is a big oversite.
>> I contacted customer support through their online live chat support. >> My expectation was that they would either point me to a page where I >> could go through a process of requesting a password reset or that they >> would have to reset my password and the system would automatically >> send it to my email address.
>> The support rep asked for my name, email address, and billing address >> for the credit card on file. What happened next, was a complete shock >> to me...in the chat window, there was my password in plain text. Not >> only did the rep have access to my password (which is completely >> unacceptable), but they actually gave it to me without any real >> assurance that I was who I said I was.
>> Getting someone's name, email address, and billing address is about as >> easy as it gets - especially in the corporate world.
>> Bill Gates, bi...@microsoft.com, One Microsoft Way, Redmond, WA 98052
>> I'm sure Bill isn't a GoGrid customer, but you get the point. As an >> industry, we have to be a lot better than this if we expect to earn >> the trust of enterprise customers. I know that the GoGrid team is >> strong and they'll correct this problem very quickly, but it should be >> an eye opener for all of us.
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.
Thanks,
Michael Sheehan
Technology Evangelist for GoGrid
On Sep 4, 11:03 pm, Shane Jones <shanedjo...@gmail.com> wrote:
> Let me start by saying that I like GoGrid. I think they are a viable
> player in the cloud computing space, and I hope they do well. I'm
> starting this discussion so they and all of us can learn together to
> build credibility for cloud computing in general.
> We all know that security is only as strong as your weakest link and
> you never get a second change to make a first impression. With so
> many people already skeptical of cloud computing, we need to make sure
> that people's first experience with cloud computing is a positive one.
> GoGrid has failed to secure the most basic component of IT security -
> customers' passwords. When you try to login to GoGrid's control
> panel, the screen doesn't provide any way to retrieve your username
> and password. If you lose it, you have to contact customer support to
> retrieve it. In and of itself, this is a big oversite.
> I contacted customer support through their online live chat support.
> My expectation was that they would either point me to a page where I
> could go through a process of requesting a password reset or that they
> would have to reset my password and the system would automatically
> send it to my email address.
> The support rep asked for my name, email address, and billing address
> for the credit card on file. What happened next, was a complete shock
> to me...in the chat window, there was my password in plain text. Not
> only did the rep have access to my password (which is completely
> unacceptable), but they actually gave it to me without any real
> assurance that I was who I said I was.
> Getting someone's name, email address, and billing address is about as
> easy as it gets - especially in the corporate world.
> Bill Gates, bi...@microsoft.com, One Microsoft Way, Redmond, WA 98052
> I'm sure Bill isn't a GoGrid customer, but you get the point. As an
> industry, we have to be a lot better than this if we expect to earn
> the trust of enterprise customers. I know that the GoGrid team is
> strong and they'll correct this problem very quickly, but it should be
> an eye opener for all of us.
> 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.
I think one of Shane's point is that support shouldn't have access to clear text passwords at all and should have stronger authentication procedure of the customer (3-4 factor plus).
This single incident might make one think the entire system has same level of protection, which doesn't create more comfort.
I will go out on a limb here and say that it does NOT reflect the
general state of security. As I mentioned previously, all of GoGrid
runs under 128-bit SSL encryption. Some further background. GoGrid is
a product of ServePath who does managed hosting and colocation. We
have been doing this for over 7 years and have very robust security
protocols and procedure for our entire organization (SAS70 certified
as well).
The password delivery over chat is a serious matter that we will
address promptly. I would ask simply that people don't make
assumptions on the quality or security of the product due to a human
interaction (e.g., an action on chat) as it may not reflect the
product itself.
Thanks,
Michael
On Sep 5, 7:33 am, "Khazret Sapenov" <sape...@gmail.com> wrote:
> On Fri, Sep 5, 2008 at 10:24 AM, Michael Sheehan <mich...@servepath.com>wrote:
> > 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.
> I think one of Shane's point is that support shouldn't have access to clear
> text passwords at all and should have stronger authentication procedure of
> the customer (3-4 factor plus).
> This single incident might make one think the entire system has same level
> of protection, which doesn't create more comfort.
Thanks Michael. Just to let everyone know, I did let the support team
know about this issue before posting it to the board, and they said
they would escalate this to the right people.
I would suggest the following:
1. Add a password reset function to the login page that generates a
new, random password and emails it directly to the primary email
address of the main administrator.
2. Eliminate the internal tool that the support team uses to access
customer passwords and train them to redirect people to the automated
reset function.
3. Long term, it would be great if you allowed the administrator to
set their own policies on how passwords could be retrieved/reset. For
example, the user could require both an email address and primary
credit card number be passed to the password reset function. The
password reset function should be able to have access to an encrypted
version of the credit card number to compare to an encrypted version
of the number provided by the user without presenting a security risk.
Another concern that I have is whether or not server passwords stored
inside the control panel are accessible to the support team. I
assumed that when you change a server password inside the control
panel, it would change the account password on the virtual server. I
contacted support after my login failed, and he said that the
passwords stored inside the control panel are not connected to the
virtual servers, and that they were "just for our reference". At the
time, I assumed he meant just for *my* reference. But the more I
think about it, he retrieved my original password for the virtual
server, he didn't reset it. I'm guessing that they have a similar
tool that lets them retrieve passwords for each virtual server
account? If so, that needs to be changed as well.
Thanks again Michael for your quick response and seeing that these
issues get resolved.
-shane
On Sep 5, 7:24 am, Michael Sheehan <mich...@servepath.com> wrote:
> 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.
> Thanks,
> Michael Sheehan
> Technology Evangelist for GoGrid
> On Sep 4, 11:03 pm, Shane Jones <shanedjo...@gmail.com> wrote:
> > Let me start by saying that I like GoGrid. I think they are a viable
> > player in the cloud computing space, and I hope they do well. I'm
> > starting this discussion so they and all of us can learn together to
> > build credibility for cloud computing in general.
> > We all know that security is only as strong as your weakest link and
> > you never get a second change to make a first impression. With so
> > many people already skeptical of cloud computing, we need to make sure
> > that people's first experience with cloud computing is a positive one.
> > GoGrid has failed to secure the most basic component of IT security -
> > customers' passwords. When you try to login to GoGrid's control
> > panel, the screen doesn't provide any way to retrieve your username
> > and password. If you lose it, you have to contact customer support to
> > retrieve it. In and of itself, this is a big oversite.
> > I contacted customer support through their online live chat support.
> > My expectation was that they would either point me to a page where I
> > could go through a process of requesting a password reset or that they
> > would have to reset my password and the system would automatically
> > send it to my email address.
> > The support rep asked for my name, email address, and billing address
> > for the credit card on file. What happened next, was a complete shock
> > to me...in the chat window, there was my password in plain text. Not
> > only did the rep have access to my password (which is completely
> > unacceptable), but they actually gave it to me without any real
> > assurance that I was who I said I was.
> > Getting someone's name, email address, and billing address is about as
> > easy as it gets - especially in the corporate world.
> > Bill Gates, bi...@microsoft.com, One Microsoft Way, Redmond, WA 98052
> > I'm sure Bill isn't a GoGrid customer, but you get the point. As an
> > industry, we have to be a lot better than this if we expect to earn
> > the trust of enterprise customers. I know that the GoGrid team is
> > strong and they'll correct this problem very quickly, but it should be
> > an eye opener for all of us.
Thanks for the details. Your points are exactly what I was thinking as
well. Points #2 and 3 are great as well.
The other suggestions that you have are intriguing as well. The
passwords that are displayed within the GoGrid portal are there for
reference and do not reflect the current state of a password on a
GoGrid server. Think of it as a notepad. You can update it manually
(say, for example, you have a team of developers that you need to
share this information with). We wanted to create a utility that would
be self-serving and automated for when you created a cloud server. We
didn't want to email user/password information for newly created
servers because of the security concerns. So, we developed a slick way
that automagically creates the user/pass combo that populates the
password section. Once you go in to your server, though, it is up to
you to manage them.
In terms of not allowing support to view passwords, this is a tricky
thing. Since we do provide (free) 24x7 support for GoGrid, we needed
to be sure that we could provide support (to some extent) within the
server itself. I can't really talk about the "behind the scenes" magic
that makes that work, but it is a pretty complex and well vetted
process that continues to evolve.
Anyway, thanks for your ideas!
-Michasel
On Sep 5, 8:22 am, Shane Jones <shanedjo...@gmail.com> wrote:
> Thanks Michael. Just to let everyone know, I did let the support team
> know about this issue before posting it to the board, and they said
> they would escalate this to the right people.
> I would suggest the following:
> 1. Add a password reset function to the login page that generates a
> new, random password and emails it directly to the primary email
> address of the main administrator.
> 2. Eliminate the internal tool that the support team uses to access
> customer passwords and train them to redirect people to the automated
> reset function.
> 3. Long term, it would be great if you allowed the administrator to
> set their own policies on how passwords could be retrieved/reset. For
> example, the user could require both an email address and primary
> credit card number be passed to the password reset function. The
> password reset function should be able to have access to an encrypted
> version of the credit card number to compare to an encrypted version
> of the number provided by the user without presenting a security risk.
> Another concern that I have is whether or not server passwords stored
> inside the control panel are accessible to the support team. I
> assumed that when you change a server password inside the control
> panel, it would change the account password on the virtual server. I
> contacted support after my login failed, and he said that the
> passwords stored inside the control panel are not connected to the
> virtual servers, and that they were "just for our reference". At the
> time, I assumed he meant just for *my* reference. But the more I
> think about it, he retrieved my original password for the virtual
> server, he didn't reset it. I'm guessing that they have a similar
> tool that lets them retrieve passwords for each virtual server
> account? If so, that needs to be changed as well.
> Thanks again Michael for your quick response and seeing that these
> issues get resolved.
> -shane
> On Sep 5, 7:24 am, Michael Sheehan <mich...@servepath.com> wrote:
> > 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.
> > Thanks,
> > Michael Sheehan
> > Technology Evangelist for GoGrid
> > On Sep 4, 11:03 pm, Shane Jones <shanedjo...@gmail.com> wrote:
> > > Let me start by saying that I like GoGrid. I think they are a viable
> > > player in the cloud computing space, and I hope they do well. I'm
> > > starting this discussion so they and all of us can learn together to
> > > build credibility for cloud computing in general.
> > > We all know that security is only as strong as your weakest link and
> > > you never get a second change to make a first impression. With so
> > > many people already skeptical of cloud computing, we need to make sure
> > > that people's first experience with cloud computing is a positive one.
> > > GoGrid has failed to secure the most basic component of IT security -
> > > customers' passwords. When you try to login to GoGrid's control
> > > panel, the screen doesn't provide any way to retrieve your username
> > > and password. If you lose it, you have to contact customer support to
> > > retrieve it. In and of itself, this is a big oversite.
> > > I contacted customer support through their online live chat support.
> > > My expectation was that they would either point me to a page where I
> > > could go through a process of requesting a password reset or that they
> > > would have to reset my password and the system would automatically
> > > send it to my email address.
> > > The support rep asked for my name, email address, and billing address
> > > for the credit card on file. What happened next, was a complete shock
> > > to me...in the chat window, there was my password in plain text. Not
> > > only did the rep have access to my password (which is completely
> > > unacceptable), but they actually gave it to me without any real
> > > assurance that I was who I said I was.
> > > Getting someone's name, email address, and billing address is about as
> > > easy as it gets - especially in the corporate world.
> > > Bill Gates, bi...@microsoft.com, One Microsoft Way, Redmond, WA 98052
> > > I'm sure Bill isn't a GoGrid customer, but you get the point. As an
> > > industry, we have to be a lot better than this if we expect to earn
> > > the trust of enterprise customers. I know that the GoGrid team is
> > > strong and they'll correct this problem very quickly, but it should be
> > > an eye opener for all of us.
In addition to Shane's suggestions below, encypt (not just transit via SSL, etc) or hash the password in storage if it's not being done already. Also the email that's being send should never contain both the password and the userid in the same email.
> Thanks Michael. Just to let everyone know, I did let the support team > know about this issue before posting it to the board, and they said > they would escalate this to the right people.
> I would suggest the following:
> 1. Add a password reset function to the login page that generates a > new, random password and emails it directly to the primary email > address of the main administrator.
> 2. Eliminate the internal tool that the support team uses to access > customer passwords and train them to redirect people to the automated > reset function.
> 3. Long term, it would be great if you allowed the administrator to > set their own policies on how passwords could be retrieved/reset. For > example, the user could require both an email address and primary > credit card number be passed to the password reset function. The > password reset function should be able to have access to an encrypted > version of the credit card number to compare to an encrypted version > of the number provided by the user without presenting a security risk.
> Another concern that I have is whether or not server passwords stored > inside the control panel are accessible to the support team. I > assumed that when you change a server password inside the control > panel, it would change the account password on the virtual server. I > contacted support after my login failed, and he said that the > passwords stored inside the control panel are not connected to the > virtual servers, and that they were "just for our reference". At the > time, I assumed he meant just for *my* reference. But the more I > think about it, he retrieved my original password for the virtual > server, he didn't reset it. I'm guessing that they have a similar > tool that lets them retrieve passwords for each virtual server > account? If so, that needs to be changed as well.
> Thanks again Michael for your quick response and seeing that these > issues get resolved.
> -shane
> On Sep 5, 7:24 am, Michael Sheehan <mich...@servepath.com> wrote: > > 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.
> > Thanks, > > Michael Sheehan > > Technology Evangelist for GoGrid
> > On Sep 4, 11:03 pm, Shane Jones <shanedjo...@gmail.com> wrote:
> > > Let me start by saying that I like GoGrid. I think they are a viable > > > player in the cloud computing space, and I hope they do well. I'm > > > starting this discussion so they and all of us can learn together to > > > build credibility for cloud computing in general.
> > > We all know that security is only as strong as your weakest link and > > > you never get a second change to make a first impression. With so > > > many people already skeptical of cloud computing, we need to make sure > > > that people's first experience with cloud computing is a positive one.
> > > GoGrid has failed to secure the most basic component of IT security - > > > customers' passwords. When you try to login to GoGrid's control > > > panel, the screen doesn't provide any way to retrieve your username > > > and password. If you lose it, you have to contact customer support to > > > retrieve it. In and of itself, this is a big oversite.
> > > I contacted customer support through their online live chat support. > > > My expectation was that they would either point me to a page where I > > > could go through a process of requesting a password reset or that they > > > would have to reset my password and the system would automatically > > > send it to my email address.
> > > The support rep asked for my name, email address, and billing address > > > for the credit card on file. What happened next, was a complete shock > > > to me...in the chat window, there was my password in plain text. Not > > > only did the rep have access to my password (which is completely > > > unacceptable), but they actually gave it to me without any real > > > assurance that I was who I said I was.
> > > Getting someone's name, email address, and billing address is about as > > > easy as it gets - especially in the corporate world.
> > > Bill Gates, bi...@microsoft.com, One Microsoft Way, Redmond, WA 98052
> > > I'm sure Bill isn't a GoGrid customer, but you get the point. As an > > > industry, we have to be a lot better than this if we expect to earn > > > the trust of enterprise customers. I know that the GoGrid team is > > > strong and they'll correct this problem very quickly, but it should be > > > an eye opener for all of us.
CSRs (Customer Service Reps) should not have the ability to view any customers' passwords. In fact, all passwords should be "one-way" hashed before they are stored in the secured database that has limited access. Most of the secured transactional oriented sites would allow users to reset the password rather than retrieve the password - perhaps you want to evaluate GoGrid's architecture based on type of applications that would be hosed on the environment. If there is a need for CSRs to impersonate as a customer, they should login with their super id, and this id along with customer id (and operation performed) should be recorded in the database for audit purposes.
Vishal
On Fri, Sep 5, 2008 at 8:36 AM, Michael Sheehan <mich...@servepath.com>wrote:
> Thanks for the details. Your points are exactly what I was thinking as > well. Points #2 and 3 are great as well.
> The other suggestions that you have are intriguing as well. The > passwords that are displayed within the GoGrid portal are there for > reference and do not reflect the current state of a password on a > GoGrid server. Think of it as a notepad. You can update it manually > (say, for example, you have a team of developers that you need to > share this information with). We wanted to create a utility that would > be self-serving and automated for when you created a cloud server. We > didn't want to email user/password information for newly created > servers because of the security concerns. So, we developed a slick way > that automagically creates the user/pass combo that populates the > password section. Once you go in to your server, though, it is up to > you to manage them.
> In terms of not allowing support to view passwords, this is a tricky > thing. Since we do provide (free) 24x7 support for GoGrid, we needed > to be sure that we could provide support (to some extent) within the > server itself. I can't really talk about the "behind the scenes" magic > that makes that work, but it is a pretty complex and well vetted > process that continues to evolve.
> Anyway, thanks for your ideas!
> -Michasel
> On Sep 5, 8:22 am, Shane Jones <shanedjo...@gmail.com> wrote: > > Thanks Michael. Just to let everyone know, I did let the support team > > know about this issue before posting it to the board, and they said > > they would escalate this to the right people.
> > I would suggest the following:
> > 1. Add a password reset function to the login page that generates a > > new, random password and emails it directly to the primary email > > address of the main administrator.
> > 2. Eliminate the internal tool that the support team uses to access > > customer passwords and train them to redirect people to the automated > > reset function.
> > 3. Long term, it would be great if you allowed the administrator to > > set their own policies on how passwords could be retrieved/reset. For > > example, the user could require both an email address and primary > > credit card number be passed to the password reset function. The > > password reset function should be able to have access to an encrypted > > version of the credit card number to compare to an encrypted version > > of the number provided by the user without presenting a security risk.
> > Another concern that I have is whether or not server passwords stored > > inside the control panel are accessible to the support team. I > > assumed that when you change a server password inside the control > > panel, it would change the account password on the virtual server. I > > contacted support after my login failed, and he said that the > > passwords stored inside the control panel are not connected to the > > virtual servers, and that they were "just for our reference". At the > > time, I assumed he meant just for *my* reference. But the more I > > think about it, he retrieved my original password for the virtual > > server, he didn't reset it. I'm guessing that they have a similar > > tool that lets them retrieve passwords for each virtual server > > account? If so, that needs to be changed as well.
> > Thanks again Michael for your quick response and seeing that these > > issues get resolved.
> > -shane
> > On Sep 5, 7:24 am, Michael Sheehan <mich...@servepath.com> wrote:
> > > 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.
> > > Thanks, > > > Michael Sheehan > > > Technology Evangelist for GoGrid
> > > On Sep 4, 11:03 pm, Shane Jones <shanedjo...@gmail.com> wrote:
> > > > Let me start by saying that I like GoGrid. I think they are a viable > > > > player in the cloud computing space, and I hope they do well. I'm > > > > starting this discussion so they and all of us can learn together to > > > > build credibility for cloud computing in general.
> > > > We all know that security is only as strong as your weakest link and > > > > you never get a second change to make a first impression. With so > > > > many people already skeptical of cloud computing, we need to make > sure > > > > that people's first experience with cloud computing is a positive > one.
> > > > GoGrid has failed to secure the most basic component of IT security - > > > > customers' passwords. When you try to login to GoGrid's control > > > > panel, the screen doesn't provide any way to retrieve your username > > > > and password. If you lose it, you have to contact customer support > to > > > > retrieve it. In and of itself, this is a big oversite.
> > > > I contacted customer support through their online live chat support. > > > > My expectation was that they would either point me to a page where I > > > > could go through a process of requesting a password reset or that > they > > > > would have to reset my password and the system would automatically > > > > send it to my email address.
> > > > The support rep asked for my name, email address, and billing address > > > > for the credit card on file. What happened next, was a complete > shock > > > > to me...in the chat window, there was my password in plain text. Not > > > > only did the rep have access to my password (which is completely > > > > unacceptable), but they actually gave it to me without any real > > > > assurance that I was who I said I was.
> > > > Getting someone's name, email address, and billing address is about > as > > > > easy as it gets - especially in the corporate world.
> > > > Bill Gates, bi...@microsoft.com, One Microsoft Way, Redmond, WA > 98052
> > > > I'm sure Bill isn't a GoGrid customer, but you get the point. As an > > > > industry, we have to be a lot better than this if we expect to earn > > > > the trust of enterprise customers. I know that the GoGrid team is > > > > strong and they'll correct this problem very quickly, but it should > be > > > > an eye opener for all of us.
> CSRs (Customer Service Reps) should not have the ability to view any
> customers' passwords. In fact, all passwords should be "one-way" hashed
> before they are stored in the secured database that has limited access. Most
> of the secured transactional oriented sites would allow users to reset the
> password rather than retrieve the password - perhaps you want to evaluate
> GoGrid's architecture based on type of applications that would be hosed on
> the environment. If there is a need for CSRs to impersonate as a customer,
> they should login with their super id, and this id along with customer id
> (and operation performed) should be recorded in the database for audit
> purposes.
> Vishal
> On Fri, Sep 5, 2008 at 8:36 AM, Michael Sheehan <mich...@servepath.com>wrote:
> > Hi Shane,
> > Thanks for the details. Your points are exactly what I was thinking as
> > well. Points #2 and 3 are great as well.
> > The other suggestions that you have are intriguing as well. The
> > passwords that are displayed within the GoGrid portal are there for
> > reference and do not reflect the current state of a password on a
> > GoGrid server. Think of it as a notepad. You can update it manually
> > (say, for example, you have a team of developers that you need to
> > share this information with). We wanted to create a utility that would
> > be self-serving and automated for when you created a cloud server. We
> > didn't want to email user/password information for newly created
> > servers because of the security concerns. So, we developed a slick way
> > that automagically creates the user/pass combo that populates the
> > password section. Once you go in to your server, though, it is up to
> > you to manage them.
> > In terms of not allowing support to view passwords, this is a tricky
> > thing. Since we do provide (free) 24x7 support for GoGrid, we needed
> > to be sure that we could provide support (to some extent) within the
> > server itself. I can't really talk about the "behind the scenes" magic
> > that makes that work, but it is a pretty complex and well vetted
> > process that continues to evolve.
> > Anyway, thanks for your ideas!
> > -Michasel
> > On Sep 5, 8:22 am, Shane Jones <shanedjo...@gmail.com> wrote:
> > > Thanks Michael. Just to let everyone know, I did let the support team
> > > know about this issue before posting it to the board, and they said
> > > they would escalate this to the right people.
> > > I would suggest the following:
> > > 1. Add a password reset function to the login page that generates a
> > > new, random password and emails it directly to the primary email
> > > address of the main administrator.
> > > 2. Eliminate the internal tool that the support team uses to access
> > > customer passwords and train them to redirect people to the automated
> > > reset function.
> > > 3. Long term, it would be great if you allowed the administrator to
> > > set their own policies on how passwords could be retrieved/reset. For
> > > example, the user could require both an email address and primary
> > > credit card number be passed to the password reset function. The
> > > password reset function should be able to have access to an encrypted
> > > version of the credit card number to compare to an encrypted version
> > > of the number provided by the user without presenting a security risk.
> > > Another concern that I have is whether or not server passwords stored
> > > inside the control panel are accessible to the support team. I
> > > assumed that when you change a server password inside the control
> > > panel, it would change the account password on the virtual server. I
> > > contacted support after my login failed, and he said that the
> > > passwords stored inside the control panel are not connected to the
> > > virtual servers, and that they were "just for our reference". At the
> > > time, I assumed he meant just for *my* reference. But the more I
> > > think about it, he retrieved my original password for the virtual
> > > server, he didn't reset it. I'm guessing that they have a similar
> > > tool that lets them retrieve passwords for each virtual server
> > > account? If so, that needs to be changed as well.
> > > Thanks again Michael for your quick response and seeing that these
> > > issues get resolved.
> > > -shane
> > > On Sep 5, 7:24 am, Michael Sheehan <mich...@servepath.com> wrote:
> > > > 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.
> > > > Thanks,
> > > > Michael Sheehan
> > > > Technology Evangelist for GoGrid
> > > > On Sep 4, 11:03 pm, Shane Jones <shanedjo...@gmail.com> wrote:
> > > > > Let me start by saying that I like GoGrid. I think they are a viable
> > > > > player in the cloud computing space, and I hope they do well. I'm
> > > > > starting this discussion so they and all of us can learn together to
> > > > > build credibility for cloud computing in general.
> > > > > We all know that security is only as strong as your weakest link and
> > > > > you never get a second change to make a first impression. With so
> > > > > many people already skeptical of cloud computing, we need to make
> > sure
> > > > > that people's first experience with cloud computing is a positive
> > one.
> > > > > GoGrid has failed to secure the most basic component of IT security -
> > > > > customers' passwords. When you try to login to GoGrid's control
> > > > > panel, the screen doesn't provide any way to retrieve your username
> > > > > and password. If you lose it, you have to contact customer support
> > to
> > > > > retrieve it. In and of itself, this is a big oversite.
> > > > > I contacted customer support through their online live chat support.
> > > > > My expectation was that they would either point me to a page where I
> > > > > could go through a process of requesting a password reset or that
> > they
> > > > > would have to reset my password and the system would automatically
> > > > > send it to my email address.
> > > > > The support rep asked for my name, email address, and billing address
> > > > > for the credit card on file. What happened next, was a complete
> > shock
> > > > > to me...in the chat window, there was my password in plain text. Not
> > > > > only did the rep have access to my password (which is completely
> > > > > unacceptable), but they actually gave it to me without any real
> > > > > assurance that I was who I said I was.
> > > > > Getting someone's name, email address, and billing address is about
> > as
> > > > > easy as it gets - especially in the corporate world.
> > > > > Bill Gates, bi...@microsoft.com, One Microsoft Way, Redmond, WA
> > 98052
> > > > > I'm sure Bill isn't a GoGrid customer, but you get the point. As an
> > > > > industry, we have to be a lot better than this if we expect to earn
> > > > > the trust of enterprise customers. I know that the GoGrid team is
> > > > > strong and they'll correct this problem very quickly, but it should
> > be
> > > > > an eye opener for all of us.
One of the important reasons for using a one-way-hash for passwords is to prevent the original password from being ever discovered or recovered. Part of the security concern is that many people reuse passwords for other services, so if you leak a plain text password, there is a good chance that you could log into other services that the same customers uses.
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. If the support people can reset and supply a new one-time password over a secure chat session or even over email, that could be a completely acceptable risk. If they can recover my password, that makes me cringe...
Brendon.
On Fri, Sep 5, 2008 at 10:15 AM, Michael Sheehan <mich...@servepath.com>wrote:
> Great suggestions! Thanks for the info. I'm not privy to how things > are actually architected so we may be actually doing that.
> -Michael
> On Sep 5, 9:03 am, "Vishal Mehra" <vishal.m.me...@gmail.com> wrote: > > Hi Michael,
> > CSRs (Customer Service Reps) should not have the ability to view any > > customers' passwords. In fact, all passwords should be "one-way" hashed > > before they are stored in the secured database that has limited access. > Most
On Fri, Sep 5, 2008 at 11:40 AM, Brendon Whateley <bren...@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, 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
> On Fri, Sep 5, 2008 at 11:40 AM, Brendon Whateley <bren...@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, 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
On Fri, Sep 5, 2008 at 12:03 PM, Dan Kearns <d...@thekearns.org> wrote: > On Fri, Sep 5, 2008 at 11:40 AM, Brendon Whateley <bren...@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, 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
> -d
That sounds a lot like OpenID. That seems to be gaining traction at the moment and has a bunch of nice features.
Access control and authorization are getting to be bigger hurdles as more stuff moves into the cloud. And the impact of compromise is growing!
> 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.
never heard of it.
seriously though, note the keywords: trust, delegation, usable, and widespread.
Then try to imagine a yodlee or travelocity saying "I know, we'll just use openid"
We can do that with OpenID and OAuth. Actually we can do it with better
granularity.
Cheers
<k/>
From: cloud-computing@googlegroups.com
[mailto:cloud-computing@googlegroups.com] On Behalf Of Dan Kearns
Sent: Friday, September 05, 2008 12:04 PM
To: cloud-computing@googlegroups.com
Subject: Re: GoGrid Needs to Rethink Security
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,
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 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.
> > 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
"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."
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):
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...
For those who have been following this thread, I just posted more
information and some changes that we have put into effect (today) to
mitigate some of the concerns that users have.
> Let me start by saying that I like GoGrid. I think they are a viable
> player in the cloud computing space, and I hope they do well. I'm
> starting this discussion so they and all of us can learn together to
> build credibility for cloud computing in general.
> We all know that security is only as strong as your weakest link and
> you never get a second change to make a first impression. With so
> many people already skeptical of cloud computing, we need to make sure
> that people's first experience with cloud computing is a positive one.
> GoGrid has failed to secure the most basic component of IT security -
> customers' passwords. When you try to login to GoGrid's control
> panel, the screen doesn't provide any way to retrieve your username
> and password. If you lose it, you have to contact customer support to
> retrieve it. In and of itself, this is a big oversite.
> I contacted customer support through their online live chat support.
> My expectation was that they would either point me to a page where I
> could go through a process of requesting a password reset or that they
> would have to reset my password and the system would automatically
> send it to my email address.
> The support rep asked for my name, email address, and billing address
> for the credit card on file. What happened next, was a complete shock
> to me...in the chat window, there was my password in plain text. Not
> only did the rep have access to my password (which is completely
> unacceptable), but they actually gave it to me without any real
> assurance that I was who I said I was.
> Getting someone's name, email address, and billing address is about as
> easy as it gets - especially in the corporate world.
> Bill Gates, bi...@microsoft.com, One Microsoft Way, Redmond, WA 98052
> I'm sure Bill isn't a GoGrid customer, but you get the point. As an
> industry, we have to be a lot better than this if we expect to earn
> the trust of enterprise customers. I know that the GoGrid team is
> strong and they'll correct this problem very quickly, but it should be
> an eye opener for all of us.
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-computing@googlegroups.com
[mailto:cloud-computing@googlegroups.com] On Behalf Of Adwait Ullal
Sent: Friday, September 05, 2008 12:19 PM
To: cloud-computing@googlegroups.com
Subject: Re: GoGrid Needs to Rethink Security
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,
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
> From: cloud-computing@googlegroups.com > [mailto:cloud-computing@googlegroups.com] On Behalf Of Dan Kearns > Sent: Friday, September 05, 2008 12:04 PM > To: cloud-computing@googlegroups.com > Subject: Re: GoGrid Needs to Rethink Security
> On Fri, Sep 5, 2008 at 11:40 AM, Brendon Whateley > <bren...@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, > 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
First I want to commend you on your rapid response on this issue.
Moving quickly to respond to and fix these issues is important. Now
for the bad part.
If passwords have always been stored via one-way hash, how did Shane
get his actual password back?
Also, I know the web chats I've used always ask if I want a transcript
emailed to me. I was once asked to give my password in one of these
chats and thought it very odd and would not do it, because these
emailed transcripts are sometimes sent over the wire in plain text or
cached on the smtp server or thick clients. So there are still holes
even if the web sessions are all SSL.
The customer support rep that I spoke with said that the passwords
were encrypted, but not 1-way hash encrypted. They had an internal
tool that could lookup customer records and decrypt their password if
needed. He didn't mention the exact encryption method used.
Michael, thanks for your blog post and fast action on the issue. Your
open communication about this issue builds confidence that the GoGrid
team takes this seriously and isn't trying to sweep it under the rug.
-shane
On Sep 5, 9:40 pm, randall <rand...@qrimp.com> wrote:
> First I want to commend you on your rapid response on this issue.
> Moving quickly to respond to and fix these issues is important. Now
> for the bad part.
> If passwords have always been stored via one-way hash, how did Shane
> get his actual password back?
> Also, I know the web chats I've used always ask if I want a transcript
> emailed to me. I was once asked to give my password in one of these
> chats and thought it very odd and would not do it, because these
> emailed transcripts are sometimes sent over the wire in plain text or
> cached on the smtp server or thick clients. So there are still holes
> even if the web sessions are all SSL.
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.
> First I want to commend you on your rapid response on this issue. > Moving quickly to respond to and fix these issues is important. Now > for the bad part.
> If passwords have always been stored via one-way hash, how did Shane > get his actual password back?
> Also, I know the web chats I've used always ask if I want a transcript > emailed to me. I was once asked to give my password in one of these > chats and thought it very odd and would not do it, because these > emailed transcripts are sometimes sent over the wire in plain text or > cached on the smtp server or thick clients. So there are still holes > even if the web sessions are all SSL.
> - randall
> --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google > Groups "Cloud Computing" group. > To post to this group, send email to cloud-computing@googlegroups.com > To unsubscribe from this group, send email to > cloud-computing-unsubscribe@googlegroups.com > To post job listing, send email to j...@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-qu... > To collaborate in group's Wiki (http://sites.google.com/site/cloudcomputingwiki/) send request to cloudmodera...@gmail.com > -~----------~----~----~----~------~----~------~--~---
|
