You're missing some basics. For example, I can find out easily what version of Apache/OpenSSH etc you are running (Apache/2.2.11 (Ubuntu) mod_ssl/2.2.11 OpenSSL/0.9.8g mod_wsgi/2.3 Python/2.6.2, OpenSSH 5.1p1). Please turn off the banners that advertise these things. Also, don't run your SSH server off of your Apache box. And use public keys instead of passwords.
You can consult this hardening guide written by the NSA for Red Hat: http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf. Even though you're using Ubuntu, the same general principles apply. Follow that guide to the letter and you will be secure enough until you can afford to higher professional pen testers.
Note that the NSA guide doesn't cover web application security, so you'll need to take other steps to ensure that part of your business is secure.
That's a fine security page (except that it needs to be clear that you're holding on to gmail passwords). But, please remember: if you don't have a security response page, which tells people how to contact you if they find a horrible security problem in your application, they are within our cultural norms to write a very unpleasant blog post about you.
Well, I've got good news and bad news. The good news is I want to use your service. If it works the way it looks like it works, I'd pay you to use it. I'm guessing a lot of other people will think the same thing. That's huge!
The bad news is that "bank-level" encryption and assertions of good intentions are not sufficient for me to give you my Google password. My Google password is one of two that is not recorded anywhere. The second is for the vault that contains my other 575 passwords. I almost edited my original post to be less melodramatic, but on reflection I think it's right. For a cool grand, I would spend the time to completely separate the associated accounts (analytics, webmaster, docs, calendar, talk, voice) and any password reminders that forward into my gmail now into a separate account. Short of that, I just can't do it. I'm selfishly hopeful that Google gives you a way in without needing to store my password.
I'm hopeful google borrows a few ideas for their next features. Sorry, I'm not giving anyone my password. Next time release it as a firefox plugin, or something client-side.
Have you had a vulnerability assessment done?
Do you protect against SQL Injection?
Do you protect against Cross-Site Scripting?
How about Cross-Site Request Forgery?
What preventative measures have you taken to lock down your servers?
I know most users don't care about all of those and you're trying to be friendly by saying you use "bank-level" encryption, but some more info would be nice for those of us that care.
We use the latest in bank-level 256-bit SSL encryption to protect your information, and your passwords are securely encrypted.
Right. 256 bits, like everyone else, like it makes some critical difference over 128 unless you're the freaking NSA, and like anyone even bothers trying to break into a TLS session. Not encouraging.
First thing I always check is whether the site's behind a gateway, so let's try and connect on 22:
$ ssh etacts.com
The authenticity of host 'etacts.com (173.203.202.141)' can't be established.
RSA key fingerprint is ec:c2:2f:fe:ef:7e:06:a3:a5:f0:a3:54:04:79:2a:16.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'etacts.com,173.203.202.141' (RSA) to the list of known hosts.
sailormoon@etacts.com's password:
Permission denied, please try again.
Tsk. Early days I know, but .. if you become popular for storing a large database of people's login creds for gmail .. that's a nice juicy target.
And I actually found the mention that they're encrypting the passwords, like that means anything (the key is obviously somewhere on the server, and once they're in, they're in) to be more worrisome than not.
That you store passwords in the first place is the problem. As a developer, I consider it to be borderline unethical to build such a system in the first place, as it is inherently insecure. Furthermore, it helps to train users that it is ok to enter your username and password into other sites - which makes it easier for phishers and other sites that may have poor security.
Somehow Mint convinced a million people to give them their bank logins. It probably just takes time, credibility, and a really attractive service. Though, hackers might never be your audience.
It's interesting that of all the various Google Data API's (which many use OAuth, I believe) Gmail isn't one of them. I guess that makes sense, since there are protocols like IMAP and POP... but for something like this it would be nice.
The Google Contact API supports OAuth, which is fantastic because so many sites want your email address and password to get contacts (for like invite friend style functionality) but it doesn't appear they store any kind of communication frequency data.
How about an option where the user enters their credentials once per day (or however often they like), directly feeding the polling process, so that their credentials aren't stored?
IANASE[1], but this seems a lot less secure than letting them keep track of your credentials. It seems like an open invitation for man-in-the-middle and phishing attacks. Training your users to (thoughtlessly) enter their credentials over and over seems like a really bad idea.
You should release an app that people can self-host which provides a layer of indirection for IMAP. That is, an IMAP client/server I can run myself. I put my credentials in the client part, and give you an account in the server part. That way I don't need to give you my real credentials password.
Of course, this would limit the reliability of your service to the reliability of my connection, but that's a trade-off I'd be willing to make.
Comments
I want this very, very badly. But they'd have to pay me a thousand dollars to get me to type my Google password in that box.
Same here. When I read the article, this is probably the best email add-on I've seen in a while.
But when it asked for my Gmail password, I just can't type it in. My calendar, email, Android, etc. are all on Google.
My Google and to a slightly lower importance, my facebook account are the most important accounts of my online life.
I'm a co-founder of eTacts. This is a legitimate concern and we do everything we can to address this issue: http://etacts.com/security/
You're missing some basics. For example, I can find out easily what version of Apache/OpenSSH etc you are running (Apache/2.2.11 (Ubuntu) mod_ssl/2.2.11 OpenSSL/0.9.8g mod_wsgi/2.3 Python/2.6.2, OpenSSH 5.1p1). Please turn off the banners that advertise these things. Also, don't run your SSH server off of your Apache box. And use public keys instead of passwords.
You can consult this hardening guide written by the NSA for Red Hat: http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf. Even though you're using Ubuntu, the same general principles apply. Follow that guide to the letter and you will be secure enough until you can afford to higher professional pen testers.
Note that the NSA guide doesn't cover web application security, so you'll need to take other steps to ensure that part of your business is secure.
That's a fine security page (except that it needs to be clear that you're holding on to gmail passwords). But, please remember: if you don't have a security response page, which tells people how to contact you if they find a horrible security problem in your application, they are within our cultural norms to write a very unpleasant blog post about you.
good feedback, we will take care of this.
This was the beginning of a similar episode with 37signals (of which tptacek was a vocal contributor): http://news.ycombinator.com/item?id=803899
Well, I've got good news and bad news. The good news is I want to use your service. If it works the way it looks like it works, I'd pay you to use it. I'm guessing a lot of other people will think the same thing. That's huge!
The bad news is that "bank-level" encryption and assertions of good intentions are not sufficient for me to give you my Google password. My Google password is one of two that is not recorded anywhere. The second is for the vault that contains my other 575 passwords. I almost edited my original post to be less melodramatic, but on reflection I think it's right. For a cool grand, I would spend the time to completely separate the associated accounts (analytics, webmaster, docs, calendar, talk, voice) and any password reminders that forward into my gmail now into a separate account. Short of that, I just can't do it. I'm selfishly hopeful that Google gives you a way in without needing to store my password.
I'm hopeful google borrows a few ideas for their next features. Sorry, I'm not giving anyone my password. Next time release it as a firefox plugin, or something client-side.
The bad news is that "bank-level" encryption and assertions of good intentions are not sufficient for me to give you my Google password
indeed I'd say my google account needs more inventive protection than my bank detail. The chance of misuse is a lot higher.
OK. So you use encryption. +1
Have you had a vulnerability assessment done? Do you protect against SQL Injection? Do you protect against Cross-Site Scripting? How about Cross-Site Request Forgery? What preventative measures have you taken to lock down your servers?
I know most users don't care about all of those and you're trying to be friendly by saying you use "bank-level" encryption, but some more info would be nice for those of us that care.
Yes to all of that. And ..
We use the latest in bank-level 256-bit SSL encryption to protect your information, and your passwords are securely encrypted.
Right. 256 bits, like everyone else, like it makes some critical difference over 128 unless you're the freaking NSA, and like anyone even bothers trying to break into a TLS session. Not encouraging.
First thing I always check is whether the site's behind a gateway, so let's try and connect on 22:
Tsk. Early days I know, but .. if you become popular for storing a large database of people's login creds for gmail .. that's a nice juicy target.And I actually found the mention that they're encrypting the passwords, like that means anything (the key is obviously somewhere on the server, and once they're in, they're in) to be more worrisome than not.
That you store passwords in the first place is the problem. As a developer, I consider it to be borderline unethical to build such a system in the first place, as it is inherently insecure. Furthermore, it helps to train users that it is ok to enter your username and password into other sites - which makes it easier for phishers and other sites that may have poor security.
Somehow Mint convinced a million people to give them their bank logins. It probably just takes time, credibility, and a really attractive service. Though, hackers might never be your audience.
It's interesting that of all the various Google Data API's (which many use OAuth, I believe) Gmail isn't one of them. I guess that makes sense, since there are protocols like IMAP and POP... but for something like this it would be nice.
The Google Contact API supports OAuth, which is fantastic because so many sites want your email address and password to get contacts (for like invite friend style functionality) but it doesn't appear they store any kind of communication frequency data.
How about an option where the user enters their credentials once per day (or however often they like), directly feeding the polling process, so that their credentials aren't stored?
IANASE[1], but this seems a lot less secure than letting them keep track of your credentials. It seems like an open invitation for man-in-the-middle and phishing attacks. Training your users to (thoughtlessly) enter their credentials over and over seems like a really bad idea.
[1] I Am Not a Security Expert
You'd still have to trust their server with your gmail password
You should release an app that people can self-host which provides a layer of indirection for IMAP. That is, an IMAP client/server I can run myself. I put my credentials in the client part, and give you an account in the server part. That way I don't need to give you my real credentials password.
Of course, this would limit the reliability of your service to the reliability of my connection, but that's a trade-off I'd be willing to make.
>and your passwords are securely encrypted.
Just curious, what encryption scheme are you using?
Promising to not be evil is not "doing something" in my opinion.
EVERY company in the world promises to not be evil. Not all of them keep their promise.
I would rather prefer to type-in my contact list than handing over my password. Why don't you make that option available?
Because your contact list doesn't contain frequency information?
Sadly I'm in the same boat as you, if anyone nefarious got my gmail account I think I would have to start a new identity ;)
Maybe everyone here could suggest automatic and periodic exports as a labs feature:
http://groups.google.com/group/gmail-labs-suggest-a-labs-fea...
It's always nice to have a product that would make a killer addition to a Google App. Best of luck to you guys.
Get acquired by Google, problem solved.
... and become the Xobni of Gmail?