我的分享

`

  • Zypr将Siri带给每一个人
    发布于: November 8, 2011
    来源: Solidot
    先锋（Pioneer）宣布了提供语音控制的在线免费服务平台Zypr，让用户可以通过语音访问在线服务如地图、导航、社交媒体、日历和天气等。利用Zypr APT，开发者可以让用户从智能手机、桌面或汽车内直接访问这些在线服务。 苹果的Siri是一个封闭式服务，开发者无法将其嵌入进自己的应用，或者是让Siri支持他们的应用程序。Zypr便是设计完成这些任务。先锋公司希望它的Zypr能登陆范围广泛的设备。它的服务和API都是免费使用，该公司希望从付费搜索、广告、优惠券和订阅服务中获取收入，并与开发者分享收入。该公司还发布了一个开源的Java客户端帮助开发者。


  • Open Hardware Journal
    发布于: November 2, 2011
    来源: Dangerous Prototypes


    Kelvin writes:

    Just to highlight that there is an Open Hardware Journal. Do check it out.

    Via the contact form.

  • 【转】 教你在家发极品豆芽，想吃到无公害的就学吧
    发布于: October 29, 2011
    来源: 极乐世界

    豆芽的好处不用多说了，饮料瓶子发豆芽比传统家里发豆芽的方法发出的更粗更长，先看一下成果。        

           实验了好多种方法 这种方法发的豆芽又直又粗又长 炒着吃很脆，很好吃呦！用时一周，我把步骤告诉大家：

            材料：绿豆 可口可乐塑料瓶（别的牌子的也行，哈）  遮阳的布（不透光即可）
           步骤：
           1、把绿豆泡24个小时左右直到小芽钻出绿豆皮，准备发豆芽
           2、把可口可乐瓶子底下钻几个眼 用小剪刀阔一下眼的大小 以绿豆刚好不钻出来为宜（为了每天浇的水都能不积在瓶子里，保证绿豆芽的新鲜） 把瓶口锥形的那部分剪掉，为了瓶内通风和倒水
           3、把泡好的绿豆放入瓶内 约是瓶高的五分之一，给豆芽一个生长的空间
          
         4、 给瓶子包上一层布或者纸，只要能不透光 透了光的豆芽会发红，这一点很关键，要注意
        
          5、这就马上完成了，咱开始第一次浇水，水从瓶底自然流出来了 ，把布拿下，看个清楚哈
          
     
           6、在上面包上一层布，也是一定不能透光！！！切忌，图下的是一开始实验用的布，后来发现透光，又换了但没有照
          
          7、每天尽量浇3次水 早中晚 上班族门早晚一次也可以哦，这就是饮料瓶子的好处 水分保留还还不错 看一下一个礼拜后的成果
        
           看一下豆芽的细图 好粗好长把，一点不比超市那些化学东西催出来的豆芽芽，就是观察一下根，根好长，还有分支，这才是真正自然生长的豆芽芽哈
        
    这种方法发的豆芽又粗又长 ，分析了一下 是因为瓶子很窄 豆子又多 这样挤着豆芽，并且水分又不大流失，让豆芽长的更旺盛。


    阅读全文
    类别：默认分类 查看评论
  • QQ邮箱iPhone版 — 混搭式开发的尝试
    发布于: October 26, 2011
    来源: 车东[Blog^2]

    QQ邮箱iPhone版开发了几个月，多次延迟发布，过程十分艰辛。这是第一次尝试混搭的开发方式，即整个应用主要由web组成，APP给web套上一个壳并提供一些原生的接口，以达到更好的体验。我们使用了开源的PhoneGap框架，但其实到后来已经可以抛弃它了，没用它多少接口，自己实现一下也只是时间的问题。

    总体

    整个APP主要是以下三点：

    1. APP由js驱动，与手机邮箱触屏版/ipad版使用同一套逻辑，同样的M层，架构一致。
    2. 由APP客户端提供绘制头尾以及动画切换的接口，由js调用。
    3. 使用HTML5的sqlite/localstorage缓存数据，applicationCache缓存静态文件和页面。

    加上各种细节，就可以构建一个仿原生应用了。

    问题

    实际上说得简单，做起来难，碰到很多问题。

    性能

    DOM的性能差，渲染速度慢，最初在各个模块之间切换时速度不能忍受，经过各种优化后情况才好转。优化包括：去除所有高级CSS特性，例如阴影渐变等，减少list默认显示条数，缓存DOM，APP头尾控件缓存，APP动画拍照优化。即使经过很多优化，目前性能上还是跟原生APP有所差距。这种差距目前来看只能等待硬件升级。其实在未做任何优化前，在mac的模拟器上体验已经很好了，无性能问题，因为mac的硬件够好。

    manifest

    applicationCache的manifest是个令人头痛的东西，项目过程中几度出问题。它最大的不足在于不能清空缓存，一旦使用了它，将很难抛弃它，只能更新，不能抛弃。造成的问题是，manifest更新时，拉取新的资源文件，一旦主页面在后台输出的是个不正确的页面，被缓存起来了，就万劫不复，再也无法进入应用了，因为没有机会再次取拉正确的页面了。所以要使用它，需要强力保证主页面绝不会输出错误，最好是个静态页面。

    此外用manifest还要非常细心。项目过程中有两次出现突然无法离线的情况。一次是manifest针对高清屏输出的文件有个地方没换行，导致缓存无效。很难看出它没换行，因为manifest文件是套模板的，模板上是有换行的，转完输出就没有了。只针对高清屏错误就导致模拟器和iphone3都没问题，只有iphone4有问题。折腾这个诡异的问题半天。另一次是写在APP里的启动网址参数里多了个’s'，导致打开的页面跟缓存的页面不一致，很难发现，也查了挺久。

    JS-APP不同步

    APP提供了绘制头部底部的接口，何时绘制以及绘制什么由JS控制。模块的切换会有动画效果，在js调用模块切换时，先拍照，再画头画底，再回调开始动画的事件，JS渲染自身的dom，动画切过去，整个流程挺简单挺清晰，但实际会有各种问题出现。

    在初期经常出现APP头尾和模块内容不一致的问题，由各种原因导致，可能在切换模块整个流程没结束时马上又切换模块了，或者再调一次画头尾，会打乱流程。这通过APP那边把命令加入一个队列顺序执行，并且在动画过程不响应事件来解决。

    登录问题

    由于历史问题，登录没有使用ajax，整个应用不可避免地需要页面跳转，这会导致非常多的问题：
    1.在某些网速非常慢的情况下，整个应用白屏无法避免，因为在跳转了页面并且页面还未载入时，必然会先出现一个空白页面。
    2.登录的loading菊花卡住不转，因为跳转了页面本页面的无论是gif还是canvas都停止运行了。
    3.一旦出现运营商劫持/wifi验证页面，整个应用就会调转到这个页面去，完蛋了。这个后来通过把表单提交到iframe解决。
    所以，最好不要出现跳转页面的情况，必须整个应用在一个页面里。

    沟通成本

    本来一个iPhone APP的开发链就是，UI-客户端-后台，加入js后，多了js与客户端沟通的成本。而在这种开发模式不成熟的时候，这个沟通成本挺大。另外在APP出问题的时候，有时挺难判断是js的问题还是客户端的问题。

    由于APP介入了表现层，进入JS的逻辑，所以必须对APP和JS两端都熟悉了解，才能掌握整个流程。之前不清楚为什么phoneGap不推出这个固定画头画底的接口，这是所有APP必备而在web上实现性能又很差的东西。现在知道这会使APP变复杂，phoneGap只提供功能接口，作为后台角色，其他全交给JS，不需要与APP进行过多的沟通。

    webView/网络

    出现了一些问题我们还没弄清除是不是webView的问题，例如，记住cookie的问题，登陆过后是设了cookie的，但如果这时马上退出，下次进来就不会有cookie，如果是隔个二三十秒过后再退出，cookie就能记住。非常奇怪的行为，对此我们只能打个补丁，把某些cookie存到localstorage，下次进来如果没有cookie就从localstorage里取，这个方案还依赖了mainifest。

    另一个是APP环境改变时ajax的行为问题，在请求或者上传时，APP切换到后台，APP切换网络，APP切换到后台长时间不用再打开，APP终止webView的请求，都会由可能导致ajax卡死，无onsuccess或onerror的callback，有时还会导致JS被阻塞，接下来无法正常响应请求。这是我们框架的缘故，还是webView的缘故，还待查。

    好处

    与纯原生APP比，它是有带来一些好处的。

    1. 云端升级：应用的某些升级无需通过AppStore，无需用户下载安装，可以快速迭代。
    2. 代码复用：触屏版/ipad版的多数代码可以复用或者共用，降低开发成本，提高开发速度。
    3. 跨平台：我们暂时没用到这个好处。若要跨平台，数据层没问题，VC层还是有很多的不同。

    总结

    混搭的开发方式，APP最好不要参与到表现层的东西，只提供必须的功能接口，否则js与APP一起管理整个表现，会导致复杂度增加，开发困难。但目前没办法，可能走得有点快，就目前来说，纯web的表现还与APP的差距甚大，必须借助APP的力量，像最基本的头尾固定，只能由APP来展现。

    目前iOS5的浏览器支持了position:fixed属性，可以在屏幕上固定元素，支持-webkit-overflow-scrolling: touch，可以原生支持对区域滚动，就具备了使用纯web实现目前的体验的基础。等接口提供再加上硬件不断加强，性能上的差距也会缩小，等市面最低版本是iOS5了，硬件都升级了，web主导的这类应用估计会多些。

  • Facebook Goes Global With Data Center in Sweden
    发布于: October 27, 2011
    来源: Data Center Knowledge

    An artist's illustration of what the new Facebook data center in Lulea, Sweden will look like when it is completed. (Click for larger image)

    Facebook will build a huge new data center in northern Sweden to support the rapid global growth of its users, the company said today. The new data center in Lulea, Sweden will be Facebook’s first facility outside the United States. 

    The location takes advantage of the cool climate in Lulea, a seaside town of 45,000 located at approximately the same latitude as Fairbanks, Alaska. That cool weather will allow Facebook to use outside air to cool the tens of thousands of servers that will occupy the new campus.

    Facebook plans to build multiple data centers in Lulea, beginning with a 27,000 square meter (290,000 square foot) first phase that will be completed in late 2012 and begin supporting traffic in the first half of 2013.

    Electricity from Green Power Sources

    The Facebook Lulea data center will be powered primarily by renewable energy, a change from the social network’s first two company-built data centers in Oregon and North Carolina, which each relied upon utility power that originated primarily from coal. Facebook’s power sourcing had been highlighted by the environmental group Greenpeace, which launched a lengthy campaign urging Facebook to “Unfriend Dirty Coal.”

    The expansion of Facebook’s infrastructure beyond the U.S. reflects the increasingly global makeup of its user base. More than 75 percent of Facebook’s 800 million users are located outside the United States. Building data centers closer to these users can improve the speed of their connection and overall Facebook experience.

    “It’s the next step in our ongoing strategy of building our own infrastructure and moving away from leased facilities,” said Facebook spokesman Michael Kirkland. “We are expecting this data center to continue to help us reduce latency for our users in Europe and beyond.”

    Sweden: Climate, Connectivity, Green Power

    The Facebook announcement is being celebrated in Sweden, and particularly in Lulea, where economic development officials have been marketing the region as a data center destination due to its combination of a cool climate, strong connectivity and plentiful supply of cheap, renewable energy.

    “The cool, dry climate will allow us to continue our practice of using outside air to cool our data centers,” said Kirkland. The average daily temperature in Lulea ranges from high of 41 degrees F (5 degrees C) to low of 27 degrees F (-2.5 degrees C). The area averages just four days a year with high temperatures exceeding 25°C (77 degrees F).

    Sweden is ranked second in the world for its telecommunications infrastructure by the International Telecommunication Union (ITU), trailing only South Korea. Lulea has connectivity from five carriers: backbone provider TeliaSonera and Tele 2, TDC, Telenor and Banverket.

    Energy Sourcing an “Important Consideration”

    The nearby Lule River produces about 13.6 million megawatt hours of hydro-electric power, equal to 10 percent of Sweden’s total demand for electricity. Officials in Lulea say the area has some of the cheapest power rates in all of Europe.

    “This will be the first Facebook data center powered primarily by renewable power, primarily hydro,” said Kirkland. “It’s a really important consioderation for us. Obviously, it’s not the only consideration.”

    “This is a great step forward for Facebook, but we would like more details on how much renewable energy will power its data centre in Luleå,” said Casey Harrell, Greenpeace IT analyst. “With the IT sector one of the fastest growing consumers of electricity in the world, Facebook’s taking leadership on renewable energy could help determine whether we have a dirty ‘cloud’ or not.”

    Facebook says the Lulea facility with be an energy-efficient data center, and employ many of the techniques used to conserve power at its Prineville site. The Oregon facility uses evaporative cooling instead of a chiller system, continuing a trend towards chiller-less data centers and water conservation. Facebook also says it will use waste heat from servers to heat office areas.

    Inside the building, Facebook is expected to implement the server and data center designs outlined in the Open Compute Project, which the company launched in February to release its custom designs for servers, power supplies and UPS units.

    We’ll have more details on the new facility after today’s press conference in Sweden and the Facebook Open Compute Summit in New York.

  • Rapid Prototyping For Any Device With Foundation
    发布于: October 26, 2011
    来源: Smashing Magazine Feed




     



     

    Editor’s note: This article is the second piece in our new series introducing new, useful and freely available tools and techniques presented and released by active members of the Web design community (the first article covered PrefixFree, a new tool be Lea Verou). ZURB are well-known for their wireframing and prototyping tools and in this post they present their recent tool, Foundation, a framework to help you build prototypes and production code that’s truly responsive.

    You’ve probably already heard about responsive design, which is website design that responds to the device constraints of the person viewing it. It’s a hot topic right now, and with good reason: alternative devices outsell desktop PCs 4 to 1 already, and within three years more Internet traffic in the US will go through mobile devices than through laptops or desktops.

    All of this is forcing a convergence on what Jeremy Keith calls the “one Web”: a single Web that doesn’t care what device you’re on, how you’re viewing content or how you’re interacting with it.

    What we found at ZURB was that while the concept of one Web is strong and the need for responsive websites great, the tools to help us quickly build that way just didn’t exist. That’s why we built Foundation, a framework to help you build prototypes and production code that’s truly responsive.

    The Problem with Global CSS

    For years at ZURB, we used and refined a global CSS file that included a nice 960 grid, typography styles, buttons and other common elements. The trouble with our global CSS was that none of these pieces were written to be used by others, so they required a good deal of ramping up and training, with no great documentation.

    screenshot

    Our CSS style guide had a lot of good global elements, but it wasn’t well documented, and it certainly wasn’t ready for other devices.

    The bigger problem was that it wasn’t designed to be responsive or mobile-friendly in any way. We were stuck in the same rut that a lot of designers are in: creating a 1000-pixel-wide canvas, putting a 960 grid on it, and calling it a day. Our tools were built to support that workflow. So, we rewrote it into Foundation, a framework for everyone to be able to rapidly prototype in a responsive way.

    screenshot

    Foundation is an MIT-licensed framework that includes a nestable arbitrary-width responsive grid; mobile styles, buttons and typography; layout affordances such as tabs and pagination; forms; and useful JavaScript plugins. We wrote or packaged all of these pieces to achieve a few goals:

    1. Quickly train new designers, inside and outside ZURB, to use a common framework;
    2. Rapidly prototype websites for desktops and any mobile device;
    3. Easily customize and complete the prototype to turn it into production code for particular projects or clients.

    The first goal can’t be overstated; the value of having a single set of styles and best practices that the team can iterate on as a whole and communicate to our clients is tremendous. We can ramp up new designers much more quickly, build things faster and work together more easily. On one recent project, we even got a volunteer sufficiently up to speed on Foundation that we could collaborate on code — and it took only about 15 minutes.

    So, How Does Foundation Work?

    The core of Foundation can be summed up in a few points:

    • A 12-column, percentage-based grid with an arbitrary maximum width.
      The grid can be nested and used for quite complex layouts, and it works all the way back to IE 7. The grid reshuffles itself for smaller devices.
    • Image styles that disregard pixels.
      Images in Foundation are scaled by the grid to different widths.
    • UI and layout elements.
      Foundation includes common pieces such as typography and forms, as well as tabs, pagination, N-up grids and more.
    • Mobile visibility classes.Rapidly prototyping is partly about having built-in functionality to tailor the experience.
      Foundation lets you very quickly hide and show elements on desktops, tablets and phones.

    We deliberately built Foundation as a starting point, not as a style guide. We’ve included some styles to help you rapidly build something clickable and usable, but not something stylistically complete. Everything in Foundation is meant to be customized, including button styles, form styles (even custom radio, checkbox and select elements), typography, and layout elements such as tabs.

    The Grid

    A lot of grids are floating around, including some very good ones right here on Smashing Coding. Grid systems have a few issues, though, and we built Foundation to tackle them… well, some of them.

    Fluidity

    One of the critical pieces of device-agnostic design is having a fluid layout that conforms to the size (and orientation) of the device. Foundation’s grid is completely fluid, with percentage-based widths and margins, and it works all the way back to IE 7 (but not IE 6 — philosophically speaking, acting like IE 6 doesn’t exist makes sense at this point). The HTML markup is pretty simple. Here’s an example of the grid in use, where we nest it for a more complex layout:

    <div class="row">
  <div class="eight columns">
	<p>…</p>
	<div class="row">
	  <div class="six columns">
	    <h5>Another Section (.six.columns)</h5>
	    <p>…</p>
  </div>
	  <div class="six columns">
	    <h5>Another Section (.six.columns)</h5>
	    <p>…</p>
	  </div>
      </div>
    <p>Now the nested row has been closed, and we're back to the original eight-column section.</p>
  </div>
</div>

    You can check out the above code on this example page.

    screenshot

    Here are some of the built-in grid constructs, all of which scale with the browser window.

    Responsiveness

    The second critical piece is for the grid to be able to easily adapt to small devices and their unique constraints. We tackled this in three ways:

    • On small devices (such as phones), the grid simply stacks vertically, with every column running the full width.
    • We’ve also included block-grid classes, which are definitions for ULs that can be two-up through five-up and that remain a grid even on very small devices.
    • And we have mobile visibility classes. These are a group of styles that enable you to quickly try things out by hiding and showing elements on different kinds of devices. You can attach classes like so:
    <div class="hide-on-phones">
	<p>This is a paragraph that we don't want to see on small devices.</p>
</div>
<div class="show-on-phones">
	<p>This paragraph will be shown only on phones, not on tablets or desktops.</p>
</div>

    Another interesting use for the classes is to prototype a common mobile consideration: placing mobile navigation at the bottom, as opposed to its more common placement at the top. You could do this:

    <nav class="hide-on-phones">
  <ul>
    <li><a href=#>…<a></li>
    <li><a href=#>…<a></li>
    <li><a href=#>…<a></li>
  </ul>
</nav>
…
<nav class="show-on-phones">
  <dl class="mobile tabs">
    <dd><a href="#">…</a></dd>
    <dd><a href="#">…</a></dd>
    <dd><a href="#">…</a></dd>
  </dl>
</nav>

    screenshot

    Foundation lets you write code once and show it on different devices easily.

    Semantics

    This one is tricky. A very compelling case is to be made that grid systems are by nature not semantic. This is partly true; they’re still descriptive of their function, but they do break the separation of data and display.

    We didn’t want to base the Foundation framework on another extension, such as LESS. LESS is a great tool enabling you to use variables, shortcuts and more in your CSS, but we didn’t want to have to rely on it and add another barrier to using Foundation. The recent article we mentioned above actually fixed the data and display issue of grids by using LESS, which is awesome, but Foundation doesn’t fix that. Here’s why…

    All of these methods are a stopgap. The replacement technique might come out next month or next year, but really all of these tools will change drastically in the very near future. Tools like LESS help us get a little closer to a very clean solution, but at a higher technology and learning cost. We wanted Foundation to be the fastest way to prototype for all kinds of devices, so we paid a small price for truly separated markup.

    Rapid Prototyping Examples

    Let’s look at a recent example for which Foundation was used. Every year, we do a 24-hour design marathon for a local non-profit, usually producing new marketing collateral and a new website. This year, we chose Rebekah Children’s Services, a great organization that helps with adoptions and takes care of disadvantaged kids.

    This year, we wanted to build a website that was really responsive, and we had very little time to do it. Using just Foundation, we started prototyping the website based on some sketches we had done. In two hours, we managed to build this prototype.

    screenshot

    Using Foundation, we built the prototype on the left in two hours (including every screen), and then started modifying it until it became the final website on the right.

    It’s not terribly pretty, but it did give us something we could click around in, add copy to and iterate on. In the prototype, we used only a bare minimum of custom styles to more accurately represent the intended visuals.

    Once we completed the prototype, we were able to complete the visual design and apply it to the existing Foundation code base to produce the final website. The final website retains all of Foundation’s framework, with the new styles applied on top of it.

    How to Further Tailor the Experience

    We recently launched an app through which to give traditional design feedback on mockups and websites. It’s called Spur, and it has been great fun for us; not only is it in our wheelhouse (for design feedback), but building a responsive Web app was an awesome opportunity.

    Spur has a number of tools and actions, as well as some simple forms and a fairly complex JavaScript- and HTML-loading animation. Adapting all of this to mobile devices could have been really painful, but by starting with Foundation, we cut down on that considerably and prototyped the app quickly.

    screenshot

    Spur on a desktop is different than Spur on a mobile device such as an iPhone.

    Spur helped us get more comfortable with the constraints of a given device, including screen size, orientation, tap target size and copy. Spur is simpler on smaller devices, but it’s not stripped down. You can still capture a page, view it through the various filters, and share it with someone else.

    Rapid Prototyping Is Required Now

    The days of creating a blank Photoshop canvas and laying down a 960 grid are over, even if some of us are still working in that shared fantasy world. Mobile devices — or, let’s just say, devices beyond just laptops and desktops — are already prevalent and will only become more ubiquitous.

    Don’t build a desktop website that’s pixel-perfect before thinking about other devices; get used to designing for several different sizes, and then quickly prototype your design to get a feel for the flow, function and interaction.

    We built Foundation to help us do this faster and to develop better websites and apps for us and our clients. We feel so strongly about the need for this that Foundation is MIT-licensed and completely free to use, forever. If you try it out and have success with it, let us know. We’d love to hear about it, just as we’d love to hear about bugs or issues that you’ve run into.

    We’re excited about this watershed moment in Web design (and in connectivity and data availability), and you should be, too: our industry will change more in the next three years than it has in its entire history. We hope this helps.

    (al)

    © ZURB for Smashing Magazine, 2011.

  • Reddit’s nicechips community
    发布于: October 25, 2011
    来源: Dangerous Prototypes

    Kelvin wrote to us about the new “nicechips” community available at Reddit. They collect links to data sheets of components they find interesting.

    Via the contact form.

  • ranyunfei: 我曾说过，不少国人三十岁就说自己老了，四十岁就可以抬出去埋了，那种被深深欺负的沦陷感和不曾反抗过的沧桑感，与陈丹青说美国人长着一张不曾被欺负过的脸，有很大的不同，这点值得你细细体味。拙文《为父示女儿书》今天全文刊载《南方周末》http://t.co/jbqfUqnD
    发布于: October 20, 2011
    来源: Twitter / ranyunfei
    ranyunfei: 我曾说过，不少国人三十岁就说自己老了，四十岁就可以抬出去埋了，那种被深深欺负的沦陷感和不曾反抗过的沧桑感，与陈丹青说美国人长着一张不曾被欺负过的脸，有很大的不同，这点值得你细细体味。拙文《为父示女儿书》今天全文刊载《南方周末》http://t.co/jbqfUqnD
  • On cryptography and dogmas
    发布于: October 21, 2011
    来源: antirez weblog
    Yesterday I finally released the initial public release of Lamer News, that is both a real world Redis programming example in the form of an Hacker News style site, and a project to run a completely independent (with a consortium) programming news site.

    The project was well received, and was in the top page of HN for some time. Thanks for providing your feedbacks.

    After the release of the code I got a few requests about changing the hash function I was using in order to hash passwords in the database: 
    # Turn the password into an hashed one, using
# SHA1(salt|password).
def hash_password(password)
    Digest::SHA1.hexdigest(PasswordSalt+password)
end
    The above code uses SHA1 with a Salt. As others pointed out this is not the safest pick, since there are ways to compute SHA1 very fast. After some time a chorus of people started twitting and commenting a single sentece: "Use bcrypt". I proposed using nested SHA1 in a loop, in order to avoid adding more dependencies in the code (if you check the README one of the goals is to take the code simple and depending on just a few gems). And at this point it happened: the crypto dogma. No way to reason about crypto primitives and their possible applications and combinations, but just "use bcrypt". In the eyes of this crew programmers are just stupid drones applying guidelines, that can't in any way reason about cryptography. But I'll talk more about that later...

    For now let's do a step backward... and show what the original problem is with all this, and how much insecure the original code is.

    The problem

    The problem is pretty easy to understand, but it is worth to be explained in details. In order to avoid storing passwords in cleartext into the database is common practice to hash passwords. So: 
    HP (hashed password) = HASH (password)
    When the software needs to perform the user authentication it receives the plaintext password, hashes it again, and verifies that it matches the one in the database. If so the user is authenticated.

    However what happens if an attacker, let's call it Eve, will steal the database and the passwords are leaked? Eve has a number of hashed passwords, let's call them HP1, HP2, HP3, ... Her goal is to find an attack such that it can turn back HP into P.

    The hashing algorithm HASH is public, so the first thing Eve can do is to apply HASH to a dictionary composed of common words and check if HP matches the HASH(common_word). If there is a match the original password was found. Note that there are not so many words in the English dictionary, so this attack is very easy to perform, and super fast.

    But maybe our user, Bob, picked a password that is not in the dictionary, but is neither particularly long.

    Eve can generate all the combinations up to 6 chars passwords and hash them with HASH, trying to find a match. This attack is computationally harder. If the password is a completely binary string, let's say of six characters, there are 256^6 passwords, that is, 281474976710656.

    If our attacker can hash one billion passwords per second (it is possible with modern GPUs without spending a fortune on it) cracking this password takes: 
    281474976710656 / 1000000000 = 281474 seconds
    This is just... three days, so one day and half in the average case. Not good! it's too easy to crack. There is another problem, an user will hardly use all the 256 characters with equal probability. Let's consider the worst case of it just using 26 low case letters without number nor symbols. This time let's consider an 8 characters password.

    There are 26 ^ 8 possible passwords, that is: 208827064576 possible passwords. This time our password can be cracked in 208 seconds (half that time in average).

    This is clearly not good. How long should be a 26 letters alphabet password to be unaccessible for the attacker able to compute HASH 1 billion times per second?

    A 14 characters password will resist 1024 years on average to be cracked. For a 16 characters password our attacker needs 1382824 years.

    Just 12 chars will resist for one year and half in average, definitely too little for most applications.

    So is SHA1 secure for hashing passwords? Yes if the user picked a strong password of 14 chars or more. Otherwise not very secure. It all depends on the length of the password, and guess what, users have a bad habit of picking bad and short passwords.

    It is worse than that

    Unfortunately it is worse than that. For instance the attack against our 12 chars password can be made instantaneous in an easy way: using three years to compute a table of all the 12 chars passwords and associated resulting hash value. This is basically a big map between HASH(P) and P.

    However such a table takes space, a lot of terabytes (86792 for precision) to store the lookup table assuming we have a so cool compression algorithm that can use just a byte per HP,P pair (an unreachable goal likely). However this is a valid attack when the size of the table is reasonable.

    The point here is, many times in cryptography an attack can be made working using space instead of time.

    The good thing is that there is a way to avoid the user precomputing a single table that will work for all the sites using the same hash function, that is, using *a salt. A salt is an (assumed public) string we concatenate to our password before hashing it, so if our salt is "lame", and the password is "foo" we will perform: 
    HP = HASH("foolame")


    This way for the table-based attack to work the attacker needs to pre-compute a table with all the 12 char passwords combination hashed with the same salt. This means, this table is useless if Eve plans to attack another site with a different salt.

    Random salts

    We can do even better than that, and not just store HP, but also a random salt. When we create the user account we also generate an user-specific random salt, and store it along with the hashed password.

    With a per-user salt we are safer, the requirement is a table per user now if the attacker wants to precompute it. And even more interesting while a global salt is more likely to be leaked even if the user passwords are not leaked, this is unlikely to happen if you have a salt per every user.

    Making HASH slow

    However even if we stop all the table based attacks, there is still a fundamental problem: if the password is short and Eve is able to compute HASH 1 billion times per second we have problems.

    There is one thing we can do: using an hash function HASH that is MONKEY ASSES SLOW.

    There are algorithms that are very slow both in hardware and in software for instance. Or we can take an existing algorithm and make it very slow by using it into a loop.

    For example Blowfish is an encryption algorithm with a slow key scheduling algorithm (the algorithm is pretty fast once you performed the key scheduling, so Blowfish is not good only if you want to encrypt many short messages with different keys, but can be fast if you want to encrypt a big message with a single key).

    The fact Blowfish key scheduling algorithm is slow makes it a good candidate for HASH.

    So Niels Provos and David Mazières designed an algorithm called Bcrypt that can be used in order to hash passwords. The algorithm was presented in 1999 and uses a modified blowfish key scheduling algorithm. I'm not sure if past analysis against Blowfish can be applied to Bcrypt after the modifications, nor how much analysis was performed against Bcrypt itself, so I can't comment about the security of the algorithm in question.

    However it is a popular pick, Provos and Mazières are two known cryptographer so probably the algorithm has no obvious flaws as well.

    Once you use a slow HASH the attacker will start to have much troubles. For instance Bcrypt is "tunable", you can modify an input parameter to make it slower or faster. If you make it slow enough so that even with good hardware you can't compute more than 1000 hashes per second, it is still probably fast enough for your authentications servers to handle, but it is unpractically slow for Eve to crack even a 8 characters password, even using just 26 letters: 
    26^8/1000/3600/24/365 =6.6218627782
    3.3 years on average to crack an 8 digits password. Probably still a bit too weak but better than a few seconds...

    However note how we are still not secure against a dictionary attack. If the user picked a common word there are no hopes. 30k hashes are still trivial to perform in a reasonable amount of time.

    On dogmas

    So far we showed a few interesting points I think, first: there is no hashing schema that will save users picking very bad passwords. It is very important to force users to add non alphanumerical characters and a few capital letters in the password IF security is very important for your application.

    It is important to understand how things work. And this brings us to the following point. After the "use bcrypt" chorus I replied that I could use another solution instead, based on just iterating SHA1. But apparently cryptography is not a topic a programmer should understand for many. It is just a dogma. When you have dogmas you are going to be a bad programmer probably, what about if your system does not have bcrypt support for some reason and you still want to mount something useful?

    What I proposed was this trivial schema: 
    SHA1(SHA1(SHA1(...(SHA1(password|salt))))


    How heretic! I was marked as a stupid not understanding security, that is not safe to chain hash functions like this, and so forth. But if you think at it:

    SHA1 is a one way hash function. It is composed of a small computation step called round that is iterated again and again. There is no key scheduling as it is not a block cipher, it just compresses a stream of bits into a fixed length output.

    It is very important to understand that many crypto algorithms are based on that idea of taking a simpler function and iterating it many times to strength the effect it has. This concept is so important that sometimes an attack to an algorithm disappears (becomes not practical or requires more time than brute force) if you add more rounds. Sometimes cryptographers use a variant of the algorithm with a reduced amount of rounds just to analyze the algorithm in a more attackable form, to understand better how strong the variant with the full number of rounds is.

    So why we don't just add a lot of rounds? Because it is slow. Even an amateur cryptographer could design an algorithm that is secure but slow. A good cryptographer will be able to find the tradeoff between security and speed.

    But... now we know this concept of rounds, and we know that in SHA1 there is no key scheduling algorithm, the output of the function is only related to its input, nor SHA1 is designed to be inverted, as there is no decryption stage.

    So it is quite natural that the schema I proposed of computing SHA1(SHA1(SHA1(..))) will just do that, adding rounds to SHA1. So for the fundamental properties of SHA1 it should be computationally unfeasible to write a function SHA1000 that is equivalent to 1000 times SHA1 nested but that can be computed easily.

    Note that the output of SHA1(SHA1(..)) is not the same as modifying the algorithm adding more rounds since there is a pre and post stage in the SHA1 algorithm that will make the output differ compared to a plain SHA1 with more rounds.

    But guess what? This morning I discovered that actually the algorithm PBKDF1 described into RFC2898 does exactly what I proposed.

    There are people that are very happy to show you the way, but if you look at them more closely you discover they are clueless. So please use proven standards, try to write secure code, but use your mind, learn about cryptography and how you can combine primitives. Dogmas are lame.

    It is not a good idea for a programmer to try designing a block cipher and then use it for sensible purposes, there are specialists doing that, but understanding what are the building blocks, and what you can do with cryptography, how to mount protocols, it is a very important skill for our community.

    Finally it is ok for me when people are rude with me when they are right. Arrogance can be handled if it is mixed with smartness. When instead it meets ignorance it is really just a sad affair.

    Edit: two new interesting links from HN:

    About the second link, in the message the explanation is not very clear but this is what happens:

    Here the attack they want to mount is the following: find another string, ANY string, that will hash to the same output, but only 32 bits of the output.

    Since it is any string, it can also be a SHA1 itself. So what you do is to start with an "X" that can be ANY ANY value, even "foo". And you start doing: 
        x = SHA1(x)
    x = SHA1(x)
    ... again and again ...
    ok? Well in the average case after 2^31 iterations you find a collision, right?

    But the output 65536 iterations ago was it! The string that will output that specific 32 bit output after SHA1() nested 65536 times. So you want to go backward but it is not possible, SHA1 can't be inverted. So what you do? You start again from "X" and stop exactly 65536 iterations before you found the wanted value.

    Obviously doing 65536 more SHA1s of that string you get the previous output. So you found your string. Why the original poster says that the attack takes 2x time but can even optimized? Since you can store the value of SHA1 at 10000 iterations, at 20000 and so forth. Then instead of re-running the iteration again you start from the nearest cached value.
    13222 views*
    Posted at 14:14:09 | permalink | discuss | print
  • Stay Hungry, Stay Foolish ！！
    发布于: October 20, 2011
    来源: 酷壳 - CoolShell.cn

    在整个社会都在关注乔帮主的时候，我想在这里和大家分享一个真实的就在我们程序员身边的故事。和我在《如果你看不见你还能编吗？》一文里介绍的那些盲人程序员一样，同样是Stay Hungry， Stay Foolish。但我个人更认为我今天想要给大家讲述的这个故事对于我们这些普通人更有意义一些。我真心的希望大家认真看完这个“从刷厕所到程序员”故事后，我们能从中感悟到点什么。

    因为朋友的原因，我和一个创业团队经常有些往来，通过这个团队，我认识了这个故事的主人翁——王平（@wpingsuper）。其实，很早前他在Google Reader和Buzz里follow了我，但我从没和他交流过。而他的经历我却是在上周末去看望这个创业团队的时候才听说。我问他们要了王平的电话，联系了王平，详细地了解了王平的经历，并征得他的同意，在这里给大家分享他的故事。

    王平是一个贵州人，03年大学毕业，体育专业，没有任何家庭背景，只能在贵州的山区里的一个中学里当体育老师，月薪150元。可能和大多数心怀梦想的年轻人一样，他并不甘心，从03年到05年间，他有好多次到北京，他觉得在大城市里有他的梦想。于是，他在04年底，05年初，他正式来到了北京，因为大学专业的问题，他无法找像大学生一样找到不错的工作，那时的他只能在北京一家很小的餐馆当清洁工，他在餐馆里洗盘子，扫地，刷厕所，一个月400元钱。

    因为他的学历是这个小餐馆里学历最高的，所以，餐馆里出了什么事都会让他对去搞，所以，财务使用的电脑有了故障也让他去修，当时的他根本对电脑完全不知道是怎么一回事，但是自从接触了电脑以后他就迷上了电脑。他和我说，他这个人就是好奇心强，好动，什么都想弄一弄，所以，时间长了，弄得多了，也能为餐饮解决一些没有懂的问题，维护财务电脑就是其中之一。日子一长，虽然还是刷厕所，但是薪水也涨到了800元一个月，就连餐馆的大厨也对他说，他不属于这里，他将来一定会有前途的。当时的他还觉得不可能，笑了笑就过了。

    直到07年的一天，餐馆的会计对他说——“看你对电脑那么有兴趣，你应该去学习一下电脑”，这句话点醒了他。于是他在报纸上找到了一个教做网页的培训班，培训分成三期，近一年，每期需要7000元钱，好心的那个会计给了他6000元钱，让他可以在周末参加这个培训班。他和我说，这个会计是他的贵人，换钱的时候她也比较推辞，至今他也还和那位会计老师保持联系。

    不过好景不长，只上了一期，问题来了，餐馆周末也要上班，他无法去参加培训班了。所以，他只好辞职，去了中日友好医院，当一个送药工，就是用板车把药从这个地方送到另一个地方，全是体力活，一个月只有200元钱，不过他有了周末可以去培训班的那个时间。但是钱也花完了，上了两期都没法继续了。他和我说，当时觉得只要能活着就行，吃不饱无所谓。

    此时的他虽然上了网页制作的培训班，但是因为没有实际做一个东西，所以就算是培训了也什么都不懂。这时他看到Java是一个很不错的方向，所以，想学Java。于是，08年初的时候，他用自己以前办的信用卡向银行申请了个人贷款，去报了一个需要14000多元的Java的培训班。此时，他认识了我的朋友——阎斌（@yanbin001），我这个朋友当时在这个培训公司里做讲师，讲Java。

    没有计算机基础的王平学习Java的难度可想而之，非常地痛苦，所以，阎斌看到他懂点网页开发，就让他别学Java了，搞搞Web的前端网页开发。而且，我这个朋友阎斌是个创业狂，所以，经常拉着王平一起去和他做互联网上的产品，并让王平去研究一些别人做的网页，于是王平从此学会做了Web前端，并开始能独立开发一些前端网页，有了实实在在的锻炼，王平他开始真正会用html + css，还会一点点js。

    09年4月份的时候，王平在北京西四环找到了第一份像样的工作，是一家做保健品的小公司，需要做一个公司的网站，月薪3400元。这让他得以还清了欠银行的钱。他还和我开玩笑说，他和我做的都是电子商务。当然，这对于他来说他并不满足。而我那个创业狂的朋友阎斌，又叫他出来创业，可惜创业再次未果。他只好又回去打工。

    2010年4月份的时候，他到了12580做前端开发，月薪4000元左右。他说，12580的前端开发只有他一个人，今天12580的网页90%以上还是他写的，并且他还让给了我这个链接：http://12580.10086.cn/。大家可以去看看，你能想得到这个网页是出自一个以前对电脑一窍不通在饭馆里做清洁的人之手吗？

    此时的王平，对Web前端开发已经是驾轻就熟，非常熟练，就连后端的工程师对他也非常佩服。 觉得他用CSS和JS用得直是相当的不错。当然，王平并不满意这份工作，在10年的11月份，他换到了现在的工作单位——百度和日本Rokuten的合资公司——乐酷天。还是老样子，他一个人负责所有的前端开发，不过这次的跳槽，他找到了一份相当不错的薪水。我对这份薪水的理解是——高级前端开发程序员。我引用我另外一个在微软和出过国并和王平一同工作过的朋友的话——“王平太猛了，CSS和JS用得巨熟无比，每次我们请他帮我们搞定一个网页效果，我们问他2天行不行，结果他2个小时就搞定了！”。

    好了，我的故事到这里要结束了，先让我们来看一看80后王平的样子吧。

    在享受工作的王平，个人博客 http://www.soboom.com

    我不知道你看完这个故事后是什么样的感受。我有两个感觉——

    • 乔布斯说Stay Hungry, Stay Foolish。今天，当我们所有的人都在仰望神一样的乔布斯的时候，在我们津津乐道那些浪潮之巅的人物时，在听过王平对我讲述他的经历过后，我只想说，其实，我们大多数人真的不懂什么是——Stay Hungry, Stay Foolish。包括我自己在内。
    • 王平让还让我想到了电影《命运规划局》里的最后一句话，大概是这样说的——“大多数人按照我们所安排的路线生活，害怕探索其它路线，但也会有一些人，他们并不满足于被设定的生活轨迹，冲破我们设置的重重阻碍，意识到自由意志是天赐之物的人，才明白只有在奋力抗争后才知道如何善用之。”

    （全文完）

    ————更新 2011/10/20 15:00————

    有些人觉得这篇文章是给培训公司做广告或是炒作。有些人觉得几百元钱在北京生存并不可能。我可以理解你们的怀疑，但这些言论让我有些无语，我只希望你们能在做些调查后，再做这样的结论。你可以看到，王平在第一个培训公司没有学到什么，在第二个培训公司也没有学到什么，而是在和我的朋友阎斌去尝试创业时才学到了很多。呼唤这些人的阅读智商啊。

    这个世界有时候并不是像我们所想像的那样，在北京，几百元一个月的人并不少，上大学也好，去培训公司也好，这都不重要，重要的是我们想改变自己的那种心态和积极。而我只希望王平的经历能给大家带来人生的一些感触。

    您可能也喜欢：

    程序员的八个级别
    程序员版的凡客
    C++ 程序员自信心曲线图
    未来五年程序员需要掌握的10项技能
    别的程序员是怎么读你的简历的
    无觅

    相关文章

  • 查看全部共享文档
  • Plugin by C. Murray Consulting
`