Recently I\u2019ve had some interesting conversations about passwords and password policies.<\/p>\n
In general I despise password policies, or at least I despise the silly requirements made by most policies.\u00a0 As I wrote in TCS\u2019s recent\u00a0Better Passwords, Usable Security<\/a><\/em>\u00a0white paper, \u201cWhy do you require your users\u2019 passwords to look as though somebody sneezed on their keyboard? \u2026 Is your organization really better protected if you require your users to memorize a new 14-character password every two months? I argue no!\u201d<\/p>\n In the\u00a0BPUS<\/em>\u00a0white paper \u2014 which is behind a paywall, and I understand how that means it\u2019s unlikely you\u2019ll ever read it \u2014 I argue for three counterintuitive points:<\/p>\n Beyond these points, it is also important to implement good mechanisms for storing and checking passwords.<\/p>\n Storing passwords:<\/em>\u00a0In June of this year there was a flurry of news articles about password leaks, including leaks at\u00a0LinkedIn<\/a>,\u00a0eHarmony<\/a>, and\u00a0Last.fm<\/a>.\u00a0 The LinkedIn leak was especially bad because they didn\u2019t \u201csalt\u201d their stored password hashes.\u00a0 Salting works as follows:<\/p>\n If you don\u2019t salt your passwords, then anyone who can get access to the leaked file can likely reverse many of the passwords, very easily.\u00a0 This password recovery is especially a problem since many users reuse passwords across sites (I admit that I used to do this on certain sites until fairly recently).<\/p>\n Checking passwords:<\/em>\u00a0But it turns out that salt may no longer be solving the world\u2019s password woes.\u00a0 A colleague sent me a link to a post-LeakedIn interview arguing that\u00a0cryptographic hashes are pass\u00e9<\/a>.\u00a0 At first I felt that the interviewee was blowing smoke, and wrote the following observations to my colleague:<\/p>\n He confuses the notion of \u201cstrong salt\u201d with \u201cstrong hash\u201d.<\/p>\n (A) strong salt: you add a lot of random characters to your password before hashing\u2026as a result the attacker has to run a brute force attack against the hash for a looooong time (many * small effort) in order to crack the password.<\/p>\n (B) strong hash: you use a computationally-intensive function to compute the hash\u2026as a result the attacker has to run a brute force attack against the hash for a looooong time (few * large effort) in order to crack the password.<\/p>\n In both cases you get the desirable \u201clooooong time\u201d property.\u00a0 You can also combine 1 and 2 for an even looooonger time (and in general looooonger is better, though looooong is often long enough).<\/p>\n There can be some problems with approach #2 \u2014 the biggest is non-portability of the hash (SHA-1 is supported by pretty much everything; bcrypt isn\u2019t necessarily), another could be remote denial of service attacks against the authentication system (it will have a much higher workload because of the stronger hash algorithm, and if you\u2019re LinkedIn you have to process a lot of authentications per second).<\/p>\n Conclusion: The problem with LinkedIn was the lack of salted passwords.<\/p><\/blockquote>\n But I kept thinking about that article, and\u00a0related posts<\/a>, and eventually had to eat some of my words (though not all of them).\u00a0 Looooong is often\u00a0not<\/strong>\u00a0long enough.<\/p>\n The best discussion I found on the topic was in the RISKS digest,\u00a0especially this post<\/a>\u00a0and its two\u00a0particularly<\/a>\u00a0interesting<\/a>\u00a0references.<\/p>\n\n
\n