Forbidden
Either you're trying to access something you're not supposed to, or you've been banned.
If you think you've been banned, email havoc@defuse.ca to appeal.
================================================ FILE: src/css/main.css ================================================ /* * CrackStation, a web-based hash cracking website. * Copyright (C) 2013 Taylor Hornby * * This file is part of CrackStation. * * CrackStation is free software: you can redistribute it and/or modify * it under the terms of the GNU Affero General Public License as * published by the Free Software Foundation, either version 3 of the * License, or (at your option) any later version. * * CrackStation is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU Affero General Public License for more details. * * You should have received a copy of the GNU Affero General Public License * along with this program. If not, see
Twitter
| Hash | Type | Result |
|---|---|---|
| $html_escaped_hash | Unknown | Unrecognized hash format. |
| $html_escaped_hash | Unknown | Not found. |
| $html_escaped_hash | "; $html_escaped_alg = htmlentities($result->getAlgorithmName(), ENT_QUOTES); echo "$html_escaped_alg | "; $html_escaped_plaintext = htmlentities($result->getPlaintext(), ENT_QUOTES); echo "$html_escaped_plaintext | "; echo "
Color Codes: Green: Exact match, Yellow: Partial match, Red: Not found.
'; } ?> ================================================ FILE: src/libs/URLParse.php ================================================ . */ /* * Defuse Cyber-Security's Secure & Lightweight CMS in PHP for Linux. * Setup & Usage Instructions: https://defuse.ca/helloworld-cms.htm */ /* * The purpose of this class is to process the current request URL to * determine which page is to be displayed to the user, or to which URL * the user should be redirected. Once the user has been redirected to * the correct URL, and the desired page is determined, the page contents * can be loaded from a file into a dynamically generated web page. * * The URL parsing is split into four processes: * 1. First, the hostname (domain name) the request was made to is verified * against a list of "accepted hosts." If the hostname doesn't match any of * these accepted hosts, the user is redirected to the same URL on the * "master host." The accepted hosts and master host variables can be set * by modifying the $ACCEPTED_HOSTS and $MASTER_HOST variables respectively. * 2. Second, an HTTPS connection is enforced if $FORCE_HTTPS is set to true. * If $FORCE_HTTPS === true and the current connection is not secure, the * user is redirected to a secure (https) URL. * 3. The desired page is determined from the URL (see below). If this page * is really an alias for another page, the user is redirected to the proper * page. * 4. If the user did not request the page using the cannonical filename, * they are redirected to the cannonical URL for the page (see below). * * How the desired page is determined from the URL: * * Every page has a name, and there are two valid URLs for each page name. * For a page named "foobar", the following are valid URLs for the page: * 1. http://example.com/foobar * 2. http://example.com/foobar.htm * (2) is the cannonical URL for the page. So if the user were to type (1) into * their browser, they would be redirected to (2). The URL without the .htm * extension is recognized as a convienience so the URL can be spoken without * explicitly pronouncing the "dot h-t-m." * * Names can also contain forward slashes, allowing virtual directories to be * created. For example, the page name "foo/bar" is valid, with the following * URLs: * 1. http://example.com/foo/bar * 2. http://example.com/foo/bar.htm * With (2) being the cannonical form. * There is a special case of these names where no ".htm" extension is allowed. * For example, the name "" (meaning the homepage) is accessible though: * http://example.com/ * but NOT through: * http://example.com/.htm * The same applies to names ending in "/", e.g. "foo/" is accessible through: * http://example.com/foo/ * but NOT through: * http://example.com/foo/.htm * Note that a page named "foo/" and "foo" can exist simultaneously, but since * it is common to ommit the trailing "/" when typing the URL, this practice * is strongly discouraged. If the name "foo/" exists and the user omits the * trailing "/", they will be redirected to the "foo/" URL. But if "foo/" and * "foo" both exist, they will be redirected to "foo.htm". */ // Keys used for definining page data arrays define('P_FILE', 0); // File content (suffix to $ROOT_FOLDER) define('P_TITL', 1); //This page does not exist.
(ERROR 404)
About CrackStation
CrackStation is a security awareness project started by Defuse Security. Its purpose is to raise awareness about insecure password storage in web applications, and to provide guidance to implementors of user authentication systems. By making large hash lookup tables freely available to the public, we make it easier for security researchers to demonstrate why password storage solutions, like non-salted hashing, are insecure.
While CrackStation does provide paid services, its goal is not to make a profit. The money is used to pay for the hardware required to run CrackStation, and any left-overs go toward other security research projects (the results of which are released into the public domain). You may support CrackStation and other Defuse Security projects by donating using the PayPal donate button above.
If you have any questions, comments, or concerns about CrackStation, or would like help implementing secure password storage in an authentication system, please contact us. You can find our contact information on the Contact Information Page.
CrackStation's Password Cracking Dictionary
I am releasing CrackStation's main password cracking dictionary (1,493,677,782 words, 15GB) for download.
What's in the list?
The list contains every wordlist, dictionary, and password database leak that I could find on the internet (and I spent a LOT of time looking). It also contains every word in the Wikipedia databases (pages-articles, retrieved 2010, all languages) as well as lots of books from Project Gutenberg. It also includes the passwords from some low-profile database breaches that were being sold in the underground years ago.
The format of the list is a standard text file sorted in non-case-sensitive alphabetical order. Lines are separated with a newline "\n" character.
You can test the list without downloading it by giving SHA256 hashes to the free hash cracker. Here's a tool for computing hashes easily. Here are the results of cracking LinkedIn's and eHarmony's password hash leaks with the list.
The list is responsible for cracking about 30% of all hashes given to CrackStation's free hash cracker, but that figure should be taken with a grain of salt because some people try hashes of really weak passwords just to test the service, and others try to crack their hashes with other online hash crackers before finding CrackStation. Using the list, we were able to crack 49.98% of one customer's set of 373,000 human password hashes to motivate their move to a better salting scheme.
Download
Note: To download the torrents, you will need a torrent client like Transmission (for Linux and Mac), or uTorrent for Windows.
GZIP-compressed (level 9). 4.2 GiB compressed. 15 GiB uncompressed.
HTTP Mirror (Slow)
Checksums (crackstation.txt.gz)
MD5: 4748a72706ff934a17662446862ca4f8 SHA1: efa3f5ecbfba03df523418a70871ec59757b6d3f SHA256: a6dc17d27d0a34f57c989741acdd485b8aee45a6e9796daf8c9435370dc61612
Smaller Wordlist (Human Passwords Only)
I got some requests for a wordlist with just the "real human" passwords leaked from various website databases. This smaller list contains just those passwords. There are about 64 million passwords in this list!
Checksums (crackstation-human-only.txt.gz)
MD5: fbc3ca43230086857aac9b71b588a574 SHA1: 116c5f60b50e80681842b5716be23951925e5ad3 SHA256: 201f8815c71a47d39775304aa422a505fc4cca18493cfaf5a76e608a72920267
Sharing and Licensing
.
You are allowed to share these lists! They are both licensed under the Creative Commons Attribution-ShareAlike 3.0 license. If you do share them, I would appreciate it if you included a link to this page.
================================================ FILE: src/pages/contactus.php ================================================Contacting CrackStation
If you purchased the wordlist and it isn't working for you, or otherwise need support with the website, or just want to provide feedback, please email me. You can find my contact information here.
HashDB
PHP Cracking Script
Waterfall
Wordlists
================================================ FILE: src/pages/hashing-security-draft.php ================================================How to Store Passwords
This article will walk you through the design of a secure password storage system. Along the way, we'll encounter many common mistakes, and for each mistake, we'll understand why it's a mistake and how to fix it.
If for some reason you missed that big red warning note, please go read it now. Really, this guide is not meant to walk you through the process of writing your own storage system, it's to explain the reasons why passwords should be stored a certain way.
With that in mind, we can begin. To understand password storage, we will start with an insecure system and iteratively improve it until it is secure. At each iteration, we'll see how an attacker can take advantage of the vulnerability, and how we as defenders can make the attacker's job harder.
For concreteness, we'll use a standard web site login system as an example.
Weak System #1: Plain Text Storage
The most obvious way to store passwords is to just put them straight into the database without any kind of encryption or hashing. Obviously, this is a horrible idea, since if an attacker gains access to your database, they will have all of your users' passwords, and you'll be in PR hell trying to win back your users' trust.
Worse, if attackers know you're storing passwords in plain text, they will target you, because password databases are valuable and can be sold on the black market.
It's a huge risk, not just to you, but to your users too. It's very common for people to re-use the same password on multiple websites. If your website exposes a user's password to an attacker, that attacker might be able to use it to log in to the user's account on another website. You might be tempted to blame the user for re-using their password, but if you had protected the passwords, the user wouldn't be at risk, so it is partly your responsibility.
Another problem you'll have, if you store passwords in plain text, is that when you get hacked, it will be nearly impossible to give your users a secure way to reclaim their account, even after you've fixed the vulnerability. Once the attacker has all of the passwords, they can log in to any accounts they're interested in, set new passwords, and have permanent access to the accounts. Protecting the password database buys you a little bit of time to tell your users that they need to change their password.
Weak System #2: Encryption
The next obvious step is to encrypt passwords with symmetric encryption. As we'll see, this turns out to be a bad idea.
Symmetric encryption works by using a random key to encrypt some data. The encrypted data is called the ciphertext. To turn the ciphertext back into the original data, you need to know the key that it was encrypted with. Without the key, you can't decrypt the ciphertext.
You might think encrypting passwords would be a good idea. It's not, because where do you store the key? The server that creates user accounts and verifies usernames and passwords has to have access to it. So, chances are, if an attacker can get the encrypted password database, they'll be able to get the encryption key, and will be able to decrypt all of the passwords.
Weak System #3: Hashing Without Salt
To move on to a more secure design, we need to realize that to verify a password, you don't actually need to know the correct password. It is possible to compute the "fingerprint" of a password, with the following properties:
- It's very unlikely for two different passwords to have the same fingerprint.
- It's hard to "reverse" the fingerprint back into the password.
This can be done with a cryptographic hash function like SHA256. These functions compute a fixed-length fingerprint from a variable-length input. They have the properties we want: It's hard to find two inputs that hash to the same value, and given an output, it's very difficult to find the input.
Here are some example SHA256 hashes. You can see that even if the input only changes by one letter, the output looks completely different.
hash("hbllo") = 58756879c05c68dfac9866712fad6a93f8146f337a69afe7dd238f3364946366
hash("waltz") = c0e81794384491161f1777c232bc6bd9ec38f616560b120fda8e90f383853542
We can use a function like this to protect passwords. Instead of storing the password in plain text, or encrypting the password, we can store the hash of the password. Then, when a user logs in, we hash the password they've given us and compare it to the hash that's saved in the database. Because the chance of two passwords producing the same hash is extremely low (one of the properties of a hash function), the chance of someone getting in with the wrong password is also extremely low.
You might think we can stop here. In fact, we can't, because storing passwords this way is insecure.
To see why, consider what happens when two users have the same password: the hashes are the same! An attacker can tell, just by comparing the hashes, which users are using the same password. Clearly this is a vulnerability, since if the attacker wants to get in to Alice's account, and sees that Bob has the same password, the attacker can bribe (or torture) Bob for his password to get into Alice's account.
That's not the only reason. Another reason is that the same password always hashes to the same value. There's a one-to-one correspondence between hashes and passwords. This means that an attacker can pre-compute huge tables of hashes, then search for the hash they want to crack in that table. Because the search can be done very quickly, cracking hashes this way is a lot faster than trying to guess the password for each hash.
To see how fast it can be, copy and paste these SHA256 hashes into CrackStation's Hash Cracker:
08eac03b80adc33dc7d8fbe44b7c7b05d3a2c511166bdb43fcb710b03ba919e7
e4ba5cbd251c98e6cd1c23f126a3b81d8d8328abc95387229850952b3ef9f904
5206b8b8a996cf5320cb12ca91c7b790fba9f030408efe83ebb83548dc3007bd
The result is that all four hashes can be cracked in under a second. This is obviously much faster than trying to guess each hash's password one by one. Using this technique, an attacker can crack most of the hashes in your user account database in a matter of minutes.
These password cracking databases are very real, and are used by attackers all the time. One special type, called a "Rainbow Table", can fit the MD5 hashes of all possible 8 character passwords into a 1049 GB file that can be downloaded from the Internet.
Weak System #4: Hashing With Salt
The attacks we saw in the previous section were possible because every time the same password was hashed, the result was the same. This let attackers see who was using the same password, and let them build a huge database of hashes that could be quickly searched to find the password for a given hash.
To prevent these attacks, we need to make sure that even if two users use the same password, or if one user uses the same password twice, the hash values are always different. This is done by adding some randomness to the hashing process.
To hash a password, we use a cryptographically secure pseudo-random number generator (CSPRNG) to generate a random string, called a salt, which we prepend to the password before hashing it. We then save that random number with the hash, since we'll need to verify passwords against the hash.
Here's what it looks like in pseudocode. The double bar symbol "A || B" means concatenate the string A with the string B.
# When a new account is created, or a user changes their password.
create_hash(PASSWORD):
Generate a random string SALT with a CSPRNG.
HASH = sha256(SALT || PASSWORD).
return (SALT, HASH).
# When a user tries to log in.
check_password((SALT, HASH), PASSWORD_GUESS):
GUESS_HASH = sha256(SALT || PASSWORD_GUESS).
if GUESS_HASH equals HASH:
return TRUE.
else:
return FALSE.
Assuming the salt is long enough, always generated with a CSPRNG, and no salt is ever used to hash more than one password, the attacks of the previous section are no longer possible. The only way to crack these hashes is to test password guesses for each hash individually. However, this is still not good enough!
Hash functions like SHA256 were designed to be fast. Good CPUs can compute millions of SHA256 hashes per second, and good GPUs (graphics processors) can compute billions of hashes per second. Customized hardware (FPGAs and ASICs) can reach even higher speeds. This is exactly the opposite of what we want, since it means an attacker who stole the user account database can crack the hashes a rate of billions of password guesses per second. Not good.
This is the last hurdle in the race. Once we pass it, we'll finally arrive at a secure password storage system.
Secure System #1: Slow Hashing
In the previous section, we added salt to our passwords to prevent pre-computation attacks. We then saw that hash functions like SHA256 can be computed extremely quickly by GPUs and custom hardware, letting attackers test billions of passwords per second.
Password hashing functions don't need to be that fast. You probably won't be handling millions of authentication requests per second from one server, so there's no reason an authentication server will ever need to compute millions of hashes per second. It's alright if the password hashing process is 1,000 times or even 1,000,000 times slower than a regular hash function. To make things harder for GPUs and custom hardware, we also want the hashing process to need lots of memory.
It's not enough to add a call to sleep() or a time-consuming "no op" loop into the password hashing code. An attacker can remove it and compute hashes as fast as they want. Instead, the hashing function has to be truly hard to compute. There should be no way to compute it any faster or with less memory. More correctly stated, there should be no way to reduce the overall time * area needed to compute the function, where "area" means the size of the circuit you need to compute the hash in a given amount of time.
We want the defender's (password authenticator's) implementation of the function to be as optimal as possible. This is important, since if the defender is taking 10x longer to compute the function, the attacker, using a 10x more efficient implementation, has an advantage over the defender. That means these functions should be implemented in native code (assembly language or C/C++), and not in a scripting language.
Researchers are still figuring out how to best design these slow hashes. There's a competition going on right now, called the Password Hashing Competition (PHC), to find the best one. It's similar in nature to the competition that selected the AES cipher. Even though the competition hasn't finished yet, we already have some slow hash functions that we think are good, and are in common use. These are: scrypt, bcrypt, and PBKDF2.
If you want to know more about how slow hashes are designed, read the Scrypt paper and the Catena paper. You should also join and read the PHC mailing list, since research in this area is evolving quickly! Whatever you do, do not try to design and use your own slow hash function. Stick to the ones that already exist and have been used for a while. Feel free to design (and break) your own as a learning exercise, but for crying out loud, don't use it.
So, if we choose scrypt as our slow hash, we can store passwords securely like this. It's the same as before, except we're using scrypt instead of SHA256.
# When a new account is created, or a user changes their password.
create_hash(PASSWORD):
Generate a random string SALT with a CSPRNG.
HASH = scrypt(SALT, PASSWORD).
return (SALT, HASH).
# When a user tries to log in.
check_password((SALT, HASH), PASSWORD_GUESS):
GUESS_HASH = scrypt(SALT, PASSWORD_GUESS).
if GUESS_HASH equals HASH:
return TRUE.
else:
return FALSE.
- want defender to be optimized - the functions are parameterized (take time and memory parameters) - summarry like "we've mitigated pre-computation attacks as well as made it extremely difficult for GPUs or whatever"
- Weak passwords can still be found .. intro next section with
security-by-obscurity key.
- AKA key stretching,
- Offloading to the client (sjcl) -- does not remove need for server hashing
- Re-read old post since this is missing some stuff that was covered in it
Even with the salt and slow hashing, weak passwords can still be cracked. In the next section, we'll see how, with the help of some special hardware, we can protect our hashes so that even the weak ones can't be cracked.
Increasing Security: Hardware Security Modules
- Use hardware device with embedded key to do the hashing, so that unless
it's physically stolen and tampered with, the passwords are really safe.
- Also possible to do w/o custom hardware... just set up dedicated password
authentication box that does nothing but hash passwords; no services, etc.
- Mandatory for websites with more than 100k users.
- Cloud options? (amazon thing)?
- Physical options? (yubihsm?)
Common Mistakes
Be on the lookout for these common password hashing mistakes.
Salt Reuse
Short Salts
Generating Salts with a Weak Random Number Generator
Frequently Asked Questions
- Basically the same list of FAQ from the original article except emphasize
slow hashing.
- In "what to do when" section... "don't clutter up the notice message with
all the crap about salt and hashing and scrypt, they won't understand. Just tell
them to change their password if they used it anywhere else etc. But do publish
the information about hashing, just don't make it distracting or give a false
sense of security."
Source Code
- Embed the source code here.
- Putting the source code way down here might make people miss it, so add
prominent links up at the top (not just in the red warning box).
================================================
FILE: src/pages/hashing-security.php
================================================
Salted Password Hashing - Doing it Right
If you're a web developer, you've probably had to make a user account system. The most important aspect of a user account system is how user passwords are protected. User account databases are hacked frequently, so you absolutely must do something to protect your users' passwords if your website is ever breached. The best way to protect passwords is to employ salted password hashing. This page will explain why it's done the way it is.
There are a lot of conflicting ideas and misconceptions on how to do password hashing properly, probably due to the abundance of misinformation on the web. Password hashing is one of those things that's so simple, but yet so many people get wrong. With this page, I hope to explain not only the correct way to do it, but why it should be done that way.
If for some reason you missed that big red warning note, please go read it now. Really, this guide is not meant to walk you through the process of writing your own storage system, it's to explain the reasons why passwords should be stored a certain way.
You may use the following links to jump to the different sections of this page.
| 1. What is password hashing? | 2. How Hashes are Cracked | 3. Adding Salt |
| 4. Ineffective Hashing Methods | 5. How to hash properly | 6. Frequently Asked Questions |
What is password hashing?
hash("hbllo") = 58756879c05c68dfac9866712fad6a93f8146f337a69afe7dd238f3364946366
hash("waltz") = c0e81794384491161f1777c232bc6bd9ec38f616560b120fda8e90f383853542
Hash algorithms are one way functions. They turn any amount of data into a fixed-length "fingerprint" that cannot be reversed. They also have the property that if the input changes by even a tiny bit, the resulting hash is completely different (see the example above). This is great for protecting passwords, because we want to store passwords in a form that protects them even if the password file itself is compromised, but at the same time, we need to be able to verify that a user's password is correct.
The general workflow for account registration and authentication in a hash-based account system is as follows:
- The user creates an account.
- Their password is hashed and stored in the database. At no point is the plain-text (unencrypted) password ever written to the hard drive.
- 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).
- If the hashes match, the user is granted access. If not, the user is told they entered invalid login credentials.
- Steps 3 and 4 repeat every time someone tries to login to their account.
In step 4, never tell the user if it was the username or password they got wrong. Always display a generic message like "Invalid username or password." This prevents attackers from enumerating valid usernames without knowing their passwords.
It should be noted that the hash functions used to protect passwords are not the same as the hash functions you may have seen in a data structures course. The hash functions used to implement data structures such as hash tables are designed to be fast, not secure. Only cryptographic hash functions may be used to implement password hashing. Hash functions like SHA256, SHA512, RipeMD, and WHIRLPOOL are cryptographic hash functions.
It is easy to think that all you have to do is run the password through a cryptographic hash function and your users' passwords will be secure. This is far from the truth. There are many ways to recover passwords from plain hashes very quickly. There are several easy-to-implement techniques that make these "attacks" much less effective. To motivate the need for these techniques, consider this very website. On the front page, you can submit a list of hashes to be cracked, and receive results in less than a second. Clearly, simply hashing the password does not meet our needs for security.
The next section will discuss some of the common attacks used to crack plain password hashes.
How Hashes are Cracked
-
Dictionary and Brute Force Attacks
Dictionary Attack
Trying apple : failed
Trying blueberry : failed
Trying justinbeiber : failed
... Trying letmein : failed
Trying s3cr3t : success!
Brute Force Attack
Trying aaaa : failed
Trying aaab : failed
Trying aaac : failed
... Trying acdb : failed
Trying acdc : success!
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. The two most common ways of guessing passwords are dictionary attacks and brute-force attacks.
A dictionary attack uses a file containing words, phrases, common passwords, and other strings that are likely to be used as a password. Each word in the file is hashed, and its hash is compared to the password hash. If they match, that word is the password. These dictionary files are constructed by extracting words from large bodies of text, and even from real databases of passwords. Further processing is often applied to dictionary files, such as replacing words with their "leet speak" equivalents ("hello" becomes "h3110"), to make them more effective.
A brute-force attack tries every possible combination of characters up to a given length. These attacks are very computationally expensive, and are usually the least efficient in terms of hashes cracked per processor time, but they will always eventually find the password. Passwords should be long enough that searching through all possible character strings to find it will take too long to be worthwhile.
There is no way to prevent dictionary attacks or brute force attacks. They can be made less effective, but there isn't a way to prevent them altogether. If your password hashing system is secure, the only way to crack the hashes will be to run a dictionary or brute-force attack on each hash.
-
Lookup Tables
Searching: 5f4dcc3b5aa765d61d8327deb882cf99: FOUND: password5
Searching: 6cbe615c106f422d23669b610b564800: not in database
Searching: 630bf032efe4507f2c57b280995925a9: FOUND: letMEin12
Searching: 386f43fab5d096a7a66d67c8f213e5ec: FOUND: mcd0nalds
Searching: d5ec75d5fe70d428685510fae36492d9: FOUND: p@ssw0rd!
Lookup tables are an extremely effective method for cracking many hashes of the same type very quickly. The general idea is to pre-compute the hashes of the passwords in a password dictionary and store them, and their corresponding password, in a lookup table data structure. A good implementation of a lookup table can process hundreds of hash lookups per second, even when they contain many billions of hashes.
If you want a better idea of how fast lookup tables can be, try cracking the following sha256 hashes with CrackStation's free hash cracker.
c11083b4b0a7743af748c85d343dfee9fbb8b2576c05f3a7f0d632b0926aadfc
08eac03b80adc33dc7d8fbe44b7c7b05d3a2c511166bdb43fcb710b03ba919e7
e4ba5cbd251c98e6cd1c23f126a3b81d8d8328abc95387229850952b3ef9f904
5206b8b8a996cf5320cb12ca91c7b790fba9f030408efe83ebb83548dc3007bd
Reverse Lookup Tables
Searching for hash(apple) in users' hash list... : Matches [alice3, 0bob0, charles8]
Searching for hash(blueberry) in users' hash list... : Matches [usr10101, timmy, john91]
Searching for hash(letmein) in users' hash list... : Matches [wilson10, dragonslayerX, joe1984]
Searching for hash(s3cr3t) in users' hash list... : Matches [bruce19, knuth1337, john87]
Searching for hash(z@29hjja) in users' hash list... : No users used this password
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.
First, the attacker creates a lookup table that maps each password hash from the compromised user account database to a list of users who had that hash. The attacker then hashes each password guess and uses the lookup table to get a list of users whose password was the attacker's guess. This attack is especially effective because it is common for many users to have the same password.
Rainbow Tables
Rainbow tables are a time-memory trade-off technique. They are like lookup tables, except that they sacrifice hash cracking speed to make the lookup tables smaller. Because they are smaller, the solutions to more hashes can be stored in the same amount of space, making them more effective. Rainbow tables that can crack any md5 hash of a password up to 8 characters long exist.
Next, we'll look at a technique called salting, which makes it impossible to use lookup tables and rainbow tables to crack a hash.
Adding Salt
hash("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
hash("hello" + "QxLUF1bgIAdeQX") = 9e209040c863f84a31e719795b2577523954739fe5ed3b58a75cff2127075ed1
hash("hello" + "bv5PehSMfV11Cd") = d1d3ec2e6f20fd420d50e2642992841d8338a314b8ea157c9e18477aaef226ab
hash("hello" + "YYLmfY6IehjZMQ") = a49670c3c18b9e079b9cfaf51634f563dc8ae3070db2c4a8544305df1b60f007Lookup tables and rainbow tables only work because each password is hashed the exact same way. If two users have the same password, they'll have the same password hashes. We can prevent these attacks by randomizing each hash, so that when the same password is hashed twice, the hashes are not the same.
We can randomize the hashes by appending or prepending a random string, called a salt, to the password before hashing. As shown in the example above, this makes the same password hash into a completely different string every time. To check if a password is correct, we need the salt, so it is usually stored in the user account database along with the hash, or as part of the hash string itself.
The salt does not need to be secret. Just by randomizing the hashes, lookup tables, reverse lookup tables, and rainbow tables become ineffective. An attacker won't know in advance what the salt will be, so they can't pre-compute a lookup table or rainbow table. If each user's password is hashed with a different salt, the reverse lookup table attack won't work either.
In the next section, we'll look at how salt is commonly implemented incorrectly.
The WRONG Way: Short Salt & Salt Reuse
The most common salt implementation errors are reusing the same salt in multiple hashes, or using a salt that is too short.
Salt Reuse
A common mistake is to use the same salt in each hash. Either the salt is hard-coded into the program, or is generated randomly once. This is ineffective because if two users have the same password, they'll still have the same hash. An attacker can still use a reverse lookup table attack to run a dictionary attack on every hash at the same time. They just have to apply the salt to each password guess before they hash it. If the salt is hard-coded into a popular product, lookup tables and rainbow tables can be built for that salt, to make it easier to crack hashes generated by the product.
A new random salt must be generated each time a user creates an account or changes their password.
Short Salt
If the salt is too short, an attacker can build a lookup table for every possible salt. For example, if the salt is only three ASCII characters, there are only 95x95x95 = 857,375 possible salts. That may seem like a lot, but if each lookup table contains only 1MB of the most common passwords, collectively they will be only 837GB, which is not a lot considering 1000GB hard drives can be bought for under $100 today.
For the same reason, the username shouldn't be used as a salt. Usernames may be unique to a single service, but they are predictable and often reused for accounts on other services. An attacker can build lookup tables for common usernames and use them to crack username-salted hashes.
To make it impossible for an attacker to create a lookup table for every possible salt, the salt must be long. A good rule of thumb is to use a salt that is the same size as the output of the hash function. For example, the output of SHA256 is 256 bits (32 bytes), so the salt should be at least 32 random bytes.
The WRONG Way: Double Hashing & Wacky Hash Functions
This section covers another common password hashing misconception: wacky combinations of hash algorithms. It's easy to get carried away and try to combine different hash functions, hoping that the result will be more secure. In practice, though, there is very little benefit to doing it. All it does is create interoperability problems, and can sometimes even make the hashes less secure. Never try to invent your own crypto, always use a standard that has been designed by experts. Some will argue that using multiple hash functions makes the process of computing the hash slower, so cracking is slower, but there's a better way to make the cracking process slower as we'll see later.
Here are some examples of poor wacky hash functions I've seen suggested in forums on the internet.
- md5(sha1(password))
- md5(md5(salt) + md5(password))
- sha1(sha1(password))
- sha1(str_rot13(password + salt))
- md5(sha1(md5(md5(password) + sha1(password)) + md5(password)))
Do not use any of these.
Note: This section has proven to be controversial. I've received a number of emails arguing that wacky hash functions are a good thing, because it's better if the attacker doesn't know which hash function is in use, it's less likely for an attacker to have pre-computed a rainbow table for the wacky hash function, and it takes longer to compute the hash function.
An attacker cannot attack a hash when he doesn't know the algorithm, but note Kerckhoffs's principle, that the attacker will usually have access to the source code (especially if it's free or open source software), and that given a few password-hash pairs from the target system, it is not difficult to reverse engineer the algorithm. It does take longer to compute wacky hash functions, but only by a small constant factor. It's better to use an iterated algorithm that's designed to be extremely hard to parallelize (these are discussed below). And, properly salting the hash solves the rainbow table problem.
If you really want to use a standardized "wacky" hash function like HMAC, then it's OK. But if your reason for doing so is to make the hash computation slower, read the section below about key stretching first.
Compare these minor benefits to the risks of accidentally implementing a completely insecure hash function and the interoperability problems wacky hashes create. It's clearly best to use a standard and well-tested algorithm.
Hash Collisions
Because hash functions map arbitrary amounts of data to fixed-length strings, there must be some inputs that hash into the same string. Cryptographic hash functions are designed to make these collisions incredibly difficult to find. From time to time, cryptographers find "attacks" on hash functions that make finding collisions easier. A recent example is the MD5 hash function, for which collisions have actually been found.
Collision attacks are a sign that it may be more likely for a string other than the user's password to have the same hash. However, finding collisions in even a weak hash function like MD5 requires a lot of dedicated computing power, so it is very unlikely that these collisions will happen "by accident" in practice. A password hashed using MD5 and salt is, for all practical purposes, just as secure as if it were hashed with SHA256 and salt. Nevertheless, it is a good idea to use a more secure hash function like SHA256, SHA512, RipeMD, or WHIRLPOOL if possible.
The RIGHT Way: How to Hash Properly
This section describes exactly how passwords should be hashed. The first subsection covers the basics—everything that is absolutely necessary. The following subsections explain how the basics can be augmented to make the hashes even harder to crack.
The Basics: Hashing with Salt
Warning: Do not just read this section. You absolutely must implement the stuff in the next section: "Making Password Cracking Harder: Slow Hash Functions".
We've seen how malicious hackers can crack plain hashes very quickly using lookup tables and rainbow tables. We've learned that randomizing the hashing using salt is the solution to the problem. But how do we generate the salt, and how do we apply it to the password?
Salt should be generated using a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG). CSPRNGs are very different than ordinary pseudo-random number generators, like the "C" language's rand() function. As the name suggests, CSPRNGs are designed to be cryptographically secure, meaning they provide a high level of randomness and are completely unpredictable. We don't want our salts to be predictable, so we must use a CSPRNG. The following table lists some CSPRNGs that exist for some popular programming platforms.
Platform 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 changes their password, the password should be hashed using a new random salt. Never reuse a salt. The salt also needs to be long, so that there are many possible salts. As a rule of thumb, make your salt is at least as long as the hash function's output. The salt should be stored in the user account table alongside the hash.
To Store a Password
- Generate a long random salt using a CSPRNG.
- Prepend the salt to the password and hash it with a standard password hashing function like Argon2, bcrypt, scrypt, or PBKDF2.
- Save both the salt and the hash in the user's database record.
To Validate a Password
- Retrieve the user's salt and hash from the database.
- Prepend the salt to the given password and hash it using the same hash function.
- 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.
In a Web Application, always hash on the server
If you are writing a web application, you might wonder where to hash. Should the password be hashed in the user's browser with JavaScript, or should it be sent to the server "in the clear" and hashed there?
Even if you are hashing the user's passwords in JavaScript, you still have to hash the hashes on the server. Consider a website that hashes users' passwords in the user's browser without hashing the hashes on the server. To authenticate a user, this website will accept a hash from the browser and check if that hash exactly matches the one in the database. This seems more secure than just hashing on the server, since the users' passwords are never sent to the server, but it's not.
The problem is that the client-side hash logically becomes the user's password. All the user needs to do to authenticate is tell the server the hash of their password. If a bad guy got a user's hash they could use it to authenticate to the server, without knowing the user's password! So, if the bad guy somehow steals the database of hashes from this hypothetical website, they'll have immediate access to everyone's accounts without having to guess any passwords.
This isn't to say that you shouldn't hash in the browser, but if you do, you absolutely have to hash on the server too. Hashing in the browser is certainly a good idea, but consider the following points for your implementation:
-
Client-side password hashing is not a substitute for HTTPS (SSL/TLS). If the connection between the browser and the server is insecure, a man-in-the-middle can modify the JavaScript code as it is downloaded to remove the hashing functionality and get the user's password.
-
Some web browsers don't support JavaScript, and some users disable JavaScript in their browser. So for maximum compatibility, your app should detect whether or not the browser supports JavaScript and emulate the client-side hash on the server if it doesn't.
-
You need to salt the client-side hashes too. The obvious solution is to make the client-side script ask the server for the user's salt. Don't do that, because it lets the bad guys check if a username is valid without knowing the password. Since you're hashing and salting (with a good salt) on the server too, it's OK to use the username (or email) concatenated with a site-specific string (e.g. domain name) as the client-side salt.
Making Password Cracking Harder: Slow Hash Functions
Salt ensures that attackers can't use specialized attacks like lookup tables and rainbow tables to crack large collections of hashes quickly, but it doesn't prevent them from running dictionary or brute-force attacks on each hash individually. High-end graphics cards (GPUs) and custom hardware can compute billions of hashes per second, so these attacks are still very effective. To make these attacks less effective, we can use a technique known as key stretching.
The idea is to make the hash function very slow, so that even with a fast GPU or custom hardware, dictionary and brute-force attacks are too slow to be worthwhile. The goal is to make the hash function slow enough to impede attacks, but still fast enough to not cause a noticeable delay for the user.
Key stretching is implemented using a special type of CPU-intensive hash function. Don't try to invent your own–simply iteratively hashing the hash of the password isn't enough as it can be parallelized in hardware and executed as fast as a normal hash. Use a standard algorithm like PBKDF2 or bcrypt. You can find a PHP implementation of PBKDF2 here.
These algorithms take a security factor or iteration count as an argument. This value determines how slow the hash function will be. For desktop software or smartphone apps, the best way to choose this parameter is to run a short benchmark on the device to find the value that makes the hash take about half a second. This way, your program can be as secure as possible without affecting the user experience.
If you use a key stretching hash in a web application, be aware that you will need extra computational resources to process large volumes of authentication requests, and that key stretching may make it easier to run a Denial of Service (DoS) attack on your website. I still recommend using key stretching, but with a lower iteration count. You should calculate the iteration count based on your computational resources and the expected maximum authentication request rate. The denial of service threat can be eliminated by making the user solve a CAPTCHA every time they log in. Always design your system so that the iteration count can be increased or decreased in the future.
If you are worried about the computational burden, but still want to use key stretching in a web application, consider running the key stretching algorithm in the user's browser with JavaScript. The Stanford JavaScript Crypto Library includes PBKDF2. The iteration count should be set low enough that the system is usable with slower clients like mobile devices, and the system should fall back to server-side computation if the user's browser doesn't support JavaScript. Client-side key stretching does not remove the need for server-side hashing. You must hash the hash generated by the client the same way you would hash a normal password.
Impossible-to-crack Hashes: Keyed Hashes and Password Hashing Hardware
As long as an attacker can use a hash to check whether a password guess is right or wrong, they can run a dictionary or brute-force attack on the hash. The next step is to add a secret key to the hash so that only someone who knows the key can use the hash to validate a password. This can be accomplished two ways. Either the hash can be encrypted using a cipher like AES, or the secret key can be included in the hash using a keyed hash algorithm like HMAC.
This is not as easy as it sounds. The key has to be kept secret from an attacker even in the event of a breach. If an attacker gains full access to the system, they'll be able to steal the key no matter where it is stored. The key must be stored in an external system, such as a physically separate server dedicated to password validation, or a special hardware device attached to the server such as the YubiHSM.
I highly recommend this approach for any large scale (more than 100,000 users) service. I consider it necessary for any service hosting more than 1,000,000 user accounts.
If you can't afford multiple dedicated servers or special hardware devices, you can still get some of the benefits of keyed hashes on a standard web server. Most databases are breached using SQL Injection Attacks, which, in most cases, don't give attackers access to the local filesystem (disable local filesystem access in your SQL server if it has this feature). If you generate a random key and store it in a file that isn't accessible from the web, and include it into the salted hashes, then the hashes won't be vulnerable if your database is breached using a simple SQL injection attack. Don't hard-code a key into the source code, generate it randomly when the application is installed. This isn't as secure as using a separate system to do the password hashing, because if there are SQL injection vulnerabilities in a web application, there are probably other types, such as Local File Inclusion, that an attacker could use to read the secret key file. But, it's better than nothing.
Please note that keyed hashes do not remove the need for salt. Clever attackers will eventually find ways to compromise the keys, so it is important that hashes are still protected by salt and key stretching.
Other Security Measures
Password hashing protects passwords in the event of a security breach. It does not make the application as a whole more secure. Much more must be done to prevent the password hashes (and other user data) from being stolen in the first place.
Even experienced developers must be educated in security in order to write secure applications. A great resource for learning about web application vulnerabilities is The Open Web Application Security Project (OWASP). A good introduction is the OWASP Top Ten Vulnerability List. Unless you understand all the vulnerabilities on the list, do not attempt to write a web application that deals with sensitive data. It is the employer's responsibility to ensure all developers are adequately trained in secure application development.
Having a third party "penetration test" your application is a good idea. Even the best programmers make mistakes, so it always makes sense to have a security expert review the code for potential vulnerabilities. Find a trustworthy organization (or hire staff) to review your code on a regular basis. The security review process should begin early in an application's life and continue throughout its development.
It is also important to monitor your website to detect a breach if one does occur. I recommend hiring at least one person whose full time job is detecting and responding to security breaches. If a breach goes undetected, the attacker can make your website infect visitors with malware, so it is extremely important that breaches are detected and responded to promptly.
Frequently Asked Questions
What hash algorithm should I use?
DO use:- Well-designed key stretching algorithms such as PBKDF2, bcrypt, and scrypt.
- OpenWall's Portable PHP password hashing framework
- My implementations of PBKDF2 in PHP, C#, Java, and Ruby.
- Secure versions of crypt ($2y$, $5$, $6$)
DO NOT use:- Fast cryptographic hash functions such as MD5, SHA1, SHA256, SHA512, RipeMD, WHIRLPOOL, SHA3, etc.
- Insecure versions of crypt ($1$, $2$, $2x$, $3$).
- Any algorithm that you designed yourself. Only use technology that is in the public domain and has been well-tested by experienced cryptographers.
Even though there are no cryptographic attacks on MD5 or SHA1 that make their hashes easier to crack, they are old and are widely considered (somewhat incorrectly) to be inadequate for password storage. So I don't recommend using them. An exception to this rule is PBKDF2, which is frequently implemented using SHA1 as the underlying hash function.
How should I allow users to reset their password when they forget it?
It is my personal opinion that all password reset mechanisms in widespread use today are insecure. If you have high security requirements, such as an encryption service would, do not let the user reset their password.
Most websites use an email loop to authenticate users who have forgotten their password. To do this, generate a random single-use token that is strongly tied to the account. Include it in a password reset link sent to the user's email address. When the user clicks a password reset link containing a valid token, prompt them for a new password. Be sure that the token is strongly tied to the user account so that an attacker can't use a token sent to his own email address to reset a different user's password.
The token must be set to expire in 15 minutes or after it is used, whichever comes first. It is also a good idea to expire any existing password tokens when the user logs in (they remembered their password) or requests another reset token. If a token doesn't expire, it can be forever used to break into the user's account. Email (SMTP) is a plain-text protocol, and there may be malicious routers on the internet recording email traffic. And, a user's email account (including the reset link) may be compromised long after their password has been changed. Making the token expire as soon as possible reduces the user's exposure to these attacks.
Attackers will be able to modify the tokens, so don't store the user account information or timeout information in them. They should be an unpredictable random binary blob used only to identify a record in a database table.
Never send the user a new password over email. Remember to pick a new random salt when the user resets their password. Don't re-use the one that was used to hash their old password.
What should I do if my user account database gets leaked/hacked?
Your first priority is to determine how the system was compromised and patch the vulnerability the attacker used to get in. If you do not have experience responding to breaches, I highly recommend hiring a third-party security firm.
It 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 your users at further risk by not informing them that their passwords and other personal information may be compromised. You must inform your users as soon as possible—even if you don't yet fully understand what happened. Put a notice on the front page of your website that links to a page with more detailed information, and send a notice to each user by email if possible.
Explain to your users exactly how their passwords were protected—hopefully hashed with salt—and that even though they were protected with a salted hash, a malicious hacker can still run dictionary and brute force attacks on the hashes. Malicious hackers will use any passwords they find to try to login to a user's account on a different website, hoping they used the same password on both websites. Inform your users of this risk and recommend that they change their password on any website or service where they used a similar password. Force them to change their password for your service the next time they log in. Most users will try to "change" their password to the original password to get around the forced change quickly. Use the current password hash to ensure that they cannot do this.
It is likely, even with salted slow hashes, that an attacker will be able to crack some of the weak passwords very quickly. To reduce the attacker's window of opportunity to use these passwords, you should require, in addition to the current password, an email loop for authentication until the user has changed their password. See the previous question, "How should I allow users to reset their password when they forget it?" for tips on implementing email loop authentication.
Also tell your users what kind of personal information was stored on the website. If your database includes credit card numbers, you should instruct your users to look over their recent and future bills closely and cancel their credit card.
What should my password policy be? Should I enforce strong passwords?
If your service doesn't have strict security requirements, then don't limit your users. I recommend showing users information about the strength of their password as they type it, letting them decide how secure they want their password to be. If you have special security needs, enforce a minimum length of 12 characters and require at least two letters, two digits, and two symbols.
Do not force your users to change their password more often than once every six months, as doing so creates "user fatigue" and makes users less likely to choose good passwords. Instead, train users to change their password whenever they feel it has been compromised, and to never tell their password to anyone. If it is a business setting, encourage employees to use paid time to memorize and practice their password.
If an attacker has access to my database, can't they just replace the hash of my password with their own hash and login?
Yes, but if someone has access to your database, they probably already have access to everything on your server, so they wouldn't need to login to your account to get what they want. The purpose of password hashing (in the context of a website) is not to protect the website from being breached, but to protect the passwords if a breach does occur.
You can prevent hashes from being replaced during a SQL injection attack by connecting to the database with two users with different permissions. One for the 'create account' code and one for the 'login' code. The 'create account' code should be able to read and write to the user table, but the 'login' code should only be able to read.
Why do I have to use a special algorithm like HMAC? Why can't I just append the password to the secret key?
Hash functions like MD5, SHA1, and SHA2 use the Merkle–Damgård construction, which makes them vulnerable to what are known as length extension attacks. This means that given a hash H(X), an attacker can find the value of H(pad(X) + Y), for any other string Y, without knowing X. pad(X) is the padding function used by the hash.
This means that given a hash H(key + message), an attacker can compute H(pad(key + message) + extension), without knowing the key. If the hash was being used as a message authentication code, using the key to prevent an attacker from being able to modify the message and replace it with a different valid hash, the system has failed, since the attacker now has a valid hash of message + extension.
It is not clear how an attacker could use this attack to crack a password hash quicker. However, because of the attack, it is considered bad practice to use a plain hash function for keyed hashing. A clever cryptographer may one day come up with a clever way to use these attacks to make cracking faster, so use HMAC.
Should the salt come before or after the password?
It doesn't matter, but pick one and stick with it for interoperability's sake. Having the salt come before the password seems to be more common.
Why does the hashing code on this page compare the hashes in "length-constant" time?
Comparing the hashes in "length-constant" time ensures that an attacker cannot extract the hash of a password in an on-line system using a timing attack, then crack it off-line.
The standard way to check if two sequences of bytes (strings) are the same is to compare the first byte, then the second, then the third, and so on. As soon as you find a byte that isn't the same for both strings, you know they are different and can return a negative response immediately. If you make it through both strings without finding any bytes that differ, you know the strings are the same and can return a positive result. This means that comparing two strings can take a different amount of time depending on how much of the strings match.
For example, a standard comparison of the strings "xyzabc" and "abcxyz" would immediately see that the first character is different and wouldn't bother to check the rest of the string. On the other hand, when the strings "aaaaaaaaaaB" and "aaaaaaaaaaZ" are compared, the comparison algorithm scans through the block of "a" before it determines the strings are unequal.
Suppose an attacker wants to break into an on-line system that rate limits authentication attempts to one attempt per second. Also suppose the attacker knows all of the parameters to the password hash (salt, hash type, etc), except for the hash and (obviously) the password. If the attacker can get a precise measurement of how long it takes the on-line system to compare the hash of the real password with the hash of a password the attacker provides, he can use the timing attack to extract part of the hash and crack it using an offline attack, bypassing the system's rate limiting.
First, the attacker finds 256 strings whose hashes begin with every possible byte. He sends each string to the on-line system, recording the amount of time it takes the system to respond. The string that takes the longest will be the one whose hash's first byte matches the real hash's first byte. The attacker now knows the first byte, and can continue the attack in a similar manner on the second byte, then the third, and so on. Once the attacker knows enough of the hash, he can use his own hardware to crack it, without being rate limited by the system.
It might seem like it would be impossible to run a timing attack over a network. However, it has been done, and has been shown to be practical. That's why the code on this page compares strings in a way that takes the same amount of time no matter how much of the strings match.
How does the SlowEquals code work?
The previous question explains why SlowEquals is necessary, this one explains how the code actually works.
1. private static boolean slowEquals(byte[] a, byte[] b)
2. {
3. int diff = a.length ^ b.length;
4. for(int i = 0; i < a.length && i < b.length; i++)
5. diff |= a[i] ^ b[i];
6. return diff == 0;
7. }
The code uses the XOR "^" operator to compare integers for equality, instead of the "==" operator. The reason why is explained below. The result of XORing two integers will be zero if and only if they are exactly the same. This is because 0 XOR 0 = 0, 1 XOR 1 = 0, 0 XOR 1 = 1, 1 XOR 0 = 1. If we apply that to all the bits in both integers, the result will be zero only if all the bits matched.
So, in the first line, if
a.lengthis equal tob.length, the diff variable will get a zero value, but if not, it will get some non-zero value. Next, we compare the bytes using XOR, and OR the result into diff. This will set diff to a non-zero value if the bytes differ. Because ORing never un-sets bits, the only way diff will be zero at the end of the loop is if it was zero before the loop began (a.length == b.length) and all of the bytes in the two arrays match (none of the XORs resulted in a non-zero value).The reason we need to use XOR instead of the "==" operator to compare integers is that "==" is usually translated/compiled/interpreted as a branch. For example, the C code "
diff &= a == b" might compile to the following x86 assembly:MOV EAX, [A]
CMP [B], EAX
JZ equal
JMP done
equal:
AND [VALID], 1
done:
AND [VALID], 0
The branching makes the code execute in a different amount of time depending on the equality of the integers and the CPU's internal branch prediction state.
The C code "
diff |= a ^ b" should compile to something like the following, whose execution time does not depend on the equality of the integers:MOV EAX, [A]
XOR EAX, [B]
OR [DIFF], EAX
Why bother hashing?
Your users are entering their password into your website. They are trusting you with their security. If your database gets hacked, and your users' passwords are unprotected, then malicious hackers can use those passwords to compromise your users' accounts on other websites and services (most people use the same password everywhere). It's not just your security that's at risk, it's your users'. You are responsible for your users' security.
================================================ FILE: src/pages/home.php ================================================ . */ mb_language('uni'); mb_internal_encoding('UTF-8'); require_once('libs/recaptchalib.php'); require_once('libs/CrackHashes.php'); require_once('/storage/creds.php'); // Copied from: https://stackoverflow.com/a/30749288 function checkReCAPTCHA() { try { $url = 'https://www.google.com/recaptcha/api/siteverify'; $creds = Creds::getCredentials("timecapsule_recaptcha"); $data = ['secret' => $creds[C_PASS], 'response' => $_POST['g-recaptcha-response'], 'remoteip' => $_SERVER['REMOTE_ADDR']]; $options = [ 'http' => [ 'header' => "Content-type: application/x-www-form-urlencoded\r\n", 'method' => 'POST', 'content' => http_build_query($data) ] ]; $context = stream_context_create($options); $result = file_get_contents($url, false, $context); return json_decode($result)->success; } catch (Exception $e) { return null; } } if(isset($_GET['p'])) { header("HTTP/1.1 301 Moved Permanently"); header("Location: http://crackstation.net/"); } function trim_value(&$value) { $value = trim($value); $value = trim($value, "*"); // For MySQL 4.1+ hashes } ?>Article written by Defuse Security.
Free Password Hash Cracker
Enter up to 20 non-salted hashes, one per line:
Supports: LM, NTLM, md2, md4, md5, md5(md5_hex), md5-half, sha1, sha224, sha256, sha384, sha512, ripeMD160, whirlpool, MySQL 4.1+ (sha1(sha1_bin)), QubesV3.1BackupDefaults
Please enter 20 or less hashes. "; } } else { echo "Incorrect captcha. Please try again.
"; } } ?>How CrackStation Works
CrackStation uses massive pre-computed lookup tables to crack password hashes. These tables store a mapping between the hash of a password, and the correct password for that hash. The hash values are indexed so that it is possible to quickly search the database for a given hash. If the hash is present in the database, the password can be recovered in a fraction of a second. This only works for "unsalted" hashes. For information on password hashing systems that are not vulnerable to pre-computed lookup tables, see our hashing security page.
Crackstation's lookup tables were created by extracting every word from the Wikipedia databases and adding with every password list we could find. We also applied intelligent word mangling (brute force hybrid) to our wordlists to make them much more effective. For MD5 and SHA1 hashes, we have a 190GB, 15-billion-entry lookup table, and for other hashes, we have a 19GB 1.5-billion-entry lookup table.
You can download CrackStation's dictionaries here, and the lookup table implementation (PHP and C) is available here.
================================================ FILE: src/pages/legal-privacy.php ================================================CrackStation's Terms of Service and Privacy Policy
Terms of Service
CrackStation's main goal is to promote the use of properly implemented salted hashing in new and existing web applications. We provide this service to help security researchers demonstrate the importance of hash salting. Any users that choose to use CrackStation as a malicious tool are solely responsible for their own actions. We do not ask where our clients get their hashes, so we are unable to help any law enforcement agency.
Privacy Policy
CrackStation respects the privacy of its users. Your IP address and web browser information may be logged as you request web pages from this site, but we do not sell that information or share that information with anyone. We DO NOT log the hashes that you crack. However, you should still not try to crack the hash of your own password or other sensitive information, since your connection might be being intercepted by the NSA.
================================================ FILE: src/pages/thank-you.php ================================================THANKS!
You just bought the CrackStation wordlist. Thank you VERY much for your support!
If you haven't downloaded the wordlist yet, see step 2.
If you have any questions or concerns, please contact me.
================================================ FILE: src/robots.txt ================================================ User-agent: * Disallow: /tor-mirror/