密码为什么明文存放

 

很早就写过一篇blog,说到过,你的密码应当一次一密,至少某些密码泄露时不至于波及太广。结果这次CSDN不幸中枪。我不去讨论多少人急急忙忙修改密码,多少人数据泄露,单说说为什么很多时候密码是明文存放的。

就我有记忆以来,我写应用就从来没有明文存放过密码。最起先是md5方式存放。md5可以让你找到hash值,有的时候也会被用于穷举。但是无论如何,md5密码本身比明文安全很多。后来改成了challenge-response验证模式,也是用md5做的hash后进行c-r的。再后来,md5的碰撞冲突的论文出来,后面用的多数都是sha256了。从头到脚,我就没做过密码明文存放,并且,我认为这是正常程序员最起码的修养。(当然,明文存放的代码不是没有,不过那是调试模式) 但是现在我所知,很多系统的身份验证都是密码明文存放的,为什么?其实我不大理解。不过有时候问起,有些人和我说了几个我觉得不是搪塞的理由,现在抄录如下,告大家知。

1.明文密码没法应付检查。大家知道互联网审查,有时往往会一个电话过来,要XX用户的密码。如果你没法给出,上头就认为你不配合,事情各种难搞。作为审查机构的老板,当然没必要知道明文密码的危害。他们只知道,我要密码,为什么不行。所以,悲崔的程序员们就往往会得到一条死命令,保存明文密码。

2.压根不知道明文密码有什么问题。中国的互联网有太多的没基础的新人,从石头的缝隙中顽强的生长出来。这不是坏事,坏事的是这些人往往会在一些基础问题上出现奇怪的毛病。例如有些程序员,写程序很快,但是居然从来不知道密码明文存放会导致什么问题。更神奇的是,这些人中,有一家银行…

3.自信暴棚的混帐。有些人的自信总比别人强,而且强在莫名其妙的地方。例如:我的服务器肯定是没问题的,所以我的密码一定要明文存放。如果不,就是质疑我的技术。

实话说,这种人真是少数中的少数。

4.遗留系统。很多系统设计的时候因为某个其他理由,使用了明文密码。等后来这个理由不存在了,密码系统升级成了一个困难。因为密码系统太重要了,所以在没有太大利益的情况下,总是倾向于不修改系统。但是有什么足够利益来推动系统修改呢?用户安全问题在发现前不是一个问题——好比这次的CSDN,不是被暴出来的话就根本不会被当作一个问题。系统的管理者,每个人都没有足够的动力去修改系统。

5.世界的阴暗角落。有的时候,程序员/老板明文存放的理由,是为了方便盗窃用户其他网站资料。例如我所知的某钓鱼案例,你注册网站,就提供很多免费服务,网站看起来也很靠谱——除了后来突然爆出这家网站其实暗地中用你的生日/密码猜解信用卡/银行卡密码,大家才突然发现,这家网站其实根本没有在美国注册,而是一个听都没听说过的国家。

而且很多网站提供从其他网站导入之类的功能,更加的危险。以前经常爆出twitter密码被窃取,主要就是因为OAuth开放以前,twitter上的第三方应用需要提供原生密码,导致很多小应用的目的其实就是收集密码…

6.为了给用户提供方便。这个理由和上一个很类似,不过不是为了某些险恶的目的。而是客户经常要求——为什么我不能做XX事,为什么我不能blahblah。好吧,为了让你能,我们就必须保存明文密码。

明文密码的保存原因很多,不过结论都是一样的。在任何网站/服务上,你绝对不能使用同一个密码,零级密码除外。尤其请注意,不要在两家银行使用同样的银行卡密码/网银密码,原因不说。

