Once again, "cloud" doesn't mean "lol, we don't need to know about servers!"
The other part of me wants to say, "You have nine million dollars in funding. Figure shit out. This isn't a game."
Then spend the time to properly look at your information security requirements and develop a plan to comply with them.
If you just turn off SSH you're going to have a lot of pain with little gain or loss if it's properly configured.
I'm not saying that SSH 0day doesn't exist, but why SSH and not other 0day for say a VPN or the HTTP server? I think I see what you're saying, perhaps that SSH 0day is more valuable and less likely to be publicly disclosed but without any data on attacks in the wild, someone at wepay needs to make a risk decision.
My main point isn't that they shouldn't harden their platform, on the contrary I think they should, but they need to do so in a structured manner that doesn't leave them with a bigger mess to deal with. Hardening SSH isn't hard, hardening an IPSEC 2FA VPN is going to be a different story.
More hosts have SSH than VPN available. SSH is pretty much standardised in comparison to VPN. VPN touches mostly certificates and network interfaces, while SSH touches the whole authentication stack, so there's a possibility of exploiting whatever pam environment you're using. Also, you can drop root in most VPN solutions, but not in SSH (by design).
Sure - hardening SSH is enough and most likely thing to do in case of standard servers. But if you're providing some special services... why not add the special protection?
Does this really matter if a site only allows 1 registered user per email address? I can farm this information by trying to sign up a new account.
[1] I don't doubt the flow of information, but the rate at which that information can be leaked through a signup page can be severely limited compared to a password recovery page.
can you be more specific about how we can improve the home page? we're constantly trying to improve it, but our oldest (and admittedly ugliest) one always converts the best. tell me the dominant page color and i'll know which version you're looking at.
"WePay helps you collect, manage, and spend money." should be displayed above the fold and have embedded screenshots or an embedded video nearby. I don't recommend popping it up in a lightbox.
Include a "create account" link near your "Sign in" link. The top right corner is prime real estate and needs a call-to-action for current users and potential users.
The site seems segmented because of the various different styles and content widths used. I found three different widths so far (1010px, 960px, and 770px).
The logo needs to go. It's really bad.
Move "featured in" to the bottom.
Move "What kinds of groups are using WePay?" up more. Remove the italics on the links.
Take a look at this: http://i.imgur.com/4zHX7.png - I threw it together in 5 minutes, so don't judge it too much. White is the primary color here and you'll notice that it is visually easy to follow. Looking at the current WePay is actually straining on the eyes.
This is completely subjective though. To me, for instance, We Pay's current webpage looks like a site I might use for the scenarios described in the NYT article, like a way to collect payment among a group of friends. Your mock-up looks like the site of a bank or mutual fund, which is exactly not the sort of site that comes to mind for the purpose. Again, this is completely subjective - I just don't think there is any way to justify something as vague as 'vibrant is unprofessional'.
cool mockup. perhaps we'll try it out and see how the conversions look.
thanks!
The homepage layout is all wrong though. Poor element placement, messy typography, and the color scheme is off. It looks amateur and unpolished. All those SEO'd subpages are worthless if they don't convert.
Also:
- Upgrade to Nginx 0.7.67, there was a lot of bug fixes in 0.7.65 and 0.7.66.
- Limit the number of login attempts to prevent brute forcing.
- Don't show "That email address was not found" when someone tries to recover a password. You are giving out too much info, which can be used maliciously.
- Block scraper/vuln scanner/curl scripts by user-agent to keep away the script kiddies and botnets.
- Don't host your Javascript on Google. This gives hackers another possible point of entry. It's probably safe, but you're better off limiting points of entry.
- Use mod_rewrite as an additional layer of security. You'll need to slightly modify it to make it work with Nginx.
- Remove "access info anytime" and "post to my wall anytime" when signing up with Facebook.
- Limit SSH access by IP address.
Feel free to contact me if you need help.