<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Hashing on Karpoke - Just Another Blog</title><link>http://karpoke.ignaciocano.com/tags/hashing/</link><description>Recent content in Hashing on Karpoke - Just Another Blog</description><generator>Hugo -- 0.167.0</generator><language>es</language><lastBuildDate>Sat, 24 Sep 2016 13:32:00 +0100</lastBuildDate><atom:link href="http://karpoke.ignaciocano.com/tags/hashing/index.xml" rel="self" type="application/rss+xml"/><item><title>How Dropbox securely stores your passwords</title><link>http://karpoke.ignaciocano.com/2016/09/24/how-dropbox-securely-stores-your-passwords/</link><pubDate>Sat, 24 Sep 2016 13:32:00 +0100</pubDate><guid>http://karpoke.ignaciocano.com/2016/09/24/how-dropbox-securely-stores-your-passwords/</guid><description>&lt;blockquote&gt;
&lt;p&gt;It’s universally acknowledged that it’s a bad idea to store plain-text
passwords. If a database containing plain-text passwords is compromised,
user accounts are in immediate danger. For this reason, as early as 1976,
the industry standardized on storing passwords using secure, one-way hashing
mechanisms (starting with Unix Crypt). Unfortunately, while this prevents
the direct reading of passwords in case of a compromise, all hashing
mechanisms necessarily allow attackers to brute force the hash offline, by
going through lists of possible passwords, hashing them, and comparing the
result. In this context, secure hashing functions like SHA have a critical
flaw for password hashing: they are designed to be fast. A modern commodity
CPU can generate millions of SHA256 hashes per second. Specialized GPU
clusters allow for calculating hashes at a rate of billions per second.&lt;/p&gt;
&lt;/blockquote&gt;</description></item></channel></rss>