Tag: security

  • Email encoder for not being spidered

    我用Email encoder很久了。以前总是去别人网站上运算一下,拿来就用。如今觉得加密算法很多,我应该筛选一下,并作一个适合我自己的常用的工具。

    因为跟javascript 字符串加解密有关,我首先找到一段程序,试运行了一下,相当不错,据说还支持中文字符串加密以及中文密码。

    function Encrypt(str, pwd) {
    if(str=="")return "";
    str = escape(str);
    if(!pwd || pwd==""){ var pwd="1234"; }
    pwd = escape(pwd);
    if(pwd == null || pwd.length <= 0) {
    alert("Please enter a password with which to encrypt the message.");
    return null;
    }
    var prand = "";
    for(var i=0; i<pwd.length; i++) {
    prand += pwd.charCodeAt(i).toString();
    }
    var sPos = Math.floor(prand.length / 5);
    var mult = parseInt(prand.charAt(sPos) + prand.charAt(sPos*2) + prand.charAt(sPos*3) + prand.charAt(sPos*4) + prand.charAt(sPos*5));
    var incr = Math.ceil(pwd.length / 2);
    var modu = Math.pow(2, 31) - 1;
    if(mult < 2) {
    alert("Algorithm cannot find a suitable hash. Please choose a different password. \nPossible considerations are to choose a more complex or longer password.");
    return null;
    }
    var salt = Math.round(Math.random() * 1000000000) % 100000000;
    prand += salt;
    while(prand.length > 10) {
    prand = (parseInt(prand.substring(0, 10)) + parseInt(prand.substring(10, prand.length))).toString();
    }
    prand = (mult * prand + incr) % modu;
    var enc_chr = "";
    var enc_str = "";
    for(var i=0; i<str.length; i++) {
    enc_chr = parseInt(str.charCodeAt(i) ^ Math.floor((prand / modu) * 255));
    if(enc_chr < 16) {
    enc_str += "0" + enc_chr.toString(16);
    }else
    enc_str += enc_chr.toString(16);
    prand = (mult * prand + incr) % modu;
    }
    salt = salt.toString(16);
    while(salt.length < 8)salt = "0" + salt;
    enc_str += salt;
    return enc_str;
    }
    
    function Decrypt(str, pwd) {
    if(str=="")return "";
    if(!pwd || pwd==""){ var pwd="1234"; }
    pwd = escape(pwd);
    if(str == null || str.length < 8) {
    alert("A salt value could not be extracted from the encrypted message because it's length is too short. The message cannot be decrypted.");
    return;
    }
    if(pwd == null || pwd.length <= 0) { 
    alert("Please enter a password with which to decrypt the message.");
    return;
    }
    var prand = "";
    for(var i=0; i<pwd.length; i++) {
    prand += pwd.charCodeAt(i).toString();
    }
    var sPos = Math.floor(prand.length / 5);
    var mult = parseInt(prand.charAt(sPos) + prand.charAt(sPos*2) + prand.charAt(sPos*3) + prand.charAt(sPos*4) + prand.charAt(sPos*5));
    var incr = Math.round(pwd.length / 2);
    var modu = Math.pow(2, 31) - 1;
    var salt = parseInt(str.substring(str.length - 8, str.length), 16);
    str = str.substring(0, str.length - 8);
    prand += salt;
    while(prand.length > 10) {
    prand = (parseInt(prand.substring(0, 10)) + parseInt(prand.substring(10, prand.length))).toString();
    }
    prand = (mult * prand + incr) % modu;
    var enc_chr = "";
    var enc_str = "";
    for(var i=0; i<str.length; i+=2) {
    enc_chr = parseInt(parseInt(str.substring(i, i+2), 16) ^ Math.floor((prand / modu) * 255));
    enc_str += String.fromCharCode(enc_chr);
    prand = (mult * prand + incr) % modu;
    }
    return unescape(enc_str);
    }

    转念一想,我把问题搞复杂了,对自己没什么好处。我的Email encoder用得着这么复杂吗?毕竟我想保护的又不是名人的Email address。所以我改用我自己的方式——采用双重url encode,在第二重url encoding时,encode全部字符(含字母和数字)。

  • Useless Gift

    汇丰把McAfee Security三用户版12 months subscription大派送,我也有一份。

    可是对我来说没什么用啊,F-Secure我都有lifetime subscription了,要卖咖啡干什么?

  • Change WordPress Table Prefix

    WordPress 安全白皮书里倡议其中一条是采用别人猜不着的数据表前缀。

    想必很多WordPress Blog安装时都是采用默认的数据表前缀”wp_”,那么要让”wp_”迁移到”unguessable_”,要做三部分工作:

    1. 修改表中数据,就WordPress当前版本2.6.5而言,有三处要改
      1. 在表”wp_usermeta”中,”meta_key”字段,把”wp_capabilities” 改为 “unguessable_capabilities”
      2. 在表”wp_usermeta”中,”meta_key”字段,把”wp_user_level” 改为 “unguessable_user_level”
      3. 在表”wp_usermeta”中,”option_name”字段,把”wp_user_roles” 改为 “unguessable_user_roles”
    2. 重命名数据表(RENAME TABLE tbl_name TO new_tbl_name[, tbl_name2 TO new_tbl_name2] …)
    3. 修改wp-config.php,$table_prefix = “wp_” 改成 “unguessable_”

    还不算复杂吧。有个plugin据说能帮你自动迁移表前缀,但我没试过,毕竟表前缀前年改一回,何必依赖一个素不相识的plugin呢?

    顺便说一句,如果不做第一部分工作(修改表中数据),前台能可以工作,但后台会有”You do not have sufficient permissions to access this page.”,这错误提示很容易让人联想到密码的hash变了,是老密码无法使用了吗?其实不是,错误跟密码无关,密码还是那个密码。

  • safe_mode

    我想用script.php访问文件系统,但又想把script.php能访问权限限制在script.php owner 的权限内(而不是apache的权限)。今天才知道把safe_mode turn on就可以,真是又高兴又痛苦,因为很久以前我就想限制script.php的访问权限了,不知道怎么,当时我得出的结论是php 以cgi模式安装才能做到权限检查,sapi模式是做不到的。可能fastcgi过分宣传它的安全特性给我造成一种错觉,其实就文件访问权限来说,sapi一样安全。

    同样也是很久以前,见论坛上有个好学的人想要一个免费的空间体验一下xoops,对于好学的人我总想热心帮忙的,况且我又不用额外支出,何乐而不为。无奈我的服务器的designer做的初始设置不是针对share hosting的,safe_mode default off。这样把服务器分给别人用我总归不放心,所以最终没有划空间给好学之士。

    safe_mode=on,真就这么简单!

  • It’s all Flash’s Fault

    不经意中,电脑被装上了Flash 10。等我发现magento后台不能浏览和上传文件时,我怎么也没把原因和Flash 10联系起来。

    首先我以为是magento 1.1.5升级到1.1.6造成的,因为我在1.1.5还成功上传过文件。当我专门为此搞了个试验,全新安装了一个magento 1.1.5来上传图片,还是无功而返。

    浏览器提示javascript出错,可是我实在想不明白为什么以前可以,现在不可以。为此浪费了无数个晚上,终于让我找到了答案,Flash 10!

    Flash 对此的解释冠冕堂皇:为了安全,Flash 10不再允许间接调用文件浏览对话框,文件浏览对话框只能由鼠标动作触发。很不幸,作为magento的上传部件,SWFUpload采用的是间接调用的方式,落入了Flash 10的打击范围。

    我本来就不喜欢Flash,这次Flash 10又浪费了我这么多时间,magento至少被我拆装了3次!尽管它有千万个安全理由,我还是对它敬而远之。

  • Block Ad By Hosts

    Internet上充满了垃圾广告,更有一些phishing广告。今天我发现有个细心的人整理了一份广告商所使用的域名清单,把它添加到hosts文件里,就不怕来自这些域名的广告在你屏幕上蹦出来了。只是:

    • Google Adsense 的广告也在打击范围之内,而我对Google的文字广告并不反感;
    • 我浏览的网站中,中文广告占很大比例,质量普遍不高,这份清单便宜了中文的广告商,对中文用户有欠照顾。

    这个方法很简单,难得的是有心人在整理,大家就坐享其成了。因为全部是指向localhost,所以就算有心人判断失误,也不会有什么危害,更不会有DNS劫持发生。

    # This Hosts file has been altered to block ad servers.
    # To restore the file just
    # delete everything below the first entry or rename hosts.nbk
    # to hosts and move it to the proper directory.
    # Updated: scroll down for date stamp
    # This is an ad blocking hosts file compiled by
    # Mike Skallas (user245 (at) hotmail.com)
    # Available at http://everythingisnt.com/hosts.html
    # Copyright 1999-2007. Please do not redistribute, use above link.
    # Free only for Residential/Non-Profit use.
    # Just add ‘127.0.0.1 ADSERVER’ to the bottom to continue the list.

    因为列表很长,竟然超过WordPress Post字数限制,直接post需要修改”wp-includes/default-filters.php” file,

    commenting

    //add_filter(‘the_content’, ‘wpautop’);

    这么做还不知道对WordPress有什么副作用。还是做一个单独的文件让大家下载吧,hosts.

  • WorldPay的安全隐患

    越来越不喜欢WorldPay了。最近发生的几件事情让我觉得它降格为业余级的payment service provider。

    首先是cardholder authentication事件

    其次,除了cardholder authentication升级之外,WorldPay最近老说在升级系统,有关升级的邮件通知发了一封又一封。不过我没觉得任何实质性的升级,这就让人在收到通知时觉得很烦。WorldPay的各种升级不光不合并一次完成,而且总是不能按预定时间完成。Cardholder authentication就延期了至少两次,最后实施了还是个半拉子工程。

    再次,今天发现WorldPay和WorldAccess payment server当机两次,不过每次时间不长。

    最后,也是最重要的,WorldAccess多了个安全隐患:card number, cardholder’s name, security code, 等等,这些敏感信息input box竟然没有使用 autocomplete=’off’ 属性,在浏览器开启auto complete的情况下,我的浏览器已经cache了一大堆本不该存储的敏感信息。

  • elong的安全隐患

    我对国内商家搞的消费积分已经没有兴趣了。所以,当我要在elong订酒店和机票时,我把积分机会送给一个好友。好友让我在elong报出他的手机号码和姓名即可。

    我选择电话预订,预订过程很顺利,到最后一步选择如何付款和出票时,我说货到付款,接线小姐说如果邮寄可以三倍积分。但邮寄意味着我的在电话里付款, 我没有中国银行卡可以让elong扣钱,接线小姐提醒我,这个elong账号下关联一张银行卡,我尖叫:这不是我的银行卡,您可千万别扣里面的钱。

    随即我想到,elong并不验证用户身份,这意味着:任何人只要知道elong用户的手机号码和姓名,就可以动用他项下的银行卡?!

  • cardholder authentication是吃素的

    我还没来英国的时候,就听说这里信用卡付款时不需要密码即可完成网上支付,当时我已经用中国的银行卡在中国的网上消费过几次,我觉得中国的银行卡的网上消费方案还是安全的,所以一对比英国的网上消费,我觉得很不可思议,在金融、网络技术领域都走在中国前面的英国,信用卡消费竟然不需要密码?!这个漏洞太大了,太可怕了。

    来英国久了以后,我也渐渐接受了这个事实:所有信用卡消费都不需密码,全凭几个security questions保证持卡人的安全(这大概也是英国人和西方国家很看重隐私的一个原因)。

    又过了一段时间,Master推出了MasterSecurity,Visa推出了VerifiedByVisa,很多payment service providers开始实施cardholder authentication,顾客在付款时回答完常规的security questions之后还要回答从authentication password里随机挑选的三个字母。如果所有的payment service providers都实施了cardholder authentication,付款不需密码的漏洞在我看来算是堵上了。

    最近,paymenet service providers的大哥大之一worldpay宣布实施cardholder authentication,我很高兴,可随即我发现worldpay实施cardholder authentication不够彻底——在顾客在付款时回答完常规的security questions之后,worldpay会给顾客一个选择,也就是说顾客可以option in or out cardholder authentication。这样还不是老方一贴?安全性增强在哪里?不过我猜测worldpay给顾客选择是过渡期的方案,让顾客熟悉之后,最终cardholder authentication全面实施,不会把选择权留给顾客的。

    今天,我又发现一件更离奇的事情,我收到了ebuyer一份“订单也被受理”的通知,事情的起因得从上周三我为公司订购一块usb wireless ethernet card说起。我先在ebuyer上选了一款,付款进行到最后一步碰到cardholder authentication,我使用的是公司信用卡,cardholder authentication security password不是我设的,我一看ebuyer的payment service provider要cardholder authentication,我只好终止了付款转而向boardbandbuyers买了一块usb wireless ethernet card。boardbandbuyers的payment service provider不需要cardholder authentication,所以订单一下子就通过了,第二天货也收到了。

    如果说worldpay还在过渡期,cardholder authentication可以被option out还情有可原,但ebuyer的cardholder authentication岂不更是形同虚设?明明没有完成全部付款过程,ebuyer仍可以借记cardholder,这个安全漏洞更大。

    作为商家,cardholder authentication的实施给顾客付款制造了一点障碍,似乎对商家不利(比如我的订单从ebuyer逃到了broadbandbuyers),但cardholder authentication的anti-fraud也是为了保护商家。我在这里倒不想进行cardholder authentication的利弊分析,只是觉得cardholder authentication作为一项安全屏障,一旦实施,就应该把它落实到实处。