I really hope WePay destroys PayPal. They have screwed myself and my friends too many times.
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.
Thanks for catching that. We've spent the last week moving into a new office and it must have slipped by as we were getting everything reconfigured. It's been locked down again.
I must admit I didn't know the big domains disabled ssh. Naive/beginner's question: how do programmers work remotely at these companies (if it's allowed at all)? Do they ssh into other (safe) servers, from which a safe transfer is eventually made into the production servers?
You could set it up by allowing sshing to a server on a subdomain something like ssh.xyz.com or vpn.xyz.com and from there can ssh to production servers, which are set up to only allow ssh internally.
It's a matter of setting up VPNs and IP-restricting where you can SSH in from. You can also set up port knocking and other SSH-related security measures. It depends how much convenience you're willing to trade for security.
Practicality trumps everything, after 10+ years of using ssh and trying port knocking and everything else none of it works when you're 4000km away in another country with only a handheld to access the servers.
I think it should probably company policy at a financial institution not to allow someone in a different control on a handheld device to access the servers.
I use layered security (in the sense of servers) with a password lifetime of 10 days. I deal with servers daily and the issue of compromise has been twice in on firewall containers/servers which was fine as the systems in place found it, found the issue with the net facing software and I fixed it. Practicality doesn't mean no security.
Can you require keys AND passwords? I haven't been able to figure out how to get that to function - if passwords are allowed, it lets you in with or without a key, from what I can tell.
I'd be happy to be wrong though!
Generally you VPN in (using two-factor auth for PCI compliance) to a private network and can SSH in from there. Public facing SSH is generally a bad idea. Also it didn't seem like they had any firewall rules preventing brute forcing.
Don't necessarily turn it off. Make sure you've hardened SSH, only do key-based authentication and limit access to specific source IP addresses or use something like fail2ban.
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.
Just out of interest, how many 0day pre-auth OpenSSH vulnerabilities are you aware of? The last publicly disclosed pre-auth OpenSSH vulnerability that if exploited would lead to arbitrary code execution came out in 2006.
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.
> but why SSH and not other 0day for say a VPN or the HTTP server
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?
> - 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.
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.
Even if this is true[1], it never hurts to consciously limit the places where information flows out of your system. The idea is that securing one point is easier than securing n points.
[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.
Most websites out there don't actually require a captcha for signup. Paypal certainly doesn't. (I'm not going to create a fake wepay account to check if/when they do email uniqueness validation.)
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.
White and blue are good colors for your industry, but the current homepage has too much blue above the fold. The blue is slightly too vibrant also. You want to be careful about the saturation of your colors. Vibrant/Saturated colors are subconsciously distracting and unprofessional. The hurdle to trust a vibrant website is much higher.
"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.
The blue is slightly too vibrant also. You want to be careful about the saturation of your colors. Vibrant/Saturated colors are subconsciously distracting and unprofessional.
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'.
Don't host JS on Google? Do you mean libraries like jQuery? I'm curious because we use Google for jQuery and a few other libraries. I've never heard this to be a security issue, and I'm not entirely sure how it would be. Nonetheless, security is all about cost-benefit, it may be worth the security risk for the page load speed increase with Google.
It's a security issue because someone can compromise google's CDN, or cache poison, or DNS poison/hijack that, and can inject malicious JS code into a large number of websites with one attack. If you're running a payment related it pays to be paranoid.
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.