Forbidden
\n \nEither you're trying to access something you're not supposed to, or you've been banned.
\nIf you think you've been banned, email havoc@defuse.ca to appeal.
\n\n \n\n" }, { "path": "src/css/main.css", "content": "/*\n * CrackStation, a web-based hash cracking website.\n * Copyright (C) 2013 Taylor Hornby\n * \n * This file is part of CrackStation.\n * \n * CrackStation is free software: you can redistribute it and/or modify\n * it under the terms of the GNU Affero General Public License as\n * published by the Free Software Foundation, either version 3 of the\n * License, or (at your option) any later version.\n * \n * CrackStation is distributed in the hope that it will be useful,\n * but WITHOUT ANY WARRANTY; without even the implied warranty of\n * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n * GNU Affero General Public License for more details.\n * \n * You should have received a copy of the GNU Affero General Public License\n * along with this program. If not, see![\"CrackStation\"](\"/images/1by1.gif\")
![\"Follow](\"/images/twitter.png\")
\n Twitter\n \n - \n
- CrackStation
![\"▼\"/](\"/images/downarrow.gif\")
\n \n \n \n
- \n
- Password Hashing Security\n \n \n
- \n
- Defuse Security\n \n \n
| Last Modified: | \n\n |
|---|---|
| Page Hits: | \n\n |
| Unique Hits: | \n\n |
![\"Creative](\"/images/cc-by-sa.png\")
\nDefuse Security | \n Zcash |\n Secure Pastebin | \n Source Code\n | Hash | Type | Result |
|---|---|---|
| $html_escaped_hash | Unknown | Unrecognized hash format. |
| $html_escaped_hash | Unknown | Not found. |
| $html_escaped_hash | \";\n $html_escaped_alg = htmlentities($result->getAlgorithmName(), ENT_QUOTES);\n echo \"$html_escaped_alg | \";\n $html_escaped_plaintext = htmlentities($result->getPlaintext(), ENT_QUOTES);\n echo \"$html_escaped_plaintext | \";\n echo \"
Color Codes: Green: Exact match, Yellow: Partial match, Red: Not found.
';\n}\n?>\n" }, { "path": "src/libs/URLParse.php", "content": ".\n */\n\n/*\n * Defuse Cyber-Security's Secure & Lightweight CMS in PHP for Linux.\n * Setup & Usage Instructions: https://defuse.ca/helloworld-cms.htm\n */\n\n/*\n * The purpose of this class is to process the current request URL to \n * determine which page is to be displayed to the user, or to which URL\n * the user should be redirected. Once the user has been redirected to\n * the correct URL, and the desired page is determined, the page contents\n * can be loaded from a file into a dynamically generated web page.\n *\n * The URL parsing is split into four processes:\n * 1. First, the hostname (domain name) the request was made to is verified \n * against a list of \"accepted hosts.\" If the hostname doesn't match any of\n * these accepted hosts, the user is redirected to the same URL on the\n * \"master host.\" The accepted hosts and master host variables can be set\n * by modifying the $ACCEPTED_HOSTS and $MASTER_HOST variables respectively.\n * 2. Second, an HTTPS connection is enforced if $FORCE_HTTPS is set to true.\n * If $FORCE_HTTPS === true and the current connection is not secure, the\n * user is redirected to a secure (https) URL.\n * 3. The desired page is determined from the URL (see below). If this page\n * is really an alias for another page, the user is redirected to the proper\n * page.\n * 4. If the user did not request the page using the cannonical filename,\n * they are redirected to the cannonical URL for the page (see below).\n *\n * How the desired page is determined from the URL:\n *\n * Every page has a name, and there are two valid URLs for each page name.\n * For a page named \"foobar\", the following are valid URLs for the page:\n * 1. http://example.com/foobar\n * 2. http://example.com/foobar.htm\n * (2) is the cannonical URL for the page. So if the user were to type (1) into\n * their browser, they would be redirected to (2). The URL without the .htm\n * extension is recognized as a convienience so the URL can be spoken without\n * explicitly pronouncing the \"dot h-t-m.\"\n *\n * Names can also contain forward slashes, allowing virtual directories to be\n * created. For example, the page name \"foo/bar\" is valid, with the following\n * URLs:\n * 1. http://example.com/foo/bar\n * 2. http://example.com/foo/bar.htm\n * With (2) being the cannonical form.\n * There is a special case of these names where no \".htm\" extension is allowed.\n * For example, the name \"\" (meaning the homepage) is accessible though:\n * http://example.com/\n * but NOT through:\n * http://example.com/.htm\n * The same applies to names ending in \"/\", e.g. \"foo/\" is accessible through:\n * http://example.com/foo/\n * but NOT through:\n * http://example.com/foo/.htm\n * Note that a page named \"foo/\" and \"foo\" can exist simultaneously, but since\n * it is common to ommit the trailing \"/\" when typing the URL, this practice\n * is strongly discouraged. If the name \"foo/\" exists and the user omits the \n * trailing \"/\", they will be redirected to the \"foo/\" URL. But if \"foo/\" and\n * \"foo\" both exist, they will be redirected to \"foo.htm\".\n */\n\n// Keys used for definining page data arrays\ndefine('P_FILE', 0); // File content (suffix to $ROOT_FOLDER)\ndefine('P_TITL', 1); //\nThis page does not exist.
\n
![](\"/images/divzero.png\")
\n(ERROR 404)\n
About CrackStation
\n\n\nCrackStation is a security awareness project started by Defuse\nSecurity. Its purpose is to raise awareness about insecure password storage in web\napplications, and to provide guidance to implementors of user authentication systems. By making\nlarge hash lookup tables freely available to the public, we make it easier for security researchers\nto demonstrate why password storage solutions, like non-salted hashing, are insecure.\n
\n\n\nWhile CrackStation does provide paid services, its goal is not to make a profit. The money is used\nto pay for the hardware required to run CrackStation, and any left-overs go toward other security\nresearch projects (the results of which are released into the public domain). You may support\nCrackStation and other Defuse Security projects by donating using the PayPal donate button\nabove.\n
\n\n\nIf you have any questions, comments, or concerns about CrackStation, or would like help implementing\nsecure password storage in an authentication system, please contact us. You can find\nour contact information on the Contact Information Page.\n
\n\nCrackStation's Password Cracking Dictionary
\n\n\nI am releasing CrackStation's main password cracking dictionary (1,493,677,782\nwords, 15GB) for download.\n
\n\nWhat's in the list?
\n\n\nThe list contains every wordlist, dictionary, and password database leak that\nI could find on the internet (and I spent a LOT of time looking). It also\ncontains every word in the Wikipedia databases (pages-articles, retrieved 2010,\nall languages) as well as lots of books from
\nThe format of the list is a standard text file sorted in non-case-sensitive\nalphabetical order. Lines are separated with a newline \"\\n\" character.\n
\n\n\nYou can test the list without downloading it by giving SHA256 hashes to the
\nThe list is responsible for\ncracking about 30% of all hashes given to CrackStation's free hash cracker, but\nthat figure should be taken with a grain of salt because some people try hashes\nof really weak passwords just to test the service, and others try to crack their\nhashes with other online hash crackers before finding CrackStation. Using the\nlist, we were able to crack 49.98% of one customer's set of 373,000\nhuman password hashes to motivate their move to a better salting scheme.\n
\n\nDownload
\n\n\nNote: To download the torrents, you will need a torrent client like\nTransmission (for Linux and Mac), or uTorrent for Windows.\n
\n\n\n GZIP-compressed (level 9). 4.2 GiB compressed. 15 GiB uncompressed.\n \n
\n \n HTTP Mirror (Slow)\n \n
Checksums (crackstation.txt.gz)
\n\n\nMD5: 4748a72706ff934a17662446862ca4f8\nSHA1: efa3f5ecbfba03df523418a70871ec59757b6d3f\nSHA256: a6dc17d27d0a34f57c989741acdd485b8aee45a6e9796daf8c9435370dc61612\n\n\n\n
Smaller Wordlist (Human Passwords Only)
\n\n\nI got some requests for a wordlist with just the \"real human\" passwords leaked\nfrom various website databases. This smaller list contains just those passwords.\nThere are about 64 million passwords in this list!\n
\n\n\n GZIP-compressed. 247 MiB compressed. 684 MiB uncompressed.\n \n
\n \n HTTP Mirror (Slow)\n \n
\n
Checksums (crackstation-human-only.txt.gz)
\n\n\nMD5: fbc3ca43230086857aac9b71b588a574\nSHA1: 116c5f60b50e80681842b5716be23951925e5ad3\nSHA256: 201f8815c71a47d39775304aa422a505fc4cca18493cfaf5a76e608a72920267\n\n\n
Sharing and Licensing
\n\n![\"Creative](\"/images/cc-by-sa-big.png\")
.\n\nYou are allowed to share these lists! They are both licensed under\nthe Creative\nCommons Attribution-ShareAlike 3.0 license. If you do share them, I would\nappreciate it if you included a link to this page.\n
\n\n" }, { "path": "src/pages/contactus.php", "content": "Contacting CrackStation
\n\n\nIf you purchased the wordlist and it isn't working for you, or otherwise need\nsupport with the website, or just want to provide feedback, please email me. You\ncan find my contact information\nhere.\n
\n\nHashDB
\n\nPHP Cracking Script
\n\nWaterfall
\n\nWordlists
\n\n" }, { "path": "src/pages/hashing-security-draft.php", "content": "How to Store Passwords
\n\n\nThis article will walk you through the design of a secure password storage\nsystem. Along the way, we'll encounter many common mistakes, and for each\nmistake, we'll understand why it's a mistake and how to fix it.\n
\n\n\nIf for some reason you missed that big red warning note, please go read it now.\nReally, this guide is not meant to walk you through the process of\nwriting your own storage system, it's to explain the reasons why passwords\nshould be stored a certain way.\n
\n\n\nWith that in mind, we can begin. To understand password storage, we will start\nwith an insecure system and iteratively improve it until it is secure. At each\niteration, we'll see how an attacker can take advantage of the vulnerability,\nand how we as defenders can make the attacker's job harder.\n
\n\n\nFor concreteness, we'll use a standard web site login system as an\nexample. \n
\n\nWeak System #1: Plain Text Storage
\n\n\nThe most obvious way to store passwords is to just put them straight into the\ndatabase without any kind of encryption or hashing. Obviously, this is\na horrible idea, since if an attacker gains access to your database, they will\nhave all of your users' passwords, and you'll be in PR hell trying to win back\nyour users' trust.\n
\n\n\nWorse, if attackers know you're storing passwords in plain text, they will\ntarget you, because password databases are valuable and can be sold on the black\nmarket.\n
\n\n\nIt's a huge risk, not just to you, but to your users too. It's very common for\npeople to re-use the same password on multiple websites. If your website exposes\na user's password to an attacker, that attacker might be able to use it to log\nin to the user's account on another website. You might be tempted to blame the\nuser for re-using their password, but if you had protected the passwords, the\nuser wouldn't be at risk, so it is partly your responsibility.\n
\n\n\nAnother problem you'll have, if you store passwords in plain text, is that when\nyou get hacked, it will be nearly impossible to give your users a secure way to\nreclaim their account, even after you've fixed the vulnerability. Once the\nattacker has all of the passwords, they can log in to any accounts they're\ninterested in, set new passwords, and have permanent access to the accounts.\nProtecting the password database buys you a little bit of time to tell your\nusers that they need to change their password.\n
\n\nWeak System #2: Encryption
\n\n\nThe next obvious step is to encrypt passwords with symmetric encryption. As\nwe'll see, this turns out to be a bad idea.\n
\n\n\nSymmetric encryption works by using a random key to encrypt some data. The\nencrypted data is called the ciphertext. To turn the ciphertext back into the\noriginal data, you need to know the key that it was encrypted with. Without the\nkey, you can't decrypt the ciphertext.\n
\n\n\nYou might think encrypting passwords would be a good idea. It's not, because\nwhere do you store the key? The server that creates user accounts and verifies\nusernames and passwords has to have access to it. So, chances are, if an\nattacker can get the encrypted password database, they'll be able to get the\nencryption key, and will be able to decrypt all of the passwords.\n
\n\nWeak System #3: Hashing Without Salt
\n\n\nTo move on to a more secure design, we need to realize that to verify\na password, you don't actually need to know the correct password. It is possible\nto compute the \"fingerprint\" of a password, with the following properties:\n
\n\n- \n
- It's very unlikely for two different passwords to have the same fingerprint. \n
- It's hard to \"reverse\" the fingerprint back into the password. \n
\nThis can be done with a cryptographic hash function like SHA256. These functions\ncompute a fixed-length fingerprint from a variable-length input. They have the\nproperties we want: It's hard to find two inputs that hash to the same value,\nand given an output, it's very difficult to find the input.\n
\n\n\nHere are some example SHA256 hashes. You can see that even if the input only\nchanges by one letter, the output looks completely different.\n
\n\n\nhash(\"hbllo\") = 58756879c05c68dfac9866712fad6a93f8146f337a69afe7dd238f3364946366
\nhash(\"waltz\") = c0e81794384491161f1777c232bc6bd9ec38f616560b120fda8e90f383853542
\n
\nWe can use a function like this to protect passwords. Instead of storing the\npassword in plain text, or encrypting the password, we can store the hash of the\npassword. Then, when a user logs in, we hash the password they've given us and\ncompare it to the hash that's saved in the database. Because the chance of two\npasswords producing the same hash is extremely low (one of the properties of\na hash function), the chance of someone getting in with the wrong password is\nalso extremely low.\n
\n\n\nYou might think we can stop here. In fact, we can't, because storing passwords\nthis way is insecure. \n
\n\n\nTo see why, consider what happens when two users have the same password: the\nhashes are the same! An attacker can tell, just by comparing the hashes, which\nusers are using the same password. Clearly this is a vulnerability, since if the\nattacker wants to get in to Alice's account, and sees that Bob has the same\npassword, the attacker can bribe (or torture) Bob for his password to\nget into Alice's account.\n
\n\n\nThat's not the only reason. Another reason is that the same password always\nhashes to the same value. There's a one-to-one correspondence between hashes and\npasswords. This means that an attacker can pre-compute huge tables of\nhashes, then search for the hash they want to crack in that table. Because the\nsearch can be done very quickly, cracking hashes this way is a lot faster than\ntrying to guess the password for each hash.\n
\n\n\nTo see how fast it can be, copy and paste these SHA256 hashes into CrackStation's Hash Cracker:\n
\n\n\n08eac03b80adc33dc7d8fbe44b7c7b05d3a2c511166bdb43fcb710b03ba919e7
\ne4ba5cbd251c98e6cd1c23f126a3b81d8d8328abc95387229850952b3ef9f904
\n5206b8b8a996cf5320cb12ca91c7b790fba9f030408efe83ebb83548dc3007bd
\n
\nThe result is that all four hashes can be cracked in under a second. This is\nobviously much faster than trying to guess each hash's password one by one.\nUsing this technique, an attacker can crack most of the hashes in your user\naccount database in a matter of minutes.\n
\n\n\nThese password cracking databases are very real, and are used by attackers all\nthe time. One special type, called a \"Rainbow Table\", can fit the MD5 hashes of\nall possible 8 character passwords into a
Weak System #4: Hashing With Salt
\n\n\nThe attacks we saw in the previous section were possible because every time the\nsame password was hashed, the result was the same. This let attackers see who\nwas using the same password, and let them build a huge database of hashes that\ncould be quickly searched to find the password for a given hash.\n
\n\n\nTo prevent these attacks, we need to make sure that even if two users use the\nsame password, or if one user uses the same password twice, the hash values are\nalways different. This is done by adding some randomness to the hashing process.\n
\n\n\nTo hash a password, we use a cryptographically secure pseudo-random number\ngenerator (CSPRNG) to generate a random string, called a salt, which we\nprepend to the password before hashing it. We then save that random number with\nthe hash, since we'll need to verify passwords against the hash.\n
\n\n\nHere's what it looks like in pseudocode. The double bar symbol \"A || B\" means\nconcatenate the string A with the string B.\n
\n\n\n# When a new account is created, or a user changes their password.\ncreate_hash(PASSWORD):\n Generate a random string SALT with a CSPRNG.\n HASH = sha256(SALT || PASSWORD).\n return (SALT, HASH).\n\n\n# When a user tries to log in.\ncheck_password((SALT, HASH), PASSWORD_GUESS):\n GUESS_HASH = sha256(SALT || PASSWORD_GUESS).\n if GUESS_HASH equals HASH:\n return TRUE.\n else:\n return FALSE.\n\n
\nAssuming the salt is long enough, always generated with a CSPRNG, and no salt is\never used to hash more than one password, the attacks of the previous section\nare no longer possible. The only way to crack these hashes is to test password\nguesses for each hash individually. However, this is still not good enough!\n
\n\n\nHash functions like SHA256 were designed to be fast. Good CPUs can compute\nmillions of SHA256 hashes per second, and good GPUs (graphics processors) can\ncompute billions of hashes per second. Customized hardware (FPGAs and\nASICs) can reach even higher speeds. This is exactly the opposite of what we\nwant, since it means an attacker who stole the user account database can crack\nthe hashes a rate of billions of password guesses per second. Not good.\n
\n\n\nThis is the last hurdle in the race. Once we pass it, we'll finally arrive at\na secure password storage system.\n
\n\n\nSecure System #1: Slow Hashing
\n\n\nIn the previous section, we added salt to our passwords to prevent\npre-computation attacks. We then saw that hash functions like SHA256 can be\ncomputed extremely quickly by GPUs and custom hardware, letting attackers test\nbillions of passwords per second.\n
\n\n\nPassword hashing functions don't need to be that fast. You probably won't be\nhandling millions of authentication requests per second from one server, so\nthere's no reason an authentication server will ever need to compute millions of\nhashes per second. It's alright if the password hashing process is 1,000 times\nor even 1,000,000 times slower than a regular hash function. To make things\nharder for GPUs and custom hardware, we also want the hashing process to need\nlots of memory.\n
\n\n\nIt's not enough to add a call to sleep() or a time-consuming \"no op\"\nloop into the password hashing code. An attacker can remove it and compute\nhashes as fast as they want. Instead, the hashing function has to be truly hard\nto compute. There should be no way to compute it any faster or with less memory.\nMore correctly stated, there should be no way to reduce the overall time\n* area needed to compute the function, where \"area\" means the size of the\ncircuit you need to compute the hash in a given amount of time.\n
\n\n\nWe want the defender's (password authenticator's) implementation of the function\nto be as optimal as possible. This is important, since if the defender is taking\n10x longer to compute the function, the attacker, using a 10x more efficient\nimplementation, has an advantage over the defender. That means these functions\nshould be implemented in native code (assembly language or C/C++), and not in\na scripting language.\n
\n\n\nResearchers are still figuring out how to best design these slow hashes. There's\na competition going on right now, called the
\nIf you want to know more about how slow hashes are designed, read the
\nSo, if we choose scrypt as our slow hash, we can store passwords securely like\nthis. It's the same as before, except we're using scrypt instead of SHA256.\n
\n\n\n# When a new account is created, or a user changes their password.\ncreate_hash(PASSWORD):\n Generate a random string SALT with a CSPRNG.\n HASH = scrypt(SALT, PASSWORD).\n return (SALT, HASH).\n\n\n# When a user tries to log in.\ncheck_password((SALT, HASH), PASSWORD_GUESS):\n GUESS_HASH = scrypt(SALT, PASSWORD_GUESS).\n if GUESS_HASH equals HASH:\n return TRUE.\n else:\n return FALSE.\n\n
\n- want defender to be optimized\n- the functions are parameterized (take time and memory parameters)\n- summarry like \"we've mitigated pre-computation attacks as well as made it\nextremely difficult for GPUs or whatever\"\n
\n\n\n - Weak passwords can still be found .. intro next section with\n security-by-obscurity key.\n - AKA key stretching,\n - Offloading to the client (sjcl) -- does not remove need for server hashing\n - Re-read old post since this is missing some stuff that was covered in it\n\n\n
\nEven with the salt and slow hashing, weak passwords can still be cracked.\nIn the next section, we'll see how, with the help of some special hardware, we\ncan protect our hashes so that even the weak ones can't be cracked.\n
\n\nIncreasing Security: Hardware Security Modules
\n\n\n - Use hardware device with embedded key to do the hashing, so that unless\n it's physically stolen and tampered with, the passwords are really safe.\n - Also possible to do w/o custom hardware... just set up dedicated password\n authentication box that does nothing but hash passwords; no services, etc.\n - Mandatory for websites with more than 100k users.\n - Cloud options? (amazon thing)?\n - Physical options? (yubihsm?)\n\n\n
Common Mistakes
\n\n\nBe on the lookout for these common password hashing mistakes.\n
\n\nSalt Reuse
\n\nShort Salts
\n\nGenerating Salts with a Weak Random Number Generator
\n\nFrequently Asked Questions
\n\n\n - Basically the same list of FAQ from the original article except emphasize\n slow hashing.\n\n - In \"what to do when\" section... \"don't clutter up the notice message with\nall the crap about salt and hashing and scrypt, they won't understand. Just tell\nthem to change their password if they used it anywhere else etc. But do publish\nthe information about hashing, just don't make it distracting or give a false\nsense of security.\"\n\n\n
Source Code
\n\n\n - Embed the source code here.\n - Putting the source code way down here might make people miss it, so add\n prominent links up at the top (not just in the red warning box).\n\n" }, { "path": "src/pages/hashing-security.php", "content": "
Salted Password Hashing - Doing it Right
\n\n\nIf you're a web developer, you've probably had to make a user account system.\nThe most important aspect of a user account system is how user passwords are\nprotected. User account databases are hacked frequently, so you absolutely must\ndo something to protect your users' passwords if your website is ever breached.\nThe best way to protect passwords is to employ salted password hashing.\nThis page will explain why it's done the way it is.\n
\n\n\nThere are a lot of conflicting ideas and misconceptions on how to do password\nhashing properly, probably due to the abundance of misinformation on the web.\nPassword hashing is one of those things that's so simple, but yet so many people\nget wrong. With this page, I hope to explain not only the correct way to do it,\nbut why it should be done that way.\n
\n\n\n\nIf for some reason you missed that big red warning note, please go read it now.\nReally, this guide is not meant to walk you through the process of\nwriting your own storage system, it's to explain the reasons why passwords\nshould be stored a certain way.\n
\n\nYou may use the following links to jump to the different sections of this page.
\n\n| 1. What is password hashing? | \n2. How Hashes are Cracked | \n\n3. Adding Salt | \n
| 4. Ineffective Hashing Methods | \n5. How to hash properly | \n6. Frequently Asked Questions | \n
What is password hashing?
\n\n hash(\"hbllo\") = 58756879c05c68dfac9866712fad6a93f8146f337a69afe7dd238f3364946366
\n hash(\"waltz\") = c0e81794384491161f1777c232bc6bd9ec38f616560b120fda8e90f383853542
\n
\nHash algorithms are one way functions. They turn any amount of data into\na fixed-length \"fingerprint\" that cannot be reversed. They also have the\nproperty that if the input changes by even a tiny bit, the resulting hash is\ncompletely different (see the example above). This is great for protecting\npasswords, because we want to store passwords in a form that protects them even\nif the password file itself is compromised, but at the same time, we need to be\nable to verify that a user's password is correct.\n
\n\n\nThe general workflow for account registration and authentication in a hash-based\naccount system is as follows:\n
\n- \n
- The user creates an account. \n
- Their password is hashed and stored in the database. At no point is the plain-text (unencrypted) password ever written to the hard drive. \n\n
- When the user attempts to login, the hash of the password they entered is checked against the hash of their real password (retrieved from the database). \n
- If the hashes match, the user is granted access. If not, the user is told they entered invalid login credentials. \n
- Steps 3 and 4 repeat every time someone tries to login to their account. \n
\nIn step 4, never tell the user if it was the username or password they got wrong. Always display\na generic message like \"Invalid username or password.\" This prevents attackers from enumerating\nvalid usernames without knowing their passwords.\n
\n\n\nIt should be noted that the hash functions used to protect passwords are not the\nsame as the hash functions you may have seen in a data structures course. The\nhash functions used to implement data structures such as hash tables are\ndesigned to be fast, not secure. Only cryptographic hash functions may be\nused to implement password hashing. Hash functions like SHA256, SHA512, RipeMD,\nand WHIRLPOOL are cryptographic hash functions.\n
\n\n\nIt is easy to think that all you have to do is run the password through a\ncryptographic hash function and your users' passwords will be secure. This is\nfar from the truth. There are many ways to recover passwords from plain hashes\nvery quickly. There are several easy-to-implement techniques that make these\n\"attacks\" much less effective. To motivate the need for these techniques,\nconsider this very website. On the front page, you can submit a list of hashes\nto be cracked, and receive results in less than a second. Clearly, simply\nhashing the password does not meet our needs for security.\n
\n\nThe next section will discuss some of the common attacks used to crack plain password hashes.
\n\n\nHow Hashes are Cracked
\n- \n
- \n
Dictionary and Brute Force Attacks
\n\n
\n\n \n\n \n\n\nDictionary Attack
\n Trying apple : failed
\n Trying blueberry : failed
\n Trying justinbeiber : failed
\n... \n Trying letmein : failed
\n\n Trying s3cr3t : success!
\n\n \n\n\nBrute Force Attack
\n Trying aaaa : failed
\n Trying aaab : failed
\n Trying aaac : failed
\n... \n Trying acdb : failed
\n Trying acdc : success!
\n\n The simplest way to crack a hash is to try to guess the password, hashing each guess, and checking if the guess's hash equals the hash being cracked. If the hashes are equal, the guess is the password.\n The two most common ways of guessing passwords are dictionary attacks and brute-force attacks.\n
\n\n\n A dictionary attack uses a file containing words, phrases, common passwords,\n and other strings that are likely to be used as a password. Each word in the\n file is hashed, and its hash is compared to the password hash. If they\n match, that word is the password. These dictionary files are constructed by\n extracting words from large bodies of text, and even from real databases of\n passwords. Further processing is often applied to dictionary files, such as\n replacing words with their \"leet speak\" equivalents (\"hello\" becomes\n \"h3110\"), to make them more effective.\n
\n\n\n A brute-force attack tries every possible combination of characters up to a\n given length. These attacks are very computationally expensive, and are\n usually the least efficient in terms of hashes cracked per processor time,\n but they will always eventually find the password. Passwords should be long\n enough that searching through all possible character strings to find it will\n take too long to be worthwhile.\n
\n\n\n There is no way to prevent dictionary attacks or brute force attacks. They\n can be made less effective, but there isn't a way to prevent them\n altogether. If your password hashing system is secure, the only way to crack\n the hashes will be to run a dictionary or brute-force attack on each hash.\n
\n \n\n - \n
Lookup Tables
\n\n \n Searching: 5f4dcc3b5aa765d61d8327deb882cf99: FOUND: password5
\n Searching: 6cbe615c106f422d23669b610b564800: not in database
\n Searching: 630bf032efe4507f2c57b280995925a9: FOUND: letMEin12
\n Searching: 386f43fab5d096a7a66d67c8f213e5ec: FOUND: mcd0nalds
\n Searching: d5ec75d5fe70d428685510fae36492d9: FOUND: p@ssw0rd!
\n \n \n\n\n Lookup tables are an extremely effective method for cracking many hashes of\n the same type very quickly. The general idea is to pre-compute the\n hashes of the passwords in a password dictionary and store them, and their\n corresponding password, in a lookup table data structure. A good\n implementation of a lookup table can process hundreds of hash lookups per\n second, even when they contain many billions of hashes.\n
\n\n\n If you want a better idea of how fast lookup tables can be, try cracking the\n following sha256 hashes with CrackStation's free hash\n cracker.\n
\n\n\n c11083b4b0a7743af748c85d343dfee9fbb8b2576c05f3a7f0d632b0926aadfc\n\n\n\n
\n 08eac03b80adc33dc7d8fbe44b7c7b05d3a2c511166bdb43fcb710b03ba919e7
\n e4ba5cbd251c98e6cd1c23f126a3b81d8d8328abc95387229850952b3ef9f904
\n 5206b8b8a996cf5320cb12ca91c7b790fba9f030408efe83ebb83548dc3007bd
\n- \n
Reverse Lookup Tables
\n\n \n Searching for hash(apple) in users' hash list... : Matches [alice3, 0bob0, charles8]
\n Searching for hash(blueberry) in users' hash list... : Matches [usr10101, timmy, john91]
\n Searching for hash(letmein) in users' hash list... : Matches [wilson10, dragonslayerX, joe1984]
\n Searching for hash(s3cr3t) in users' hash list... : Matches [bruce19, knuth1337, john87]
\n Searching for hash(z@29hjja) in users' hash list... : No users used this password
\n \n \n\n This attack allows an attacker to apply a dictionary or brute-force attack to many hashes at the same time, without having to pre-compute a lookup table.\n
\n\n\n First, the attacker creates a lookup table that maps each password hash from\n the compromised user account database to a list of users who had that hash.\n The attacker then hashes each password guess and uses the lookup table to\n get a list of users whose password was the attacker's guess. This attack is\n especially effective because it is common for many users to have the same\n password. \n
\n\n\n- \n
\n\n\nRainbow Tables
\n\n Rainbow tables are a time-memory trade-off technique. They are like lookup\n tables, except that they sacrifice hash cracking speed to make the lookup\n tables smaller. Because they are smaller, the solutions to more hashes can\n be stored in the same amount of space, making them more effective. Rainbow\n tables that can crack any md5 hash of a password up to 8 characters long
\n\nNext, we'll look at a technique called salting, which makes it impossible to use\nlookup tables and rainbow tables to crack a hash.\n
\n\n\nAdding Salt
\n\n hash(\"hello\") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824\n\n
\n hash(\"hello\" + \"QxLUF1bgIAdeQX\") = 9e209040c863f84a31e719795b2577523954739fe5ed3b58a75cff2127075ed1
\n\n hash(\"hello\" + \"bv5PehSMfV11Cd\") = d1d3ec2e6f20fd420d50e2642992841d8338a314b8ea157c9e18477aaef226ab
\n hash(\"hello\" + \"YYLmfY6IehjZMQ\") = a49670c3c18b9e079b9cfaf51634f563dc8ae3070db2c4a8544305df1b60f007\n\nLookup tables and rainbow tables only work because each password is hashed the\nexact same way. If two users have the same password, they'll have the same\npassword hashes. We can prevent these attacks by randomizing each hash, so that\nwhen the same password is hashed twice, the hashes are not the same.\n
\n\n\nWe can randomize the hashes by appending or prepending a random string, called a\nsalt, to the password before hashing. As shown in the example above, this\nmakes the same password hash into a completely different string every time. To\ncheck if a password is correct, we need the salt, so it is usually stored in the\nuser account database along with the hash, or as part of the hash string itself.\n
\n\n\nThe salt does not need to be secret. Just by randomizing the hashes, lookup\ntables, reverse lookup tables, and rainbow tables become ineffective. An\nattacker won't know in advance what the salt will be, so they can't pre-compute\na lookup table or rainbow table. If each user's password is hashed with a\ndifferent salt, the reverse lookup table attack won't work either. \n
\n\n\nIn the next section, we'll look at how salt is commonly implemented incorrectly.\n
\n\n\nThe WRONG Way: Short Salt & Salt Reuse
\n\n\nThe most common salt implementation errors are reusing the same salt in multiple\nhashes, or using a salt that is too short.\n
\n\nSalt Reuse
\n\n\nA common mistake is to use the same salt in each hash. Either the salt is\nhard-coded into the program, or is generated randomly once. This is ineffective\nbecause if two users have the same password, they'll still have the same hash.\nAn attacker can still use a reverse lookup table attack to run a dictionary\nattack on every hash at the same time. They just have to apply the salt to each\npassword guess before they hash it. If the salt is hard-coded into a popular\nproduct, lookup tables and rainbow tables can be built for that salt, to make it\neasier to crack hashes generated by the product.\n
\n\n\nA new random salt must be generated each time a user creates an account or changes their password.\n
\n\nShort Salt
\n\n\nIf the salt is too short, an attacker can build a lookup table for every\npossible salt. For example, if the salt is only three ASCII characters, there\nare only 95x95x95 = 857,375 possible salts. That may seem like a lot, but if\neach lookup table contains only 1MB of the most common passwords, collectively\nthey will be only 837GB, which is not a lot considering 1000GB hard drives can\nbe bought for under $100 today.\n
\n\n\nFor the same reason, the username shouldn't be used as a salt. Usernames may be\nunique to a single service, but they are predictable and often reused for\naccounts on other services. An attacker can build lookup tables for common\nusernames and use them to crack username-salted hashes.\n
\n\n\nTo make it impossible for an attacker to create a lookup table for every\npossible salt, the salt must be long. A good rule of thumb is to use a salt that\nis the same size as the output of the hash function. For example, the output of\nSHA256 is 256 bits (32 bytes), so the salt should be at least 32 random bytes.\n
\n\nThe WRONG Way: Double Hashing & Wacky Hash Functions
\n\n\nThis section covers another common password hashing misconception: wacky\ncombinations of hash algorithms. It's easy to get carried away and try to\ncombine different hash functions, hoping that the result will be more secure. In\npractice, though, there is very little benefit to doing it. All it does is\ncreate interoperability problems, and can sometimes even make the hashes less\nsecure. Never try to invent your own crypto, always use a standard that has\nbeen designed by experts. Some will argue that using multiple hash functions\nmakes the process of computing the hash slower, so cracking is slower, but\nthere's a better way to make the cracking process slower as we'll see later.\n
\n\nHere are some examples of poor wacky hash functions I've seen suggested in forums on the internet.
\n\n- \n
- md5(sha1(password)) \n
- md5(md5(salt) + md5(password)) \n
- sha1(sha1(password)) \n
- sha1(str_rot13(password + salt)) \n
- md5(sha1(md5(md5(password) + sha1(password)) + md5(password))) \n
\nDo not use any of these.\n
\n\n\nNote: This section has proven to be controversial. I've received a number of\nemails arguing that wacky hash functions are a good thing, because it's better\nif the attacker doesn't know which hash function is in use, it's less\nlikely for an attacker to have pre-computed a rainbow table for the wacky hash\nfunction, and it takes longer to compute the hash function.\n
\n\n\nAn attacker cannot attack a hash when he doesn't know the algorithm, but note
\n\n\nIf you really want to use a standardized "wacky" hash function like HMAC, then it's OK.\nBut if your reason for doing so is to make the hash computation slower, read the section below about key stretching first.\n
\n\n\nCompare these minor benefits to the risks of accidentally implementing a\ncompletely insecure hash function and the interoperability problems wacky hashes\ncreate. It's clearly best to use a standard and well-tested algorithm.\n
\n\nHash Collisions
\n\n\nBecause hash functions map arbitrary amounts of data to fixed-length strings,\nthere must be some inputs that hash into the same string. Cryptographic hash\nfunctions are designed to make these collisions incredibly difficult to find.\nFrom time to time, cryptographers find \"attacks\" on hash functions that make\nfinding collisions easier. A recent example is the MD5 hash function, for which\ncollisions have actually been found.\n
\n\n\nCollision attacks are a sign that it may be more likely for a string other than\nthe user's password to have the same hash. However, finding collisions in even a\nweak hash function like MD5 requires a lot of dedicated computing power, so it\nis very unlikely that these collisions will happen \"by accident\" in practice. A\npassword hashed using MD5 and salt is, for all practical purposes, just as\nsecure as if it were hashed with SHA256 and salt. Nevertheless, it is a good\nidea to use a more secure hash function like SHA256, SHA512, RipeMD, or\nWHIRLPOOL if possible.\n
\n\n\nThe RIGHT Way: How to Hash Properly
\n\n\nThis section describes exactly how passwords should be hashed. The first\nsubsection covers the basics—everything that is absolutely necessary. The\nfollowing subsections explain how the basics can be augmented to make the hashes\neven harder to crack.\n
\n\nThe Basics: Hashing with Salt
\n\n\nWarning: Do not just read this section. You absolutely must implement the\nstuff in the next section: \"Making Password Cracking Harder: Slow Hash\nFunctions\".\n
\n\n\nWe've seen how malicious hackers can crack plain hashes very quickly using\nlookup tables and rainbow tables. We've learned that randomizing the hashing\nusing salt is the solution to the problem. But how do we generate the salt, and\nhow do we apply it to the password?\n
\n\n\nSalt should be generated using a Cryptographically Secure Pseudo-Random\nNumber Generator (CSPRNG). CSPRNGs are very different than ordinary\npseudo-random number generators, like the \"C\" language's \nrand() function. As the name suggests, CSPRNGs are\ndesigned to be cryptographically secure, meaning they provide a high level of\nrandomness and are completely unpredictable. We don't want our salts to be\npredictable, so we must use a CSPRNG. The following table lists some CSPRNGs\nthat exist for some popular programming platforms.\n
\n\n\n
\n\nPlatform CSPRNG PHP mcrypt_create_iv, openssl_random_pseudo_bytes Java java.security.SecureRandom Dot NET (C#, VB) System.Security.Cryptography.RNGCryptoServiceProvider Ruby SecureRandom Python secrets Perl Math::Random::Secure C/C++ (Windows API) CryptGenRandom Any language on GNU/Linux or Unix Read from /dev/random or /dev/urandom The salt needs to be unique per-user per-password. Every time a user creates an account or\nchanges their password, the password should be hashed using a new random salt. Never reuse a salt.\nThe salt also needs to be long, so that there are many possible salts. As a rule of thumb, make your\nsalt is at least as long as the hash function's output. The salt should be stored in the user\naccount table alongside the hash.
\n\nTo Store a Password
\n\n- \n
- Generate a long random salt using a CSPRNG. \n
- Prepend the salt to the password and hash it with a standard password hashing function like Argon2, bcrypt, scrypt, or PBKDF2. \n
- Save both the salt and the hash in the user's database record. \n
To Validate a Password
\n\n- \n
- Retrieve the user's salt and hash from the database. \n
- Prepend the salt to the given password and hash it using the same hash function. \n
- Compare the hash of the given password with the hash from the database. If they match, the password is correct. Otherwise, the password is incorrect. \n
In a Web Application, always hash on the server
\n\nIf you are writing a web application, you might wonder where to hash.\nShould the password be hashed in the user's browser with JavaScript, or should\nit be sent to the server \"in the clear\" and hashed there?\n
\n\nEven if you are hashing the user's passwords in JavaScript, you still have\nto hash the hashes on the server. Consider a website that hashes users'\npasswords in the user's browser without hashing the hashes on the server. To\nauthenticate a user, this website will accept a hash from the browser and check\nif that hash exactly matches the one in the database. This seems more secure\nthan just hashing on the server, since the users' passwords are never sent to\nthe server, but it's not.
\n\n\nThe problem is that the client-side hash logically becomes the user's\npassword. All the user needs to do to authenticate is tell the server the hash\nof their password. If a bad guy got a user's hash they could use it to\nauthenticate to the server, without knowing the user's password! So, if the bad\nguy somehow steals the database of hashes from this hypothetical website,\nthey'll have immediate access to everyone's accounts without having to guess any\npasswords.\n
\n\n\nThis isn't to say that you shouldn't hash in the browser, but if you\ndo, you absolutely have to hash on the server too. Hashing in the browser is\ncertainly a good idea, but consider the following points for your implementation:\n
\n\n- \n
- \n
\n Client-side password hashing is not a substitute for HTTPS\n (SSL/TLS). If the connection between the browser and the server is\n insecure, a man-in-the-middle can modify the JavaScript code as it is\n downloaded to remove the hashing functionality and get the user's\n password.\n
\n \n\n - \n
\n Some web browsers don't support JavaScript, and some users disable\n JavaScript in their browser. So for maximum compatibility, your app\n should detect whether or not the browser supports JavaScript and emulate\n the client-side hash on the server if it doesn't.\n
\n \n\n - \n
\n You need to salt the client-side hashes too. The obvious solution is to\n make the client-side script ask the server for the user's salt. Don't do\n that, because it lets the bad guys check if a username is valid without\n knowing the password. Since you're hashing and salting (with a good\n salt) on the server too, it's OK to use the username (or email)\n concatenated with a site-specific string (e.g. domain name) as the\n client-side salt.\n
\n \n
Making Password Cracking Harder: Slow Hash Functions
\n\n\n Salt ensures that attackers can't use specialized attacks like lookup tables\n and rainbow tables to crack large collections of hashes quickly, but it\n doesn't prevent them from running dictionary or brute-force attacks on each\n hash individually. High-end graphics cards (GPUs) and custom hardware can\n compute billions of hashes per second, so these attacks are still very\n effective. To make these attacks less effective, we can use a technique\n known as key stretching.\n
\n\n\n The idea is to make the hash function very slow, so that even with a fast\n GPU or custom hardware, dictionary and brute-force attacks are too slow to\n be worthwhile. The goal is to make the hash function slow enough to impede\n attacks, but still fast enough to not cause a noticeable delay for the user.\n
\n\n\n Key stretching is implemented using a special type of CPU-intensive hash\n function. Don't try to invent your own–simply iteratively hashing the\n hash of the password isn't enough as it can be parallelized in hardware and\n executed as fast as a normal hash. Use a standard algorithm like
\n\n\n These algorithms take a security factor or iteration count as an argument.\n This value determines how slow the hash function will be. For desktop\n software or smartphone apps, the best way to choose this parameter is to run\n a short benchmark on the device to find the value that makes the hash take\n about half a second. This way, your program can be as secure as possible\n without affecting the user experience.\n
\n\n\n If you use a key stretching hash in a web application, be aware that you\n will need extra computational resources to process large volumes of\n authentication requests, and that key stretching may make it easier to run a\n Denial of Service (DoS) attack on your website. I still recommend using key\n stretching, but with a lower iteration count. You should calculate the\n iteration count based on your computational resources and the expected\n maximum authentication request rate. The denial of service threat can be\n eliminated by making the user solve a CAPTCHA every time they log in.\n Always design your system so that the iteration count can be increased or\n decreased in the future.\n
\n\n\n If you are worried about the computational burden, but still want to use key\n stretching in a web application, consider running the key stretching\n algorithm in the user's browser with JavaScript. The Stanford JavaScript Crypto\n Library includes PBKDF2. The iteration count should be set low enough\n that the system is usable with slower clients like mobile devices, and the\n system should fall back to server-side computation if the user's browser\n doesn't support JavaScript. Client-side key stretching does not remove the\n need for server-side hashing. You must hash the hash generated by the client\n the same way you would hash a normal password.\n
\n\nImpossible-to-crack Hashes: Keyed Hashes and Password Hashing Hardware
\n\n\n As long as an attacker can use a hash to check whether a password guess is\n right or wrong, they can run a dictionary or brute-force attack on the hash.\n The next step is to add a secret key to the hash so that only someone\n who knows the key can use the hash to validate a password. This can be\n accomplished two ways. Either the hash can be encrypted using a cipher like\n AES, or the secret key can be included in the hash using a keyed hash\n algorithm like HMAC.\n
\n\n\n This is not as easy as it sounds. The key has to be kept secret from an\n attacker even in the event of a breach. If an attacker gains full access to\n the system, they'll be able to steal the key no matter where it is stored.\n The key must be stored in an external system, such as a physically separate\n server dedicated to password validation, or a special hardware device\n attached to the server such as the YubiHSM.\n
\n\n\n I highly recommend this approach for any large scale (more than 100,000\n users) service. I consider it necessary for any service hosting more than\n 1,000,000 user accounts.\n
\n\n\n If you can't afford multiple dedicated servers or special hardware devices,\n you can still get some of the benefits of keyed hashes on a standard web\n server. Most databases are breached using
\n\n\n Please note that keyed hashes do not remove the need for salt. Clever\n attackers will eventually find ways to compromise the keys, so it is\n important that hashes are still protected by salt and key stretching.\n
\n\n\nOther Security Measures
\n\n\nPassword hashing protects passwords in the event of a security breach. It does\nnot make the application as a whole more secure. Much more must be done to\nprevent the password hashes (and other user data) from being stolen in the first\nplace.\n
\n\n\nEven experienced developers must be educated in security in order to write secure applications.\nA great resource for learning about web application vulnerabilities is \nThe Open Web Application\nSecurity Project (OWASP). A good introduction is the \nOWASP Top Ten Vulnerability List.\nUnless you understand all the vulnerabilities on the list, do not attempt to\nwrite a web application that deals with sensitive data. It is the employer's\nresponsibility to ensure all developers are adequately trained in secure\napplication development.\n
\n\n\nHaving a third party \"penetration test\" your application is a good idea. Even\nthe best programmers make mistakes, so it always makes sense to have a security\nexpert review the code for potential vulnerabilities. Find a trustworthy\norganization (or hire staff) to review your code on a regular basis. The\nsecurity review process should begin early in an application's life and continue\nthroughout its development.\n
\n\n\nIt is also important to monitor your website to detect a breach if one does\noccur. I recommend hiring at least one person whose full time job is detecting\nand responding to security breaches. If a breach goes undetected, the attacker\ncan make your website infect visitors with malware, so it is extremely important\nthat breaches are detected and responded to promptly.\n
\n\n\nFrequently Asked Questions
\nWhat hash algorithm should I use?
\nDO use:\n\n- \n
- Well-designed key stretching algorithms such as PBKDF2, bcrypt, and scrypt. \n
- OpenWall's Portable PHP password hashing\n framework \n
- My implementations of PBKDF2 in PHP, C#, Java, and Ruby. \n
- Secure versions of crypt ($2y$, $5$, $6$) \n
\nDO NOT use:\n\n- \n
- Fast cryptographic hash functions such as MD5, SHA1, SHA256, SHA512, RipeMD, WHIRLPOOL, SHA3, etc. \n
- Insecure versions of crypt ($1$, $2$, $2x$, $3$). \n
- Any algorithm that you designed yourself. Only use technology that is in the public domain and has been well-tested by experienced cryptographers. \n
\n Even though there are no cryptographic attacks on MD5 or SHA1 that make\n their hashes easier to crack, they are old and are widely considered\n (somewhat incorrectly) to be inadequate for password storage. So I don't\n recommend using them. An exception to this rule is PBKDF2, which is\n frequently implemented using SHA1 as the underlying hash function.\n
\nHow should I allow users to reset their password when they forget it?
\n\n\n It is my personal opinion that all password reset mechanisms in widespread\n use today are insecure. If you have high security requirements, such as an\n encryption service would, do not let the user reset their password.\n
\n\n\nMost websites use an email loop to authenticate users who have forgotten their\npassword. To do this, generate a random single-use token that is strongly\ntied to the account. Include it in a password reset link sent to the user's\nemail address. When the user clicks a password reset link containing a valid\ntoken, prompt them for a new password. Be sure that the token is strongly tied\nto the user account so that an attacker can't use a token sent to his own email\naddress to reset a different user's password.\n
\n\n\nThe token must be set to expire in 15 minutes or after it is used, whichever\ncomes first. It is also a good idea to expire any existing password tokens when\nthe user logs in (they remembered their password) or requests another reset\ntoken. If a token doesn't expire, it can be forever used to break into the\nuser's account. Email (SMTP) is a plain-text protocol, and there may be\nmalicious routers on the internet recording email traffic. And, a user's email\naccount (including the reset link) may be compromised long after their password\nhas been changed. Making the token expire as soon as possible reduces the\nuser's exposure to these attacks.\n
\n\n\nAttackers will be able to modify the tokens, so don't store the user account\ninformation or timeout information in them. They should be an unpredictable\nrandom binary blob used only to identify a record in a database table.\n
\n\n\nNever send the user a new password over email. Remember to pick a new random\nsalt when the user resets their password. Don't re-use the one that was used to\nhash their old password.\n
\n\nWhat should I do if my user account database gets leaked/hacked?
\n\n\nYour first priority is to determine how the system was compromised and patch\nthe vulnerability the attacker used to get in. If you do not have experience\nresponding to breaches, I highly recommend hiring a third-party security firm.\n
\n\n\nIt may be tempting to cover up the breach and hope nobody notices. However, trying to cover up a breach makes you look worse, because you're putting\nyour users at further risk by not informing them that their passwords and other\npersonal information may be\ncompromised. You must inform your users as soon as possible—even if you don't yet fully understand what happened. Put a notice on the\nfront page of your website that links to a page with more detailed information,\nand send a notice to each user by email if possible. \n
\n\n\nExplain to your users exactly how their passwords were protected—hopefully\nhashed with salt—and that even though they were protected with a salted\nhash, a malicious hacker can still run dictionary and brute force attacks on the\nhashes. Malicious hackers will use any passwords they find to try to login to a\nuser's account on a different website, hoping they used the same password on\nboth websites. Inform your users of this risk and recommend that they change\ntheir password on any website or service where they used a similar password.\nForce them to change their password for your service the next time they log in.\nMost users will try to \"change\" their password to the original password to get\naround the forced change quickly. Use the current password hash to ensure that\nthey cannot do this.\n
\n\n\nIt is likely, even with salted slow hashes, that an attacker will be able to\ncrack some of the weak passwords very quickly. To reduce the attacker's window of opportunity to use these passwords, you should require, in\naddition to the current password, an email loop for authentication until the\nuser has changed their password. See the previous question, \"How should I allow\nusers to reset their password when they forget it?\" for tips on implementing\nemail loop authentication.\n
\n\n\nAlso tell your users what kind of personal information was stored on the\nwebsite. If your database includes credit card numbers, you should instruct your\nusers to look over their recent and future bills closely and cancel their\ncredit card.\n
\n\nWhat should my password policy be? Should I enforce strong passwords?
\n\nIf your service doesn't have strict security requirements, then don't limit your\nusers. I recommend showing users information about the strength of their\npassword as they type it, letting them decide how secure they want their\npassword to be. If you have special security needs, enforce a minimum length of\n12 characters and require at least two letters, two digits, and two symbols.\n
\n\nDo not force your users to change their password more often than once every six\nmonths, as doing so creates \"user fatigue\" and makes users less likely to choose\ngood passwords. Instead, train users to change their password whenever they feel\nit has been compromised, and to never tell their password to anyone. If it is a\nbusiness setting, encourage employees to use paid time to memorize and practice\ntheir password.\n
\n\nIf an attacker has access to my database, can't they just replace the hash of my password with their own hash and login?
\n\n\nYes, but if someone has access to your database, they probably already have\naccess to everything on your server, so they wouldn't need to login to your\naccount to get what they want. The purpose of password hashing (in the context\nof a website) is not to protect the website from being breached, but to protect\nthe passwords if a breach does occur.\n
\n\n\nYou can prevent hashes from being replaced during a SQL injection attack by\nconnecting to the database with two users with different permissions. One for\nthe 'create account' code and one for the 'login' code. The 'create account'\ncode should be able to read and write to the user table, but the 'login' code\nshould only be able to read.\n
\n\nWhy do I have to use a special algorithm like HMAC? Why can't I just append\nthe password to the secret key?
\n\nHash functions like MD5, SHA1, and SHA2 use the \nMerkle–Damgård construction, which makes them vulnerable to what are known\nas length extension attacks. This means that given a hash H(X), an attacker can\nfind the value of H(pad(X) + Y), for any other string Y, without knowing X.\npad(X) is the padding function used by the hash.\n
\n\n\nThis means that given a hash H(key + message), an attacker can compute H(pad(key +\nmessage) + extension), without knowing the key. If the hash was being used as a\nmessage authentication code, using the key to prevent an attacker from being\nable to modify the message and replace it with a different valid hash, the\nsystem has failed, since the attacker now has a valid hash of message +\nextension.\n
\n\n\nIt is not clear how an attacker could use this attack to crack a password hash\nquicker. However, because of the attack, it is considered bad practice to\nuse a plain hash function for keyed hashing. A clever cryptographer may one day\ncome up with a clever way to use these attacks to make cracking faster, so use\nHMAC.\n
\n\n\nShould the salt come before or after the password?
\n\n\nIt doesn't matter, but pick one and stick with it for interoperability's sake.\nHaving the salt come before the password seems to be more common.\n
\n\nWhy does the hashing code on this page compare the hashes in\n"length-constant"\ntime?
\n\n\nComparing the hashes in "length-constant" time ensures that an\nattacker cannot extract the hash of a password in an on-line system using a\ntiming attack, then crack it off-line.\n
\n\n\nThe standard way to check if two sequences of bytes (strings) are the same is to\ncompare the first byte, then the second, then the third, and so on. As soon as\nyou find a byte that isn't the same for both strings, you know they are\ndifferent and can return a negative response immediately. If you make it through\nboth strings without finding any bytes that differ, you know the strings are the\nsame and can return a positive result. This means that comparing two strings can\ntake a different amount of time depending on how much of the strings match.\n
\n\n\nFor example, a standard comparison of the strings "xyzabc" and\n"abcxyz" would immediately see that the first character is different\nand wouldn't bother to check the rest of the string. On the other hand, when the\nstrings "aaaaaaaaaaB" and "aaaaaaaaaaZ" are compared, the\ncomparison algorithm scans through the block of \"a\" before it determines the\nstrings are unequal.\n
\n\n\nSuppose an attacker wants to break into an on-line system that rate limits\nauthentication attempts to one attempt per second. Also suppose the attacker\nknows all of the parameters to the password hash (salt, hash type, etc), except\nfor the hash and (obviously) the password. If the attacker can get a precise\nmeasurement of how long it takes the on-line system to compare the hash of the\nreal password with the hash of a password the attacker provides, he can use the\ntiming attack to extract part of the hash and crack it using an offline attack,\nbypassing the system's rate limiting.\n
\n\n\nFirst, the attacker finds 256 strings whose hashes begin with every possible\nbyte. He sends each string to the on-line system, recording the amount of time\nit takes the system to respond. The string that takes the longest will be the\none whose hash's first byte matches the real hash's first byte. The attacker now\nknows the first byte, and can continue the attack in a similar manner on the\nsecond byte, then the third, and so on. Once the attacker knows enough of the\nhash, he can use his own hardware to crack it, without being rate limited by the\nsystem.\n
\n\n\nIt might seem like it would be impossible to run a timing attack over a network.\nHowever, it has been done, and has been\nshown to be practical.\nThat's why the code on this page compares strings in a way that takes the same\namount of time no matter how much of the strings match.\n
\n\n\nHow does the SlowEquals code work?
\n\n\nThe previous question explains why SlowEquals is necessary, this one explains\nhow the code actually works.\n
\n\n\n1. private static boolean slowEquals(byte[] a, byte[] b)\n\n
\n2. {
\n3. int diff = a.length ^ b.length;
\n4. for(int i = 0; i < a.length && i < b.length; i++)
\n5. diff |= a[i] ^ b[i];
\n6. return diff == 0;
\n7. }
\n\nThe code uses the XOR \"^\" operator to compare integers for equality, instead of\nthe \"==\" operator. The reason why is explained below. The result of XORing\ntwo integers will be zero if and only if they are exactly the same. This is\nbecause 0 XOR 0 = 0, 1 XOR 1 = 0, 0 XOR 1 = 1, 1 XOR 0 = 1. If we apply that to\nall the bits in both integers, the result will be zero only if all the bits\nmatched.\n
\n\n\nSo, in the first line, if
\n\na.lengthis equal to\nb.length, the diff variable will get a zero value, but if not, it\nwill get some non-zero value. Next, we compare the bytes using XOR, and OR the\nresult into diff. This will set diff to a non-zero value if the bytes differ.\nBecause ORing never un-sets bits, the only way diff will be zero at the end of\nthe loop is if it was zero before the loop began (a.length == b.length) and all\nof the bytes in the two arrays match (none of the XORs resulted in a non-zero\nvalue).\n\nThe reason we need to use XOR instead of the \"==\" operator to compare integers\nis that \"==\" is usually translated/compiled/interpreted as a branch. For example,\nthe C code \"
\n\ndiff &= a == b\" might compile to the following x86\nassembly:\n\nMOV EAX, [A]\n\n
\nCMP [B], EAX
\nJZ equal
\nJMP done
\nequal:
\nAND [VALID], 1
\ndone:
\nAND [VALID], 0
\n\nThe branching makes the code execute in a different amount of time depending on\nthe equality of the integers and the CPU's internal branch prediction state.\n
\n\n\nThe C code \"
\n\ndiff |= a ^ b\" should compile to something like\nthe following, whose execution time does not depend on the equality of the\nintegers:\n\nMOV EAX, [A]\n\n
\nXOR EAX, [B]
\nOR [DIFF], EAX
\nWhy bother hashing?
\n\n\nYour users are entering their password into your website. They are trusting you\nwith their security. If your database gets hacked, and your users' passwords are\nunprotected, then malicious hackers can use those passwords to compromise your\nusers' accounts on other websites and services (most people use the same\npassword everywhere). It's not just your security that's at risk, it's your\nusers'. You are responsible for your users' security.\n
\n\n\n\n" }, { "path": "src/pages/home.php", "content": ".\n */\n\nmb_language('uni');\nmb_internal_encoding('UTF-8');\n\nrequire_once('libs/recaptchalib.php');\nrequire_once('libs/CrackHashes.php');\nrequire_once('/storage/creds.php');\n\n// Copied from: https://stackoverflow.com/a/30749288\nfunction checkReCAPTCHA() \n{\n try {\n $url = 'https://www.google.com/recaptcha/api/siteverify';\n $creds = Creds::getCredentials(\"timecapsule_recaptcha\");\n $data = ['secret' => $creds[C_PASS],\n 'response' => $_POST['g-recaptcha-response'],\n 'remoteip' => $_SERVER['REMOTE_ADDR']];\n\n $options = [\n 'http' => [\n 'header' => \"Content-type: application/x-www-form-urlencoded\\r\\n\",\n 'method' => 'POST',\n 'content' => http_build_query($data) \n ]\n ];\n\n $context = stream_context_create($options);\n $result = file_get_contents($url, false, $context);\n return json_decode($result)->success;\n }\n catch (Exception $e) {\n return null;\n }\n}\n\nif(isset($_GET['p']))\n{\n\theader(\"HTTP/1.1 301 Moved Permanently\");\n\theader(\"Location: http://crackstation.net/\");\n}\n\nfunction trim_value(&$value)\n{\n $value = trim($value);\n $value = trim($value, \"*\"); // For MySQL 4.1+ hashes\n}\n\n?>\n\n\n\nArticle written by Defuse Security.
\nFree Password Hash Cracker
\n\n\n Enter up to 20 non-salted hashes, one per line:\n
\n\n\n\n\n\n\n\n\nSupports:\nLM, NTLM, md2, md4, md5, md5(md5_hex), md5-half, sha1, sha224, sha256, sha384,\nsha512, ripeMD160, whirlpool, MySQL 4.1+ (sha1(sha1_bin)), QubesV3.1BackupDefaults\n
\n\n\n
\n\n\n Please enter 20 or less hashes.\n \";\n }\n }\n else\n {\n echo \"\n\n\n\n\n\n Incorrect captcha. Please try again.\n
\";\n }\n}\n?>\nHow CrackStation Works
\n\n\nCrackStation uses massive pre-computed lookup tables to crack password hashes.\nThese tables store a mapping between the hash of a password, and the correct\npassword for that hash. The hash values are indexed so that it is possible to\nquickly search the database for a given hash. If the hash is present in the\ndatabase, the password can be recovered in a fraction of a second. This only\nworks for \"unsalted\" hashes. For information on password hashing systems that\nare not vulnerable to pre-computed lookup tables, see our
\n\n\nCrackstation's lookup tables were created by extracting every word from the\nWikipedia databases and adding with every password list we could find. We also\napplied intelligent word mangling (brute force hybrid) to our wordlists to make\nthem much more effective. For MD5 and SHA1 hashes, we have a 190GB,\n15-billion-entry lookup table, and for other hashes, we have a 19GB\n1.5-billion-entry lookup table.\n
\n\n\nYou can download CrackStation's dictionaries
\n" }, { "path": "src/pages/legal-privacy.php", "content": "CrackStation's Terms of Service and Privacy Policy
\r\n\r\nTerms of Service
\r\n\r\nCrackStation's main goal is to promote the use of properly implemented salted\r\nhashing in new and existing web applications. We provide this service to help\r\nsecurity researchers demonstrate the importance of hash salting. Any users that\r\nchoose to use CrackStation as a malicious tool are solely responsible for their\r\nown actions. We do not ask where our clients get their hashes, so we are unable\r\nto help any law enforcement agency.\r\n
\r\n\r\nPrivacy Policy
\r\n\r\nCrackStation respects the privacy of its users. Your IP address and web browser\r\ninformation may be logged as you request web pages from this site, but we do not\r\nsell that information or share that information with anyone. We DO NOT log the\r\nhashes that you crack. However, you should still not try to crack the hash of\r\nyour own password or other sensitive information, since your connection might be\r\nbeing intercepted by the NSA.\r\n
\r\n" }, { "path": "src/pages/thank-you.php", "content": "THANKS!
\n\n\nYou just bought the CrackStation wordlist. Thank you VERY much for your support!\n
\n\n\nIf you haven't downloaded the wordlist yet, see
\n\n\nIf you have any questions or concerns, please contact me.\n
\n" }, { "path": "src/robots.txt", "content": "User-agent: *\nDisallow: /tor-mirror/\n" } ] - \n