从未来进化的角度说,密码的未来进化趋势是核心授权体系。就是你要向某个网站验证身份,只需要向身份验证商验证,剩下自动完成。现在的openid就是一种解决方案。密码都没了,还谈什么泄露呢?同时,实体交互和授权的精细划分也是一个趋势。某个网站访问别的网站的数据的时候,会形成一个访问令牌。这个令牌对需要访问的内容详细写明,并且需要用户授权。OAuth就是这个趋势的代表。另外一个趋势是利用某个足够安全的设备作为以上两者的终端载体。目前这个设备用的是手机,可是——手机不是一个足够安全的设备。也许这会是下一个XX门的隐患吧。

关于Apache默认编码错误,导致网站乱码的解决方案

最近经常有同学在使用LAMP/WAMP时,遇到这样的编码错误问题:

A网站程序编码UTF-8编码安装成功,运行成功。

B网站程序编gb2312也要安装在同一服务器上。

这样就出现问题了,Apache默认编码UTF-8在解析A网站的时候没有任何问题,当运行B网站时出现的”蝌蚪文”乱码问题。

单纯的修改Apache默认编码为gb2312这样就导致A网站出现”蝌蚪文”。

问题分析:

如果你在网上搜索 “apache配置”,搜到的页面大多都会建议你在httpd.conf中加上这么一句:AddDefaultCharset GB2312。

对于新手而且是只用GB2312编码的开发人来说,这么做是ok的。但是如果要想使用UTF-8字符集的话,比如 在test.php文件中需要有 meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″ 这段代码。

这时你再打开浏览器访问test.php页面的话,你看到的是正确的页面。但是如果实际上浏览器还是以GB2312编码解释从服务器返回的response,为什么呢?原因是浏览器是根据http应答消息头部中的 Content-type: text/html; charset=GB2312 来决定使用何种编码解释应答,也就是说apache服务器仍然用GB2312编码传递数据。

所以说如果apache的默认字符集被设置成了GB2312,即使在页面中声明使用UTF-8编码,apache服务器还是会按照GB2312编码来传送http response。没关系,我们把AddDefaultCharset GB2312 改成 AddDefaultCharset UTF-8,看看什么结果?

如果你看到乱码恭喜你,你还知道是乱码问题;如果你看到是空白页面,那么你就惨了,你可能会以为这是其他什么原因造成的,而不会从编码的角度去考虑怎么解决问题。这是为什么?原因在于php文件本身是用系统字符集来编码的,中文的windows XP都是用GB2312,每一个文件头部都有字段指示该文件是用何种方式编码的。当apache接到浏览器的请求后,会让php去解释所请求的页面,比如 test.php。php会识别出test.php的编码方式是GB2312后(就像我们用javac编译java源文件时,编译器默认用系统编码读源文件里的内容。

如果源文件不是用系统编码来保存的,可以用命令javac -encoding指定具体的编码),把数据以GB2312的编码格式传递给apache,而apache服务器不会改变从php传来的数据,只是在应答消息头部中把字符集设置成UTF-8: Content-type: text/html; charset=UTF-8. 也就是说你传递的是GB2312编码的数据,而浏览器却以UTF-8编码来解释应答消息。

由于UTF-8为3个字节表示一个汉子,而普通的GB2312或BIG5是两个。页面输出时,由于上述原因,出现半个汉字的情况,这时该半个汉字会和的>结合成一个乱码字,导致IE无法读完的话,会发现实际上整个叶面全部已经输出了。如果使用的是Mozilla、Mozilla Firefox、Sarafi的浏览器这不会造成这个问题,而是一堆乱码。这是由于Firefox浏览器和IE解析网页编码的策略不同产生的。OK,我们把test.php以UTF-8保存,再用浏览器访问时,就没有问题了。

可这样做,会使得apache目录下的所有web应用只能用同一种编码。如何搞定?

解决办法:

首先,可以使用AddDefaultCharset off来关闭默认文件编码,这样apache服务器就不会在http应答消息头部设置charset,只是设置Content-type: text/html. 而浏览器就会依靠html文件中设置的harset来决定编码。

其次,脚本php.ini文件中的default_charset = “UTF-8″作用同httpd.conf文件,把该行注释掉,使php自动识别文件的编码方式。

