一、安全性和可用性思考
任何一个系统都需要考虑安全性和可用性，在理想情况下系统都要满足这两点。有时安全性和可用性会相互制约，比如为了满足众多客户的需求，系统所采用的必要手段无法达到绝对安全（即0风险）。或者反过来说，为了达到绝对安全，需要舍弃一些必要的功能，或者这些必要功能需要修改成花费大量代价来达到绝对安全，这需要我们在这两者中做出抉择。
比如，邮件系统需要对外开放143和25端口，因为客户端软件（foxmail/outlook之类）需要连接这些端口进行邮件的收发，如下图foxmail设置界面：
图一
但是在很多安全扫描工具或者安全提供商的角度上，对外开放这些端口是非常危险的，一个原因是邮件在这些端口传输往往是未加密的，这样可能在网络传输中被第三方黑客窃取。解决上述问题，最好的方式是开启SSL/TLS加密。宏观上说，客户端会用SSL/TLS方式将数据加密然后在网络上传输来保证数据安全。我们系统对外提供默认域名已经支持SSL/TLS，如果您要使用自己公司的域名，需要将证书提供给我们。但是对于绝大多数想要使用自己公司的域名但又没有对应域名证书的客户需求情况下，143和25端口还是必须要对外提供的。如果为了做到绝对安全，143和25端口不对外开放，则众多客户将无法正常使用邮局服务。此外，网页访问方式对外提供的80端口和https的443端口也是同理。
所以考虑当可用性和安全性互相矛盾的情况下，我们需要考虑如下2点：
1.当一个对外提供的功能是必须的，但无法保证绝对安全（或会采用非常大的代价去实现）的情况下，有没有此功能外另外一种方式来防护的。比如上述143和25端口可以采用SSL/TLS方式来解决，http的80端口可以用https的443端口来解决。
2.当一个对外提供的功能是必须的，但无法保证绝对安全（或会采用非常大的代价去实现），也没有其他方式来防护的，退而求其次，是否能做到基本安全。比如一些页面样式数据，即使在网络传输中被第三方黑客获取，是否会造成更危险的安全问题。
我们系统会根据上述的2点来权衡可用性和安全性。
二、网页登录页面说明
1.你们的密码没有在浏览器中用js方式加密？
图二
虽然我们邮箱系统和后台管理系统在登录时都会对密码加密，但是这种方式是有局限性的。密码在浏览器使用js进行加密，这个手段的初衷是为了密码在网络传输时即使被黑客获取也无法解密。这个手段的具体意思如下图：
图三
浏览器通过js把密码加密后在网络中传输，第三方黑客在网络中获取到的是密码加密后的字串，这样黑客就无法通过加密字串来还原成客户原始密码。但是不幸的是，上述这种方案无法解决安全问题。我们可以参看下图来理解：
图四
在图三中黑客获取到的密码加密字串（密文）根本无需解密，而是和图三中客户浏览器发起请求一样，将密文直接请求到邮局服务器，这样也就能正常登录。虽然密码在网络中加密传输不被解密，但是黑客将这个加密密码直接提交上服务器就和正常用户登录方式一样，也能够完成登录。
此外，加密方式写在浏览器js端，意味着加密方式是对外完全公开的（任何人都能看到），这样也无法做到较好的安全性。
还有一个问题就是加密方式可能无法满足系统可用性，比如浏览器采用md5或者sha1这样的密码加密手段传输，但如果我们数据库不是以md5(或sha1)方式存储（其他加密方式存储），这样我们的系统一定要将浏览器提交上来的md5（或sha1）密码解密然后和数据库中的密码想比较，但是这两个加密方式无法解密（不可逆），系统则无法正确判断用户是否密码正确。
为了能够更好的实现安全性，我们建议用户使用SSL方式来使用我们网页邮箱系统，这个遵循上文提到的安全性和可用性考虑的第一点。用户用https的方式来访问我们系统，然后来抓取https（即SSL）的数据包来证明密码是在网络中加密传输的。注意：测试时不要用http（不开启SSL）的方式来抓包。
2.你们的cookie怎么没有使用secure属性？
有些用户朋友使用安全工具扫描时会得到某些cookie没有设置secure属性。cookie的secure属性的目的是在https（即SSL）情况下才会提交到我们服务器端，在http（非SSL）情况下无法提交到我们服务器上。我们当然希望用户都使用SSL的方式来访问我们的系统，但是此邮箱系统还是有大量采用http（即非SSL）方式来访问，如果cookie都设置了secure属性，则对于这些大量使用http协议的用户将无法正常运行。这个就类似本文开头论述的143和25端口的例子。同样您可以使用SSL的方式访问我们的网页系统，因为数据包在网络传输前使用非对称加密，cookie和上文的密码所在的数据包都会已加密的方式传输，保证数据安全性。