这样不论你用什么编码方式,只要test.php中的meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″ 与你test.php文件编码方式相同,就不会产生乱码问题。用户提交数据的编码浏览器提交的字符编码由客户端的characher encoding决定。

例如,当前浏览器的编码是Gb2312,用户提交数据后,无论apache设置的编码方式是GB2312还是UTF-8,这时在服务器端接收到的仍是以Gb2312编码的数据。

如果要在返回页面上显示用户刚才提交的数据,而该页面是用UTF-8编码的或者要在数据库中存储的用户提交的数据,而数据库是UTF-8编码的,那就要做字符转换了。

 

转载自:http://www.cnblogs.com/wendywu/archive/2011/12/06/2278537.html

浅析PHP模板引擎之二

上篇文章我简要的介绍下模板引擎的运行机理,但是过于简单不太实用,下面我继续扩展这一问题,并使它成为轻量型引擎。

首先我们建立三个目录 ./templates ./templates_c    ./lib 这三个目录分别放模板文件、经过编译后生成的文件、引擎代码文件

下面放上运行原理图:

下面写上各个部分代码:

1.模板引擎template.class.php代码:

< ?php  class template{  private $template_c;  private $data=array();  public function __set($name,$value){  if(!array_key_exists($name,$this->data)){
$this->data[$name]=$value;
}else{
$this->data[$name]=$value;
}

}
public function display($templatename){
$this->template_c=file_get_contents('./templates/'.$templatename);
foreach($this->data as $name => $value){

$this->template_c=str_replace('{'.$name.'}',$value,$this->template_c);

}
echo $this->template_c;

}

}

模板test.tpl代码:

我的名字是 {name}
 手机号 {telephone}
 性别{sex}
 口头禅是{say}

index.php代码:

< ?php  Header('Content-type:text/html;charset=utf-8'); require_once  "./lib/template.class.php"; $template= new template; $template->name="lvxinwei";
$template->telephone=15151827622;
$template->sex="男";
$template->say="我勒个去";
$template->display('test.tpl');

显示效果:
我的名字是 harold
手机号 151518276xx
性别男
口头禅是我勒个去
在第三节,我会继续扩展该问题,使之能进行智能化的页面缓存;

浅析PHP模板引擎运行的机理

PHP有相当多的模板引擎,比较出名的也是笔者比较喜欢的有smarty引擎。

模板引擎的机理是分离了逻辑代码和外在的内容,提供了一种易于管理和使用的方法,用来将原本与HTML代码混杂在一起PHP代码逻辑分离。简单的讲,目的就是要使PHP程序员同前端人员分离,使程序员改变程序的逻辑内容不会影响到前端人员的页面设计,前端人员重新修改页面不会影响到程序的程序逻辑,这在多人合作的项目中显的尤为重要。

下面我通过编写的一个类简要的说明运行机理。

首先我说下大致的使用过程:

1.引入模板引擎,可以通过类中的–autoload()方法自动加载相应类。

2.给相应的要生成的动态内容赋值。例如在smarty中通过$smarty->assign(“name”,$value);给name赋予$value值,但是查询
name的值的过程交给程序员做。

3.调用方法生成动态内容。$smarty->display(“test.tpl”);

下面写上我写的一个缩小型模板引擎

class template {

private $vars=array();
public function setattributes($name,$value){
$this->vars[$name]=$value;

}
public function getHtml($html){
foreach($this->vars as $name=>$value){
$html=str_replace(‘{‘.$name.’}’,$value,$html);
}
return $html;

}
}
$template =new template;
$template->setattributes(“name”,”lvxinwei”);
echo $template->getHtml(“I am  {name} “);

可以看到我输入“ I am {name}” 输出“my lvxinwei”;

原理就是将变量值以key-value对储存起来。然后处理输入用键值替换键名。

当然这个引擎不是很实用但是说明了模板引擎运行机理。